Jimmy Mathew | 1 Aug 2008 10:35
Picon
Favicon

TCP IP header



Hi

Is there a function to fill the required headers of Ethernet for an outgoing packet in Contiki? Or should I do it manually?

Wish You A Good Day!..

Jimmy Mathew

 

Connect with friends all over the world. Get Yahoo! India Messenger.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Contiki-developers mailing list
Contiki-developers@...
https://lists.sourceforge.net/lists/listinfo/contiki-developers
Jimmy Mathew | 1 Aug 2008 16:32
Picon
Favicon

Uip packet header



Hi

Could you please tell me if uip will automatically insert IP header and TCP Header in the out going packet from the information given? Or I am supposed to insert it manually using the structure uip_tcpip_hdr?

Wish You A Good Day!..

Jimmy Mathew

 

Unlimited freedom, unlimited storage. Get it now
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Contiki-developers mailing list
Contiki-developers@...
https://lists.sourceforge.net/lists/listinfo/contiki-developers
Christopher Wang | 4 Aug 2008 05:11
Favicon

Questions regarding malloc.c in Contiki v2.2

I've been working on a Zigbee stack based on the Contiki OS for a few months
now and actually, its getting close to completion. However Zigbee uses many,
many, many tables and also requires multiple queues to be implemented.
Currently, all of my table and queue elements are statically allocated at
compile time. Unfortunately, this is an inefficient use of RAM which is a
precious resource on the systems I'll porting to. I've been wanting to
convert to dynamically allocating elements from a pre-allocated memory pool
instead which would lead to more efficient utilization of RAM, but I haven't
been able to find any good allocators. When I downloaded Contiki v2.2 and
checked it out, I noticed the new malloc.c and malloc_compact.c files in the
core/lib folder. I have the following questions regarding malloc:

1) If I allocated a linked list element with malloc.c, is there any chance
that the memory block would change locations (ie: by compacting)? I ran into
this problem with mmem.c in Contiki v2.1 where the act of compacting the
memory would mess up my linked list "next" pointers. 

2) Can the linked list elements be used with the current version of
malloc_compact.c? I suspect that the same problem I mentioned above would
probably occur. 

3) Is there any way to use linked lists with malloc and malloc_compact
safely? I like the fact that its possible to compact memory and prevent
fragmentation, but I'm using a lot of linked lists right now.

4) If the answer to (3) is no, do you recommend any better method for
efficient RAM allocation (either in Contiki or from some other source)? I'm
looking for something that can be dynamically allocated, but where I can set
the heap size to get better control of RAM usage.

Thanks. And by the way, using Contiki was one of the best decisions I made
in developing this stack. It made things much easier for me, and the stack
may be on its way to becoming one of the smallest Zigbee stacks mainly due
to Contiki (possibly after a few release iterations, tho :) ).

Chris
FreakLabs
Open Source Zigbee
http://www.freaklabs.org

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
Vijay Gabale | 12 Aug 2008 20:26
Picon

Approaching the maximum 802.15.4 multi-hop throughput

Hi there,

I greatly "appreciated Approaching the maximum 802.15.4 multi-hop throughput" zero copy mechanism.I have been trying to dig out how to implement this mechanism on Tmote sky platform (MSP430 + CC2420 radio) using TinyOS. I observed following

1) No command is available on the part of CC2420 to transmit data directly from RX fifo to TX fifo, thus avoiding unnecessary copying. If you want to do this with current design, the data has to go all over through processor memory.
2) STXON command can only transmit data from transmit fifo i.e. data in TX fifo specific location of RAM. There is no command to transmit data from RX fifo directly.

I would be highly obliged if you could convey how you implemented the mechanism using CC2420 radio only in Contiki esp. the features of CC2420 that you have utilized.

Eagerly awaiting your early response.

Thanks in advance.

Regards,
Vijay Gabale
Senior graduate student
IIT Bombay, India.
http://www.cse.iitb.ac.in/~vijaygabale
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Contiki-developers mailing list
Contiki-developers@...
https://lists.sourceforge.net/lists/listinfo/contiki-developers
Fredrik Österlind | 13 Aug 2008 01:41
Picon
Picon

