dhenry:
why bother with the added headache and limitation of simulators?
A lot.
For example, I travel a lot. Blinking leds, naked pcb boards and 7-segment leds are huge attractions going through the various "check points" on my journey. Plus, I do tons of cross-platform development it isn't always feasible to have everything with me.
Thus, simulation is vital to me. And it has been a great productivity enhancer, as long as you understand what they cannot do so you can use them for what they can do.
I think simulators have their place, and many also include or work with some source level debugging
tool but most of the embedded projects I do require talking to actual hardware running
in real time, so a simulator has virtually no value.
Even when I was writing a Windows Phone APP or Android APP, the simulators were of limited
use - I gave up trying to use them and went to running the source level debugger on the real hardware.
I think a much bigger productivity enhancer than a simulator is source level debugging. (gdb is a great tool)
After the low level hardware is debugged (which can't be done on a simulator) most embedded projects
would get much better productivity out of getting the full gnu tools up and working rather than continuing
on with simplistic debugging techniques like blinking LEDs, etc...
Toggling pins and blinking LEDs has their use, I use it quite a bit, hand in hand with a logic analyzer
for low level real time debugging and timing/profiling
but that is generally not the bulk of the type of debugging that needs to be done a project.
Accidental logic errors and race conditions are much more common and those are more easily caught with
source level debugging and breakpoints.
Having source level debugging allows you run in real time and then break under certain
situations and then poke around and look at the state of things.
gdb has been round for more than 20 years so
I'm amazed that I still see so many developers out there, even using gcc, that don't take the up front
time to get acquainted with modern debugging tools
and to get their source level debugging tools in order.
The small amount of time to get it up and going is rapidly returned
over the project.
As far as traveling goes, you can set things up appropriately, so you can source
level debug actual hardware form anywhere in the world.
Back in the late 80's I was debugging firmware on a disk controller in a live system
that was in California while I was in Texas.
I even had access to the host system that was using the disk controller.
It amazing what you can do over an IP session if you set things up.
--- bill