Re: [riot-devel] ReSupport for Microchip MRF24J40 Radio Module

[Adika Bintang Sulaeman]

Hallo Bernhard,

I'm trying to use STM32F4 Discovery with MRF24J40 transceiver, but I
didn't find the driver for this transceiver. It's a relief to see in
this mailing list that you and Tobias are working on this driver and I
hope the code will be merged soon. By the way, can I see the code you
are working on? Maybe if it is possible I can fork the code through
Github.

Thank you

> Hello Malo,
> thanks a lot for your hint about the atzb-a-233-xpro module.
> I guess RIOT should support this module out of the box (as a reference for
> debugging).
>
> Best regards,
> Bernhard
>
> ---
>
> Hello Peter,
> shure - you are right - Tobias is working on it and I stay in contact
> with him.
>
> Thanks also a lot for your help!
>
> Best regards
> Bernhard
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] address option fields inside of NA/NS

[Alexander Aring]

Hi,

while hacking the short address handling for Linux, I _maybe_ stumble
over some issue.
_Maybe_, because I am not sure how it really should work.

The issue is that when setting src_len to 2 then a short address will be
part of source/target link address option only.

For my knowledge the setting of "src_len" is wrong, the interface can
really have two mac addresses at the same time. According to 802.15.4
the short address is somewhat optional. If they is available then add
them to the address option fields. (Then you have two address option
fields).

General proceeding is (in my opinion), copy from irc:

16:37 < eintopf> I think extended address address field for extended
address (length==2) need to be always there, then if the short address
is valid (not 0x or 0xfffe, for unicast neighbour) then add also a
second option for short address.

16:50 < eintopf> so in NS/NA source/target link address option fields:
extended address _always_ AND short address if link short address is
valid (not 0x or 0xfffe).

This is how I did it for linux.

- Alex
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] UDP travic between RIOT device and Raspberry PI 6LoWPAN seems not to work

[Alexander Aring]

Hi,

On Sun, Mar 13, 2016 at 08:36:21AM +0100, Martine Lenders wrote:
> Hi,
> 
> Bernhard Nägele  writes:
> > thank you for that hint. Is it sufficient to enable that modul in the
> > Makefile.dep file in the main-folder, or should I add this to the Makefile
> > in my example//Makefiles? Are there any changes needed elsewhere?
> 
> it is pretty insignificant where you enable it. You can even set
> USEMODULE=gnrc_sixlowpan_iphc_nhc as a local environment variable to
> make with the same effect (which IMHO is the cleanest approach since
> it does not change any files, so in case you forget about that it
> isn't hurting you afterwards ;-)):
> 

btw:

I want to change the default handling here inside the Linux kernel.

Compression for nhc at transmit side is turned off and can be turned on
by a debugfs UAPI which doesn't exist right now.
Same handling like the "compression flag" for rfc6775 stateful
compression, just adapted for nhc.

Receive handling is default on for nhc de-compression.

This is a small open task inside the linux-kernel, everybody is welcome
to send-patches, see [0].

I currently have other priorities e.g. short address handling.

- Alex

[0] http://wpan.cakelab.org/#_developing
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel