RE: [Tinyos-help] how to display signed data in oscilloscope app(TinyOS 2.x)
Dear Micheal,
First of all, thanks for your interest.
I listed my actions below in T2;
1. I modified nx_int16_t line of oscilloscope.h
typedef nx_struct oscilloscope {
nx_uint16_t version; /* Version of the interval. */
nx_uint16_t interval; /* Samping period. */
nx_uint16_t id; /* Mote id of sending mote. */
nx_uint16_t count; /* The readings are samples count * NREADINGS
onwards */
nx_int16_t readings[NREADINGS];
} oscilloscope_t;
#endif
2. I ran make clean in apps/oscilloscope/java
3. Then make command is run. But it gives me the error attached.
[EMAIL PROTECTED] /cygdrive/c/cygwin/opt/tinyos-2.x/apps/Oscilloscope/java
$ make
mig -target=null -java-classname=OscilloscopeMsg java ../Oscilloscope.h
oscillos
cope -o OscilloscopeMsg.java
ncg -target=null -java-classname=Constants java ../Oscilloscope.h
NREADINGS DEFA
ULT_INTERVAL -o Constants.java
javac *.java
Oscilloscope.java:71: update(int,int,int[]) in Data cannot be applied to
(int,in
t,short[])
data.update(omsg.get_id(), omsg.get_count(),
omsg.get_readings());
^
Note: Window.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 error
make: *** [Oscilloscope.class] Error 1
NOTE: In default oscilloscope app it samples ADC, but i modified the app
that it communicates with sensor via SPI. But the reading data is
signed.
Have a nice day,
Firat TARAKTAS
ElectricalElectronics Engineer
Reseracher
GENETLAB INFORMATION TECHNOLOGIES
Kayisdagi Caddesi Kar Plaza D Blok Kat:3 34752 Icerenkoy / ISTANBUL /
TURKIYE
Phone: +90 (216) 573 00 85 (int.354)
Fax: +90 (216) 469 85 07
[EMAIL PROTECTED]
www.genetlab.com
-Original Message-
From: Michael Schippling [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 16, 2007 7:02 PM
To: Firat TARAKTAS
Cc: tinyos-help@Millennium.Berkeley.EDU
Subject: Re: [Tinyos-help] how to display signed data in oscilloscope
app(TinyOS 2.x)
It may be that the nx implementation is not complete on the Java side.
Without seeing the error and the code it's hard to tell. Can you post
the relevant oscope and message code, and the actual error text?
MS
Firat TARAKTAS wrote:
Hi to all,
My problem is to display the signed data in oscilloscope application
in TinyOS 2.x?
In TinyOS 1.x, modifying apps/oscilloscope/OscopeMsg.h *uint16_t
data[BUFFER_SIZE] *as *int16_t data[BUFFER_SIZE] *and recompiling java
tools solved my problem.
But in TinyOS 2.x, I modifed apps/oscilloscope/oscilloscope.h file
*nx_uint16_t readings[NREADINGS] *line as* nx_int16_t
readings[NREADINGS] *and recompile java files in
apps/oscilloscope/java folder. But it gives an error in line 71 of
oscilloscope.java.
I will be glad if you help me.
Have a nice day.
Firat TARAKTAS
ElectricalElectronics Engineer
Reseracher
*GENETLAB INFORMATION TECHNOLOGIES**
*Kayisdagi Caddesi Kar Plaza D Blok Kat:3 34752 Icerenkoy / ISTANBUL /
TURKIYE
Phone: +90 (216) 573 00 85 (int.354)
Fax: +90 (216) 469 85 07
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
www.genetlab.com http://www.genetlab.com/
--
--
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-h
elp
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] how to display signed data in oscilloscope app(TinyOS 2.x)
looks like nx_int16_t is defined as a short (int)
and Java don't know from shorts...this may be a bug
in the T2 mig impl vis the nx types. The error is
kind of weird as I would have thought it would complain
about short not being defined anywhere...but who knows.
The Java update() method, as defined in whatever data is,
wants to get an array of ints, but somehow get_readings()
is defined to return an array of shorts, a type that doesn't
exist in Java. Looks like fun. You might be able to finesse
the issue by editing the mig generated message file.
MS
Firat TARAKTAS wrote:
Dear Micheal,
First of all, thanks for your interest.
I listed my actions below in T2;
1. I modified nx_int16_t line of oscilloscope.h
typedef nx_struct oscilloscope {
nx_uint16_t version; /* Version of the interval. */
nx_uint16_t interval; /* Samping period. */
nx_uint16_t id; /* Mote id of sending mote. */
nx_uint16_t count; /* The readings are samples count * NREADINGS
onwards */
nx_int16_t readings[NREADINGS];
} oscilloscope_t;
#endif
2. I ran make clean in apps/oscilloscope/java
3. Then make command is run. But it gives me the error attached.
[EMAIL PROTECTED] /cygdrive/c/cygwin/opt/tinyos-2.x/apps/Oscilloscope/java
$ make
mig -target=null -java-classname=OscilloscopeMsg java ../Oscilloscope.h
oscillos
cope -o OscilloscopeMsg.java
ncg -target=null -java-classname=Constants java ../Oscilloscope.h
NREADINGS DEFA
ULT_INTERVAL -o Constants.java
javac *.java
Oscilloscope.java:71: update(int,int,int[]) in Data cannot be applied to
(int,in
t,short[])
data.update(omsg.get_id(), omsg.get_count(),
omsg.get_readings());
^
Note: Window.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 error
make: *** [Oscilloscope.class] Error 1
NOTE: In default oscilloscope app it samples ADC, but i modified the app
that it communicates with sensor via SPI. But the reading data is
signed.
Have a nice day,
Firat TARAKTAS
ElectricalElectronics Engineer
Reseracher
GENETLAB INFORMATION TECHNOLOGIES
Kayisdagi Caddesi Kar Plaza D Blok Kat:3 34752 Icerenkoy / ISTANBUL /
TURKIYE
Phone: +90 (216) 573 00 85 (int.354)
Fax: +90 (216) 469 85 07
[EMAIL PROTECTED]
www.genetlab.com
-Original Message-
From: Michael Schippling [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 16, 2007 7:02 PM
To: Firat TARAKTAS
Cc: tinyos-help@Millennium.Berkeley.EDU
Subject: Re: [Tinyos-help] how to display signed data in oscilloscope
app(TinyOS 2.x)
It may be that the nx implementation is not complete on the Java side.
Without seeing the error and the code it's hard to tell. Can you post
the relevant oscope and message code, and the actual error text?
MS
Firat TARAKTAS wrote:
Hi to all,
My problem is to display the signed data in oscilloscope application
in TinyOS 2.x?
In TinyOS 1.x, modifying apps/oscilloscope/OscopeMsg.h *uint16_t
data[BUFFER_SIZE] *as *int16_t data[BUFFER_SIZE] *and recompiling java
tools solved my problem.
But in TinyOS 2.x, I modifed apps/oscilloscope/oscilloscope.h file
*nx_uint16_t readings[NREADINGS] *line as* nx_int16_t
readings[NREADINGS] *and recompile java files in
apps/oscilloscope/java folder. But it gives an error in line 71 of
oscilloscope.java.
I will be glad if you help me.
Have a nice day.
Firat TARAKTAS
ElectricalElectronics Engineer
Reseracher
*GENETLAB INFORMATION TECHNOLOGIES**
*Kayisdagi Caddesi Kar Plaza D Blok Kat:3 34752 Icerenkoy / ISTANBUL /
TURKIYE
Phone: +90 (216) 573 00 85 (int.354)
Fax: +90 (216) 469 85 07
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
www.genetlab.com http://www.genetlab.com/
--
--
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-h
elp
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] How to debug the send message ?
I don't understand the relationship between send() and receive() here
but it's possible that the intermediate put() fails because the UART
is busy. I think put() just starts a uart xmit, and like the radio
send() you need to wait for a done() before successfully posting
another char.
MS
liangjing wrote:
Hi all,
I encountered a problem when debugging the send message. I use the
UART to give me the debugging information. In my application, I start
a timer to send the message repeatly, and when the timer is fired, I
send the message out. Now, I insert two debugging sentences to send
number to UART. My send code is below,
call HPLUART.put(0x06);
call CC1100Control.send( (uint8_t *)cm, CONTROL_MSG_LENGTH+1);
call HPLUART.put(0x07);
I could receive 0x06 and 0x07 on my PC. But I am not sure the
CC1100Control.send is implemented correctly, because in my receive
section, I don't the debugging number I expected. My receive code is
below,
event result_t CC1100Control.receive(uint8_t *t)
{
call HPLUART.put(0x02);
}
I don't get 0x02 on my PC. Is anything wrong ? Any advice is appreciated.
Best Regards
Jing
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] need help
i'm doing my final project but i have some trouble. i'm making wireless sensors. i'm using cc1000 and AVR ATMega 8 or 16 to make my final project. These are my trouble n i need: 1.layout of PCB AVR+cc1000. 2.the library of cc1000 from codevision. 3.Schematics of RF Modem. i have found some PCB layout but not for AVR ATMega 8 or 16. they are all for PIC. i really need your help n i will very thanks for your help. thanks. regards Roby __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Ubuntu 7.04 packages?
Edgy packages work on feisty. You just have to install udev. Have a look at the archives. On 5/18/07, Micfox Micfox [EMAIL PROTECTED] wrote: I think you can install tinyos from source code(checkout the source code from CVS), which is Ubuntu-version independent. The relevant installation guide can be found on the following link: http://www.5secondfuse.com/tinyos/oldInstall.html From: leith [EMAIL PROTECTED] To: tinyos-help@Millennium.Berkeley.EDU CC: Justin Dugger [EMAIL PROTECTED] Subject: Re: [Tinyos-help] Ubuntu 7.04 packages? Date: Thu, 17 May 2007 09:23:07 -0700 i'll push out feisty packages sometime next week. however, the edgy packages do work on feisty, though you might have some trouble connecting ttyUSB0. search the archives for the solution to that. -leith Justin Dugger wrote: It's been about a month since 7.04 was released. Are there any plans to open a feisty repo for the tinyOS tools? I don't think I'm subscribed to the list so please CC me. Justin Dugger ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help _ 享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] MICA2 ROM/RAM access times
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
Tinyos-help@Millennium.Berkeley.EDU
mailto:Tinyos-help@Millennium.Berkeley.EDU
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
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] assigning a unsized array
Hi,
I have made a TLV packet with the following declaration :
typedef nx_struct sensing_msg {
nx_uint8_t flags;
nx_uint8_t length;
nx_uint8_t value[];
} sensing_msg_t;
I used [] instead of a pointer, because I need to mig the packet in
java and a pointer won't work. In my nesC application, when I receive
the packet, I would like to avoid a copy of the payload, so I naïvely
tried :
sensing_msg_t * sm = payload;
But of course It does not work, payload[2] is assigned to value, not value[0].
So I tried then :
sm-value = payload + 2
But this does not compile, even if I cast value into a pointer.
Am I obliged to copy the payload here, or is there another trick I
didn't think of ?
Thanks for your help,
Romain
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Re: assigning a unsized array
Actually, the copy does not work either.
When I access sm-value[1] at different times, it seems to have random
values, I guess I'm accessing the data of some other component.
I quite clueless now...
Romain
On 5/18/07, Romain Thouvenin [EMAIL PROTECTED] wrote:
Hi,
I have made a TLV packet with the following declaration :
typedef nx_struct sensing_msg {
nx_uint8_t flags;
nx_uint8_t length;
nx_uint8_t value[];
} sensing_msg_t;
I used [] instead of a pointer, because I need to mig the packet in
java and a pointer won't work. In my nesC application, when I receive
the packet, I would like to avoid a copy of the payload, so I naïvely
tried :
sensing_msg_t * sm = payload;
But of course It does not work, payload[2] is assigned to value, not value[0].
So I tried then :
sm-value = payload + 2
But this does not compile, even if I cast value into a pointer.
Am I obliged to copy the payload here, or is there another trick I
didn't think of ?
Thanks for your help,
Romain
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] questions on the interface CC2420Packet
You can use CC2420Control.setRFpower. On 5/18/2007, Shuo Xiao [EMAIL PROTECTED] wrote: Hi all, I tried to use the command CC2420Packet.getPower to get the current transmission power, and the application wires the component CC2420PacketC. But why the data I got is 0, not the default tx power 31? And how to use the command CC2420Packet.setPower? Thanks for your help. Shuo _ Advertisement: 1000s of Sexy Singles online now at Lavalife - Click here http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Flavalife9%2Eninemsn%2Ecom%2Eau%2Fclickthru%2Fclickthru%2Eact%3Fid%3Dninemsn%26context%3Dan99%26locale%3Den%5FAU%26a%3D27782_t=762255081_r=lavalife_may07_1000sexysingles_m=EXT ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] questions on the interface CC2420Packet
On May 17, 2007, at 9:50 PM, Shuo Xiao wrote: Hi all, I tried to use the command CC2420Packet.getPower to get the current transmission power, and the application wires the component CC2420PacketC. But why the data I got is 0, not the default tx power 31? And how to use the command CC2420Packet.setPower? 0 means default power level. Phil ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Re: assigning a unsized array
unfortunately
nx_uint8_t value[];
is just another way to say
nx_uint8_t *value;
The packet definition must contain the actual data because
the lower levels treat the message as a single char array.
When you do the assignment, whatever is at payload[2] and [3]
is treated as a pointer, probably into space...especially on
the receiving end because it will be pointing to something
in the transmitter's memory.
I'm not sure where the copy you are trying to avoid is,
so I can't be of much more help...
MS
Romain Thouvenin wrote:
Actually, the copy does not work either.
When I access sm-value[1] at different times, it seems to have random
values, I guess I'm accessing the data of some other component.
I quite clueless now...
Romain
On 5/18/07, Romain Thouvenin [EMAIL PROTECTED] wrote:
Hi,
I have made a TLV packet with the following declaration :
typedef nx_struct sensing_msg {
nx_uint8_t flags;
nx_uint8_t length;
nx_uint8_t value[];
} sensing_msg_t;
I used [] instead of a pointer, because I need to mig the packet in
java and a pointer won't work. In my nesC application, when I receive
the packet, I would like to avoid a copy of the payload, so I naïvely
tried :
sensing_msg_t * sm = payload;
But of course It does not work, payload[2] is assigned to value, not
value[0].
So I tried then :
sm-value = payload + 2
But this does not compile, even if I cast value into a pointer.
Am I obliged to copy the payload here, or is there another trick I
didn't think of ?
Thanks for your help,
Romain
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] Re: assigning a unsized array
Actually, there was a stupid mistake in my code where I access the
data. With the mistake fixed, it works!
I mean this works:
receive(message_t * msg, void * payload, uint8_t length){
sensing_msg_t * sm = payload;
do_something_with(sm-value[0]);
...
}
I have to say I don't really understand why...
Does the nesc (or C) compiler recognize the uint8_t[] and
automatically put copy instructions ? Or better, does it set the value
of codevalue/code with payload+2bytes ?
Anyway, thanks for your reply Michael.
Romain
On 5/18/07, Michael Schippling [EMAIL PROTECTED] wrote:
unfortunately
nx_uint8_t value[];
is just another way to say
nx_uint8_t *value;
The packet definition must contain the actual data because
the lower levels treat the message as a single char array.
When you do the assignment, whatever is at payload[2] and [3]
is treated as a pointer, probably into space...especially on
the receiving end because it will be pointing to something
in the transmitter's memory.
I'm not sure where the copy you are trying to avoid is,
so I can't be of much more help...
MS
Romain Thouvenin wrote:
Actually, the copy does not work either.
When I access sm-value[1] at different times, it seems to have random
values, I guess I'm accessing the data of some other component.
I quite clueless now...
Romain
On 5/18/07, Romain Thouvenin [EMAIL PROTECTED] wrote:
Hi,
I have made a TLV packet with the following declaration :
typedef nx_struct sensing_msg {
nx_uint8_t flags;
nx_uint8_t length;
nx_uint8_t value[];
} sensing_msg_t;
I used [] instead of a pointer, because I need to mig the packet in
java and a pointer won't work. In my nesC application, when I receive
the packet, I would like to avoid a copy of the payload, so I naïvely
tried :
sensing_msg_t * sm = payload;
But of course It does not work, payload[2] is assigned to value, not
value[0].
So I tried then :
sm-value = payload + 2
But this does not compile, even if I cast value into a pointer.
Am I obliged to copy the payload here, or is there another trick I
didn't think of ?
Thanks for your help,
Romain
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] Simulators for Micaz--Plz help
Hi All,I am searching for simulator for energy consumption in MicaZ,but i can\'t find one.I also can\'t find energy model for MicaZ in Avrora,PowerTOSSIM.Does ns-2,omnett++ simulate energy consumption for any application in MicaZ( as micaZ uses CC2420 chip).I also tried nesct in Omnet++ without MF,it gives some battery consumednbsp; voltage.But will that suit for MicaZ hardware.Atlast what all i need is a simulator that simulate power consumption in any applicatiion(Blink or SenseToRfm or SenseToLog) in MicaZ.Dows Any simulator is there for MicaZ energy Consumption.Plz Help Me.I am trying this for a very long Time.Thanks in Advance Sang___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] MICA2 ROM/RAM access times
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
Tinyos-help@Millennium.Berkeley.EDU
mailto: Tinyos-help@Millennium.Berkeley.EDU
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
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] MICA2 ROM/RAM access times
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
Tinyos-help@Millennium.Berkeley.EDU
mailto: Tinyos-help@Millennium.Berkeley.EDU
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
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] MICA2 ROM/RAM access times
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/800 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
Tinyos-help@Millennium.Berkeley.EDU
mailto: Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
--
Pozdrawiam
Artur Skrajnowski
[EMAIL PROTECTED] mailto:
Re: [Tinyos-help] MICA2 ROM/RAM access times
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
Tinyos-help@Millennium.Berkeley.EDU
mailto: Tinyos-help@Millennium.Berkeley.EDU
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
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
[Tinyos-help] CC1000 radio stack in TOSSIM
Hello, We've tried using the CC1000 radio stack ported by Victor Shnayder from Harvard, for TOSSIM. We are using TinyOS 1.15, and have also tried the latest version of the code from the TinyOS1.x CVS. According to the instructions at http://www.eecs.harvard.edu/~shnayder/ptossim/install.html, we added PFLAGS += -I%T/platform/pc/CC1000Radio to the Makefile, but this resulted in a compilation error relating to an array, radio_power_off, not being declared in the file tos/platform/pc/CC1000Radio/CC1000ControlM.nc. It appeared that this array is declared and written to by another file in the same directory (rfm_model.c), but is not actually read anywhere. So we reluctantly commented it out, and compilation was successful. I am not however convinced that this course of action will lead to correct behaviour of the CC1000 radio. Does anyone have any idea why it might be happening? Is there any additional wiring I need to do? I only interact with the radio using GenericComm, and therefore I have wired the SendMsg[], ReceiveMsg[] and StdControl from my main application component to GenericComm. Thanks in advance Ixent ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] MICA2 ROM/RAM access times
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
Tinyos-help@Millennium.Berkeley.EDU
mailto: Tinyos-help@Millennium.Berkeley.EDU
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
Re: [Tinyos-help] MICA2 ROM/RAM access times
(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/800 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:
[Tinyos-help] Time Synchronization using NetSync
Hi all, I want to use NetSync to provide time synchronization in the Delta app code for Tmotes at full power. In the NetSyncC file it says, never to wire to it but instead use make tmote lowpower. So, when I compile using make tmote lowpower not providing the duty cycle value there but changing the default NETSYNC_DUTYCYCLE value from 5 to 100 hoping to get the desired effect. Will doing this suffice or would it adversely affect the nodes? Thanks, Ankur ___ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
