Hello,
Referring to this post
http://www.keil.com/forum/59779/
Maybe it is time to remove the simulator from uv5 to prevent confusion...?
I tend to stay away from third party drivers and middleware as much as I can.
Yes PCB manufacturing can be quite quick, but I can start working on the software from very, very preliminary schematics, i.e. well before there are any layout to send out for ordering of any PCB.
For testing code on a systems level, I have done a bit of work with posix threads and sockets or shared memory - so a separate program or some additional threads have represented the outside world. So the "microcontroller software" adds SPI data to a send queue and a different thread picks up the data, decodes and sends back responses. This makes it easy to perform repeatable tests. In some situations, I have written GUI software displaying a graphical keypad etc.
What remains for the actual hardware is to verify actual load + timing - the PC simulation can't detect if there will be FIFO overruns on the real hardware or how many percent of the processor capacity that will be consumed by ISR code.
Also, I need to verify on real hardware that I haven't misunderstood the register descriptions for the peripheral hardware.
"you evidently only work with hardware that has complete and accurate specificatins"
This can be a significant issue.
I had one project where I implemented the full software in N hours. Then I had to spend 5*N hours to implement workarounds for bugs in the middleware. When reporting bugs, the company in question claimed there were no bugs - even when supplied with test code repeatable showing failures.
Then when middleware 3.0 or maybe 4.0 was released, I noticed that trace output indicated that the workarounds did not trig anymore - so I could spend two days removing workaround after workaround. The middleware without bugs had suddenly started to function as their documentation claimed - but without any release document ever admitting to any fixes. All I know is that the company who developed the middleware had got at least one new developer on their team - I can only guess that this was the magical difference.
Anyway - all methods of simulation are good. Options are always good.
Options are always good. exactly.
I 'never' use the simulator, but if I have some heavy crunching non-I/O stuff, I do. I 'never' use printf debug, but when there is an issue that show up once a month at a customer site, I stick in a printf so the customer can report I 'never' ... ,but...
I'm actually using printf() debugging a lot.
I get information without stopping any real-time code and wrecking the interaction with timed operations.
And I normally always have enough CPU cycles and flash space that I can ship with trace functionality in place. Some few lines always enabled. Some possible to turn on/off on command.
It's nice to be able to sign in to a live unit out in the field and look at performance statistics etc.
Printouts might be very much 1980 but they just happen to work very well. It's often enough with a very minor hint to be able to visualize what a unit is doing and why. Especially since most issues tends to be caused by incorrect configurations.
Or we know what the hardware does, and can validate and test enough that a ROM'd boot loader is actually going to function out of the gate, or the library functions do what they are supposed to on any ARM7, ARM9 or CM3, etc.
The idea that the software devs get to *** around and cause the SoC IP to be respun multiple times is alien, yes.
Perhaps you should focus on why your documentation is incomplete and inaccurate.