Re: Approaching the maximum 802.15.4 multi-hop throughput

Hi Vijay,

We also used the TmoteSky for our experiments, and the mechanism 
required a few (uncommitted) changes to the CC2420 driver.
The technique should be easy to port to any system:

You are correct in that the CC2420 does not allow transferring data 
between the FIFOs, nor can the RX FIFO be transmitted directly, however, 
the technique evaluated in the paper does not use these features. 
Instead if immediately forwarding incoming data, the approach employs 
pre-copying of already received data. Hence, on a forwarding node, an 
outgoing packet is triggered by an incoming packet, *but does not 
contain the same data*. The outgoing packet contains the data of the 
previous incoming packet.

I believe some packet radios, such as the Chipcon CC2430, support 
transmitting directly from the "RX FIFO". Using such a radio reduces the 
advantages of the pre-copying approach, but would be comparable to 
decreasing the SPI communication overhead.

Regards,
Fredrik Österlind

Vijay Gabale wrote:
> Hi there,
>
> I greatly "appreciated Approaching the maximum 802.15.4 multi-hop 
> throughput" zero copy mechanism.I have been trying to dig out how to 
> implement this mechanism on Tmote sky platform (MSP430 + CC2420 radio) 
> using TinyOS. I observed following
>
> 1) No command is available on the part of CC2420 to transmit data 
> directly from RX fifo to TX fifo, thus avoiding unnecessary copying. 
> If you want to do this with current design, the data has to go all 
> over through processor memory.
> 2) STXON command can only transmit data from transmit fifo i.e. data 
> in TX fifo specific location of RAM. There is no command to transmit 
> data from RX fifo directly.
>
> I would be highly obliged if you could convey how you implemented the 
> mechanism using CC2420 radio only in Contiki esp. the features of 
> CC2420 that you have utilized.
>
> Eagerly awaiting your early response.
>
> Thanks in advance.
>
> Regards,
> Vijay Gabale
> Senior graduate student
> IIT Bombay, India.
> http://www.cse.iitb.ac.in/~vijaygabale 
> <http://www.cse.iitb.ac.in/%7Evijaygabale>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Contiki-developers mailing list
> Contiki-developers@...
> https://lists.sourceforge.net/lists/listinfo/contiki-developers
>   

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
Scheers Bart | 13 Aug 2008 09:27
Picon
Favicon

Re: Approaching the maximum 802.15.4 multi-h op throughput

Vijay, Fredrik,

I'am just back from holiday, so I did not follow the history of this discussion, anyway I see an old problem popping up again.

In Contiki, the SPI bus between the radio CC2420 and de MSP430 is set on a too slow bit rate to do measurements on throughput. The transfer time of a packet with maximum length (127+6 Bytes) between the CC2420 and the MSP is longer than a LIFS (40 symb=640ms).

A more elegant solution would be to change the bit rate of the SPI interface so that the transfer time would be inferior to a LIFS (or even a SIFS). In this case the transfer via the memory of the MSP will have no influence on the throughput. For this, some assembler code must be adapted .... not my cup of thee.



Bart

-----------------------------------------------

Maj Bart SCHEERS

E-mail: bart.scheers-vJY35iZFB3CzQB+pC5nmwQ@public.gmane.org

Bemilcom: 9-2428-6626

Tel: 02/742.66.26

Fax: 02/742.66.22

-----------------------------------------------

 


-----Original Message-----
From: Fredrik Österlind [mailto:fros-02ecni/8Nmo@public.gmane.org]
Sent: 13 August 2008 01:42
To: Contiki developer mailing list
Subject: Re: [Contiki-developers] Approaching the maximum 802.15.4 multi-hop throughput

Hi Vijay,

We also used the TmoteSky for our experiments, and the mechanism
required a few (uncommitted) changes to the CC2420 driver.
The technique should be easy to port to any system:

You are correct in that the CC2420 does not allow transferring data
between the FIFOs, nor can the RX FIFO be transmitted directly, however,
the technique evaluated in the paper does not use these features.
Instead if immediately forwarding incoming data, the approach employs
pre-copying of already received data. Hence, on a forwarding node, an
outgoing packet is triggered by an incoming packet, *but does not
contain the same data*. The outgoing packet contains the data of the
previous incoming packet.

