[riot-devel] Is RIOT right?

[Patrick Rota - Swissponic Sagl]

Hello everyone,

we are developing an IOT application and we got impressed with RIOT. It 
sports some really nice features and it looks like there is a great 
community over here.
On the paper RIOT seems to be perfect for our application, but we need 
to go deeper before we start investing our resources into this project. 
We have some questions that are not easy to answer just by looking at 
the documentation, so your experience is much appreciated.


Let me first introduce our platform.
As in many WSN we have multiple wireless nodes and one (or more) router 
/ coordinator / gateway.


++ Nodes ++
Nodes are based on Atmel SAM R21 that, as you know, is basically an 
Atmel SAM D21 plus an Atmel RF233 in the same package. We already 
designed the modules and they work well with Atmel code examples.

We want to use the following stack:
RF233 <-> 6LowPAN <-> TCP <-> MQTT client <-> Application

++ Router / coordinator / gateway ++
Another device acts as PAN coordinator and as router/gateway to the 
local LAN.
This device is based on a Olimex A13-SOM-512 
(https://www.olimex.com/Products/SOM/A13/A13-SOM-512/) running Linux 
with a wired Ethernet interface and the same SAM R21 radio module (with 
a different firmware). The two boards are connected trough a serial 
connection (USART).

Here the communication stack is a little more complex:

[Olimex A13] Application <-> MQTT broker <-> (???) <-> Kernel Serial 
driver <-> USART

  |
[serial from A13 to SAMR21]
  |
[SAMR21] USART <-> (???) <-> 6LowPAN <-> RF233

As you can see, we are not sure about the stack composition, see 
"(???)". We would like to integrate the coordinator and routing 
functions in the A13 side (since we have more resources there) and 
basically just use the SAMR21 as a transceiver.



I hope I gave enough details to understand the platform. If not, I will 
be happy to answer your questions.

Now, our questions:

1) Architecture: is RIOT viable for this architecture?

2) Gateway: which stack layers do you advise to include for the "(???)" 
parts? Is it a good idea to include the coordinator on the A13 side? Or 
is better to put it into the SAMR21 side?


3) Robustness: please be honest, is RIOT robust and mature enough for a 
large scale use? Do you know of commercial products that integrates it?


4) License: RIOT is published with a LGPLv2 license and if we understand 
well, we can then use it in our product without any limitation. Is this 
right?


5) TCP: we have seen that some TCP support has been temporarily removed 
and being refactored. What is the plan for reintroducing it? (MQTT is 
based on TCP)


6) MQTT: is there any plan to develop a MQTT client for RIOT? Is anybody 
already developing it?


7) Mesh: what is the status of meshing networks? Is it working well / 
stable?


8) Security: which level of security RIOT provides? For a commercial 
use, it is important that security (authentication, authorization, 
encryption) is well implemented. Is this the case?


---

We hope that you can shed some light on our doubts. In that case we will 
be happy to join your community and adopt RIOT as our base. We are ready 
to contribute to the project, in particular by working on the TCP, MQTT 
and OTA update, or where needed. We could also provide some HW if 
anybody is interested.


Kind regards,

--
*Patrick Rota*



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

Re: [riot-devel] RIOT for Zigduino

[Hauke Petersen]

Hi,

I think so far nobody has attempted to port that board.

Please don't take the available porting guide word-by-word, it might be 
outdated in places - we are currently putting heavy effort in 
rewriting/updating our documentation!


So for porting the Zigduino I think you can just follow a simple 
approach: copy the `arduino-mega2560` board and the `atmega2560` cpu and 
adapt them to the specifics of the new board. Start simple by just 
trying to get the UART to work and than add to it. Don't worry about 
duplicating code while you just want to get the board working somehow - 
I would suggest that you than PR your code once you have basic 
functionality working (e.g. UART, GPIO, timers) and we can work out 
together a concept of introducing some shared board/cpu folders for 
ATMega based platforms (as done in cpu/cortexm_common for coretx-m based 
platforms).


