[riot-devel] Wakaama example on lwIP IPv4 and IPv6

[Ken Bannister]

Everyone,

I have been able to extend the Wakaama example to build for lwIP sock 
IPv4 and IPv6 [1]. This extension builds on the great recent work by 
@gchorcht, @wosym, and others to enable IPv4 for lwIP.


I decided to just post a notice rather than create a WIP PR. I had to 
#ifdef-out code related to netif functions, so an implementation for 
lwIP, as @miri64 has started with #9343, would be useful first. Also, 
I'm not sure how extensively we want to start bringing in IPv4 for 
examples. I had to add several #ifdefs for things like `ipvN_addr_equal()`.


At any rate, the example should provide some food for thought on the 
issues around supporting both IP versions. It's also valuable to me to 
demo RIOT running LwM2M on IPv4!


Ken

[1] https://github.com/kb2ma/RIOT/tree/wakaama/lwip_ipv4_poc

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

[riot-devel] Release 2019.10

[Ken Bannister]

Dear RIOTers,

We are happy to announce the 21st official release of RIOT:

--- * RIOT 2019.10 * ---

The 2019.10 release includes:

 - initial support for SUIT firmware updates
 - USB CDC-ACM serial communication
 - complete rewrite of TI CC110x radio driver
 - initial support for IPv6 fragmentation
 - DTLS support in the sock networking stack
 - complete blockwise messaging for gcoap and nanocoap
 - as always, bug fixes and documentation updates

About 460 pull requests, composed of 950 commits, have been merged since the
last release, and about 60 issues have been solved. 57 people 
contributed with

code in 105 days. Approximately 2000 files have been touched with 129000
insertions and 25000 deletions.

You can download the RIOT release from Github by cloning the repository
and checkout the release tag [1] or by downloading the tarball [2], and
look up the release notes for further details [3].

A big thank you to everybody who contributed! Special thanks to previous
release managers @miri64, @MrKevinWeiss, and @PeterKietzmann for offline
advice. Many thanks also to release testers @aabadie, @cladmi, @fjmolinas,
@jia200x, @leandrolanzieri, and @smlng.

Your friendly neighborhood release manager,
Ken Bannister


[1] https://github.com/RIOT-OS/RIOT/tree/2019.10

[2] https://github.com/RIOT-OS/RIOT/archive/2019.10.tar.gz

[3] https://github.com/RIOT-OS/RIOT/releases/tag/2019.10

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

[riot-devel] Release 2019.10 - Hard feature freeze now effective

[Ken Bannister]

|Dear RIOTers, We've created the 2019.10 release branch, so we are now 
officially in feature freeze. This means from now only bugfixes will be 
backported to the `2019.10-branch`. If anyone has any bugfixes or 
documentation improvements that they feel should be part of this 
release, please let me know. New features can still be merged into 
master during this period. The tracking issue of Release candidate 1 [1] 
is opened. If you want to help with testing (and you know you do!), 
please put your name against the corresponding item in the linked 
spreadsheet. Thanks all for the awesome work! Ken [1] 
https://github.com/RIOT-OS/Release-Specs/issues/140|


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

[riot-devel] Release 2019.10 - Soft feature freeze now effective

[Ken Bannister]

|Dear RIOTeers, The soft feature freeze (for high impact PRs) is now
effective. I have advanced the milestone for the designated high impact
PRs to 2020.01 [1]. As a gentle reminder: the final feature freeze (for
all PRs) is 10 October. As I write this, there are 70 open PRs tagged
for the release. About 35 of those are relatively actively being worked
on. Let's do what we can to get those in. Respond to comments, fixup,
push, approve, squash, merge, repeat! Ken [1]
https://github.com/RIOT-OS/RIOT/wiki/High-impact-for-2019.10 |



pEpkey.asc
Description: application/pgp-keys
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Release 2019.10 - dates and feature requests

[Ken Bannister]

|Dear RIOTers,


The release dates for the upcoming release cycle are fixed as follows:

- 01.10.2019 - soft feature freeze, for high impact features

- 10.10.2019 - hard feature freeze, for all features

- 31.10.2019 - Release date
|
|
|
|Please send your suggestions for features which you would like to see
merged during this release cycle. I'm also happy to discuss with those
at the summit over the next couple of days.


Best regards, and happy hacking!

Ken Bannister|


pEpkey.asc
Description: application/pgp-keys
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] LWM2M using ethos

[Ken Bannister]

I am a user of these tools rather than a developer, and do not know 
enough of the internals to answer your questions. It may even be 
possible that you can use ethos/tap for this application, and I just 
couldn't find the right configuration. Perhaps someone else can chime in.


On 6/25/19 3:25 AM, Ashim Asharaph wrote:

Dear Ken

Thank you very much! Everything worked like a charm. I just have a few follow 
up questions. It seems that usually tap is preferred over tun for most of the 
RIOT applications. Why is this? Also is it possible to get a tun interface set 
up with ethos?

Kind regards
Ashim Asharaph






Ken Bannister  06/22/19 1:34 PM >>>

[The e-mail server of the sender could not be verified (SPF Record)]

I forgot one other thing. You'll need the header for SLIP parameters.
Grab the one from gcoap and copy it to the location of your Makefile [1].

[1]
https://github.com/RIOT-OS/RIOT/blob/master/examples/gcoap/slipdev_params.h


On 6/22/19 7:23 AM, Ken Bannister wrote:

Hi Ashim,

I tried to get ethos to work with a samr21-xpro, but failed. I was not
permitted to assign an IP address to the wired interface. Rather than
pursue that, I was successful with SLIP, the legacy border router tool.

See the gist for the Wakaama Makefile modified for SLIP [1]. Compile
and flash that, which uses fd00:dead:beef for the network prefix. In a
separate terminal, set up a TUN interface on your workstation. I use
Ubuntu 19.04:

$ sudo dist/tools/tunslip/tunslip6 -s ttyUSB0 -t tun0
fd00:dead:beef::1/64