I believe some packet radios, such as the Chipcon CC2430, support
transmitting directly from the "RX FIFO". Using such a radio reduces the
advantages of the pre-copying approach, but would be comparable to
decreasing the SPI communication overhead.

Regards,
Fredrik Österlind

Vijay Gabale wrote:
> Hi there,
>
> I greatly "appreciated Approaching the maximum 802.15.4 multi-hop
> throughput" zero copy mechanism.I have been trying to dig out how to
> implement this mechanism on Tmote sky platform (MSP430 + CC2420 radio)
> using TinyOS. I observed following
>
> 1) No command is available on the part of CC2420 to transmit data
> directly from RX fifo to TX fifo, thus avoiding unnecessary copying.
> If you want to do this with current design, the data has to go all
> over through processor memory.
> 2) STXON command can only transmit data from transmit fifo i.e. data
> in TX fifo specific location of RAM. There is no command to transmit
> data from RX fifo directly.
>
> I would be highly obliged if you could convey how you implemented the
> mechanism using CC2420 radio only in Contiki esp. the features of
> CC2420 that you have utilized.
>
> Eagerly awaiting your early response.
>
> Thanks in advance.
>
> Regards,
> Vijay Gabale
> Senior graduate student
> IIT Bombay, India.
> http://www.cse.iitb.ac.in/~vijaygabale
> <http://www.cse.iitb.ac.in/%7Evijaygabale>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Contiki-developers mailing list
> Contiki-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/contiki-developers
>  


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Contiki-developers mailing list
Contiki-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/contiki-developers

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Contiki-developers mailing list
Contiki-developers@...
https://lists.sourceforge.net/lists/listinfo/contiki-developers
Vijay Gabale | 13 Aug 2008 15:47
Picon

Re: Approaching the maximum 802.15.4 multi-hop throughput

Hi Fredrik,

Thanks a bunch for your reply. I still have doubts.

For a continuous flow where packets are being received one after another, the scenario can be described as follows:
transmit over SPI
------------------------> transmit and receive over radio
                        ----------------------------> receive over SPI bus
                                                      ---------------------------------> 
To get maximum throughput, you need to exploit the fact of simultaneous transmissions over transmitter and receiver SPI bus considering one end is transmitting and one end is receiving.
This is the usual case and forces the throughput to be around half of what you are getting.

Now assuming for an intermediate node, you have already copied packet in transmit buffer, and as soon as you receive a packet, you send a command to transmit this packet in transmit buffer. But for the packet that has been received, you still need to copy it to transmit buffer to send it next for which it still has to go over SPI bus twice. That is the problem lies in pre-copying of this second packet received where you have to devote requisite time of copying over the bus. While this is being done, you can of course receive packets but you do not have anything in transmit buffer to send immadiately. Am I right, here?

Kindly clarify me if I am missing any part of CC2420 driver that you have modified. I would be obliged if you convey the details that I could not retrieve out of the paper. But unless you some how eradicate the copying over bus, I am not able to comprehend how we should get throughput improvement.

Awaiting your early reply eargely.

Thanks in advance.

Vijay
                             
On Wed, Aug 13, 2008 at 5:11 AM, Fredrik Österlind <fros-02ecni/8Nmo@public.gmane.org> wrote:
Hi Vijay,

We also used the TmoteSky for our experiments, and the mechanism
required a few (uncommitted) changes to the CC2420 driver.
The technique should be easy to port to any system:

You are correct in that the CC2420 does not allow transferring data
between the FIFOs, nor can the RX FIFO be transmitted directly, however,
the technique evaluated in the paper does not use these features.
Instead if immediately forwarding incoming data, the approach employs
pre-copying of already received data. Hence, on a forwarding node, an
outgoing packet is triggered by an incoming packet, *but does not
contain the same data*. The outgoing packet contains the data of the
previous incoming packet.

I believe some packet radios, such as the Chipcon CC2430, support
transmitting directly from the "RX FIFO". Using such a radio reduces the
advantages of the pre-copying approach, but would be comparable to
decreasing the SPI communication overhead.

Regards,
Fredrik Österlind

