search

VijayaLakshmiMaurya / tinyos-main

Automatically exported from code.google.com/p/tinyos-main
0 stars 0 forks source link

UDPEcho compile error with IRIS platform #30

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. cd apps/UDPEcho ; 
2. make iris blip

What is the expected output? What do you see instead?

In tos/lib/net/blip/Ieee154AddressC.nc
   tos/lib/net/blip/Ieee154AddressP.nc
the Interface CC2420Config and component CC2420RadioC only works for mica 
family, not iris. iris platform use atm1281 and rf230 chips.

What version of the product are you using? On what operating system?

tinyos-main r5538 and linux fedora 13 system

Original issue reported on code.google.com by wangj...@gmail.com on 14 Apr 2011 at 6:14

GoogleCodeExporter commented 9 years ago

Original comment by philip.l...@gmail.com on 17 Apr 2011 at 12:34

GoogleCodeExporter commented 9 years ago 
This is a valid issue. I'm accepting it and we will get this in right after the 
2.1.2 release.

Original comment by sdh...@gmail.com on 23 Aug 2011 at 1:33

GoogleCodeExporter commented 9 years ago 
NB: since IRIS (rf2x) does not currently support all of the addressing modes 
needed for 6lowpan, this is not critical.

Original comment by philip.l...@gmail.com on 25 Aug 2011 at 3:28

GoogleCodeExporter commented 9 years ago 
Can I ask what you're referring to with "addressing modes" for the RF2xx? Is it 
the fact that Ieee154{Message,Packet}Layer in rfxlink only supports short 
addresses?

Original comment by jmatts...@dius.com.au on 1 Sep 2011 at 10:39

GoogleCodeExporter commented 9 years ago 
Yes -- to support 6lowpan correctly we need to support extended addressing 
mode.  For the CC2420 I implemented this by having the 6lowpan compressor 
generate complete 802.15.4 frames (with extended addresses, if required), and 
then adding a raw frame interface to the radio.  The only changes required to 
the driver were to configure the hardware address recognition to also accept a 
64-bit address, and to look for the address in the right place.

Original comment by sdh...@gmail.com on 1 Sep 2011 at 11:10

GoogleCodeExporter commented 9 years ago 
Yep, I saw the lib6lowpan frame preparing, and re-used that for the (hackish) 
patch for enabling BLIP on an RF212 which I posted to the -help list a little 
while ago (thread "[Tinyos-help] BLIP 2.0 with RF230/RF212"). Currently the 
RF212 driver doesn't implement hardware filtering, so I didn't even need to 
tweak that.

I'm just about to start work on making Ieee154{Message,Packet}Layer 
extended-address aware for our use here. If you have any requests or comments 
on how it should be done to have the highest chance of being accepted back, 
please do let me know. In the mean-time I'll opt for maintaining backwards 
compatibility (even though I'd like to change the existing interface to take a 
short/ext address structure/union).

Original comment by jmatts...@dius.com.au on 1 Sep 2011 at 11:34

GoogleCodeExporter commented 9 years ago 
That's cool. We had an enormous amount of discussion about this on -devel a 
while back, and then we fell down on the follow through...  It would be great 
to get this going.  My suggestion at this point would be to have a consistent 
raw frame interface which all radios using 802.15.4 framing can implement; we 
can then add a separate component which is platform independent and prepares 
frames for submission using the raw interface.  The real complexity comes from 
dealing with the fact that the headers may be variable-length.  This is exactly 
the issue we spent so long wrestling with in blip, in fact.  Anyways, I can't 
speak for core or anything, but that solution seems reasonable to me.

Original comment by sdh...@gmail.com on 1 Sep 2011 at 11:41

GoogleCodeExporter commented 9 years ago 
Thanks for the pointer to the -devel discussion. Was there a TEP (or draft 
even) written up as a result that I could use as a guide? Going on the email 
thread, it sounds as if it might be okay to change the API exposed by the 
Ieee154*Layer interfaces... I'll see how the code feels once I get into it.

In terms of having a consistent raw frame interface, I fully concur. I did note 
that there is a lot of naming confusion in the code around BareSend, Send and 
Ieee154Send.

Original comment by jmatts...@dius.com.au on 1 Sep 2011 at 11:59

GoogleCodeExporter commented 9 years ago 
In the hope of this being useful to the community, I've attached the changes we 
made here to extend the Ieee154*{Layer,Address} to support extended 15.4 
addresses. The patches are against our tree, which is based on the RF212+BLIP 
patch I posted to -help a while ago. I don't expect them to apply cleanly to 
trunk (sorry), but hopefully it's close enough to save a lot of time should you 
want to make use of our work.

To summarize the patches:

- I kept things fully backwards compatible (I believe), but added 
get/setAddrExt() functions as well as get/setAddrAny() to handle either case.

- As far as possible I've avoided copying, but I am returning extended 
addresses by value rather than pointer in order to keep a consistent interface 
with the existing short address interface.

- I introduced an ieee154_base_header_t with only the fcf/dns/destpan, and am 
using that instead of the ieee154_simple_header_t. Things which relied on 
sizeof(ieee154_simple_header_t) now calculate the length as appropriate. A side 
effect of this is that the header fields have to be set in order, and before 
the payload is added or things might get overwritten. I haven't encountered any 
places where this is the case, but it's a big caveat. Unfortunately I see no 
way around that limitation.

- The Ieee154Address interface was made async rather than duplicate needed 
functionality in the Ieee154*Layer components.

- The Ieee154*Layers no longer use any ActiveMessageAddress but rather 
Ieee154Address (the AM group being 8bits vs the expected 16bits in a PAN ID bit 
us earlier I might add).

Original comment by jmatts...@dius.com.au on 16 Sep 2011 at 12:37

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by sdh...@gmail.com on 11 Jan 2012 at 5:05

GoogleCodeExporter commented 9 years ago 
People interested in BLIP support for IRIS should check out this tree:

https://github.com/mmaroti/tinyos/tree/blip

If this works, then I will commit it to the tinyos-main

Original comment by mmar...@gmail.com on 29 Mar 2012 at 4:02