Then in the terminal for the border router, configure the interface:

> ifconfig 7 add unicast fd00:dead:beef::2/64
> nib neigh add 7 fd00:dead:beef::1

Then you should be able to startup the Wakaama client to talk to the
LwM2M server.

Ken

[1] https://gist.github.com/kb2ma/462a1375ee50735cd58fb3aac7c3c021


On 6/21/19 10:29 AM, Ashim Asharaph wrote:

Dear RIOT developers

I would like to get LWM2M communication through ethos between a board
and computer (without using a border router). It is necessary to do
it this way because the board does not have any wireless or ethernet
capability. I am testing the idea on a samr21-xpro for now. I am
using the wakaama example from one of the PRs and have enabled ethos.


The problem is that the wired interface does not have a global ip
address. The wakaama client can register itself with the Leshan
server but the server cannot communicate with the client due to the
absence of a global address. I have also tried binding the Leshan
server to the tap interface, but that does not work. Any suggestions
would be highly appreciated.


Kind regards
Ashim Asharaph


___
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

___
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

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

Re: [riot-devel] LWM2M using ethos

[Ken Bannister]

I forgot one other thing. You'll need the header for SLIP parameters. 
Grab the one from gcoap and copy it to the location of your Makefile [1].


[1] 
https://github.com/RIOT-OS/RIOT/blob/master/examples/gcoap/slipdev_params.h



On 6/22/19 7:23 AM, Ken Bannister wrote:

Hi Ashim,

I tried to get ethos to work with a samr21-xpro, but failed. I was not 
permitted to assign an IP address to the wired interface. Rather than 
pursue that, I was successful with SLIP, the legacy border router tool.


See the gist for the Wakaama Makefile modified for SLIP [1]. Compile 
and flash that, which uses fd00:dead:beef for the network prefix. In a 
separate terminal, set up a TUN interface on your workstation. I use 
Ubuntu 19.04:


   $ sudo dist/tools/tunslip/tunslip6 -s ttyUSB0 -t tun0 
fd00:dead:beef::1/64


Then in the terminal for the border router, configure the interface:

   > ifconfig 7 add unicast fd00:dead:beef::2/64
   > nib neigh add 7 fd00:dead:beef::1

Then you should be able to startup the Wakaama client to talk to the 
LwM2M server.


Ken

[1] https://gist.github.com/kb2ma/462a1375ee50735cd58fb3aac7c3c021


On 6/21/19 10:29 AM, Ashim Asharaph wrote:

Dear RIOT developers

I would like to get LWM2M communication through ethos between a board 
and computer (without using a border router). It is necessary to do 
it this way because the board does not have any wireless or ethernet 
capability. I am testing the idea on a samr21-xpro for now. I am 
using the wakaama example from one of the PRs and have enabled ethos.



The problem is that the wired interface does not have a global ip 
address. The wakaama client can register itself with the Leshan 
server but the server cannot communicate with the client due to the 
absence of a global address. I have also tried binding the Leshan 
server to the tap interface, but that does not work. Any suggestions 
would be highly appreciated.



Kind regards
Ashim Asharaph


___
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

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

Re: [riot-devel] LWM2M using ethos

[Ken Bannister]

Hi Ashim,

I tried to get ethos to work with a samr21-xpro, but failed. I was not 
permitted to assign an IP address to the wired interface. Rather than 
pursue that, I was successful with SLIP, the legacy border router tool.


See the gist for the Wakaama Makefile modified for SLIP [1]. Compile and 
flash that, which uses fd00:dead:beef for the network prefix. In a 
separate terminal, set up a TUN interface on your workstation. I use 
Ubuntu 19.04:


   $ sudo dist/tools/tunslip/tunslip6 -s ttyUSB0 -t tun0 
fd00:dead:beef::1/64


Then in the terminal for the border router, configure the interface:

   > ifconfig 7 add unicast fd00:dead:beef::2/64
   > nib neigh add 7 fd00:dead:beef::1

Then you should be able to startup the Wakaama client to talk to the 
LwM2M server.


Ken

[1] https://gist.github.com/kb2ma/462a1375ee50735cd58fb3aac7c3c021


On 6/21/19 10:29 AM, Ashim Asharaph wrote:

Dear RIOT developers

I would like to get LWM2M communication through ethos between a board and 
computer (without using a border router). It is necessary to do it this way 
because the board does not have any wireless or ethernet capability. I am 
testing the idea on a samr21-xpro for now. I am using the wakaama example from 
one of the PRs and have enabled ethos.


The problem is that the wired interface does not have a global ip address. The 
wakaama client can register itself with the Leshan server but the server cannot 
communicate with the client due to the absence of a global address. I have also 
tried binding the Leshan server to the tap interface, but that does not work. 
Any suggestions would be highly appreciated.


Kind regards
Ashim Asharaph


___
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] gcoap blockwise transfer

[Ken Bannister]

Ashim, Brenton and I were able to resolve the issues they experienced. 
The issue link below includes examples to test reception of a large 
payload with gcoap PR #11057.



Ken


On 5/9/19 6:21 PM, Ken Bannister wrote:


Sorry to hear you're having issues. It will be easier to track this 
problem in a GitHub issue, so I created one [1]. Let's move the 
discussion there.



Ken


[1] https://github.com/kb2ma/RIOT/issues/29



On 5/9/19 11:37 AM, Ashim Asharaph wrote:

Dear Ken

So I decided to use the gcoap blockwise transfer from PR #11057 with 
a GET request. On native it works fine. When testing on real hardware 
using two samr21-xpro boards with one running the gnrc _border_router 
example, the block transfer only completes successfully about 50% of 
the time with a 50kB file and 128 byte packets. The application says 
"gcoap: timeout for msg ID x". The time at which the timeout 
occurs seems random at any point during the blockwise transfer.