Vijay Gabale wrote:
> Hi there,
>
> I greatly "appreciated Approaching the maximum 802.15.4 multi-hop
> throughput" zero copy mechanism.I have been trying to dig out how to
> implement this mechanism on Tmote sky platform (MSP430 + CC2420 radio)
> using TinyOS. I observed following
>
> 1) No command is available on the part of CC2420 to transmit data
> directly from RX fifo to TX fifo, thus avoiding unnecessary copying.
> If you want to do this with current design, the data has to go all
> over through processor memory.
> 2) STXON command can only transmit data from transmit fifo i.e. data
> in TX fifo specific location of RAM. There is no command to transmit
> data from RX fifo directly.
>
> I would be highly obliged if you could convey how you implemented the
> mechanism using CC2420 radio only in Contiki esp. the features of
> CC2420 that you have utilized.
>
> Eagerly awaiting your early response.
>
> Thanks in advance.
>
> Regards,
> Vijay Gabale
> Senior graduate student
> IIT Bombay, India.
> http://www.cse.iitb.ac.in/~vijaygabale
> <http://www.cse.iitb.ac.in/%7Evijaygabale>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Contiki-developers mailing list
> Contiki-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/contiki-developers
>


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Contiki-developers mailing list
Contiki-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/contiki-developers



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Contiki-developers mailing list
Contiki-developers@...
https://lists.sourceforge.net/lists/listinfo/contiki-developers
Fredrik Österlind | 13 Aug 2008 16:48
Picon
Picon

Re: Approaching the maximum 802.15.4 multi-hop throughput

Hi Vijay,

See below.

Vijay Gabale wrote:
> Hi Fredrik,
>
> Thanks a bunch for your reply. I still have doubts.
>
> For a continuous flow where packets are being received one after 
> another, the scenario can be described as follows:
> transmit over SPI
> ------------------------> transmit and receive over radio
>                         ----------------------------> receive over SPI bus
>                                                       
> ---------------------------------> 
Yes, this is for a forwarding node. (Though of course the middle step 
should be "receive over radio and then transmit over radio").

> To get maximum throughput, you need to exploit the fact of 
> simultaneous transmissions over transmitter and receiver SPI bus 
> considering one end is transmitting and one end is receiving.
?
> This is the usual case and forces the throughput to be around half of 
> what you are getting.
Hmm, I don't quite understand. What is the maximum throughput you are 
referring to? And what am I getting, what numbers do you refer to?

>
> Now assuming for an intermediate node, you have already copied packet 
> in transmit buffer, and as soon as you receive a packet, you send a 
> command to transmit this packet in transmit buffer.
Exactly.
> But for the packet that has been received, you still need to copy it 
> to transmit buffer to send it next for which it still has to go over 
> SPI bus twice.
True. The packet is fetched from the radio chip, is handled as usual by 
the MAC as well as the protocol stack, and finally reaches the application.
The application, seeing that this packet should be forwarded, 
"conditionally" sends the packet i.e. sends the packet down through the 
stack and MAC to the radio driver. The radio driver, however, merely 
copies the (potentially updated) packet to the radio chip but does not 
issue the start transmission command.

> That is the problem lies in pre-copying of this second packet received 
> where you have to devote requisite time of copying over the bus. While 
> this is being done, you can of course receive packets but you do not 
> have anything in transmit buffer to send immadiately. Am I right, here?
If there is not time to fetch the packet fully over SPI before the next 
incoming packet, you'll run into problems. However, if you complete 
fetching the packet, the radio can simultaneously both receive a packet 
over the radio (into the RX FIFO) and over the SPI (into the TX FIFO).
>
> Kindly clarify me if I am missing any part of CC2420 driver that you 
> have modified. I would be obliged if you convey the details that I 
> could not retrieve out of the paper. But unless you some how eradicate 
> the copying over bus, I am not able to comprehend how we should get 
> throughput improvement.
>
Unfortunately I am not sure what problem you have.
Both fetching and pushing the same packet over SPI is not a problem.
The throughput improvement is due to that packet copying is removed from 
the critical path, not removed entirely.
And note that the throughput achieved in multi-hop scenarios (paper) is 
less than half of 250kbps.

