Easy way to see PIC MIPS limit?

[ELCouz]

I would like to know what are the best way to test when you are at the limit of the PIC computational power?

I've never run anything that require a lot of processing with a PIC yet.

But in my next project I might hit the PIC MIPS wall...

I have to translate high speed RS232->PIC->I2C to control 16-channels 12-BIT PWM @ 120hz in the lowest latency achievable.

I don't have decided which PIC yet but I do like the 2550 (have few) for it's Internal PLL and versatile use & power (even if I don't use the USB).

What do you do to measure when the pic have trouble keeping the pace?

Using a scope and checking if there are any delays in outputs?
_________________
Regards,
Laurent

-----------
Here's my first visual theme for the CCS C Compiler. Enjoy!

[Ttelmah]

Best way is to work the other way. Work out what part of your code is the 'time limit'. Probably something like how fast you can process the character. Take this part on it's own, and encapsulate it in a minimum 'wrapper', compile this, and then run it in MPLAB SIM. Set a breakpoint at the start of the operation, and another at the end. Run this. Reset the 'stopwatch' function at the start breakpoint. Run to the second. You have an accurate cycle count of just how long this piece of code takes. If this is longer than your code can stand, then you have your answer.
Look also at things like latencies. If (for instance) you have serial arriving at a particular rate, you know the latency of it's interrupt, and how long this takes. So then look at the 'worst case'. What happens if the code has entered another interrupt, exactly at the same cycle as the interrupt event occurs. Unless hardware priorities are being used, the first interrupt has to complete, before the second can be serviced. Is this still acceptable?.

For timing critical code, I'll have a printout of every function, how long it takes, every place where interrupts are disabled highlighted, and a note on what my timing limits are. Then I'll work out what the worst case combinations are.

Other approach is to deliberately 'over-speed' incoming data. If you have to run at 115200bps, write a PC program to send a recorded sample set of real data, at a 20% higher baud rate. Change the expected rate in your PIC code to handle this and see what happens. If anything gives problems, you are approaching the limit. I'd always want my code to have at least a 10% 'margin', that it can handle data faster than it should have to.

Then the 2550, can only go to 48MHz. There are several new PIC18's that support 64MHz. The K and J families have models that do this speed. 33% gain in one go....

[ELCouz]

Thanks Ttelmah for such detailed information!

[Ttelmah]

They are available, 25K22, 26K80 for example.