How seriously do you use the UV4 simulator?

Do any of you use the simulator to model your whole embedded application to test things prior to having any hardware? That's what the documentation suggests, just wondering if anybody is using it extensively.
the problem with a simulator is that it simulates.
e.g. did you get an I/O clock running?, I guess it makes no difference to the simulator.
is your I/O pulse wide enough?, I guess it makes no difference to the simulator.

maybe my "simulator aversion" is because, in a group I'm usually "the I/O guy" I guess the "algorithm guy" could use the simulator with benefit.

anyhow, due to my dislike of simulators for the above reasons, I also do not use it when I happen to be the "algorithm guy".

While waiting for a uLink ME to arrive
most of us wait max 3 days for that, I do not understand the problem

Erik

For the most part, I have simulated most of the machines our controllers go on. It may take some work to get the simulator scripts working and tested but for us it is worth the effort as we can't just pause the machine. Some PCB components may be difficult/ complex to simulate such as SPI chips with many registers but there are probably reasonable alternatives to a massive script such as disabling SPI communication and writing program variables from the script.

Programming the simulator has it's learning curves. Expect some differences to the real chip. It has quite a bit of power in that you can directly interact with program variables. This allows you to configure aspects of your simulated system based upon calibration data therefore reducing how much you configure the simulator.

Hopefully your CPU has good simulation support. Keil has decided not to support simulating as much.

Some benefits to simulating:
1) the simulator pauses during debugging.
2) you can easily change or disable items in the simulator that may be very difficult to do in the real world
3) you can test the software before having real hardware.
4) you can sit in a comfy quiet office and get work done rather than being in a hostile environment.
5) There are many conditions that are easy to simulate but difficult or dangerous to do in the world.
6) You **might** be able to add RAM / ROM to the simulated uC if needed. Reasons for this could be test code or low optimization settings eating memory.
7) single stepping is very fast.

Some problems:
1) the simulator may have bugs for your particular uC
2) the simulator may bog down or be too slow.
3) you need to write the simulation scripts for your PCB / machine ... another thing to write and debug.
4) communication with other controllers is difficult and / or slow.
5) debugging simulation scripts is somewhat "compile, crash, and burn".

Chad

I test much business logic on a PC. For ARM, it's just 32-bit code expecting to get input and produce output. So I/O can be replaced with stub functions where input is generated or read from a file and output is sent to a file or drives a GUI front end showing the current output state.

For the I/O peripherials, I simulate or emulate depending on need to generate controlled test patterns.

When business logic and driver layer both seems to work, I mainly run on real hardware. Only the real hardware is guaranteed to have the correct timing - exact clock cycles for fetching instructions etc.