Regarding implementation (this is already covered in the paper):
The radio driver holds a pointer to a callback function, which is 
registered by the application.

RADIO DRIVER:
simple_cc2420_interrupt(void)
{
  // new packet has been received
  ...
  if (have_enqueued) {
    // notify application
    simple_cc2420_callbacks->notify();
  }
  ...
}

void
simple_cc2420_set_enqueue_mode(const struct simple_cc2420_callbacks 
*callbacks)
{
  simple_cc2420_callbacks = callbacks;
  have_enqueued = 0;
  enqueue_mode = 1;
}

int
simple_cc2420_send(const void *payload, unsigned short payload_len)
{
  ...
  simple_cc2420_write(payload, payload_len);

  if (enqueue_mode) {
    have_enqueued = 1;
    return 0;
  }

  have_enqueued = 0;
  return simple_cc2420_tx();
}

APP:
protocol_stack_recv()
{
  ...
  simple_cc2420_set_enqueue_mode(&radio_call);
  // send packet via protocol stack. note. packet will not be TXed due 
to enqueue mode
  simple_cc2420_clear_enqueue_mode();
  ...
}

static void
data_notify(void) {
  ...
  // callback from radio driver interrupt
  if (we want to) {
    simple_cc2420_send_enqueued();
  }
}

/ Fredrik

> Awaiting your early reply eargely.
>
> Thanks in advance.
>
> Vijay
>                              
> On Wed, Aug 13, 2008 at 5:11 AM, Fredrik Österlind <fros@... 
> <mailto:fros@...>> wrote:
>
>     Hi Vijay,
>
>     We also used the TmoteSky for our experiments, and the mechanism
>     required a few (uncommitted) changes to the CC2420 driver.
>     The technique should be easy to port to any system:
>
>     You are correct in that the CC2420 does not allow transferring data
>     between the FIFOs, nor can the RX FIFO be transmitted directly,
>     however,
>     the technique evaluated in the paper does not use these features.
>     Instead if immediately forwarding incoming data, the approach employs
>     pre-copying of already received data. Hence, on a forwarding node, an
>     outgoing packet is triggered by an incoming packet, *but does not
>     contain the same data*. The outgoing packet contains the data of the
>     previous incoming packet.
>
>     I believe some packet radios, such as the Chipcon CC2430, support
>     transmitting directly from the "RX FIFO". Using such a radio
>     reduces the
>     advantages of the pre-copying approach, but would be comparable to
>     decreasing the SPI communication overhead.
>
>     Regards,
>     Fredrik Österlind
>
>     Vijay Gabale wrote:
>     > Hi there,
>     >
>     > I greatly "appreciated Approaching the maximum 802.15.4 multi-hop
>     > throughput" zero copy mechanism.I have been trying to dig out how to
>     > implement this mechanism on Tmote sky platform (MSP430 + CC2420
>     radio)
>     > using TinyOS. I observed following
>     >
>     > 1) No command is available on the part of CC2420 to transmit data
>     > directly from RX fifo to TX fifo, thus avoiding unnecessary copying.
>     > If you want to do this with current design, the data has to go all
>     > over through processor memory.
>     > 2) STXON command can only transmit data from transmit fifo i.e. data
>     > in TX fifo specific location of RAM. There is no command to transmit
>     > data from RX fifo directly.
>     >
>     > I would be highly obliged if you could convey how you
>     implemented the
>     > mechanism using CC2420 radio only in Contiki esp. the features of
>     > CC2420 that you have utilized.
>     >
>     > Eagerly awaiting your early response.
>     >
>     > Thanks in advance.
>     >
>     > Regards,
>     > Vijay Gabale
>     > Senior graduate student
>     > IIT Bombay, India.
>     > http://www.cse.iitb.ac.in/~vijaygabale
>     <http://www.cse.iitb.ac.in/%7Evijaygabale>
>     > <http://www.cse.iitb.ac.in/%7Evijaygabale>
>     >
>     ------------------------------------------------------------------------
>     >
>     >
>     -------------------------------------------------------------------------
>     > This SF.Net email is sponsored by the Moblin Your Move
>     Developer's challenge
>     > Build the coolest Linux based applications with Moblin SDK & win
>     great prizes
>     > Grand prize is a trip for two to an Open Source event anywhere
>     in the world
>     > http://moblin-contest.org/redirect.php?banner_id=100&url=/
>     <http://moblin-contest.org/redirect.php?banner_id=100&url=/>
>     >
>     ------------------------------------------------------------------------
>     >
>     > _______________________________________________
>     > Contiki-developers mailing list
>     > Contiki-developers@...
>     <mailto:Contiki-developers@...>
>     > https://lists.sourceforge.net/lists/listinfo/contiki-developers
>     >
>
>
>     -------------------------------------------------------------------------
>     This SF.Net email is sponsored by the Moblin Your Move Developer's
>     challenge
>     Build the coolest Linux based applications with Moblin SDK & win
>     great prizes
>     Grand prize is a trip for two to an Open Source event anywhere in
>     the world
>     http://moblin-contest.org/redirect.php?banner_id=100&url=/
>     <http://moblin-contest.org/redirect.php?banner_id=100&url=/>
>     _______________________________________________
>     Contiki-developers mailing list
>     Contiki-developers@...
>     <mailto:Contiki-developers@...>
>     https://lists.sourceforge.net/lists/listinfo/contiki-developers
>
>
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Contiki-developers mailing list
> Contiki-developers@...
> https://lists.sourceforge.net/lists/listinfo/contiki-developers
>   

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
Vijay Gabale | 14 Aug 2008 16:54
Picon

