Well I was using "wait-state" loosely...it does appear to have
a similar effect. Anyway your interpretation of the two figures
makes sense, but I'm sure we could collect 10 people and get at
least 5 answers...The key for me is that the block diagram shows
no direct path between the Flash mem and the data bus, so there
must be some-other-magic that needs to happen in between, and
magic isn't free.
MS

Robert Szewczyk wrote:
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
>>

_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Reply via email to