Uhm..on my micaz motes, in the bottom side, it is written 1.5 V batteries. So i
think more than 3V is not possible..May be do i need any special kind of
battery or something else to source on my micaz?
i have not knowledge on the batteries to use on motes..
However thanks very much for your help, it is really important for my group,
cheers
Daniele
-----Original Message-----
From: David Moss [mailto:[EMAIL PROTECTED]
Sent: Tue 9/19/2006 1:07 AM
To: Munaretto, Daniel; [email protected]
Cc:
Subject: RE: [Tinyos-help] repeating tests,no free memory
Ah, yes - 1.3V is a definit problem. You need to be able to source 2.7
volts minimum, with 75+ mA. I recommend going above 2.7 volts to about
3.3-3.6 volts just to allow for some voltage sag. The crash happens so
fast
(1 ms) that you can't even detect what's going on.
-----Original Message-----
From: Munaretto, Daniel [mailto:[EMAIL PROTECTED]
Sent: Monday, September 18, 2006 8:52 AM
To: David Moss; [email protected]
Subject: RE: [Tinyos-help] repeating tests,no free memory
I'm using not so much RAM, at compile time is around 1700 bytes (it
depends
on the different versions of my program).
But now, after other tests, i see that when the motes enter in the
reading-from-flash phase, something happens and some of them break
down.
They are not more able to work.And only after a reading phase.
May be the batteries? i know about the 70mA of current, but if i use
rechangeable batteries, so 1.3 V, are there problems?i can measure only
voltage by a voltmetre.
I really don't know how to understand what's going on in the reading
phase
to let some motes to break down in this way.
One problem may be is about the parameters i need when the reading
phase is
done: i need the same parameters i use when i posted the task.So the
global
parameters buf_flash,State,mess,flashAddr,
flashLen,flashBuffer are probably different when the readDone event
fires up
from the ones used posting the task.But only when the reading is done i
can
use that buffer and so i can execute my program..so for example sending
packets,math operations,etc..
Buffer *flashBuffer,*buffer,*ibuf,*ibuff;
Buf_flash *Head,*buf_flash;
Datagram *mess,*datagram;
uint8_t State;
task void readFlash(){
if (!call FlashBridge.read(flashAddr,flashBuffer,flashLen)){
post readFlash();}
return;
}
void readInToFlash(uint8_t s,Buf_flash *buf,Datagram *message,Buffer
*buffer_r,uint32_t addr, uint32_t len){
buf_flash=buf;
State=s;
mess=message;
flashAddr=addr;
flashLen=len;
flashBuffer=buffer_r;
post readFlash();
return;
}
event void FlashBridge.readDone(uint32_t addr, void *buf, uint32_t len,
result_t result){
if (result){
//operations where i need to use the same global variables declared in
the
task!for now i'm using normally mess,State,etc..but i think are
different
from the same one before posting the task.
//for example if i use
//if(mess->data==...).....
//i think it is not the same "mess" written before "post
readFlash()"...
else
post readFlash();
return;
}
-----Original Message-----
From: David Moss [mailto:[EMAIL PROTECTED]
Sent: Fri 9/15/2006 6:27 PM
To: Munaretto, Daniel; [email protected]
Cc:
Subject: RE: [Tinyos-help] repeating tests,no free memory
How much RAM is your program consuming at compile time? The
MicaZ
is
notorious for running out of RAM just when you need it because
it
only has
4kB. If your global memory usage is already quite a bit (3kB
maybe?
maybe
more? maybe less?) and you throw a bunch of stuff on the stack,
your
mote
will crash in a seemingly random fashion, depending on what's
going
on.
I've had apps before that used around 3kB of RAM when the
program is
compiled, and then crashed awhile later because the stack
overflowed.
If the task queue is full (and it's in global memory btw, so
simply
posting
tasks shouldn't cause a stack overflow) then when you post a
task,
the post
will return FAIL. It could also be that your app is posting a
task
and
expecting it to run before continuing on, and that task never
actually got
posted. I've personally never had that problem before, even
with
running a
full file system on top of flash bridge with the radio
transmitting
and
receiving.
-----Original Message-----
From: Munaretto, Daniel [mailto:[EMAIL PROTECTED]
Sent: Friday, September 15, 2006 9:02 AM
To: David Moss; [email protected]
Subject: RE: [Tinyos-help] repeating tests,no free memory
Dear all,
i tried to use TinyAlloc interface but the results are
really
similar.
So this is not a problem of the calloc function.
But i start thinking the problem is in the stack. If i post too
many
tasks,
can the mote crash?
The problem is that i have to use tasks to handle the
FlashBridge
interface
in order to use properly the reading and writing phase on
Flash-RAM.
And i'm
also using a task for the sending interface (own mote messages)
and
for the
forwarding one (messages from other motes), all synchronized by
timers.
So if i use micaz motes, tinyos-1.x, can it be a problem?
Because i'm freeing all the times the memory i allocate, but if
i
repeat the
experiments with the motes on, in the second round or in the
third
one, one
(or more)of these breaks down. It seems quite randomly.
Hoping in any kind of help,
cheers
Daniele
-----Original Message-----
From: David Moss [mailto:[EMAIL PROTECTED]
Sent: Mon 9/11/2006 7:56 PM
To: Munaretto, Daniel;
[email protected]
Cc:
Subject: RE: [Tinyos-help] repeating tests,no free
memory
Daniele,
This was one thing I noticed about the code I looked at
but
failed
to warn
against, because I didn't know any better until I read
up on
it
afterwards.
Below are a few emails from this list that may point
you in
the
right
direction.
-David
https://mail.millennium.berkeley.edu/pipermail/tinyos-help/2005-February/007
712.html :
"The TinyOS programming methodology frowns on malloc,
for
several
reasons:
1) No memory protection so you can smash your stack
2) Unforeseen rate mismatches can cause you to do 1
(you
start
receiving packets faster than you can forward them)
3) Event-driven execution models can make free()ing a
hard
thing to
do
right (hence pool allocations, etc.)
If you want dynamic allocation, look at TinyAlloc
(which Joe
mentioned). It allows you to allocate a static chunk of
RAM
which
you
then parcel out dynamically. But using it in the
presence of
conflicting components is a recipe for disaster.
Systems
such as
TinyDB
get away with it because all their parts are designed
to
work
together.
Phil"
"Hi all,
Refer to the paper "The NesC Language: A Holistic
Approach to
Networked Embedded Systems", dynamic memory allocation
and
function
pointers are prohibited in NesC language. For dynamic
memory
allocation, it's quite clear to me why we can't use it
in
TinyOS as
refered to
https://mail.millennium.berkeley.edu/pipermail/tinyos-help/2005-February/007
712.html
. We can use TinyAlloc or MemAlloc instead of directly
calling
malloc() and so on. But for function pointers, it's not
clear to me
that we can or can't use it in TinyOS. What would be
the
problems if
I
use that?"
"Short answer: it leads to more reliable code.
Long answer:
Here's a pointer (haha!):
http://mail.millennium.berkeley.edu/pipermail/tinyos-help/2005-February/0077
12.html
There's a difference between malloc() and dynamic
allocation. nesC
does not forbid dynamic memory allocation: there's
nothing
stopping
you from writing a component that allocates a pool of
memory
and has
dynamic allocation interfaces. Take a look at
TinyAlloc, for
example.
nesC does, however, frown on malloc, for the reasons
described in
the
above mail. Modern coding styles generally assume
unbounded
memory,
in as much that you have swap space so will see
tremendous
performance degradation before the system crashes.
General
application behavior on allocation failure is to
exit(2) and
therefore deallocate everything. With a processes,
multitasking, and
automatic page reclamation, this works fine. But on an
embedded
system with no memory protection, well, it's not so
clean.
Part of the issue is that while dynamic allocation
among a
set of
cooperating components can work fine (e.g., TinyDB, Ben
Greenstein
@UCLA's work on signal processing), dynamic allocation
between
arbitrary components (a single shared pool) is a recipe
for
disaster.
One bad component can bring the entire system down, as
the
shared
resource breaks inter-component isolation.
The reason why nesC frowns on function pointers is
because
they are
dangerous and except for a few edge cases (e.g.,
dynamically
linking
new binary modules), unnecessary. You know the call
graph at
compile-
time. Instead of storing a function pointer in memory,
which
could
be
corrupted and lead you to jump to certain doom, you can
just
use a
parameterized interface and call based on a function
ID.
This also
gives you type checking for the functions It is more
robust,
just as
easy (once you get used to it), and generally uses less
RAM
(no need
to store the pointer). Function pointers are a basic
result
of C's
linking model. nesC's linking model does not have the
same
complications (interfaces are bidirectional), so you
can
avoid them.
Phil"
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of
Munaretto,
Daniel
Sent: Monday, September 11, 2006 1:51 AM
To: [email protected]
Subject: [Tinyos-help] repeating tests,no free memory
Dear all,
i discover a really strange behavior in my
application.
I repeat more times my code, and after some experiments
the
motes
break
down.
So there is a memory problem.
But i'm sure i free all the memory i allocate during
the
code. I'm
using
only a buffer and i re-use it all the times, instead i
allocate
memory with
"calloc()" only for creating a chain which i delete at
the
end of
each
simulation with the "free" command and then i give
"NULL" to
the
pointers.
So i don't understand where i lose memory each time i
re-run
the
program
(without re-booting the motes). i'm in tinyos
1.1.15,micaz
motes.
I'm using the FlashBridge interface because i'm working
on
the
flash.
I'm supposing that, may be, the problem is in the way
Tinyos
handles
the
packets received. For example, in the function "event
TOS_MsgPtr
Receive.receive(TOS_MsgPtr m)", before returning m, do
i
have to
free it?But
i can see it's wrong to do..
Please, if anyone knows where i have to find the waste
of
memory
(may be
some interfaces)...any helps will be really appreciated
thanks very much
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
