Re: [riot-devel] Fwd: RIOT - CC26x0 Port ready-ness

[Michael Frey]

Hi,

Am Di, 6.09.2016, 12:17, schrieb Darren Bainbridge:

> I have started looking at the different repos for C26x0.
> Who is or owns the SWIE-IO repo. when reading the main RIOT wiki it's not

The repositories are owned by Swissmic [1], a swiss startup.

> mentioned as a C26x0 development branch also it looks quite advanced.

The original work was started by Leon George, a student at FUB (afair).
Florent-Valéry Coen contributed the radio code - particularly BLE. Florent
was also with SWIE, but left at the end of July for his master thesis.
Nicholas C. Jackson provided support for the programmer/debugger. I don't
know if Nicholas is doing this in his spare time or if he is with a
company/university. At least that's my understanding. If I missed to
mention somebody I'm really sorry!

Providing support for CC26x0 is part of Leons thesis and hence, he "owns"
the pull request. Florent and I decided to work on one repository (the
swie repository) in different branches. The idea was to create a new
branch which would include the feature branches we were working on and
open pull requests from that particular branch.

However, since we both don't work at SWIE anymore we probably need another
place to clean up the code and contribute to it. The easiest way is
probably that I'm fetching the old branch, clean it up and commit to the
PR branch (iff features are working). But I'm open for other suggestions!

Best,
 Michael


[1] https://www.swie.io/
-- 
Dipl.-Inf. (FH), M. Sc. Michael Frey
Humboldt-Universität zu Berlin
Department of Computer Science
Rudower Chaussee 25
12489 Berlin, Germany

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

Re: [riot-devel] Fwd: RIOT - CC26x0 Port ready-ness

[Darren Bainbridge]

Hi Michael,
Thanks for replying.

I have started looking at the different repos for C26x0.
Who is or owns the SWIE-IO repo. when reading the main RIOT wiki it's not
mentioned as a C26x0 development branch also it looks quite advanced.

Darren

On Tue, Sep 6, 2016 at 8:56 PM, Michael Frey 
wrote:

> Hi,
>
> Am Di, 6.09.2016, 08:50, schrieb Darren Bainbridge:
>
> > I would like to connect with any developers working on a cc26x0 port.
>
> I worked for a start-up which intended to use RIOT and the CC2650STK as a
> platform for a future product. I left the company and had no time since
> then to continue to work on it, which is a shame since I've had the
> assumption that it wouldn't be that much work to a have basic working
> radio.
>
> > I would like to understand the ready-ness of any branches and willingness
>
> The repository is over here
>
> https://github.com/SWIE-IO/RIOT
>
> and the main branch is
>
> https://github.com/SWIE-IO/RIOT/tree/swie_802154_frey
>
> We ran into some timer issues. If you have some time left, it would be
> amazing if you would look into this. Also the actual interface to RIOT for
> the driver is missing (meaning RIOT/drivers/cc26x0).
>
> The IEEE 802.15.4 part needs some work and there was a bug I wanted to fix
> (which should be doable).
>
> I would like to do some refactoring of the radio code (the naming is not
> really consistent since three different people were working on it) and we
> could talk about the radio again? This would actually allow me to give you
> a (better) summary what's working and what's not, and how things are
> structured - if that's okay for you?
>
> Anyway, I'm wondering what the best way would be to "centralize" the code
> again. Clearly, I'm not going to contribute to the repository of my former
> employer and the code is nowadays somehow spread across different
> repositories.
>
> Best,
>  Michael
> --
> Dipl.-Inf. (FH), M. Sc. Michael Frey
> Humboldt-Universität zu Berlin
> Department of Computer Science
> Rudower Chaussee 25
> 12489 Berlin, Germany
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Fwd: RIOT - CC26x0 Port ready-ness

[Michael Frey]

Hi,

Am Di, 6.09.2016, 08:50, schrieb Darren Bainbridge:

> I would like to connect with any developers working on a cc26x0 port.

I worked for a start-up which intended to use RIOT and the CC2650STK as a
platform for a future product. I left the company and had no time since
then to continue to work on it, which is a shame since I've had the
assumption that it wouldn't be that much work to a have basic working
radio.

> I would like to understand the ready-ness of any branches and willingness

The repository is over here

https://github.com/SWIE-IO/RIOT

and the main branch is

https://github.com/SWIE-IO/RIOT/tree/swie_802154_frey

We ran into some timer issues. If you have some time left, it would be
amazing if you would look into this. Also the actual interface to RIOT for
the driver is missing (meaning RIOT/drivers/cc26x0).

The IEEE 802.15.4 part needs some work and there was a bug I wanted to fix
(which should be doable).

I would like to do some refactoring of the radio code (the naming is not
really consistent since three different people were working on it) and we
could talk about the radio again? This would actually allow me to give you
a (better) summary what's working and what's not, and how things are
structured - if that's okay for you?

Anyway, I'm wondering what the best way would be to "centralize" the code
again. Clearly, I'm not going to contribute to the repository of my former
employer and the code is nowadays somehow spread across different
repositories.

Best,
 Michael
-- 
Dipl.-Inf. (FH), M. Sc. Michael Frey
Humboldt-Universität zu Berlin
Department of Computer Science
Rudower Chaussee 25
12489 Berlin, Germany

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

Re: [riot-devel] MRF24J40 radio module driver

[Alexander Aring]

Hi,

