Hi,
I use the approach suggested by Ugo.
I can dump the entire tmote memory with no problem using
SerialActiveMessage, following this loop:
1) read from flash in a buffer (size of buffer is a for a log record)
2) send usign SerialAMSender
3) on sendDone event call again number 1,
On pc side I use a java application that receive, decode and print the
data, than I redirect the output by serial.
I normally wait to erase the log until I'm sure all data are fine (very
rarelly it not happen).
Davide
Il 01/09/2014 13:28, András Bíró ha scritto:
Hi Guys,
Fastserial doesn't provide faster communication, it's just using much
less blocking (atomic) segments, so it doesn't mess up important
interrupts. This is very useful when you want to use it as a really
fast basestation. You can turn it on with the fastserial extra (e.g.
"make iris fastserial").
You can also try to increase baudrate with the PLATFORM_BAUDRATE
constant in the makefile. I'm not sure about the telosb, but the
ucmotes usually works well with "CFLAGS+=-DPLATFORM_BAUDRATE=500000U",
probably even better than with 115200, because the RFA1's clock
generator can generate round numbers better than "traditional"
badrates with the integral oscillator.
I never really used the flash with serial dumping, but I used radio
downloading a lot (again, on ucmotes, but probably every stm25p based
mote is similar): Flash was always significantly slower than the
radio, which works at theoratical 250kb/s rate, but it has at least
10% overhead, probably more.
Your original problem was with printf: You don't know if it finished
the communication, or not. On top of that, I think printf does the
numbers to ascii conversion on mote. With AM, you eliminate the
conversion overhead, and you know you can send the next message when
you received the sendDone event.
So, long story short: use AM, I don't think you'll need anything else.
But you probably want to add a sequence number or address to every
package, so you can check for data loss. If there is data loss, you'll
also need some kind of ack (probably AM's ack is trustable on serial
as well, but I'm not sure). Don't forget to turn off every other
serial communication (e.g. debug printfs).
Using the UART directly can work, but it's a bad idea: You'll probably
need framing, escaping, CRC, and so on: You'll end up with a new
serial stack, which is very similar to the current.
Oh and one more thing: The default maximum payload is 28 byte. This is
mostly because RAM: every message_t allocates 28B+overhead. On serial,
the overhead is around 10B, so basicly you have about 25% overhead,
which is a lot. You can increase it with the constant
TOSH_DATA_LENGTH. I think the physical maximum on radio is 114B (the
maximum message length is 127B, but you have headers and footers).
It's unlimited on serial, but usually 100 or 110 is a good value.
Andras Biro
http://ucmote.com
On Mon, Sep 1, 2014 at 11:39 AM, Ugo Maria Colesanti
<[email protected] <mailto:[email protected]>> wrote:
I think you will manage to do everything with the standard
serialAM stack, but just in case, have a look to
tos/lib/fastserial which should be a more efficient serial
interface than the standard one (i never used it). It should
support both, ucmini and telosb.
I think it can be re-wired to serialAM. You can also consider to
write raw bytes directly on the uart without the serialAM stack
ahead.
Bye,
Ugo
2014-09-01 11:24 GMT+02:00 Alessandro Sivieri
<[email protected] <mailto:[email protected]>>:
On Mon, Sep 1, 2014 at 11:08 AM, Ugo Maria Colesanti
<[email protected] <mailto:[email protected]>>
wrote:
How big is your flash? What hardware are you using?
I'm using the telosb and the ucmini, the former with 1MB flash
and the latter with 2MB. I think I will try the active message
this week and see how it goes.
--
Sivieri Alessandro
[email protected] <mailto:[email protected]>
http://sivieri.wordpress.com/
_______________________________________________
Tinyos-help mailing list
[email protected]
<mailto:[email protected]>
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
