[mc1322x] 6LowPAN data payload

[Mariano Alvira]

On Wed, Jul 14, 2010 at 11:01:26AM -0400, Mariano Alvira wrote:
> On Wed, Jul 14, 2010 at 10:52:10AM -0400, Mariano Alvira wrote:
>
> I'm working on the slow ping times now --- there is a problem when the
> radio goes from RX -> TX --- it looks like the first DMA transfer
> needs a little time to finish (or something...)

Hey everyone,

I've just push two major changes. 

The first are two important performance enhancements to the tx_packet
in the maca driver. Now tx_packet will force an interrupt if the maca
is idle, causing an immediate transmission. And it will also advance
the reception clock so that the current reception cycle will finish
immediately or after the current packet is done being received. This
also allows the reception cycle to be made much longer (since a
transmit can preempt it now --- you can wait for packets as long as
you want). This change has been pushed to libmc1322x and
contiki-mc1322x.

The second is a HUGE bugfix to contiki. Somehow a call to maca_on()
made it's way into the prepare routine. maca_on() messes things up if
you call it while the radio is doing stuff. Now you can safely disable
BLOCKING_TX and enjoy super fast transmissions.

Between econotags, a single packet ping is now 30ms (was 500ms!). And
a 1200 byte ping (13 fragments, which should be the max) is now 337ms
(before it wouldn't even work). Packet loss is greatly improved too on
account of the long receive cycle. E.g. I can do this with 0% packet
loss:

ping6 -i .34 -s 1200 aaaa::250:c2ff:fea8:c3e2

Chances are this will fix other things too, like some of the stability
issues people were seeing.

The econotag fragments will probably completely swamp Ravens now ---
but these changes should make it easier to do a consistent interpacket
delay.

I haven't pushed these changes into Contiki CVS yet, but they will
make it in there soon...

Enjoy!

-Mar.