The final plan is to integrate the gcoap with wakaama and use both 
together for an OTA firmware update. When the integrated version is 
used, the success rate is about 5%. Are there any parameters or code 
that could be tweaked on either the RIOT application or on the 
Californium file server to improve the success rate? What could be 
causing the issue or how can I try to determine the problem?


Kind regards
Ashim Asharaph


>>> Ken Bannister  05/02/19 4:45 PM >>>
[The e-mail server of the sender could not be verified (SPF Record)]

Hi Ashim and welcome to RIOT!


As you say, we have two CoAP tools -- nanocoap and gcoap. Here are 
your options.



In the latest release, 2019.04, nanocoap has server-based block 
capabilities. So, it would work if Californium acted as a client and 
PUT/POSTed the file contents to your nanocoap server. See the 
nanocoap_server example in the source repository and documentation at 
Modules > Networking > Nanocoap.



There also are PRs for full client/server block capabilities. In this 
case it's probably easier to use gcoap because it's fully documented, 
but a nanocoap client would work, too. See #11057 for the final PR in 
the series. If you build the source documentation (make doc), you 
will find detailed instructions and links to examples. See the 
Modules > Networking > Gcoap topic.



I am the author of the PR series, and would appreciate you testing it 
out. We are actively (if slowly) reviewing and merging these PRs.



Ken


On 5/2/19 2:05 PM, Ashim Asharaph wrote:

Dear RIOT developers

I'm sending a GET request from gcoap running on native to a
californium server hosting a file. The file is about 56kB in
size. I can receive the file correctly (multiple blocks) when
using Californium Copper. I can only receive one 512 byte block
of data through gcoap. I have tried changing GCOAP_PDU_BUF_SIZE
but this only affects whether I can receive the one block. How do
I receive multiple blocks? Has coap blockwise transfer been
implemented in gcoap? Is nanocoap a suitable alternative for
receiving the file?

Kind regards
Ashim Asharaph

___devel mailing 
listdevel@riot-os.orghttps://lists.riot-os.org/mailman/listinfo/devel


___
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
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] gcoap blockwise transfer

[Ken Bannister]

Sorry to hear you're having issues. It will be easier to track this 
problem in a GitHub issue, so I created one [1]. Let's move the 
discussion there.



Ken


[1] https://github.com/kb2ma/RIOT/issues/29



On 5/9/19 11:37 AM, Ashim Asharaph wrote:

Dear Ken

So I decided to use the gcoap blockwise transfer from PR #11057 with a 
GET request. On native it works fine. When testing on real hardware 
using two samr21-xpro boards with one running the gnrc _border_router 
example, the block transfer only completes successfully about 50% of 
the time with a 50kB file and 128 byte packets. The application says 
"gcoap: timeout for msg ID x". The time at which the timeout 
occurs seems random at any point during the blockwise transfer.


The final plan is to integrate the gcoap with wakaama and use both 
together for an OTA firmware update. When the integrated version is 
used, the success rate is about 5%. Are there any parameters or code 
that could be tweaked on either the RIOT application or on the 
Californium file server to improve the success rate? What could be 
causing the issue or how can I try to determine the problem?


Kind regards
Ashim Asharaph


>>> Ken Bannister  05/02/19 4:45 PM >>>
[The e-mail server of the sender could not be verified (SPF Record)]

Hi Ashim and welcome to RIOT!


As you say, we have two CoAP tools -- nanocoap and gcoap. Here are 
your options.



In the latest release, 2019.04, nanocoap has server-based block 
capabilities. So, it would work if Californium acted as a client and 
PUT/POSTed the file contents to your nanocoap server. See the 
nanocoap_server example in the source repository and documentation at 
Modules > Networking > Nanocoap.



There also are PRs for full client/server block capabilities. In this 
case it's probably easier to use gcoap because it's fully documented, 
but a nanocoap client would work, too. See #11057 for the final PR in 
the series. If you build the source documentation (make doc), you will 
find detailed instructions and links to examples. See the Modules > 
Networking > Gcoap topic.



I am the author of the PR series, and would appreciate you testing it 
out. We are actively (if slowly) reviewing and merging these PRs.



Ken


On 5/2/19 2:05 PM, Ashim Asharaph wrote:

Dear RIOT developers

I'm sending a GET request from gcoap running on native to a
californium server hosting a file. The file is about 56kB in size.
I can receive the file correctly (multiple blocks) when using
Californium Copper. I can only receive one 512 byte block of data
through gcoap. I have tried changing GCOAP_PDU_BUF_SIZE but this
only affects whether I can receive the one block. How do I receive
multiple blocks? Has coap blockwise transfer been implemented in
gcoap? Is nanocoap a suitable alternative for receiving the file?

Kind regards
Ashim Asharaph

___devel mailing 
listdevel@riot-os.orghttps://lists.riot-os.org/mailman/listinfo/devel


___
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] gcoap blockwise transfer

[Ken Bannister]

Hi Ashim and welcome to RIOT!


As you say, we have two CoAP tools -- nanocoap and gcoap. Here are your 
options.



In the latest release, 2019.04, nanocoap has server-based block 
capabilities. So, it would work if Californium acted as a client and 
PUT/POSTed the file contents to your nanocoap server. See the 
nanocoap_server example in the source repository and documentation at 
Modules > Networking > Nanocoap.



There also are PRs for full client/server block capabilities. In this 
case it's probably easier to use gcoap because it's fully documented, 
but a nanocoap client would work, too. See #11057 for the final PR in 
the series. If you build the source documentation (make doc), you will 
find detailed instructions and links to examples. See the Modules > 
Networking > Gcoap topic.



I am the author of the PR series, and would appreciate you testing it 
out. We are actively (if slowly) reviewing and merging these PRs.



Ken


On 5/2/19 2:05 PM, Ashim Asharaph wrote:

Dear RIOT developers

