Development boards for iterative development

[e100]

(I've only used one microcontroller type so I'm not sure if this is a sensible question or not)

When it comes to iterative development are there any boards or developer tool features that ease the pain of the repetitive edit/upload/run cycle?
I'm thinking of those projects where you are the customer, and at the beginning you only have a vague idea of the project goals. Typically after months of work you have something that kind of works but you have locked yourself into something that is hard to modify, so you decide to scrap the code and start from scratch as you now have a better understanding of the requirements, the limitations of the microcontroller and the hardware you are interfacing with.

[lollandster]

I like the NUCLEO-F446RE board. It is Mbed compatible so I can do a quick and dirty proof of concept if necessary. I can then move onto building the software in low level using the built in debugger (the built in ST-Link is supported by many IDEs). The clock speed can be adjusted to simulate a weaker target (hardware FPU can also be turned off). I put all the board specific code in its own class. When I get the target board I just have to adjust the board specific class and everything should continue to work.
Something like the NUCLEO-F767ZI will give you even more headroom, but at a higher price.
This is based on my very limited experience though.

EDIT: As for the repetitive edit/upload/run cycle; J-Link, ST-Link, CMSIS-DAP and Stellaris ICDI are all very fast and support debugging with breakpoints and step-by-step execution. If you get a board with one of those you should be good. Mbed support is helpful if you come from Arduino, but I recommend quickly moving to something that support real debugging.

[ajb]

Typically after months of work you have something that kind of works but you have locked yourself into something that is hard to modify, so you decide to scrap the code and start from scratch as you now have a better understanding of the requirements, the limitations of the microcontroller and the hardware you are interfacing with.

Even with poorly defined requirements, it's possible to write code that supports iterative development.  Avoiding excessive coupling between functional units, for example.  A lot of it comes with experience, especially with writing reusable libraries.  You learn how to localize dependencies, and how to decide whether those dependencies should be resolved at link time or dynamically (via callbacks, pointers to driver functions, or OOP), and in either case how to make sure the interface between functional units is clean and maintainable.  You'll still run into situations occasionally that you didn't anticipate in a library, but you revise it and move on.  It's a good idea to write anything that you are likely to reuse as a library, as it means you have that much less to write next time and can get a basic implementation of an idea up and running with minimal investment.

If you're running into hardware issues, perhaps because the way that certain hardware features interact isn't clear, well, that's what prototypes are for.  Cheap dev boards are great, as long as you can localize your testing to functionality the dev boards support.  Sometimes that isn't possible, and you'll need to design a plug-in board for a dev board, or even a minimal custom PCB.  Sometimes you still run into issues and have to re-spin a production board, you do your best to avoid that, but it happens. 

As far as the actual edit/compile/upload/test cycle, you can speed up the editing phase with a good IDE and well-designed application, the compile phase with a well organized project (keeping the dependency tree simple so that the impact of each changed file is minimized), the upload phase really depends on the debug tool and the memory size (J-Link probes are noticeably faster than STLinks, in my experience), and the test phase comes back to a well-designed application where side effects are minimized and the application state is clearly understood.

[andersm]

Having good automated test coverage can be very helpful, giving you confidence your changes don't have unintended side-effects elsewhere. The techniques used for writing testable code have the added bonus of making it easier to modify.

[HB9EVI]

I guess it's both - a hardware and software issue.
I learned to like the Nucleo boards, like the 446RE as quite handy for many purposes. Already from my beginning Pic times to AVRs I programmed a bunch of standard functions for LCDs, TFTs, rotary encodes, ADCs, DACs a.s.o. which I ported to STM32. It's really handy to just include a header file and focus on there real objectives of a project.

[Fire Doger]

The key is to write scale-able code from the beginning. I love having different files for even very small parts of the project, this may be hard to handle on some IDE's tho...
Having every part separated its much easier to rebase the core, state machines, etc...

Use the best hardware debugger.

You may also use external editor like VS code to write the code if IDE editor is from 90s, and use IDE only for compile-debug...

Learn different mcu families before so you have an idea before using it in a big project...

Avoid customers who don't know what the f the want....