Re: Approaching the maximum 802.15.4 multi-hop throughput

Hi Fredrik,

Thanks for your reply.

Yes, the scenario looks to become cloud-free. The doubt I had, has been answered by you aptly.

Once again, thanks for responding so early and meeting my doubts head on.

Regards,
Vijay

On Wed, Aug 13, 2008 at 8:18 PM, Fredrik Österlind <fros-02ecni/8Nmo@public.gmane.org> wrote:
Hi Vijay,

See below.

Vijay Gabale wrote:
> Hi Fredrik,
>
> Thanks a bunch for your reply. I still have doubts.
>
> For a continuous flow where packets are being received one after
> another, the scenario can be described as follows:
> transmit over SPI
> ------------------------> transmit and receive over radio
>                         ----------------------------> receive over SPI bus
>
> --------------------------------->
Yes, this is for a forwarding node. (Though of course the middle step
should be "receive over radio and then transmit over radio").

> To get maximum throughput, you need to exploit the fact of
> simultaneous transmissions over transmitter and receiver SPI bus
> considering one end is transmitting and one end is receiving.
?
> This is the usual case and forces the throughput to be around half of
> what you are getting.
Hmm, I don't quite understand. What is the maximum throughput you are
referring to? And what am I getting, what numbers do you refer to?

>
> Now assuming for an intermediate node, you have already copied packet
> in transmit buffer, and as soon as you receive a packet, you send a
> command to transmit this packet in transmit buffer.
Exactly.
> But for the packet that has been received, you still need to copy it
> to transmit buffer to send it next for which it still has to go over
> SPI bus twice.
True. The packet is fetched from the radio chip, is handled as usual by
the MAC as well as the protocol stack, and finally reaches the application.
The application, seeing that this packet should be forwarded,
"conditionally" sends the packet i.e. sends the packet down through the
stack and MAC to the radio driver. The radio driver, however, merely
copies the (potentially updated) packet to the radio chip but does not
issue the start transmission command.

> That is the problem lies in pre-copying of this second packet received
> where you have to devote requisite time of copying over the bus. While
> this is being done, you can of course receive packets but you do not
> have anything in transmit buffer to send immadiately. Am I right, here?
If there is not time to fetch the packet fully over SPI before the next
incoming packet, you'll run into problems. However, if you complete
fetching the packet, the radio can simultaneously both receive a packet
over the radio (into the RX FIFO) and over the SPI (into the TX FIFO).
>
> Kindly clarify me if I am missing any part of CC2420 driver that you
> have modified. I would be obliged if you convey the details that I
> could not retrieve out of the paper. But unless you some how eradicate
> the copying over bus, I am not able to comprehend how we should get
> throughput improvement.
>
Unfortunately I am not sure what problem you have.
Both fetching and pushing the same packet over SPI is not a problem.
The throughput improvement is due to that packet copying is removed from
the critical path, not removed entirely.
And note that the throughput achieved in multi-hop scenarios (paper) is
less than half of 250kbps.