I'm sending a GET request from gcoap running on native to a 
californium server hosting a file. The file is about 56kB in size. I 
can receive the file correctly (multiple blocks) when using 
Californium Copper. I can only receive one 512 byte block of data 
through gcoap. I have tried changing GCOAP_PDU_BUF_SIZE but this only 
affects whether I can receive the one block. How do I receive multiple 
blocks? Has coap blockwise transfer been implemented in gcoap? Is 
nanocoap a suitable alternative for receiving the file?


Kind regards
Ashim Asharaph

___
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] Wakaama_RIOT

[Ken Bannister]

Thanks, José. I have been reviewing the PR, and I agree it definitely is 
usable. I think Leandro has addressed everything to this point.


Brenton, as you can see on the PR, you should be able to build and run 
the example. Please add your comments on that PR as well.


Thanks,
Ken

On 4/10/19 2:34 PM, José Alamos wrote:

Hello Brenton,

There's an open PR with a basic LWM2M Wakaama client for RIOT here [1].
You can maybe give it a look.

Does this solve your issue?

Cheers,
José

[1]: https://github.com/RIOT-OS/RIOT/pull/11036

On Wed, 2019-04-10 at 15:11 +0200, Brenton Chetty wrote:

Hey guys, sorry to worry you'll. I just graduated, and I'm an intern.
I need to update a STM32 device over the air using a Leshan Server,
and a Wakaama Client (RIOT). I managed to send a .bin file from the
Server to the RIOT_Wakaama client using the Linux native interface. I
used the 2015 RIOT_Wakaama client example created by Robby14
(Github), as i do not know how to use the Wakaama pkg in the RIOT
base. Any ideas on how i should proceed with this task? How do I use
the wakaama pkg? Any advice would be greatly appreciated!

With thanks
Brenton
___
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

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

Re: [riot-devel] Hello world stopped working

[Ken Bannister]

I replaced the package using this same approach. [1]

Ken

[1] https://github.com/RIOT-OS/RIOT/issues/9248#issuecomment-416532408


On 12/6/18 8:11 PM, Kees Bakker wrote:

For Ubuntu 18.04 there is a possibility to install the PPA. See [1].
What I did was to first remove (uninstall) all arm-none-eabi packages, 
and
I also had to uninstall the gcc-avr packages due to a conflict with 
/usr/lib/libcc1.so.0.0.0


Next, enable the PPA and install gcc-arm-embedded. That's it.

[1] https://launchpad.net/~team-gcc-arm-embedded/+archive/ubuntu/ppa

On 06-12-18 08:49, smlng wrote:

Hi all,

Joakim is right - there are several reports of broken/non-working 
firmwares

compiled with the arm-none-eabi-gcc and libs provided by Ubuntu:Bionic

see for instance:

- 
https://bugs.launchpad.net/ubuntu/+source/gcc-arm-none-eabi/+bug/1767223

- https://bugs.launchpad.net/ubuntu/+source/newlib/+bug/1768125

That's why our riotdocker image (and with that the Murdock-CI) uses the
official releases instead of the apt-packages.

Best,
   Sebastian


On 6. Dec 2018, at 08:43, Joakim Nohlgård  wrote:

Hi,
I don't believe that we require GCC 7 anywhere, it should still work
fine to build with for example the ARM provided GCC 6 release, or the
older Ubuntu/Debian toolchains. It seemed more like there is a problem
with the Ubuntu packaged arm-none-eabi toolchain that produces broken
binaries.

/Joakim

On Wed, Dec 5, 2018 at 10:05 PM Kees Bakker  wrote:

Hey Alex,

Thanks, that did the trick. Wow, what happened with that compiler?
I now see that we have PR #10404 and a few issues about it. Hmm,
that PR could have given me a warning.
-- Kees

On 05-12-18 21:20, Alexandre Abadie wrote:

Hi Kees,

You need a more recent version of the GNU ARM compiler, 7.x, and 
you only have 6.3. The recommended toolchain is the official one 
from ARM that can be downloaded at [1].


Just uncompress the archive somewhere in your filesystem (in /opt 
for example) and update your PATH variable. This is what I do and 
it works well.


Cheers!

Alex

[1] 
https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads


- Le 5 Déc 18, à 21:09, Kees Bakker k...@sodaq.com a écrit :


Hi,

This may sound like a stupid question, but I can't get output
from hello world anymore. On my Sodaq Explorer and also on my
Sodaq One.

I have been away from RIOT for a few weeks and now that I get back
there is no output on UART0, and the LEDs don't work either.

Since last time, I upgraded my Ubuntu to 18.04. It has a newer 
compiler.

Could that be it?

binutils-arm-none-eabi  2.27-9ubuntu1+9
gcc-arm-none-eabi  15:6.3.1+svn253039-1build1
gdb-arm-none-eabi  7.10-1ubuntu3+9
libnewlib-arm-none-eabi  2.4.0.20160527-3
libstdc++-arm-none-eabi-newlib 15:6.3.1+svn253039-1+10

If not, what else could it be? It must be something obvious, but
so far I haven't found it.
--
Kees
___
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

___
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

___
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

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

Re: [riot-devel] Lifting the 50 characters commit first line limit?

[Ken Bannister]

Martine and I discussed this over a PR a few months ago. The outcome was 
to update the Good Pull Request wiki page [1], which basically says what 
has just been discussed on this thread. Good to spread the word and 
share the link. :-)


Ken

[1] 
https://github.com/RIOT-OS/RIOT/wiki/Guidelines-for-Creating-a-Good-Pull-Request



On 10/10/2018 03:31 AM, Joakim Nohlgård wrote:

+1 what Martine wrote.

(I was composing a similar message when you beat me to it)
/Joakim

Den ons 10 okt. 2018 08:51Martine Lenders > skrev:


Hi Pekka,

the 50 chars is just the warning bound. You can go up to 70 until
the commit message check fails on you. Longer will make GitHub
break the commit message in the webview with the dreaded […] ;-).

