Thanks guys for all the information and help. I'm happy that the results I got roughly match the 50% overhead You pointed out.
One last thing - this is surely a stupid question but how can one estimate the execution time based on clock cycles ? Suppose I have a block of code which needs 1000 CPU cyles to complete and 8 MHz CPU (as in MICA2). Is my estimated execution time simply 1000 * 1/8000000 sec ? Regards Artur 2007/5/18, Robert Szewczyk <[EMAIL PROTECTED]>:
No hidden wait states, LPM needs to arbitrate with the loading of the regular instruction stream from program memory. If you're looking at atmega 128 datasheet, look at figure 6 and think what happens on the program memory bus. Then, consider what happens when you perform data access like the timining diagram in Figure 10. Rob On 5/18/07, Michael Schippling <[EMAIL PROTECTED]> wrote: > ah ha, so there is a hidden "wait-state"... > I couldn't find any "pipelining diagrams" in the datasheet that > I have but now I see the issue. Looks like one uses LD to get Sram > and LPM to get Flash contents, where LD takes 2 cycles and LPM 3. > So it's not even roughly 50% overhead, it's exactly 50%... > > thanks for the clarification. > MS > > ps...I got lucky in my search, in case anyone else wants the _real_ > AVR instruction set description (rather than the summary) it's here: > > http://www.atmel.com/dyn/resources/prod_documents/doc0856.pdf > > > Robert Szewczyk wrote: > > The difference between flash and RAM accesses stems from the > > architecture of AVR. You can load a byte from RAM on AVR8 into an > > arbitrary register in a two clock cycles. Loading a byte from program > > memory (in your labeling ROM, technically flash) takes 3 cycles, > > because the microcontroller needs to wait for the memory bus to the > > program memory to be available. You can get the details of that from, > > say, AtMega 128 datasheet - look at the instruction set summary, and > > at the pipelining diagrams that explain why the timing is what it is. > > > > Cheers, > > Rob > > On 5/18/07, Artur Skrajnowski <[EMAIL PROTECTED]> wrote: > >> Hi, > >> > >> I managed to use the CPU cycle count from PowerTOSSIM to measure the > >> possible difference. > >> It seems that ROM is roughly about 50% slower. > >> Here are the numbers showing the difference in three of my functions. RAM > >> access was coded with "table[addr]", ROM access was coded with > >> "PRG_RDB()". > >> > >> Function | RAM cycles | ROM cycles > >> f1 | 426 | 666 > >> f2 | 1095 | 2039 > >> f3 | 170 | 278 > >> > >> Regards > >> Artur > >> > >> 2007/5/17, Michael Schippling < [EMAIL PROTECTED]>: > >> > I guess if there's no indication in the manual, > >> > the thing to do would be to compile a couple examples > >> > down to ASM and see if different instructions are used. > >> > As far as I know there are no internal mem access wait-states. > >> > MS > >> > > >> > Artur Skrajnowski wrote: > >> > > I am asking because i stumbled upon this: > >> > > tinyos-1.x\tos\lib\TinySec\SkipJackM.nc, lines 74-80 > >> > > > >> > > "F-BOX > >> > > It can live in either RAM (faster access) or program memory (save > >> ram, > >> > > but slower access). The type CRYPTO_TABLE_TYPE, defined in crypto.h > >> > > defines where we drop the table and how we access it. This is > >> necessary > >> > > to compile for the PC target since it doesn't support tables in > >> program > >> > > memory the same way. > >> > > static const CRYPTO_TABLE_TYPE SJ_F[] = {...}" > >> > > > >> > > The comment seems to imply that there is a performance difference > >> > > between reads from ROM/RAM but I cant find any other info than this. > >> > > > >> > > Help is welcome > >> > > > >> > > Rgds > >> > > Artur > >> > > > >> > > 2007/5/17, Michael Schippling <[EMAIL PROTECTED] > >> > > <mailto:[EMAIL PROTECTED]>>: > >> > > > >> > > A quick review of the ATMEGA manual reveals...nothing... > >> > > I suspect that access times are the same, for reads anyway, > >> > > on both internal memories because instructions seem to take > >> > > the same number of clock cycles. More manual study would > >> > > be indicated however... > >> > > > >> > > MS > >> > > > >> > > Artur Skrajnowski wrote: > >> > > > Hi, > >> > > > > >> > > > Does anyone know the difference in the ROM and RAM memory > >> access > >> > > times > >> > > > for MICA2 in TinyOS? > >> > > > I have a table lookup heavy app and would like to know how > >> > > performance > >> > > > might change if I placed the table in ROM or RAM. > >> > > > Unfortunately I dont a have a mote to test it "live". > >> > > > > >> > > > Any links to docs / articles touching this subject would > >> also be > >> > > apreciated. > >> > > > > >> > > > Thanks for the help. > >> > > > > >> > > > -- > >> > > > Regards > >> > > > Artur Skrajnowski > >> > > > > >> > > > > >> > > > > >> > > > >> ------------------------------------------------------------------------ > >> > > > > >> > > > _______________________________________________ > >> > > > Tinyos-help mailing list > >> > > > [email protected] > >> > > <mailto: [email protected]> > >> > > > > >> > > > >> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > >> > > > >> > > > >> > > > >> > > > >> > > -- > >> > > Pozdrawiam > >> > > Artur Skrajnowski > >> > > [EMAIL PROTECTED] <mailto: [EMAIL PROTECTED]> > >> > > >> > >> > >> > >> -- > >> Pozdrawiam > >> Artur Skrajnowski > >> [EMAIL PROTECTED] > >> _______________________________________________ > >> Tinyos-help mailing list > >> [email protected] > >> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > >> >
-- Pozdrawiam Artur Skrajnowski [EMAIL PROTECTED]
_______________________________________________ Tinyos-help mailing list [email protected] https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
