for David Moss: [Tinyos-help] Help with real node behaviour!Micaz,
tinyos 1.x
Munaretto, Daniel
munaretto at docomolab-euro.com
Thu Aug 3 08:07:34 PDT 2006
I have a problem on compiling..i download all useful files but i have a problem about one in particular.
When i compile i have this error:
C;/tinyos/cygwin/opt/tinyos-1.x/tos/platform/mica/PageEEPROMShare.nc:40 'PageEEPROM.computeCrcContinue' not implemented
but it's implemented in PageEEPROMM.nc. If i move this implementation to PageEEPROMShare.nc file, other errors.
I don't understand.
Daniele
-----Original Message-----
From: David Moss [mailto:dmm at rincon.com]
Sent: Wed 8/2/2006 5:22 PM
To: Munaretto, Daniel
Cc: tinyos-help at Millennium.Berkeley.EDU
Subject: RE: for David Moss: [Tinyos-help] Help with real node behaviour!Micaz,tinyos 1.x
I have done a lot of work in this area because my projects require flash.
Flash memory *is* EEPROM. On your micaz you do have 128kB of ROM memory for
your actual binary program on the chip, which you don't have access to.
512kB external flash memory can store data and whatever else you want on,
and 4kB of RAM memory for variables/arrays to run your program.
For simple logging, check out
http://www.tinyos.net/tinyos-1.x/doc/tutorial/lesson8.html This will append
bytes to the flash and allow you to read them back.
It sounds like, because you're copying full buffers into flash for temporary
storage, you may need something a little different than the logging
functionality. It's easier to implement a temporary storage on flash than a
permanent storage that is retained after reboot because you don't have to
deal with finding the write location after a reboot; instead, you can erase
the pages of flash you'll use when the mote boots up and start your app
writing at 0x0 each time.
The AT45DB flash on a micaz can do page-level erases, meaning you erase 256
(+8 extra bytes/page) each time you want to erase data. When you write to
the AT45DB, the data actually goes into a physical RAM buffer on the chip
before being stored to flash. That means your data won't actually get
written until you flush it to flash.
Here's a little background on the way flash writes. The process of writing
on the AT45DB is usually a read-modify-write, which is different than
standard NOR-flash behavior in that the data from a page is first read into
its RAM, the data is modified, the page is erased, and the modified data is
written back to flash. This prevents data from being corrupted. Standard
NOR-flash behavior is 1's turn into 0's on write, and 0's turn back to 1's
on erase. So if you wrote 01101101 to a byte on a NOR-flash (like the
STM25P on tmotes) and then wrote a 10010011 to that same byte location,
you'd end up with 00000001 - not what you'd expect. The AT45DB's
read-modify-write prevents this from happening at the expense of time and
energy. If you look at the power consumption plot I attached, you can see
this behavior (as well as the required energy!) for a few page writes. The
flat line is a read, the squiggly lines are writes. Note that the current
gets up to 70 mA - you'll need some good batteries (not coin cell) to supply
that kind of instantaneous current.
With all that said, you can try the PageEEPROM component to do all that, but
I recommend trying out the component I wrote to do kind of what you're
doing, found in the TinyOS 1.x CVS under /contrib/rincon/apps/FlashBridge.
The FlashBridge component is meant to be a library that you can use in any
application to directly access flash.
You'll need to download most of that /contrib/rincon directory to get the
demo apps working (including /tos/lib/Transceiver, /tos/lib/State, and
/tools/java/com/rincon/flashbridgeviewer if you want to read the raw flash
onto your computer screen) and you'll need to modify the Makefile to include
the AT45DB directory instead of STM25P. To try it out, compile and install
the FlashBridge component onto your micaz. Then, you can connect to the
micaz using serial forwarder and use the Java FlashBridgeViewer app to
interact with the flash and get an idea of its behavior. The readme is
provided in the /contrib/rincon/apps/FlashBridge/apps/FlashBridgeViewer
directory, and part of it is copied below.
If you're working with a buffer of data that needs to be stored on flash,
I'd recommend breaking them up into 256-byte segments to make them easy to
read/write in page increments. Let's say you only need to store a few
buffers of data on flash. On boot, erase the first page of flash (this
isn't good for wear-leveling, but you probably won't reboot 100,000+ times
either):
call FlashBridge.erase(0);
This will erase the entire first sector - 256 pages of flash, or
256*256=65536 bytes (~1 second erase time). When you issue a command on
flash, wait for the event to come back before issuing another command.
Now you can start writing at 0x0:
uint8_t buffer[256]; // Here's your buffer of data you want to store to
flash
uint32_t flashWriteAddress = 0; // the next location to write to on flash
void writeToFlash() {
call FlashBridge.write(flashWriteAddress, &buffer, sizeof(buffer)); //
Write the entire buffer to flash.
}
// Wait for the event to come back....
event void FlashBridge.writeDone(uint32_t addr, void *buf, uint32_t len,
result_t result) {
if(result) {
// SUCCESS! update our write location to the next page, or something.
// Note that if we only erased sector 0 on boot, anything after
address 0x10000 (the 257'th page on flash)
// may not be valid to write to
flashWriteAddress += len;
}
}
The FlashBridge component extends the PageEEPROM component incase you want
to try to use the PageEEPROM component directly. Then you can check out how
it works in FlashBridge's AT45DB implementation.
You'll have to write you own apps to get the data onto and off of flash.
Hope that gets you started,
-david
// readme.txt
First let's take a look at what commands we have available from the
FlashBridge. Compile FlashBridgeViewerTest or BlackbookConnect or something
to the mote and connect to the mote with your serial forwarder. Then...
$ flashbridge
No arguments found
Usage: java com.rincon.flashviewer [mote] [command]
COMMANDS
-read [start address] [range]
-write [start address] [22 characters]
-erase [sector]
-flush
-crc [start address] [range]
-ping
Let's ping the mote to see if we have FlashBridgeViewer installed:
$ flashbridge -ping
Pong! The mote has FlashViewer installed.
Great, now let's read a page of data:
$ flashbridge -read 0 0x100
0x0 to 0x100
_________________________________________________
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
Let's write some data. The FlashBridge itself lets you
write as much data at a time as you want, but our TOS_Msg's being
passed back and forth over UART only hold so much. And there's
not much you can specify on the command line anyway, so here's what
happens:
$ flashbridge -write 0x0 hello_flashbridge!
Writing data
0x68 0x65 0x6c 0x6c 0x6f 0x5f 0x66 0x6c 0x61 0x73 0x68 0x62 0x72 0x69 0x64
0x67
0x65 0x21
SUCCESS: 18 bytes written to 0x0
We'll read 0x20 bytes back from 0x0 to make sure what we wrote exists:
$ flashbridge -read 0 0x20
0x0 to 0x20
_________________________________________________
68 65 6C 6C 6F 5F 66 6C 61 73 68 62 72 69 64 67 | hello_fl ashbridge
65 21 FF FF FF FF FF FF FF FF FF FF FF FF FF FF | !
Keep in mind that the AT45DB flash doesn't necessarily put what you wrote
onto the physical flash until you flush it out, so here's how you flush:
$ flashbridge -flush
SUCCESS: Flush complete
We can take the CRC of the data we just wrote:
$ flashbridge -crc 0x0 18
SUCCESS: CRC is 0x6D3F
And we can erase the entire sector. FlashBridge was designed for sector
erases, which you can actually go in and edit if you want - but it's not
entirely recommended. The ST M25P80 flash erases in sector-lengths, which
is 64kB at a time. Atmel's AT45DB flash chip erases in page-lengths, which
is 256B at a time. To maintain compatibility between the two chips,
FlashBridge erases the full 64kB at a time on both the AT45DB and the STM25P
chips. It can probably be done faster on the AT45DB implementation
than it is right now, but I haven't programmed any of the block erase
stuff that the chip actually supports.
Another option would be to go in and edit the FlashSettings.h
file for the AT45DB and define smaller sector sizes and readjust
all those flash parameters, and that should maintain compatibility as well.
So let's erase. It takes about 1 second/sector - which is 1 second per
erase.
$ flashbridge -erase 0
SUCCESS: Sector 0 erase complete
And for that AT45DB you'll want to flush after that as well to make sure
changes are commmited to flash.
Now let's read back address 0x0:
$ flashbridge -read 0 0x100
0x0 to 0x100
_________________________________________________
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |
-----Original Message-----
From: Munaretto, Daniel [mailto:munaretto at docomolab-euro.com]
Sent: Tuesday, August 01, 2006 11:46 PM
To: dmm at rincon.com
Cc: tinyos-help at Millennium.Berkeley.EDU
Subject: for David Moss: [Tinyos-help] Help with real node
behaviour!Micaz,tinyos 1.x
-----Original Message-----
From: Michael Schippling [mailto:schip at santafe.edu]
Sent: Tue 8/1/2006 7:19 PM
To: Munaretto, Daniel
Cc: tinyos-help at Millennium.Berkeley.EDU
Subject: Re: [Tinyos-help] Help with real node
behaviour!Micaz,tinyos 1.x
I haven't used the FLASH so I can't give good advice.
David Moss on this list seems to know a lot about it,
perhaps he will answer?
MS
Munaretto, Daniel wrote:
> Hi Michael,
> The problem is that we need more memory for our project. Even if
FLASH memory is slow, i think we need to use all possibilties that micaz
mote gives to us. Is it possible to use it for writing data? (i know that
for ADC readings it is used, and just to remember we use tinyos 1.x and
micaz motes, Atmel ATMEGA128)
> if yes, how?and how much? and what about relative energy
consumption and time requested? it would be really useful...any informations
will be really appreciated!
> Because we can think to solve this memory problem by using RAM and
FLASH together: sometimes, when we receive packets for bufferizing, we can
move this buffer from RAM to FLASH memory temporary or viceversa, i don't
know exactly how i should manage this situation. But what i mean is
something similar to PC hard-disk....
>
> cheers
> Daniele
>
> -----Original Message-----
> From: Michael Schippling [mailto:schip at santafe.edu]
> Sent: Mon 7/31/2006 9:12 PM
> To: Munaretto, Daniel
> Cc: tinyos-help at Millennium.Berkeley.EDU
> Subject: Re: [Tinyos-help] Help with real node
behaviour!Micaz,tinyos 1.x
>
>
>
> As far as I know all of the 4k of RAM is available for use,
> so you should have about 2.5k for your buffer allocs. Maybe
> you can put in an allocation size detector for your
simulation
> so you can see where it (is assumed to) overflow? Or log all
> the alloc/frees and match them up...
>
> MS
>
> Munaretto, Daniel wrote:
> > Thanks for your answer, in my program i allocate memory to
create in each mote a buffer-chain (i use structures that allocate memory
dynamically). But i don't know exactly how much dynamic memory i can use in
Micaz motes.
>
> > For example, if after compiling i use 1419 bytes in RAM
and 19748 bytes in ROM, is the rest used for dynamic allocation?
>
> > i don't understand this passage about exactly how much
memory i can use dynamically..for me understanding would be really
important.
>
> > Thanks for your availability,
> >
> > Cheers
> > Daniele
> >
> > -----Original Message-----
> > From: Michael Schippling [mailto:schip at santafe.edu]
> > Sent: Fri 7/28/2006 7:12 PM
> > To: Munaretto, Daniel
> > Cc: tinyos-help at Millennium.Berkeley.EDU
> > Subject: Re: [Tinyos-help] Help with real node
behaviour!Micaz,tinyos 1.x
> >
> >
> >
> > Well there's 128K of PROM and 4K of RAM in the
ATMEGA 128
> > and I believe it is all available. At the end of the
TOS
> > compile you get a line that says how much your
program is
> > using. If you are not doing any kind of dynamic
allocation
> > this should be the maximum used. Perhaps you have a
pointer
> > or something that is running amuck in a way that you
don't
> > see in simulation.
> >
> > I think using FLASH is rather slow and the number of
MTBF
> > cycles is not conducive to temporary storage.
> >
> > MS
> >
> > Munaretto, Daniel wrote:
> > > I did other experiments and i found that, with
little data size, the nodes are able to send and receive all packets they
generate. So it's definitely a memory problem. But i think not to use so
much memory and i free, when i can, the used structures. Remember i need a
buffer chain in each node cause i store incoming packets and then i create
new coded packets from these buffers.
>
> > > Now my question is: with Micaz motes, tinyos 1.x,
how much memory in ROM and RAM can i use?
> > > and is it possible to use the FLASH memory?if yes
how?and what's the size of it?
> > > If possible, i'd like to receive very precise
informations for understanding my problem in the best way.
> > >
> > > Thanks very much for your availability
> > > cheers
> > > Daniele
> > >
> > > -----Original Message-----
> > > From: Michael Schippling
[mailto:schip at santafe.edu]
> > > Sent: Thu 7/27/2006 9:25 PM
> > > To: Munaretto, Daniel
> > > Cc: tinyos-help at Millennium.Berkeley.EDU
> > > Subject: Re: [Tinyos-help] Help with real
node behaviour!Micaz,tinyos 1.x
> > >
> > >
> > >
> > > Sounds like your buffering scheme is
overflowing and crashing the mote.
> > > One clue is that I seem to see a lot of
length 5 buffer pools in TOS...
> > > You might want to double check that you are
freeing buffers after use.
> > > MS
> > >
> > > Munaretto, Daniel wrote:
> > > > Hi all,
> > > > after a lot of simulation in TOSSIM, i
uploaded my programs on the motes.
> > > > By reading the leds, i'm able to
understand what happens.
> > > >
> > > > If i run on motes a normal flooding, it's
all ok. All packets are sent and received.
> > > >
> > > > But if i run a more complex program, where
before broadcasting packets i code packets i stored in the node's internal
buffer, i notice i cannot receive over 5 packets (in my experiments i
generate 8 packets per node). But if i run only one mote, it's able to
generate all packets.
>
> > >
> > > > So if i run 2 nodes, one seems blocked or
crashed after receiving 5 packets (Leds stop to work, fixed on a color or
void) and the other one continue to send packets in a properly way.
>
> > >
> > > > I made with several motes and it's the
same, also changing batteries.
> > > >
> > > > Anyone could help me, please?
> > > > i don't know what's wrong, in TOSSIM was
all ok.
> > > > And i'm using micaz motes, tinyos 1.x,
after compiling i see: used RAM=1657 bytes, used ROM=19600 bytes.
>
> > > >
> > > > Thanks very much, i hope someone could
answer to me!
> > > > cheers
> > > > Daniele
> > > >
> > > >
> > > >
_______________________________________________
> > > > Tinyos-help mailing list
> > > > Tinyos-help at Millennium.Berkeley.EDU
> > > >
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
> > >
> >
> >
>
More information about the Tinyos-help
mailing list