Just let us know where we can help!

Cheers,
Hauke


On 17.11.2015 09:42, Behailu S. Negash wrote:

Greetings,

I have been trying to port RIOT for Zigduino board for about a week 
(On and Off), but I am confused. Has anybody done porting for zigduio? 
or is there any specific steps I need to follow, besides the general 
guideline given in documentation?


Thank you

--
Behailu Shiferaw Negash
Turku, Finland


___
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] Task Forces

[Emmanuel Baccelli]

Hi again,

OK, I modified the page, here's how it would look like:
https://github.com/RIOT-OS/RIOT/wiki/Task-Forces
Comments/input welcome.

Talking about task forces, was there not a LPM task force on the way too?

Best,

Emmanuel


On Thu, Nov 19, 2015 at 4:59 PM, Kaspar Schleiser 
wrote:

> Hey,
>
> On 11/19/15 16:50, Emmanuel Baccelli wrote:
> > - would Kaspar agree he was the shepherd of the timers task force?
>
> yes.
>
> Kaspar
> ___
> 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] Task Forces

[Kaspar Schleiser]

Hey,

On 11/19/15 16:50, Emmanuel Baccelli wrote:
> - would Kaspar agree he was the shepherd of the timers task force?

yes.

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

Re: [riot-devel] Task Forces

[Emmanuel Baccelli]

OK, I could go ahead and modify the wiki with some tentative text for that,
which we could refine later on.
In practice:

- would Kaspar agree he was the shepherd of the timers task force?

- would Martine & Hauke agree they were the shepherds of the nasty task
force?

- would Martine & Hauke agree they are the shepherds of the documentation
task force?

- who would take on the shepherding for the OTA task force? If no-one
speaks up, we could classify this TF as dormant the time being.



On Thu, Nov 19, 2015 at 4:04 PM, Oleg Hahm  wrote:

> Hi!
>
> Sounds like a sensible proposal to me.
>
> Cheers,
> Oleg
>
> Am Thu, Nov 19, 2015 at 03:51:36PM +0100 schrieb Emmanuel Baccelli:
> > +1 here too.
> > I think it is also important to describe to malloc and free :)
> > I mean how to:
> >
> > 1 - create a new task force (hopefully we have a lot more to come!)
> > 2 - join/ping/revive an existing task force (e.g. OTA is somewhat
> dormant)
> > 3 - dissolve an existing task force
> >
> > For creating: how about, simply stating something like:
> > "If you wish to launch a new task force, go ahead, create your wikipage,
> > and report your progress or summarize the latest stand of your
> discussions
> > on devel@riot-os.org"
> > There's the slight possibility that duplicate work may happen down the
> > line, if a lot of task forces are active at the same time.
> > But this is not dangerous right now. If we want to cover this case, maybe
> > we can add: "RIOT maintainers will contact you if duplicate or very
> > closely-related work has been detected elsewhere, and if joining forces
> > might make sense."
> >
> > For ping/join/revive how about naming one or two shepherds per task
> force,
> > that could be pinged?
> >
> > For dissolving: how about "either (i) the shepherd(s) declares the TF is
> > done, or gives up, or (ii) the shepherds are unreachable, the TF has been
> > dormant for a long time and RIOT maintainers declare the TF dissolved"
> >
> >
> >
> >
> > On Thu, Nov 19, 2015 at 3:34 PM, Kaspar Schleiser 
> > wrote:
> >
> > > Hey,
> > > On 11/19/15 14:48, Oleg Hahm wrote:
> > > > As an effort to "formalize" this idea of task forces a little bit
> more,
> > > I just
> > > > created a small page in the Wiki:
> > > >
> > > > What do you think?
> > >
> > > +1
> > >
> > > I've updated the xtimer page.
> > >
> > > Kaspar
> > > ___
> > > 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
>
>
> --
> /* Thanks to Rob `CmdrTaco' Malda for not influencing this code in any
>  * way.
>  */
> linux-2.4.3/net/core/netfilter.c
>
> ___
> 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] DocTF - First meeting