My usual approach is to boil down the summary to the bare minimum
within these constraints (even using just the module name instead
of the full path) and go into details in the following lines of
the commit message.

Regards,
Martine

Am Mi., 10. Okt. 2018 um 08:06 Uhr schrieb Nikander Pekka
mailto:pekka.nikan...@aalto.fi>>:

[Refactoring the nRF520 mega-PR to follow the standards...]

I guess this has been bashed to death, but I am annoyed.

With long paths, the 50 characters limit on the first line
of the commit message makes it impossible to have any meaningful
explanation of what the commit actually does.  Actually,
the limitation makes the commit messages unintelligible.

_Any_ change of increasing the limit to e.g. 72 characters?

--Pekka

___
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



___
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

[riot-devel] App development wiki page

[Ken Bannister]

Everyone,

I was inspired from the talks at the RIOT summit by Jaime Jiménez and 
Christian Amsüss to organize a top-level link on the wiki about 
standards based application development [1]. It will provide new users 
with an entry point to our implementations and packages. The CoAP page 
goes into more detail on the current state of nanocoap and gcoap.


Let me know if you can think of a better place for it, and of course 
update it with anything I've missed. My goal is to fill in more of the 
boxes above layer 4 from Christian's talk [2]. I am happy to be the page 
maintainer.


Ken

[1] 
https://github.com/RIOT-OS/RIOT/wiki/Standards-Based-Application-Development
[2] 
http://christian.amsuess.com/presentations/2018/summit-coap/slides.pdf#page=17


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

Re: [riot-devel] General configuration Task Force

[Ken Bannister]

+1! I have a to-do to document such parameters for CoAP. This kind of 
tool could provide a systematic and easily repeatable way to share and 
use that information.


Ken


On 07/09/2018 02:41 AM, Martine Lenders wrote:

Hi,

count me in as well!

Cheers,
Martine

Am Mo., 9. Juli 2018 um 11:04 Uhr schrieb Francisco Acosta 
mailto:francisco.aco...@inria.fr>>:


+1 I'm in!

On 9 July 2018 10:16:10 CEST, Koen Zandberg mailto:k...@bergzand.net>> wrote:
>Hi,
>
>Sounds fun, count me in!
>
>Koen
>
>
>On 07/09/2018 10:09 AM, Jose wrote:
>> Dear maintainers,
>>
>>
>> Last Friday we had an offline discussion with some RIOT people
about
>> he lack of a mechanism to configure Kernel parameters as well as
>> application specific configurations (private keys, timer values,
>etc).
>> Although RIOT is configurable via CFLAGS, there's no way to
(easily)
>> expose all configurations and tweak RIOT in a centralized
manner. As
>> shown, other OS are using several strategies in order to accomplish
>> this (KConfig, header files, etc).
>>
>>
>> I want to propose a "Kernel and Application specific configuration"
>> Task Force to address these issues. What are your feelings about
>this?
>> Anyone (besides me) is interested to work in this topic?
>>
>>
>> Cheers,
>>
>> José
>>
>> ___
>> devel mailing list
>> devel@riot-os.org 
>> https://lists.riot-os.org/mailman/listinfo/devel

-- 
Francisco Javier Acosta Padilla

Research Engineer at INFINE team
Inria Saclay Ile-de-France
___
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


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

Re: [riot-devel] (no subject)

[Ken Bannister]

[reposting my last message; apologies for the annoying HTML link line -- 
Ken]


On 05/07/2018 02:41 AM, David Lyon wrote:


On 2018-05-07 03:51, Mario Hoss wrote:


Hi,

could you give more information on your setup? This is a rather broad 
question.


Which temperature sensor are you using on which board?

Cheers

Forgive my popping in on the list with idea's but I'm following a lot 
of the Electronics and IoT subjects and projects on many forums.


Actually this is a very common request.

Last week I had a discussion with one of my Designers about how 
difficult it is to implement a solution for this problem in Arduino 
using "loop()".


The abstraction is that the processor loops and then the User must 
insert some sort of time keeping mechanism into that and then it gets 
really complicated.


We were discussing something like having :

every(1,tsecond){

v = read_sensor(temp_sensor);

write_value_to_cloud(v);

    }

and the job would be done in my IoT Designer.



I agree that this is a common request. I created a demo for it with 
RIOT. See the"Data collection app" link below for the RIOT side of the 
demo code. The demo includes bootstrapping code, but see 
"_run_sensor_loop" for the loop you're interested in. See pg 4-5 in 
Slides for a photo and conceptual drawings.


It would be great to somehow use your IoT Designer to generate the code! 
RIOT's SAUL API removes a lot of the board/sensor level complexity.


Ken

Data collection app
https://github.com/kb2ma/riot-data-collector

_run_sensor_loop()
https://github.com/kb2ma/riot-data-collector/blob/b91d400a6117cca192df3f79d273676fd4f1475b/main.c#L256

Slides
http://cytheric.net/files/gcoap-2017.pdf
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] (no subject)

[Ken Bannister]

On 05/07/2018 02:41 AM, David Lyon wrote:


On 2018-05-07 03:51, Mario Hoss wrote:


Hi,

could you give more information on your setup? This is a rather broad 
question.


Which temperature sensor are you using on which board?

Cheers

Forgive my popping in on the list with idea's but I'm following a lot 
of the Electronics and IoT subjects and projects on many forums.


Actually this is a very common request.

Last week I had a discussion with one of my Designers about how 
difficult it is to implement a solution for this problem in Arduino 
using "loop()".


The abstraction is that the processor loops and then the User must 
insert some sort of time keeping mechanism into that and then it gets 
really complicated.


We were discussing something like having :

every(1,tsecond){

v = read_sensor(temp_sensor);

write_value_to_cloud(v);

    }

and the job would be done in my IoT Designer.



