Alternative simulator suggestions - PIC

[augustinetez]

I'm currently using the Oshonsoft PIC simulator for some things but it can be somewhat slow when doing timed loops.

Up to a few mS, it takes a couple of minutes which can be coped with, but doing a 1 second loop (that has to be cycle perfect), it is taking in excess of 30 minutes even at ultimate speed.

Any suggestions for something - anything - faster?

 

[Nigel Goodwin]

Don't simulate loops, or don't simulate at all.

I presume you can set it to avoid loops?

 

[sagor1]

If you set the simulator default "SIMULATION_WAITMS_VALUE = 0", it tends to speed things up. The simulator always shows the elapsed uS regardless of the simulator setting. I also find that if you leave the Basic "editor" showing, it slows things down. Not sure how to get around that except minimize the editor window until you hit a breakpoint. Disable any output/monitor windows, just use the variable listing to check values. Things like the UART output window really slows things down..
I use the "Break" command to stop execution while running Ultimate speed simulation.

I just ran a small simulation that took about 2-3 seconds to run, with serial output window, and simulator showed 23mS execution time.

But none of that is relevant if you are actually trying to measure timed events in the simulator.

 

[Ian Rogers]

I use Proteus... Real time simulation... BUT!!!! comes at a price.

 

[tumbleweed]

MPLAB/MPLABX has a simulator built in, and it's free.

It doesn't simulate peripherals very well sometimes, or external hardware, but for basic algorithm development it usually works ok.

 

[atferrari]

MPSIM has an option to skip routines from CALL to RETURN. F8?

 

[augustinetez]

I think some have missed the "a 1 second loop (that has to be cycle perfect)," bit, so I have to simulate, not bypass - I do the bypass bit when the "timing loop" doesn't go off doing other things.

The current bit of software I'm working on 'must' be exactly 10 million cycles from call to return and this loop incorporates another loop that must be 1 million cycles plus it jumps out and back to another bit that is 11 cycles.

So you can see that it is easier to simulate rather than trying to add it all up on paper (or in your head).

I'll have another look at the MPlab one and see if I can make heads or tails of it - I did try it many years ago without much success.

 

[tumbleweed]

If you're using an "older chip" then MPLAB v8.92 is a lot easier to get going vs the newer MPLABX.

If you go the MPLABX route and need MPASM assembler support, then get MPLABX v5.35.
Newer versions use the new PIC-AS assembler and it's not MPASM compatible.

 

[Buk]

The current bit of software I'm working on 'must' be exactly 10 million cycles from call to return and this loop incorporates another loop that must be 1 million cycles plus it jumps out and back to another bit that is 11 cycles.

So you can see that it is easier to simulate rather than trying to add it all up on paper (or in your head).

Do it in stages.

1) Tune & test your 1M cycle inner loop by calling once, 5x, 10x.

2) Then create an 1K cycle alternative inner loop and test your outer loop calling the short inner to create a delay of 1ms; which will reduce your test runs by 1000x.

Once the outer loop is tuned, substituting the 1M cycle inner loop will produce the delay you want.

 

[atferrari]

I think some have missed the "a 1 second loop (that has to be cycle perfect)," bit, so I have to simulate, not bypass - I do the bypass bit when the "timing loop" doesn't go off doing other things.

The current bit of software I'm working on 'must' be exactly 10 million cycles from call to return and this loop incorporates another loop that must be 1 million cycles plus it jumps out and back to another bit that is 11 cycles.

So you can see that it is easier to simulate rather than trying to add it all up on paper (or in your head).

I'll have another look at the MPlab one and see if I can make heads or tails of it - I did try it many years ago without much success.

All my precisely timed routines were simulated once, for a long list of clock frequencies many years ago.

Since then, I know I can skip them in simulation.

 

[rjenkinsgb]

The current bit of software I'm working on 'must' be exactly 10 million cycles from call to return and this loop incorporates another loop that must be 1 million cycles plus it jumps out and back to another bit that is 11 cycles.

Why software timing, rather than using a timer interrupting at a set rate to give exact intervals?
That's usually vastly more versatile, as program changes do not affect timing and you can de doing other tasks in the meantime, rather than freezng everything.

 

[augustinetez]

Because making an interrupt run the exact number of cycles was doing my head in as the TMR0 interrupt flag is being used within the timing loop as well.

That flag can be tripped at completely different times and any number of times during that 1 second interval.

Plus there is nothing else needing doing until the loop is completed anyway.

If you're using an "older chip" then MPLAB v8.92 is a lot easier to get going vs the newer MPLABX.

Currently yes, doing it on a 16F628A - only because I still have at least two tubes of them to get rid of.

I intend to use something a bit newer at some stage but only up to the point it is within 8.92's list of supported chips.

All my precisely timed routines were simulated once, for a long list of clock frequencies many years ago.

I use PICLoops for timing where it is just that - no jumps out and back into the timing loop - so I don't need to simulate those.

Do it in stages.

I did - 1 million cycle bit first and then the rest, it was the 11 cycle routine that made it fun trying to work it out on paper - at 10MHz timebase, I made that to be 4.4μS but he simulator kept telling me it was 5.6μS.

I just went off and did something else while it was simulating the whole lot in the end, watching numbers tick up gets boring after a while.

 

[Nigel Goodwin]

Why software timing, rather than using a timer interrupting at a set rate to give exact intervals?
That's usually vastly more versatile, as program changes do not affect timing and you can de doing other tasks in the meantime, rather than freezng everything.

If you're writing in assembler you can be accurate with loops to within a single instruction cycle, you can't do that with timers - or at least you can only for certain values.

As the OP has said, as long as you're not wanting to do anything else while the loop is running, it doesn't really matter.