[Oleg Hahm]

Dear ritualizing IoTlers,

this morning the first virtual meeting of the documentation task force (DocTF)
took place. DocTF is chartered to improve the overall state of RIOT's
documentation and particular work on high level descriptions of RIOT's
architecture and its modules.

Please find the minutes from the meeting at http://riot.pad.spline.de/24 and
see the related issues: https://github.com/RIOT-OS/RIOT/labels/DocTF,
particular https://github.com/RIOT-OS/RIOT/issues/4309 and
https://github.com/RIOT-OS/RIOT/issues/4072. Of course, we would be very glad
if non-members of the task force would be willing to help. Please feel free to
self-assign for any of the listed topics.

Cheers,
Oleg
-- 
printk("%s: confused, missing data\n", drive->name);
linux-2.6.6/drivers/ide/ide-cd.c


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

Re: [riot-devel] Task Forces

[Emmanuel Baccelli]

+1 here too.
I think it is also important to describe to malloc and free :)
I mean how to:

1 - create a new task force (hopefully we have a lot more to come!)
2 - join/ping/revive an existing task force (e.g. OTA is somewhat dormant)
3 - dissolve an existing task force

For creating: how about, simply stating something like:
"If you wish to launch a new task force, go ahead, create your wikipage,
and report your progress or summarize the latest stand of your discussions
on devel@riot-os.org"
There's the slight possibility that duplicate work may happen down the
line, if a lot of task forces are active at the same time.
But this is not dangerous right now. If we want to cover this case, maybe
we can add: "RIOT maintainers will contact you if duplicate or very
closely-related work has been detected elsewhere, and if joining forces
might make sense."

For ping/join/revive how about naming one or two shepherds per task force,
that could be pinged?

For dissolving: how about "either (i) the shepherd(s) declares the TF is
done, or gives up, or (ii) the shepherds are unreachable, the TF has been
dormant for a long time and RIOT maintainers declare the TF dissolved"




On Thu, Nov 19, 2015 at 3:34 PM, Kaspar Schleiser 
wrote:

> Hey,
> On 11/19/15 14:48, Oleg Hahm wrote:
> > As an effort to "formalize" this idea of task forces a little bit more,
> I just
> > created a small page in the Wiki:
> >
> > What do you think?
>
> +1
>
> I've updated the xtimer page.
>
> Kaspar
> ___
> 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] Task Forces

[Martine Lenders]

Yes to both.

2015-11-19 17:54 GMT+01:00 Hauke Petersen :