I agree that this is a common request. I created a demo for it with 
RIOT. See the"Data collection app" link below for the RIOT side of the 
demo code. The demo includes bootstrapping code, but see 
"_run_sensor_loop" for the loop you're interested in. See pg 4-5 in 
Slides for a photo and conceptual drawings.


It would be great to somehow use your IoT Designer to generate the code! 
RIOT's SAUL API removes a lot of the board/sensor level complexity.


Ken

Data collection app
https://github.com/kb2ma/riot-data-collector

_run_sensor_loop()

https://github.com/kb2ma/riot-data-collector/blob/b91d400a6117cca192df3f79d273676fd4f1475b/main.c#L256

https://github.com/kb2ma/riot-data-collector/blob/b91d400a6117cca192df3f79d273676fd4f1475b/main.c#L256

Slides
http://cytheric.net/files/gcoap-2017.pdf


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

[riot-devel] gcoap and nanocoap evolution

[Ken Bannister]

Today I described the gcoap API at the Thing-to-Thing Research Group 
meeting [1]. Of course, any description of gcoap also includes nanocoap, 
the lower level API on which gcoap depends. A question was raised at the 
meeting to evaluate the relationship between the two and how they can 
evolve together.


Relationship: I created a wiki page some time ago on the big picture 
approach for gcoap and provided some contrast with nanocoap [2]. You can 
also read how the relationship got started [3]. When adding a feature to 
gcoap, I always debate the featureful vs. resource-use tradeoff. I find 
it helps that nanocoap has gcoap's back as a more constrained 
implementation.


So from my perspective, the two implementations target different uses, 
and the relationship works OK. To date, nanocoap has not developed much 
from the original implementation. It has helped gcoap to have a stable 
base, but some issues and PRs have not been addressed either.


Evolution: From gcoap's perspective, I see a change coming to it's API. 
It needs another function between the "_init()" and writing the payload 
to provide options for the message, maybe "gcoap_init_opts()" [4]. An 
example is to specify if the message is confirmable. Maybe nanocoap 
could provide some support with a "message options" struct.


Regarding changes to nanocoap and how gcoap could accommodate them, I 
guess it depends on the nature of the changes. Actually, at the meeting 
to today Oleg suggested it is confusing that gcoap-specific functions 
are named "gcoap_..." and nanocoap functions are named "coap_..." 
Perhaps one way to buffer future changes is to create "gcoap_" macros 
for the "coap_" functions to decouple the interfaces.


Ken

[1] 
https://github.com/t2trg/2017-09-berlin/blob/master/slides/37-RIOT-gcoap-api.pdf

[2] https://github.com/kb2ma/RIOT/wiki/gcoap-Features
[3] https://github.com/RIOT-OS/RIOT/pull/5598#issuecomment-233753695
[4] https://github.com/kb2ma/RIOT/wiki/Confirmable-Messaging

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

Re: [riot-devel] RIOT Research Seminar: a short report

[Ken Bannister]

Thanks for the reference, Martine. I should have been clearer. I was 
particularly referring to slide 18 on page 9. It looks to be a new 
initiative to support this integration.


On 04/29/2017 02:41 PM, Martine Lenders wrote:

Hi Ken,
there used to be OpenWSN support in RIOT but due to a missing 
maintainer on our side (we did not find the time to adapt it to our 
rapidly changing APIs for timers and networking) we had to remove it 
for now [1].


Cheers,
Martine

[1] https://github.com/RIOT-OS/RIOT/pull/6359

2017-04-29 15:22 GMT+02:00 Ken Bannister <mailto:kb...@runbox.com>>:


Emmanuel, Thomas:

Thanks for the links! I was very interested to see Thomas's slides
on OpenWSN "fresh" [1]. It would be valuable to have a 6TiSCH
implementation in RIOT. Are there any more details available on
this project?

Thanks,
Ken

http://riot-os.org/files/RIOT-Seminar-2017/RIOT-Spring-Seminar-Watteyne.pdf

<http://riot-os.org/files/RIOT-Seminar-2017/RIOT-Spring-Seminar-Watteyne.pdf>


On 04/28/2017 06:26 AM, Emmanuel Baccelli wrote:

Hi everyone,

there was a seminar organized earlier this month in Paris. The
goal of that seminar was to gather various research teams working
(or considering to work) around RIOT at Inria.

The agenda + slides are available at
http://riot-os.org/seminar-2017.html
<http://riot-os.org/seminar-2017.html>

Some synopsis/highlights below:

- Securing IoT is important now. (see slides from C. Bormann)
- Formally verified open source IoT software is desirable and
some is already available today (see slides from K. Bhargavan)
- Public key crypto is the hardest part of IoT crypto, but
significant performance improvements are on the horizon (see
slides from B. Smith)
- Industrial IoT deployments are already happening. (see slides
from T. Watteyne)
- Object security, and content-centric networking can be used for
security. (see slides from M. Enguehard)
- Need public experimental infrastructure & open data for IoT.
(see slides from E. Fleury)
- Large open source project need tools/languages to (i) flexibly
express how code should be and (ii) automate code transformation
(see slides from J. Lawall)
- OS adaptation and programming abstractions are needed for
intermittently powered IoT devices, and peripherals restoration
is the hard part (see slides from G. Salagnac)
- IoT software components and component dynamic updates are
desirable. (see slides from J. Bourcier)

If you have comments or questions, just ask here and/or contact
the authors directly!

Cheers

Emmanuel



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

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


___
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] RIOT Research Seminar: a short report

[Ken Bannister]

Emmanuel, Thomas:

Thanks for the links! I was very interested to see Thomas's slides on 
OpenWSN "fresh" [1]. It would be valuable to have a 6TiSCH 
implementation in RIOT. Are there any more details available on this 
project?


Thanks,
Ken

http://riot-os.org/files/RIOT-Seminar-2017/RIOT-Spring-Seminar-Watteyne.pdf


On 04/28/2017 06:26 AM, Emmanuel Baccelli wrote:

Hi everyone,