Regarding implementation (this is already covered in the paper):
The radio driver holds a pointer to a callback function, which is
registered by the application.

RADIO DRIVER:
simple_cc2420_interrupt(void)
{
 // new packet has been received
 ...
 if (have_enqueued) {
   // notify application
   simple_cc2420_callbacks->notify();
 }
 ...
}

void
simple_cc2420_set_enqueue_mode(const struct simple_cc2420_callbacks
*callbacks)
{
 simple_cc2420_callbacks = callbacks;
 have_enqueued = 0;
 enqueue_mode = 1;
}

int
simple_cc2420_send(const void *payload, unsigned short payload_len)
{
 ...
 simple_cc2420_write(payload, payload_len);

 if (enqueue_mode) {
   have_enqueued = 1;
   return 0;
 }

 have_enqueued = 0;
 return simple_cc2420_tx();
}

APP:
protocol_stack_recv()
{
 ...
 simple_cc2420_set_enqueue_mode(&radio_call);
 // send packet via protocol stack. note. packet will not be TXed due
to enqueue mode
 simple_cc2420_clear_enqueue_mode();
 ...
}

static void
data_notify(void) {
 ...
 // callback from radio driver interrupt
 if (we want to) {
   simple_cc2420_send_enqueued();
 }
}

/ Fredrik

> Awaiting your early reply eargely.
>
> Thanks in advance.
>
> Vijay
>
> On Wed, Aug 13, 2008 at 5:11 AM, Fredrik Österlind <fros-02ecni/8Nmo@public.gmane.org
> <mailto:fros-02ecni/8Nmo@public.gmane.org>> wrote:
>
>     Hi Vijay,
>
>     We also used the TmoteSky for our experiments, and the mechanism
>     required a few (uncommitted) changes to the CC2420 driver.
>     The technique should be easy to port to any system:
>
>     You are correct in that the CC2420 does not allow transferring data
>     between the FIFOs, nor can the RX FIFO be transmitted directly,
>     however,
>     the technique evaluated in the paper does not use these features.
>     Instead if immediately forwarding incoming data, the approach employs
>     pre-copying of already received data. Hence, on a forwarding node, an
>     outgoing packet is triggered by an incoming packet, *but does not
>     contain the same data*. The outgoing packet contains the data of the
>     previous incoming packet.
>
>     I believe some packet radios, such as the Chipcon CC2430, support
>     transmitting directly from the "RX FIFO". Using such a radio
>     reduces the
>     advantages of the pre-copying approach, but would be comparable to
>     decreasing the SPI communication overhead.
>
>     Regards,
>     Fredrik Österlind
>
>     Vijay Gabale wrote:
>     > Hi there,
>     >
>     > I greatly "appreciated Approaching the maximum 802.15.4 multi-hop
>     > throughput" zero copy mechanism.I have been trying to dig out how to
>     > implement this mechanism on Tmote sky platform (MSP430 + CC2420
>     radio)
>     > using TinyOS. I observed following
>     >
>     > 1) No command is available on the part of CC2420 to transmit data
>     > directly from RX fifo to TX fifo, thus avoiding unnecessary copying.
>     > If you want to do this with current design, the data has to go all
>     > over through processor memory.
>     > 2) STXON command can only transmit data from transmit fifo i.e. data
>     > in TX fifo specific location of RAM. There is no command to transmit
>     > data from RX fifo directly.
>     >
>     > I would be highly obliged if you could convey how you
>     implemented the
>     > mechanism using CC2420 radio only in Contiki esp. the features of
>     > CC2420 that you have utilized.
>     >
>     > Eagerly awaiting your early response.
>     >
>     > Thanks in advance.
>     >
>     > Regards,
>     > Vijay Gabale
>     > Senior graduate student
>     > IIT Bombay, India.
>     > http://www.cse.iitb.ac.in/~vijaygabale
>     <http://www.cse.iitb.ac.in/%7Evijaygabale>
>     > <http://www.cse.iitb.ac.in/%7Evijaygabale>
>     >
>     ------------------------------------------------------------------------
>     >
>     >
>     -------------------------------------------------------------------------
>     > This SF.Net email is sponsored by the Moblin Your Move
>     Developer's challenge
>     > Build the coolest Linux based applications with Moblin SDK & win
>     great prizes
>     > Grand prize is a trip for two to an Open Source event anywhere
>     in the world
>     > http://moblin-contest.org/redirect.php?banner_id=100&url=/
>     <http://moblin-contest.org/redirect.php?banner_id=100&url=/>
>     >
>     ------------------------------------------------------------------------
>     >
>     > _______________________________________________
>     > Contiki-developers mailing list
>     > Contiki-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>     <mailto:Contiki-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
>     > https://lists.sourceforge.net/lists/listinfo/contiki-developers
>     >
>
>
>     -------------------------------------------------------------------------
>     This SF.Net email is sponsored by the Moblin Your Move Developer's
>     challenge
>     Build the coolest Linux based applications with Moblin SDK & win
>     great prizes
>     Grand prize is a trip for two to an Open Source event anywhere in
>     the world
>     http://moblin-contest.org/redirect.php?banner_id=100&url=/
>     <http://moblin-contest.org/redirect.php?banner_id=100&url=/>
>     _______________________________________________
>     Contiki-developers mailing list
>     Contiki-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>     <mailto:Contiki-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
>     https://lists.sourceforge.net/lists/listinfo/contiki-developers
>
>
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Contiki-developers mailing list
> Contiki-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/contiki-developers
>


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Contiki-developers mailing list
Contiki-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/contiki-developers



