(at the risk of being wrong again....)
I'd say yes, it's (almost) that simple.
But make sure you are counting instruction
clock CYCLES not just instructions. And if
there are branches, they take a different
number of cycles for true/false so it's
not quite that easy...
MS
Artur Skrajnowski wrote:
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] <mailto:[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]
<mailto:[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
<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]
<mailto:[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]
<mailto:[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]>
> >> > > <mailto: [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]>
> >> > > <mailto: [email protected]
<mailto:[email protected]>>
> >> > > >
> >> > >
> >>
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
<https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help>
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > Pozdrawiam
> >> > > Artur Skrajnowski
> >> > > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
<mailto: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
> >> >
> >>
> >>
> >>
> >> --
> >> Pozdrawiam
> >> Artur Skrajnowski
> >> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
> >> _______________________________________________
> >> 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]>
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