>
>
> On 19.11.2015 16:50, Emmanuel Baccelli wrote:
>
> OK, I could go ahead and modify the wiki with some tentative text for
> that, which we could refine later on.
> In practice:
>
> - would Kaspar agree he was the shepherd of the timers task force?
>
> - would Martine & Hauke agree they were the shepherds of the nasty task
> force?
>
> yes
>
>
> - would Martine & Hauke agree they are the shepherds of the documentation
> task force?
>
> and yes
>
> Cheers,
> Hauke
>
>
>
> - who would take on the shepherding for the OTA task force? If no-one
> speaks up, we could classify this TF as dormant the time being.
>
>
>
> On Thu, Nov 19, 2015 at 4:04 PM, Oleg Hahm  wrote:
>
>> Hi!
>>
>> Sounds like a sensible proposal to me.
>>
>> Cheers,
>> Oleg
>>
>> Am Thu, Nov 19, 2015 at 03:51:36PM +0100 schrieb Emmanuel Baccelli:
>> > +1 here too.
>> > I think it is also important to describe to malloc and free :)
>> > I mean how to:
>> >
>> > 1 - create a new task force (hopefully we have a lot more to come!)
>> > 2 - join/ping/revive an existing task force (e.g. OTA is somewhat
>> dormant)
>> > 3 - dissolve an existing task force
>> >
>> > For creating: how about, simply stating something like:
>> > "If you wish to launch a new task force, go ahead, create your wikipage,
>> > and report your progress or summarize the latest stand of your
>> discussions
>> > on devel@riot-os.org"
>> > There's the slight possibility that duplicate work may happen down the
>> > line, if a lot of task forces are active at the same time.
>> > But this is not dangerous right now. If we want to cover this case,
>> maybe
>> > we can add: "RIOT maintainers will contact you if duplicate or very
>> > closely-related work has been detected elsewhere, and if joining forces
>> > might make sense."
>> >
>> > For ping/join/revive how about naming one or two shepherds per task
>> force,
>> > that could be pinged?
>> >
>> > For dissolving: how about "either (i) the shepherd(s) declares the TF is
>> > done, or gives up, or (ii) the shepherds are unreachable, the TF has
>> been
>> > dormant for a long time and RIOT maintainers declare the TF dissolved"
>> >
>> >
>> >
>> >
>> > On Thu, Nov 19, 2015 at 3:34 PM, Kaspar Schleiser 
>> > wrote:
>> >
>> > > Hey,
>> > > On 11/19/15 14:48, Oleg Hahm wrote:
>> > > > As an effort to "formalize" this idea of task forces a little bit
>> more,
>> > > I just
>> > > > created a small page in the Wiki:
>> > > >
>> > > > What do you think?
>> > >
>> > > +1
>> > >
>> > > I've updated the xtimer page.
>> > >
>> > > Kaspar
>> > > ___
>> > > 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
>>
>>
>> --
>> /* Thanks to Rob `CmdrTaco' Malda for not influencing this code in any
>>  * way.
>>  */
>> linux-2.4.3/net/core/netfilter.c
>>
>> ___
>> devel mailing list
>> devel@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>>
>>
>
>
> ___
> 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

[riot-devel] Task Forces

[Oleg Hahm]

Dear respected IOTlers,

for already quite some time the idea of having task forces is floating around
in our community: small teams of RIOT developers that work together for some
time towards a (more or less) well-defined goal. A good and very successful
example for such a task force that concluded its task with great success was
the Network Stack Task Force (NSTF) which delivered the awesome gnrc stack
that we're now happily using to connect IoT devices to each other and to the
Internet.

As an effort to "formalize" this idea of task forces a little bit more, I just
created a small page in the Wiki:
https://github.com/RIOT-OS/RIOT/wiki/Task-Forces

The idea is to have an overview of currently active task forces and their
members. This might be helpful to get an easy overview over the latest 
activities
and important milestones on the RIOT roadmap and to get involved in those
activities.

What do you think?

Cheers,
Oleg
-- 
#if 0
linux-2.2.16/fs/buffer.c


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

Re: [riot-devel] TI CC1310 and CC2650

[Jonas Remmert]