there was a seminar organized earlier this month in Paris. The goal of 
that seminar was to gather various research teams working (or 
considering to work) around RIOT at Inria.


The agenda + slides are available at http://riot-os.org/seminar-2017.html

Some synopsis/highlights below:

- Securing IoT is important now. (see slides from C. Bormann)
- Formally verified open source IoT software is desirable and some is 
already available today (see slides from K. Bhargavan)
- Public key crypto is the hardest part of IoT crypto, but significant 
performance improvements are on the horizon (see slides from B. Smith)
- Industrial IoT deployments are already happening. (see slides from 
T. Watteyne)
- Object security, and content-centric networking can be used for 
security. (see slides from M. Enguehard)
- Need public experimental infrastructure & open data for IoT. (see 
slides from E. Fleury)
- Large open source project need tools/languages to (i) flexibly 
express how code should be and (ii) automate code transformation (see 
slides from J. Lawall)
- OS adaptation and programming abstractions are needed for 
intermittently powered IoT devices, and peripherals restoration is the 
hard part (see slides from G. Salagnac)
- IoT software components and component dynamic updates are desirable. 
(see slides from J. Bourcier)


If you have comments or questions, just ask here and/or contact the 
authors directly!


Cheers

Emmanuel



___
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] RIOT Summit?

[Ken Bannister]

Thanks, Emmanuel. Oh yeah, I would look forward to the discussions in 
person. I don't know if I can make it, but the dates help me think it 
through.


On 03/02/2017 04:04 PM, Emmanuel Baccelli wrote:

Hi Ken,

yes there is. It is planned in September, in Berlin.

The dates are not 100% set in stone, but very probably it will be 
Sept. 29th and 30th, in conjunction with ACM ICN conference [1].


We will announce it soon.

Would you be able to come by? Would be great.

Cheers,

Emmanuel

[1] http://conferences.sigcomm.org/acm-icn/2017/ 
<http://conferences.sigcomm.org/acm-icn/2017/>


On Thu, Mar 2, 2017 at 5:00 PM, Ken Bannister <mailto:kb...@runbox.com>> wrote:


Is there any thought ongoing toward a second RIOT Summit this year?

Thanks,
Ken
___
devel mailing list
devel@riot-os.org <mailto:devel@riot-os.org>
https://lists.riot-os.org/mailman/listinfo/devel
<https://lists.riot-os.org/mailman/listinfo/devel>




___
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

[riot-devel] RIOT Summit?

[Ken Bannister]

Is there any thought ongoing toward a second RIOT Summit this year?

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

Re: [riot-devel] CoAP observe support

[Ken Bannister]

No worries, Koen. I see you've been busy elsewhere in the tree. Congrats 
on the recent merges. Below are my thoughts on priorities, but of course 
the implementation emerges from everyone's priorities.


Any CoAP implementation needs to include the base spec, and the Observe 
and Block extensions. I'm working on Observe for gcoap, and I'll 
probably add the CON type with that. Both gcoap and nanocoap need Block 
support. The Observe spec includes some clever uses of URIs (section 
1.4), so just adding Uri-Query option support would be valuable.


I like the choice of implementations within RIOT of nanocoap (class 0/1 
devices) and gcoap (class 1/2) devices, so keeping them in sync is 
valuable, too.


On top of this base, security is critical. RIOT includes a DTLS 
implementation (transport layer), but interesting work is going into the 
OSCOAP draft (application layer), too.


Also see the documents in the IETF core working group -- monitoring via 
CORE/COMI (which was my original reason for working on CoAP), pub-sub, 
HTTP mapping, multicast. Then there is the work from the thing to thing 
group (T2TRG) and ensuring a protocol like LWM2M works well. Carsten has 
posted a couple of messages recently about CoAP over serial that would 
be cool to implement, too. At this level, the priorities really depend 
on what you need CoAP to do.


Ken

On 01/21/2017 10:55 AM, Koen Zandberg wrote:

Hi Ken,

Sorry for the slow response. Time limitations are also an issue for me.

I'm going to look at the code in the next few weeks when I have time.
Besides the work for coap observe, what would be the priority to work on?

Koen

On 01/10/2017 12:31 PM, Ken Bannister wrote:

Hi Koen,

Thanks for your interest! I am working actively on Observe support for
gcoap/nanocoap. I don't see a technical difficulty -- the biggest
issue for me is time to work on it. :-/ My first goal is server-side
support. I plan to create a WIP PR within a week or two, so at least
there will be a place for discussions. You'll see a new branch in my
repository before then, and I'm happy to discuss at any time.

If you are generally interested in contributing to CoAP within RIOT,
both nanocoap and gcoap could use some help. There are a couple of
open PRs for work on nanocoap. Certainly it would benefit from more
documentation and unit tests, which are a great way to get into the
code. I also maintain a wiki about gcoap [1], and also have written up
some issues as 'notes to self' [2] but would be happy for someone to
move them to official RIOT issues. gcoap also needs full-on
confirmable messaging support, which actually is a requirement for
Observe.

Ken

[1] https://github.com/kb2ma/RIOT/wiki/gcoap-Status
[2] https://github.com/kb2ma/RIOT/issues


On 01/10/2017 04:56 AM, Koen Zandberg wrote:

Hello,

I was looking for a CoAP implementation to use with RIOT. Having looked
at both microcoap and nanocoap (gcoap), as far as I could tell both lack
observe support. Are there difficulties with implementing this? If there
are no blocking issues with it, I might be willing to spent some time
trying to get it working.

Koen.




___
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




___
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] CoAP observe support

[Ken Bannister]

Hi Koen,

Thanks for your interest! I am working actively on Observe support for 
gcoap/nanocoap. I don't see a technical difficulty -- the biggest issue 
for me is time to work on it. :-/ My first goal is server-side support. 
I plan to create a WIP PR within a week or two, so at least there will 
be a place for discussions. You'll see a new branch in my repository 
before then, and I'm happy to discuss at any time.


