Then i commented /*import com.rincon.transfer.TransferCommands;*/ in FlashViewerSender.java
in order to compile FlashViewer.java and so have a new .class.
But the results are the same.
In FlashViewer.java, i notice with debug messages, i'm able to enter in
if(cmd.matches("-read")) {
// Get the start address
if (argv.length > ++index) {
reportError("No Missing [start address]");
startAddress = parseLong(argv[index]);
/*reportError("No Missing [start address]");
*/
} else {
reportError("Missing [start address]");
}
// Get the range
if (argv.length > ++index) {
actualRange = parseLong(argv[index]);
} else {
reportError("Missing [range]");
}
runner.read(startAddress, actualRange, moteID);
[..]
but after (in the "-read" case)
startAddress = parseLong(argv[index]);
it's not able to print the debug message!(if i change the commented debug
messages)
-----Original Message-----
From: Munaretto, Daniel
Sent: Fri 8/4/2006 10:34 AM
To: David Moss
Cc: [email protected]
Subject: RE: for David Moss: [Tinyos-help] Help with real node
behaviour!Micaz,tinyos 1.x
And also with command -flush, it's working. Only with commands +
arguments it doesn't work!
-----Original Message-----
From: Munaretto, Daniel
Sent: Fri 8/4/2006 10:15 AM
To: David Moss
Cc: [email protected]
Subject: RE: for David Moss: [Tinyos-help] Help with real node
behaviour!Micaz,tinyos 1.x
Yes, i had to update the old version. Now it compiles, but when
i run the java tool i'm not able to use read and write commands.
For example, from folder /contrib/rincon/tools/java
i type
java com.rincon.flashbridgeviewer.FlashViewer 0 -ping
and i receive correctly
"Pong!The mote has FlashViewer installed"
NB i used make micaz install.0 eprb,192.168.1.3 (by ethernet)
then i tried:
java com.rincon.flashbridgeviewer.FlashViewer 0 -read 0 0x100
or also the write command from the README file, but it diplays:
For input string: "-read"
Usage: java com.rincon.flashbridgeviewer.FlashViewer [mote]
[command]
COMMANDS:
-read [start address] [range]
-write [start address][20 characters]
-erase [sector]
-flush
-crc [start address][range]
-ping
What can i do for solving this problem?
Thanks,
cheers
Daniele
-----Original Message-----
From: David Moss [mailto:[EMAIL PROTECTED]
Sent: Thu 8/3/2006 6:25 PM
To: Munaretto, Daniel
Cc: [email protected]
Subject: RE: for David Moss: [Tinyos-help] Help with
real node behaviour!Micaz,tinyos 1.x
I've seen this error before. You're using an older
version of TinyOS aren't
you?
TinyOS 1.1.7 uses a PageEEPROM interface defined in the
/platform/mica
directory, while future versions use a PageEEPROM
interface defined in
/tos/lib/Flash/AT45DB. The 1.1.7 PageEEPROM interface
version defines these
crc commands:
command result_t computeCrc(eeprompage_t page,
eeprompageoffset_t offset,
eeprompageoffset_t n);
event result_t computeCrcDone(result_t result,
uint16_t crc);
while future versions define an extra command, thanks
to Johnathan Hui, that
allows a running CRC:
command result_t computeCrc(eeprompage_t page,
eeprompageoffset_t offset,
eeprompageoffset_t n);
command result_t computeCrcContinue(eeprompage_t
page, eeprompageoffset_t
offset,
eeprompageoffset_t n, uint16_t crc);
event result_t computeCrcDone(result_t result,
uint16_t crc);
This can be fixed on your system, but you need to
update your version of
PageEEPROMM module and PageEEPROM interface. I've
attached the updated
versions of PageEEPROM files (with a slight fix to make
it work with 1.1.7).
Put these files in your local compile directory (in
either
/Blackbook5/apps/FlashBridge where you were compiling
from, or in
/Blackbook5/media/AT45DB) so you don't overwrite the
original 1.1.7
versions. When you compile, these files will override
the files in the
/platform/mica directory. Incase updating the
PageEEPROM component doesn't
work, you can remove the latest version by deleting the
files from the local
directory without breaking your TinyOS.
Hope that works. Let me know how it goes.
-David
-----Original Message-----
From: Munaretto, Daniel [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 03, 2006 8:08 AM
To: David Moss
Cc: [email protected]
Subject: RE: for David Moss: [Tinyos-help] Help with
real node
behaviour!Micaz,tinyos 1.x
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:[EMAIL
PROTECTED]
Sent: Wed 8/2/2006 5:22 PM
To: Munaretto, Daniel
Cc: [email protected]
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:[EMAIL PROTECTED]
Sent: Tuesday, August 01, 2006 11:46 PM
To: [EMAIL PROTECTED]
Cc: [email protected]
Subject: for David Moss: [Tinyos-help]
Help with real node
behaviour!Micaz,tinyos 1.x
-----Original Message-----
From: Michael Schippling
[mailto:[EMAIL PROTECTED]
Sent: Tue 8/1/2006 7:19 PM
To: Munaretto, Daniel
Cc:
[email protected]
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:[EMAIL PROTECTED]
> Sent: Mon 7/31/2006
9:12 PM
> To: Munaretto, Daniel
> Cc:
[email protected]
> 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:[EMAIL PROTECTED]
> > Sent: Fri
7/28/2006 7:12 PM
> > To: Munaretto,
Daniel
> > Cc:
[email protected]
> > 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:[EMAIL PROTECTED]
> > > Sent:
Thu 7/27/2006 9:25 PM
> > > To:
Munaretto, Daniel
> > > Cc:
[email protected]
> > >
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
> > > >
[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