On 09/06/2016 10:00 AM, Oleg Hahm wrote:
> Hey Alex!
> 
> On Tue, Sep 06, 2016 at 08:48:13AM +0200, Alexander Aring wrote:
>>> In case netopt is "NETOPT_SRC_LEN" and the value is 
>>> "IEEE802154_LONG_ADDRESS_LEN" (which is defined as 8U), this module sets 
>>> the "NETDEV2_IEEE802154_SRC_MODE_LONG" flag.
>>>
>>> https://github.com/RIOT-OS/RIOT/blob/master/drivers/netdev2_ieee802154/netdev2_ieee802154.c#L173
>>>
>>
>> I don't know why this goes down through the driver layer. The address
>> filter doesn't need such information if you use as source address long
>> or short.
>>
>> For me it's unclear for what this sourc_len really is made for. I would
>> suggest to use the best address setting which do the most smallest
>> payload. Sure, there exists situation to overwrite such setting - but
>> this should be done not as an interface setting.
> 
> Maybe I miss something, but how should the driver know which L2 address format
> is expected at the receiver's side?
> 

Why the driver needs to know about that? The driver doesn't build mac
frames. Well, there exists hardmac transceivers which do building mac
frames on transceiver side. I never had some hardmac transceiver so I am
unsure how they really work and which API they offer.

I know that neighbour discovery knows if neighbour has short and
extended address. For purely L2 solution you might need to have
coordinator support etc. It's job of some upper-layer to provide such
mapping, or you do some force setting like NETOPT_SRC_LEN which I
suggest what it is.

I can understand that this goes to the driver layer for some hardmac
transceivers which accepts mac payload data only and builds the mac frame
on transceivers side.

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

Re: [riot-devel] MRF24J40 radio module driver

[Oleg Hahm]

Hey Alex!

On Tue, Sep 06, 2016 at 08:48:13AM +0200, Alexander Aring wrote:
> > In case netopt is "NETOPT_SRC_LEN" and the value is 
> > "IEEE802154_LONG_ADDRESS_LEN" (which is defined as 8U), this module sets 
> > the "NETDEV2_IEEE802154_SRC_MODE_LONG" flag.
> > 
> > https://github.com/RIOT-OS/RIOT/blob/master/drivers/netdev2_ieee802154/netdev2_ieee802154.c#L173
> >
> 
> I don't know why this goes down through the driver layer. The address
> filter doesn't need such information if you use as source address long
> or short.
> 
> For me it's unclear for what this sourc_len really is made for. I would
> suggest to use the best address setting which do the most smallest
> payload. Sure, there exists situation to overwrite such setting - but
> this should be done not as an interface setting.

Maybe I miss something, but how should the driver know which L2 address format
is expected at the receiver's side?

Cheers,
Oleg
-- 
HARDFAIL("Not enough magic.");
linux-2.4.0-test2/drivers/block/nbd.c


signature.asc
Description: PGP signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Fwd: RIOT - CC26x0 Port ready-ness

[Darren Bainbridge]

Hello RIOT Devel,

I'm looking at adopting RIOT for a new commercial product build using the
CC2650 chipset.
I would like to connect with any developers working on a cc26x0 port.
I would like to understand the ready-ness of any branches and willingness
to collaborate. I'm happy to contribute to a project to help make it work, if
it's looking viable for a stable product release.

*Regards Darren*

Ph: 0210350341
Skype: darren.bainbridge
Linkedin: darren-bainbridge

http://www.myapiary.co.nz/
http://findmyhive.com/
[image: Inline image 2]
DISCLAIMER:  This electronic message and any files transmitted with it are
confidential and intended solely for the use of the individual or entity to
whom they are addressed. If you have received this email in error please
notify the system manager. This message contains confidential information
and is intended only for the individual named. If you are not the named
addressee you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system. If you are not
the intended recipient you are notified that disclosing, copying,
distributing or taking any action in reliance on the contents of this
information is strictly prohibited
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] MRF24J40 radio module driver

[Alexander Aring]

Hi,

not sure if I should open this discussion in this thread. :-/

On 09/05/2016 11:45 PM, Peter Kietzmann wrote:
> Hi Neo,
> 
> if I see it correctly, the procedure is as follows:
> 
> gnrc_networking uses the the gnrc_ipv6 module which automatically pulls in 
> it's dependencies. This is, among others, gnrc_ipv6_netif.
> 
> https://github.com/RIOT-OS/RIOT/blob/master/Makefile.dep#L280
> 
> Once this was defined, auto_init will call the "init by netif device" 
> function.
> 
> https://github.com/RIOT-OS/RIOT/blob/master/sys/auto_init/auto_init.c#L227
> 
> This function will set the net option "NETOPT_SRC_LEN" to 8 Byte, which is 
> the length for long hardware addresses.
> 
> https://github.com/RIOT-OS/RIOT/blob/master/sys/net/gnrc/network_layer/ipv6/netif/gnrc_ipv6_netif.c#L833
> 
> The at86rf2xx driver does not implement this option itself and passes it to 
> the netdev2_ieee802154 module.
> 
> https://github.com/RIOT-OS/RIOT/blob/master/drivers/at86rf2xx/at86rf2xx_netdev.c#L580
> 
> In case netopt is "NETOPT_SRC_LEN" and the value is 
> "IEEE802154_LONG_ADDRESS_LEN" (which is defined as 8U), this module sets the 
> "NETDEV2_IEEE802154_SRC_MODE_LONG" flag.
> 
> https://github.com/RIOT-OS/RIOT/blob/master/drivers/netdev2_ieee802154/netdev2_ieee802154.c#L173
>

I don't know why this goes down through the driver layer. The address
filter doesn't need such information if you use as source address long
or short.

For me it's unclear for what this sourc_len really is made for. I would
suggest to use the best address setting which do the most smallest
payload. Sure, there exists situation to overwrite such setting - but
this should be done not as an interface setting.

This is the way what I have in my mind to do in Linux.

side note:
interessting is that, in 6LoWPAN it depends on L3 address and
fragmentation if you use short or long address to produce the smallest
payload.

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