If you are generally interested in contributing to CoAP within RIOT, 
both nanocoap and gcoap could use some help. There are a couple of open 
PRs for work on nanocoap. Certainly it would benefit from more 
documentation and unit tests, which are a great way to get into the 
code. I also maintain a wiki about gcoap [1], and also have written up 
some issues as 'notes to self' [2] but would be happy for someone to 
move them to official RIOT issues. gcoap also needs full-on confirmable 
messaging support, which actually is a requirement for Observe.


Ken

[1] https://github.com/kb2ma/RIOT/wiki/gcoap-Status
[2] https://github.com/kb2ma/RIOT/issues


On 01/10/2017 04:56 AM, Koen Zandberg wrote:

Hello,

I was looking for a CoAP implementation to use with RIOT. Having looked
at both microcoap and nanocoap (gcoap), as far as I could tell both lack
observe support. Are there difficulties with implementing this? If there
are no blocking issues with it, I might be willing to spent some time
trying to get it working.

Koen.




___
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] Exchange CoAP messages between 2 boards

[Ken Bannister]

Thanks for the mention, Carsten. gcoap still is a work in progress. 
However, source code is source code if that helps. See PR #5598. Also, 
notice the link in there for Kaspar's small server-only implementation, 
nanocoap.


Ken

On 08/26/2016 04:21 PM, Carsten Bormann wrote:

Hi ALESSANDRO,

In Berlin we talked about a number of CoAP implementations, including 
a new one specifically for riot called gcoap. Cant dig out the 
references right now, but Google for t2trg and riot.


Grüße, Carsten

On 26 Aug 2016 17:26, ALESSANDRO NICOLI wrote:


Hi all,

I'm trying to build my CoAP environment where i should have 2 CoAP 
servers and a collector, all 3 these nodes are based on SAMR21-XPRO 
board and the /"microcoap_server"/ example on the RIOT repo.


I would like that these nodes could talk using CoAP, so, how can i 
perform a CoAP request from an other microCoAP server or similar?


Thanks a lot!

/best regards, /
/Alessandro/



___
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

[riot-devel] Web and IoT discussion

[Ken Bannister]

I read that Ari Keränen and Carsten Bormann plan to lead a discussion on 
Saturday at the RIOT Summit on the Web and IoT, including better support 
for CoAP in RIOT. I am the author of a work-in-progress CoAP 
implementation [1].


I am very interested in this discussion; however, I am unable to attend 
in person. Is there any plan for remote access or streaming? If not, I 
would appreciate a summary of the discussion.


Thanks,
Ken

[1] https://github.com/RIOT-OS/RIOT/pull/5598
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Improving support for OpenMote-cc2538

[Ken Bannister]

Aaron,

Great idea to improve the OpenMote integration! Have you tried 
contacting the OpenMote developers for guidance? In my experience they 
have been very helpful and accommodating. I expect they would appreciate 
your effort.


Ken

On 12/12/2015 10:06 PM, Aaron Sowry wrote:

Hi,

I'd like to try and improve RIOT OS support for the OpenMote platform
in general, and the TI cc2538 MCU specifically. The most pressing item
for me currently is RF support, but I would also like to see support
for the ROM API and a few other things (including the sensors on the
OpenBattery board, eventually).

I'm new to RIOT and thought I'd try to clear up a few things before
getting my hands dirty, so you'll have to excuse me if some of these
questions seem obvious/stupid/irrelevant:

1) TI provide open-source firmware for the cc2538, but I can't find
any trace of it in the RIOT tree. It seems like there are a few
cherry-picked bits and pieces but not in the same format/layout as the
original firmware. Is there a reason for not including TI's firmware
in the tree verbatim (I'm thinking licensing/re-distribution issues,
architectural or coding-style differences, etc)? It seems like this
would make fully supporting the MCU a lot easier.

2) To avoid duplication of effort, is there anyone else already
working on RF support for this chip?

3) Where should a hypothetical RF driver for the cc2538 live in the
tree? Since it's on-chip should it live in the cpu subdir? Or
programmed as a "module" the same way as for peripherals?

4) Are there any guidelines or example code for this kind of work? The
only other on-chip RF driver I could find to use as a reference is for
the nrf51. Perhaps this will do to get me on the right track, but just
thought I'd check if there's something I missed.

Thanks!
/Aaron
___
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] Radio duty cycling

[Ken Bannister]

Oleg,

I'm a contributor to OpenWSN, making a first post here based on your 
mention below.



On 03/17/2015 02:58 PM, Oleg Hahm wrote:

Hi Joakim!


What is the current state of radio duty cycling in RIOT?
I know that radio drivers implement on and off functions for the chip, but
how do we make the best use of them?
​In order to reduce power consumption it will be necessary to duty cycle
the radio​

I would agree with Martine: usually, duty cycling should be rather part of the 
MAC
layer than of the driver. However, embedded transceiver devices usually are
designed for one particular MAC layer and splitting this up in a sensible way
is not always easy/feasible.

Do you have any concrete ideas of functionality for a generic radio
transceiver the driver (netdev) API should provide?


​For comparison, in
​Contiki there are multiple RDC drivers that can be switched​ between at
compile time, the most well-known is ContikiMAC [1]. Something similar
would be very useful in battery powered scenarios for RIOT.

There's definitely a need for generic MAC layer solutions in RIOT, besides the
specific solutions like CSMA in the cc110x driver or TiSCH for 802.15.4e as
part of the OpenWSN stack. As far as I know, at least two people are currently
working on MAC layer implementations for RIOT. I will also take a look into
this topic with the goal to use only the MAC layer part of the OpenWSN stack
as a standalone module in RIOt.
I think your idea to cut its stack at the MAC layer is a good fit for 
both projects.
Use OpenWSN for its efficient and reliable 15.4e and 6TiSCH 
MAC/adaptation layers,

and RiOT for its higher level layers and libraries.

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