Comments (11)
Original comment by [email protected]
on 17 Apr 2011 at 12:34
from tinyos-main.
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 [email protected]
on 23 Aug 2011 at 1:33
- Changed state: Accepted
from tinyos-main.
NB: since IRIS (rf2x) does not currently support all of the addressing modes
needed for 6lowpan, this is not critical.
Original comment by [email protected]
on 25 Aug 2011 at 3:28
- Added labels: Priority-Low
- Removed labels: Priority-Medium
from tinyos-main.
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 [email protected]
on 1 Sep 2011 at 10:39
from tinyos-main.
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 [email protected]
on 1 Sep 2011 at 11:10
from tinyos-main.
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 [email protected]
on 1 Sep 2011 at 11:34
from tinyos-main.
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 [email protected]
on 1 Sep 2011 at 11:41
from tinyos-main.
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 [email protected]
on 1 Sep 2011 at 11:59
from tinyos-main.
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 [email protected]
on 16 Sep 2011 at 12:37
Attachments:
from tinyos-main.
Original comment by [email protected]
on 11 Jan 2012 at 5:05
- Added labels: Milestone-2.2.
from tinyos-main.
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 [email protected]
on 29 Mar 2012 at 4:02
from tinyos-main.
Related Issues (20)
- [patch] UdpP scribbles to memory it should not. HOT 3
- [patch] IPPacketC uses error return value as offset, resulting in trashed memory HOT 3
- "Make safe" does not work with the CC2420 radio chip HOT 2
- Msp430Adc12ClientAutoRVGC does not release resource. HOT 2
- PowerCycleP__startRadio task in permanent re-post spin HOT 2
- Memory Leaks : When check out some unknow critical option Libcoap allocate memory but never free HOT 3
- TOSSIM PYTHON_VERSION on Ubuntu 11.04 x86_64 HOT 3
- Shimmer I2C with msp430-gcc v4.5.3 HOT 3
- Shimmer PowerSupplyMonitor with msp430-gcc v4.5.3 HOT 2
- msp430 code accessed with bit fields HOT 1
- tos-bsl broken for shimmer family HOT 6
- [patch] CoapUdpServer infinite loop HOT 4
- [patch] CoapUdpServer fails to include the client token in many cases HOT 3
- telosb CC2420X compile error with LPL app HOT 1
- [patch] Incorrect 6lowpan PAN handling HOT 4
- rfxlink TrafficMonitorLayerP time variable shadows global one when compiling with TOSSIM HOT 3
- [patch] RF212 frame receive doesn't always complete SPI transfer HOT 2
- [patch] Dhcp6Client fails to find Status options HOT 2
- [patch] Dhcp6Client issues IPAddress.setAddress() even on RENEW HOT 1
- [patch] Dhcp6Client waits unnecessarily long between ADVERTISE and REQUEST
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from tinyos-main.