Hi Adam,just the really low-level RF stuff is executed by the M0 RF core. I am not sure if the memory section that contains the code for the RF core is reprogrammable, the reference manual describes it as ROM [1, Chapter 1.1; 1.3.2.3]. From my understanding the code for the M0 RF core is stored in a pre-programmed ROM section. Chapter 7 [1] states that the ROM has a size of 115kB in addition to the 128kB Flash. This ROM section contains a Bootloader, a Driver Library and the RF stack (I assume both RF-versions at the same time). The reason is a cheaper price for ROM, compared to Flash, during silicon production.In [1; Chapter 23.1.1] you see a block containing "Modem, frequency synthesizer, and RF interfaces". An exact description of that block would be necessary to set up the RF-path (RF to Baseband conversion) according to the desired physical layer (BLE - 1Mbps GFSK, IEEE 802.15.4 - mostly O-QPSK with DSSS, any proprietary). You need to control the analog components (filter, PLL, RF-Demodulation and DSSS-Demodulation, ADC-sample rate) in order to get the Baseband signal, which is then digitalized by the CC26xx's internal ADCs. I have not found any description of the components of the internal RF-path in the reference manual. The description of the Radio [1, Chapter 23] exclusively describes the interface between the M3 and the M0.So I suggest to just use the default IEEE 802.15.4 PHY/MAC firmware for the M0 and implement a RIOT driver running on the M3 that uses the described interface to the M0 RF core. The features of the existing IEEE 802.15.4 configuration should roughly represent the features of common IEEE 802.15.4 transceivers (e.g. as in the KW2x or SAM R21).[1] - http://www.ti.com/lit/ug/swcu117d/swcu117d.pdfBest Jonas-"devel"  schrieb: -An: RIOT OS kernel developers Von: Adam Hunt Gesendet von: "devel" Datum: 18.11.2015 18:49Betreff: Re: [riot-devel] TI CC1310 and CC2650Jonas,I was wondering, can you comment on the possibility of loading custom images for the M0 RF core? While I don't doubt that the TI firmware would be sufficient for most uses the idea of loading an open source, RIOT based, MAC onto the M0 is interesting to me.Thanks,AdamOn Wed, Nov 18, 2015 at 5:32 AM Jonas Remmert  wrote:Hi Adam,the CC2650 based board has not yet been released officially. It will appear online in a few days. Nevertheless, you can order it right now.There are two options to purchase:1. Art-No.:(PN-00101-A-001.A1) - Only the CC2650 based evaluation board for 39€ + VAT.2. Art-No.:(KPW-IOT-002) - An IoT-Kit bundle for 69€ + VAT that comes with:- CC2650 based evaluation board- TI XDS110 Debug Adapter- BLE USB StickIf you are interested in samples for development, just contact me direclty.We will be in Nuremberg at the SPS IPC Drives by next week (24.11.-26.11; Hall 6, Booth 449), so if you are nearby visit us there.BestJonas-"devel"  schrieb: -An: RIOT OS kernel developers Von: Adam Hunt Gesendet von: "devel" Datum: 18.11.2015 13:41Betreff: Re: [riot-devel] TI CC1310 and CC2650I searched Phytec's site but was unable to find a CC2650 based board.On Mon, Nov 16, 2015 at 5:54 AM Jonas Remmert  wrote:Hi RIOTers,we at Phytec offer the Evaluation board, described in the Wiki at [1], also with a CC2650 module. The yellow Board is the same as described in the Wiki, just the green PCB module differs by containing an TI CC2650 SoC instead of the Freescale KW2x SiP.The board is currently available for 39€ + VAT. Just write the Phytec sales team at: cont...@phytec.deWe don`t support RIOT on the CC2650 right now, but we are very interested in any effort to make RIOT available on the CC2650. Currently, we ship the board with an adapted version of the TI's SensorTag BLE example.If someone needs CC2650 hardware samples for porting or testing feel free to contact us.We would be happy to support your efforts.Best Jonas[1] - https://github.com/RIOT-OS/RIOT/wiki/Board%3A-Phytec-phyWAVE-KW22-"devel"  schrieb: -An: RIOT OS kernel developers Von: "b...@vpt-systems.co.za" Gesendet von: "devel" Datum: 16.11.2015 10:23Betreff: Re: [riot-devel] TI CC1310 and CC2650
  

  
  
Hi Adam

I'm looking at the CC13xx and as far as I remember is has a
Coretex-M3 running.  I have 2 CC1350's on my desk and will most
likely start to run them in the next 2 weeks, If all is goes well
with my current projects.

We are running Contiki on our MSP430 with CC1120 and CC1190 (PA) for
our OpenWSN mesh network implementation.  Debugging is a major issue
on Contiki so I will be loading RIOT and see what is required in
terms of porting

TI suggested that I wait for version 2 of the silicon of the CC1350
It should have been release 

Re: [riot-devel] Task Forces

[Kaspar Schleiser]

Hey,
On 11/19/15 14:48, Oleg Hahm wrote:
> As an effort to "formalize" this idea of task forces a little bit more, I just
> created a small page in the Wiki:
> 
> What do you think?

+1

I've updated the xtimer page.

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