Comments on: Testing the PIC32 I/O Speed http://blog.flyingpic24.com/2009/03/18/testing-the-pic32-io-speed/ Programming 16 and 32-bit microcontrollers in C. Tue, 07 Feb 2012 23:58:05 +0000 http://wordpress.org/?v=2.2.1 By: pilot http://blog.flyingpic24.com/2009/03/18/testing-the-pic32-io-speed/#comment-239 pilot Sun, 29 Mar 2009 19:55:47 +0000 http://blog.flyingpic24.com/2009/03/18/testing-the-pic32-io-speed/#comment-239 Trying to count and optimize the asm code down the single clock cycle detail gets very complicated very quickly... but let's say that you are on the right track... In fact the branch slot makes use of one clock cycle, while the pre-fetch mechanism attempts to get the (jump target) instruction. If this is within the last 256 bytes fetched (most likely) the cache will hit and there will be no stalling whatsoever... As per MPLAB SIM, there is a very crude attempt at estimating the actual number of cycles, cache included, but the ultimate test of truth is running the code on the REAL ICE and looking at the stopwatch. Trying to count and optimize the asm code down the single clock cycle detail gets very complicated very quickly… but let’s say that you are on the right track… In fact the branch slot makes use of one clock cycle, while the pre-fetch mechanism attempts to get the (jump target) instruction. If this is within the last 256 bytes fetched (most likely) the cache will hit and there will be no stalling whatsoever…
As per MPLAB SIM, there is a very crude attempt at estimating the actual number of cycles, cache included, but the ultimate test of truth is running the code on the REAL ICE and looking at the stopwatch.

]]> By: SevenLegion http://blog.flyingpic24.com/2009/03/18/testing-the-pic32-io-speed/#comment-238 SevenLegion Sun, 29 Mar 2009 19:12:31 +0000 http://blog.flyingpic24.com/2009/03/18/testing-the-pic32-io-speed/#comment-238 Nice done! And it works also like a mini-tutorial to show how to integrate C and assembly + passing parameters. :) By the way, how the MPLAB SIM is accurate in simulating the FLASH waiting states? I'm asking because, for my curiosity, I'm trying to see the waiting states while reading a table from the ROM but it works always as if there wasnt wait states... always 1 cycle to read the ROM... probably I'm wrong somewhere... In your example, if code is located in FLASH the branch works without any cycle lost (tanks to the branch slot) but only if instructions are located in the chache memory. Otherwise the cpu would be stalled for 2 cycles, I presume... I'm wrong? Anyway, if someone wants to use asm code to perform hi-speed bit-toggling, the suggestion would be to alling the code to chache rows in order to keep most instruction inside. Or, better, to relocate the code in RAM, where there are no wait cycles... Nice done!
And it works also like a mini-tutorial to show how to integrate C and assembly + passing parameters. :)

By the way, how the MPLAB SIM is accurate in simulating the FLASH waiting states?
I’m asking because, for my curiosity, I’m trying to see the waiting states while reading a table from the ROM but it works always as if there wasnt wait states… always 1 cycle to read the ROM… probably I’m wrong somewhere…

In your example, if code is located in FLASH the branch works without any cycle lost (tanks to the branch slot) but only if instructions are located in the chache memory.
Otherwise the cpu would be stalled for 2 cycles, I presume…
I’m wrong?

Anyway, if someone wants to use asm code to perform hi-speed bit-toggling, the suggestion would be to alling the code to chache rows in order to keep most instruction inside.
Or, better, to relocate the code in RAM, where there are no wait cycles…

]]>