--
Regards,
Vijay P Gabale,
MTech (Year 1)
Indian Institute of Technology,
Bombay, India
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Contiki-developers mailing list
Contiki-developers@...
https://lists.sourceforge.net/lists/listinfo/contiki-developers
Adam Dunkels | 14 Aug 2008 19:59
Picon
Picon

Re: Problems with wpcapslip in cygwin in windows?

winslip works under windows/cygwin/winpcap for me.

The problems you get seems to come from the pcap code capturing IP 
packets that do not match the headers inside the wpcapslip code. The -3 
error is from the length of the packet not matching the length field in 
the IP packet header, and the -5 error is from the TCP checksum failing 
on TCP packets. My guess is that the IP header is not aligned in the 
same way as it is for me.

Oliver, do you have any idea what could cause this? The wpcapslip code 
is based on your cpu/native/net/wpcap.c

/adam

Andrew Pullin wrote:
> Has anyone gotten the sky-webserver to work in cygwin in windows?
> I got the WinPcap files from http://www.winpcap.org/ , and I went into 
> contiki-2.2/tools/wpcap/ and did a make .
 >
> Doing "make winslip INTERFACE=192.168.55.171" invokes:
> ../../tools/wpcapslip/wpcapslip -s /dev/com3 192.168.55.171 172.16.0.0 
> 255.255.0.0
> And the output is:
> Network address 172.16.0.0/255.255.0.0
> route add 172.16.0.0 mask 255.255.0.0 192.168.55.171
> Using local network interface with address 192.168.55.171
> slip started on ``/dev/com3''
> write_to_serial: drop packet -3
> write_to_serial: drop packet -5
> write_to_serial: drop packet -5
> write_to_serial: drop packet -3
> 
> And so forth. Visiting http://172.16.1.0 (and a number of other 
> addresses) seems to do nothing, except generate more 'write_to_serial' 
> output ; any ideas?
> The rx/tx LED's on the Tmote board seems to flash now and again, but I 
> can't correlate it to anything.
> 
> Upon exit (ctrl + c), output is:
> signal 2
> route delete 192.168.55.171
> The route specified was not found.
> 
> 
> Thanks,
> Andrew
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Contiki-developers mailing list
> Contiki-developers@...
> https://lists.sourceforge.net/lists/listinfo/contiki-developers
> 

--

-- 
Adam Dunkels <adam@...>
http://www.sics.se/~adam/

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Gmane