Re: [riot-devel] [GSOC] Introduction

2015-03-19 Thread Francesco Ermini
The aim of the project is to avoid the use of hardcoded keys inside the
firmware and add more flexibility in keys management.
So we need an API that performs the following tasks:
1. Wait for an input that just says hey, install a new key
i.e  the NFC gateway detects an NFC device in his range or an UART device
has been plug.
2. Check the security parameters.
i.e a device identifier, a timeout for reading the payload,the protocol to
use...other parameters and finally the key
3. Create a database of all the informations received and guarantee that
nobody steels them!
In case of 802.15.4, since the encryption is done by the hardware of the
Xbee, the best solution consists of get rid   of the key right
after the key is set into the Xbee.
In case of RPL and CoAP the idea is to store the key in a secure storage or
a volatile area so that a device   tampering could lead
to key deletion
4. Implement the functions that will set the security keys into the desired
protocol/device

 Finally at the end of the project we'll test the encrypted communications
of the nodes

I hope I was clear, best regards Francesco


2015-03-19 10:57 GMT+01:00 Hauke Petersen hauke.peter...@fu-berlin.de:

  HI Francesco,

 On 18.03.2015 19:07, Francesco Ermini wrote:

  Thanks for the Xbee driver,I'll wait the PR for testing!

  The security aspect is about including in RIOT the possibility to
 dynamically insert a set of encryption keys at run time through an external
 channel (I have a collegue working on NFC driver on  RIOT). Basically,the
 keys I want to exchange are those concering the 802.15.4 protocol,but we
 can use the same technique for RPL or CoAP.

 Sounds very interesting! There is quite some demand for this inside (and
 outside) of our community. Regarding GSOC - do you have already a rough
 idea about an architecture and a high-level project plan on how you would
 like to structure this as a GSOC project? I encourage you to share this
 with us, so we can help you to improve it!

 Cheers,
 Hauke





 2015-03-16 19:21 GMT+01:00 Hauke Petersen hauke.peter...@fu-berlin.de:

  Hi Francesco,

 welcome to RIOT first of all.

 Cool that you are working with the UDOO boards! BLE development with
 these boards would indeed be a little difficult, as I don't know any
 shields without fully integrated network stack, that would allow for access
 to the BLE link layer.

 Porting the Xbee device to RIOT is unfortunately already almost finished
 [1] - I am just sitting on the last fixes and will release a PR in the next
 couple of days...

 The security aspect however is not yet included. Taking this to a more
 general approach (valid for not only the xbee device) is however a very hot
 topic. Here I would indeed see a project for GSOC. Do you have already any
 further ideas what you would like to do in this direction? It would be
 nice, if you could roughly sketch our your ideas, so we can discuss them
 further.

 Cheers,
 Hauke

 [1] https://github.com/haukepetersen/RIOT/tree/add_driver_xbee




 On 12.03.2015 15:46, Francesco Ermini wrote:


  Hi,

  my name is Francesco Ermini, and I'm student in electronics  and
 telecommunication engineering at the University of Florence,Italy.

  My current Ms.C. thesis is about IoT secure communications. Our testbed
 is made by some UDOO Quad boards, with Linux + RiOT as operating systems
 (the UDOO can host two OSes at once).
 I checked the GSOC ideas page, and I found the Bluetooth Low Energy
 driver one. Although interesting, using BTLE wouldn't rally match my
 current work.
 However, we also found that the XBee shield is not yet supported in RiOT
 (open bug / feature request). This would match a bit more my thesis work,
 and my (evil) tutor would be happier.

  My question is: what about implementing the XBee driver (including the
 dynamic security keys setup) ?

  Best regards,

  Francesco


  ___
 devel mailing 
 listdevel@riot-os.orghttp://lists.riot-os.org/mailman/listinfo/devel





  --
 Francesco Ermini
 Via Abebe Bikila, 8 50012 (FI)
 cell. 3338710609
 tell. 055642820





-- 
Francesco Ermini
Via Abebe Bikila, 8 50012 (FI)
cell. 3338710609
tell. 055642820
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] NFC Atmel AT86RF232B

2015-03-19 Thread Thomas Eichinger
Hi Joël,

ad NFC:
I got me some NXP pn532 modules some time ago as I heard there is work
on specifying 6LoWPAN over ISO 14443 (which NFC is part of). Beside this
there are a lot of interesting applications you could build in combination
with constraint networks.
Sadly, I didn’t come too far with the driver, as it includes a (more) complex
communication with the module, at least for the pn532, and it was kind of a
private side project. My initial work can be found in [1].

ad rf212b:
As Joakim stated, the existing at86rf231 driver supports the rf212b as the 
main functionality is the same for all current Atmel radio devices.
I’m also currently refactoring the driver, providing the ability to extend
the common functionality by very device specific features without writing
it from scratch. I have it running for the rf231 already but need some more
time to debug and entangle it correctly with all the other new network stack
work. I will open a WIP PR for this today.

Best, Thomas


 On 18 Mar 2015, at 22:04, Joël Chotard joel.chot...@xsoen.com wrote:
 
 Hi all,
 
 Does somebody is working on a RIOT NFC device driver ? and the ATMEL sub-G 
 AT86RF212B driver ?
 
 Joël
 ___
 devel mailing list
 devel@riot-os.org
 http://lists.riot-os.org/mailman/listinfo/devel

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


Re: [riot-devel] NFC Atmel AT86RF232B

2015-03-19 Thread Baptiste Clenet
Hello,

I'm also interesting in AT86RF212B driver.
Ashkay has already done some improvements with this driver.
Does anybody have a WIP branch to try this driver?

Cheers,

2015-03-18 22:14 GMT+01:00 Joakim Gebart joakim.geb...@eistec.se:

 Hello,

 On Wed, Mar 18, 2015 at 10:08 PM, Craig Younkins cr...@freshtemp.com
 wrote:
  I think the at86rf231 driver works with the 212B or will otherwise
 require
  minimal changes. I have not tested it but anticipate using it. In the
 linux
  kernel they are both supported in the same file.

 Yes, the AT86RF212B works with the at86rf231 driver. The driver is
 undergoing some work right now, see
 https://github.com/RIOT-OS/RIOT/pull/2562 and
 http://lists.riot-os.org/pipermail/devel/2015-March/002247.html

 I have seen a memory corruption bug with the driver but not had the
 time to pinpoint it exactly, it seems to happen randomly, but in the
 vicinity of the radio RX code. I will open a PR when I find a solution
 unless someone else beats me to it.

 Best regards,
 Joakim
 www.eistec.se

 
  Craig Younkins
 
  On Wed, Mar 18, 2015 at 5:04 PM, Joël Chotard joel.chot...@xsoen.com
  wrote:
 
  Hi all,
 
  Does somebody is working on a RIOT NFC device driver ? and the ATMEL
 sub-G
  AT86RF212B driver ?
 
  Joël
  ___
  devel mailing list
  devel@riot-os.org
  http://lists.riot-os.org/mailman/listinfo/devel
 
 
 
  ___
  devel mailing list
  devel@riot-os.org
  http://lists.riot-os.org/mailman/listinfo/devel
 
 ___
 devel mailing list
 devel@riot-os.org
 http://lists.riot-os.org/mailman/listinfo/devel




-- 

*Clenet BaptisteFR: +33 6 29 73 05 39 %2B33%206%2029%2073%2005%2039*
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] NFC Atmel AT86RF232B

2015-03-19 Thread Thomas Eichinger
Hi,

 On 19 Mar 2015, at 10:54, Oleg Hahm oliver.h...@inria.fr wrote:
 
 
 Sadly, I didn’t come too far with the driver, as it includes a (more) complex
 communication with the module, at least for the pn532, and it was kind of a
 private side project. My initial work can be found in [1].
 
 Link was missing. ;)

Of course, sorry about that.

[1] https://github.com/thomaseichinger/RIOT/tree/pn532

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


Re: [riot-devel] Hello_RIOT

2015-03-19 Thread Peter Kietzmann

Hi Otmane,

welcome to the RIOT community! Please go a bit through the wiki pages 
and checkout the open issues list [1]. There you can find some issues 
labeled Newbie-Task-Candidate. Would be nice if you work on one (or 
more) issues and make a PR for your fixes. This is a good point to start 
working with RIOT and get in contact with the community. Also you'll 
learn a bit about our workflows... Regarding the further progress I 
guess it would be really informative for you to read the notes from the 
yesterday's virtual GSOC meeting [2].


Cheers,
Peter

[1] https://github.com/RIOT-OS/RIOT/issues
[2] http://pad.spline.de/Ouide7Nzd8


Am 18.03.2015 um 17:28 schrieb Otmane El Mouaatamid:

Hello RIOT,
my name is Otmane EL MOUATAMID , i have 26 years i from Morocco , i'm 
PhD student , my research axes :

- IoT-A,
- ad-hoc
- MANet,
- VANet,
- WSN,
- M2M,
- RFID,
- NFC.

i'm interested to work in RIoT, Project N2: Implementation of LwM2M.
but i'm new n the summer code and RIOT, i'm reading about RIOT now  i 
liked the idea,
now i need  knowledge how to i can start my work and how i can 
contribute in this project .



best regards!

Otmane .elmouaatamid


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


--
Peter Kietzmann

Hamburg University of Applied Sciences
Dept. Informatik, Internet Technologies Group
Berliner Tor 7, 20099 Hamburg, Germany
Fon: +49-40-42875-8426
Web: http://www.haw-hamburg.de/inet

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


Re: [riot-devel] Benchmarks

2015-03-19 Thread Simon Vincent
Yes I tried to compile the rpl_udp example for the samr21-xpro but it 
did not have enough RAM. Even with RPL in non-storing mode and a very 
small routing table it would not fit.


Ultimately we would be looking to run UDP/RPL/COAP on top of the 
IPv6/6lowpan/802.15.4 stack.


For the evaluation just UDP would be fine to give me an idea if a M0+ 
would be fast enough.


Is the size of RAM/flash for RIOT likely to increase? Currently building 
the rpl_udp example results in 109K text+data, 37K bss. We were thinking 
of going for a M0+ with 128KB flash and 64KB RAM but this does not leave 
much room for expansion.


Am I correct in thinking that the IPv6/6lowpan/UDP/TCP/RPL stacks are 
fairly complete but there is quite a bit missing at the 802.15.4 mac 
layer such as beacons and security? I assume this will increase the code 
size of RIOT?


Thanks

Simon

On 18/03/15 06:51, Ludwig Ortmann wrote:

Hi,

I think our only m0+/802.15.4 board is the samr21-xpro and there are problems 
with the current/old network stack because of its memory demands.
That said: which  protocol on top of IP are you interested in?
I assume you want to ignore RPL and any other side-tasks for this evaluation?

Cheers,
Ludwig

Am 17. März 2015 17:46:52 MEZ, schrieb Simon Vincent simon.vinc...@xsilon.com:

Hi Craig,

We have a 802.15.4 transceiver that is capable of 250kbps. We are
thinking of using this with a Cortex M0+ but wanted to make sure that
the M0+ would have the processing power to handle the
802.15.4/6lowpan/ipv6 stack at a datarate of 250kbps.

I just wondered if anyone had done any datarate measurements on
existing
development boards using the Cortex M0+?

- Simon

On 17/03/15 16:20, Craig Younkins wrote:

Hi Simon,

Throughput will be highly dependent upon the RF environment and what
transceiver you are using. The M0+ most likely has enough power to do
it under ideal conditions, but retransmissions due to collisions will
limit the effective bandwidth.

You can use 900 mhz and 2.4 ghz transceivers with 15.4. ~900 is
significantly less crowded but lower theoretical bandwidth. The Atmel
212B is 900 Mhz and specs 1000 kbps as the max air data rate.

Which transceiver are you using?

Craig Younkins

On Tue, Mar 17, 2015 at 11:42 AM, Simon Vincent
simon.vinc...@xsilon.com mailto:simon.vinc...@xsilon.com wrote:

 Has anyone done any performance tests to see what throughput can
 be achieved using RIOT?

 I would be interested to know if the Cortex M0+ is powerful

enough

 to sustain 250Kb/s TCP over 6lowpan/802.15.4.

 Does RIOT have any mechanism to measure CPU usage?

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




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





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

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


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


Re: [riot-devel] NFC Atmel AT86RF232B

2015-03-19 Thread Akshay Mishra
My colleague Nidhya should be posting on this. Expect EoD India time.

Akshay

On Thursday, 19 March 2015, Baptiste Clenet bapcle...@gmail.com wrote:

 Hello,

 I'm also interesting in AT86RF212B driver.
 Ashkay has already done some improvements with this driver.
 Does anybody have a WIP branch to try this driver?

 Cheers,

 2015-03-18 22:14 GMT+01:00 Joakim Gebart joakim.geb...@eistec.se
 javascript:_e(%7B%7D,'cvml','joakim.geb...@eistec.se');:

 Hello,

 On Wed, Mar 18, 2015 at 10:08 PM, Craig Younkins cr...@freshtemp.com
 javascript:_e(%7B%7D,'cvml','cr...@freshtemp.com'); wrote:
  I think the at86rf231 driver works with the 212B or will otherwise
 require
  minimal changes. I have not tested it but anticipate using it. In the
 linux
  kernel they are both supported in the same file.

 Yes, the AT86RF212B works with the at86rf231 driver. The driver is
 undergoing some work right now, see
 https://github.com/RIOT-OS/RIOT/pull/2562 and
 http://lists.riot-os.org/pipermail/devel/2015-March/002247.html

 I have seen a memory corruption bug with the driver but not had the
 time to pinpoint it exactly, it seems to happen randomly, but in the
 vicinity of the radio RX code. I will open a PR when I find a solution
 unless someone else beats me to it.

 Best regards,
 Joakim
 www.eistec.se

 
  Craig Younkins
 
  On Wed, Mar 18, 2015 at 5:04 PM, Joël Chotard joel.chot...@xsoen.com
 javascript:_e(%7B%7D,'cvml','joel.chot...@xsoen.com');
  wrote:
 
  Hi all,
 
  Does somebody is working on a RIOT NFC device driver ? and the ATMEL
 sub-G
  AT86RF212B driver ?
 
  Joël
  ___
  devel mailing list
  devel@riot-os.org javascript:_e(%7B%7D,'cvml','devel@riot-os.org');
  http://lists.riot-os.org/mailman/listinfo/devel
 
 
 
  ___
  devel mailing list
  devel@riot-os.org javascript:_e(%7B%7D,'cvml','devel@riot-os.org');
  http://lists.riot-os.org/mailman/listinfo/devel
 
 ___
 devel mailing list
 devel@riot-os.org javascript:_e(%7B%7D,'cvml','devel@riot-os.org');
 http://lists.riot-os.org/mailman/listinfo/devel




 --

 *Clenet BaptisteFR: +33 6 29 73 05 39 %2B33%206%2029%2073%2005%2039*


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


Re: [riot-devel] PWM on STM32-L1

2015-03-19 Thread Peter Kietzmann

Hello Vivien  Co.,

and welcome to RIOT! Let my try to bring some light into the dark :-) . 
You'll find my comments inline. The general idea of the periph_conf.h 
is a RIOT specific hardware/pin abstraction. Is it correct assuming you 
have a stm32 nucleo-l1 board?



Am 17.03.2015 um 14:50 schrieb Vivien Michel:

Hello,

We are four students, working on riot-os implementation for STM32-L1. 
But we are facing some problems : we're trying to add PWM features in 
order to use a motor shield. We already have implemented the pwm.h for 
our board. And now we're having a hard time understanding how we 
should proceed with the periph_conf.h file.


The pwm.h is a peripheral interface which you can find in 
RIOT/drivers/include/periph/pwm.h. You'll need to fulfill this API 
with your driver implementation but NOT adapt it. It is designed to 
match the basic functionalities.


Actually, our main confusion comes from the defines that we have to 
use to configure the pwm pins.


As stated above, the periph_conf.h decouples hardware-specific stuff 
from the RIOT naming-scheme. For example, you can setup the pin PA09 on 
the board and name it GPIO_0 in RIOT.


- Regarding the channels, we don't really get what it refers to ? Do 
the values defined for these channels directly correspond to the 
number written on the board near the pins (numbers 3, 5, 6, 9, 10 and 
11 on the stm32l1) ? Why are there four channels defined for each pwm 
pins in the stm32f3discovery's periph_conf.h ?


Comparing the stm32f3discovery you can have multiple PWM channels on one 
port. Each channel can fulfill a separate PWM and therefore has its own 
pin. On stm32f3discovery there are two ports with four channels each. 
For your first implementation you don't need to implement multiple 
channels per board. One working PWM (pin) should be enough to validate 
the driver.
You can not compare the numbers written on the stm32 nuclea-l1 and the 
stm32f3discovery. I guess you need to understand the I/O pin multiplexer 
in general. Please read [1] p.175 sec. 7.3.2.


- What values should we use for the PWM_X_DEV, PWM_X_CLKEN(), 
PWM_X_CLKDIS() and PWM_X_PORT_CLKEN() ?


Did you have a look at the CMSIS header? You can find it in 
RIOT/cpu/stm32l1/include/stm32l1xx.h. There, all registers and cpu 
specific configurations are named. You should have a look at (i) the use 
of this file comparing for example to the gpio implementation and (ii) 
compare the stm32f3 PWM implementation. You will see that the PWM 
especially depends by timers (TIMx). You'll also need to enable bus 
clocks for the peripherals. You can find all principles in the stm32f3 
implementation as this is really similar to the stm32l1 i think. Also 
you can find everithing in the manual [1].


- For the PWM_X_PORT, should we use GPIOC and GPIOD as it is done for 
the stm32f3 ?


You need to go into the manual and see where you can map these pins to. 
It think it is not possible on every port and every pin for each 
potential function. Select a port and pin where no other peripheral 
function is placed.


- Should we disable the pins in the GPIO config if we want to use them 
as PWM ?


Please try to avoid multiple functions for one pin. Then you don't have 
to disable them.




We would be very grateful for any help.

Are you fine now, any further questions?



Best regards.


Cheers,
Peter



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


--
Peter Kietzmann

Hamburg University of Applied Sciences
Dept. Informatik, Internet Technologies Group
Berliner Tor 7, 20099 Hamburg, Germany
Fon: +49-40-42875-8426
Web: http://www.haw-hamburg.de/inet

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


[riot-devel] Iotivity, AllJoyn, Thread, Ipso Alliance

2015-03-19 Thread Baptiste Clenet
Hi Rioters,

This question is not particularly about Riot but it makes sense to ask you
since future Riot device might use one of this high level protocol
(Iotivity, AllJoyn, Thread, Ipso Alliance).
What do you think about them?  In your opinion, which one will be mostly
used?
Is there any future developments planned on RIOT?

Cheers,

-- 

*Clenet BaptisteFR: +33 6 29 73 05 39*
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] NFC Atmel AT86RF232B

2015-03-19 Thread Oleg Hahm
Hi Thomas!

 I got me some NXP pn532 modules some time ago as I heard there is work
 on specifying 6LoWPAN over ISO 14443 (which NFC is part of). 

Indeed, there is. See https://tools.ietf.org/html/draft-ietf-6lo-nfc-00

 Sadly, I didn’t come too far with the driver, as it includes a (more) complex
 communication with the module, at least for the pn532, and it was kind of a
 private side project. My initial work can be found in [1].

Link was missing. ;)

Cheers,
Oleg
-- 
The worst part about token ring jokes is that if someone starts telling one
while you are telling yours, all joking stops.


pgpwNwstUxK_7.pgp
Description: PGP signature
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] [GSOC] Introduction

2015-03-19 Thread Hauke Petersen

HI Francesco,

On 18.03.2015 19:07, Francesco Ermini wrote:

Thanks for the Xbee driver,I'll wait the PR for testing!

The security aspect is about including in RIOT the possibility to 
dynamically insert a set of encryption keys at run time through an 
external channel (I have a collegue working on NFC driver on  RIOT). 
Basically,the keys I want to exchange are those concering the 802.15.4 
protocol,but we can use the same technique for RPL or CoAP.
Sounds very interesting! There is quite some demand for this inside (and 
outside) of our community. Regarding GSOC - do you have already a rough 
idea about an architecture and a high-level project plan on how you 
would like to structure this as a GSOC project? I encourage you to share 
this with us, so we can help you to improve it!


Cheers,
Hauke





2015-03-16 19:21 GMT+01:00 Hauke Petersen hauke.peter...@fu-berlin.de 
mailto:hauke.peter...@fu-berlin.de:


Hi Francesco,

welcome to RIOT first of all.

Cool that you are working with the UDOO boards! BLE development
with these boards would indeed be a little difficult, as I don't
know any shields without fully integrated network stack, that
would allow for access to the BLE link layer.

Porting the Xbee device to RIOT is unfortunately already almost
finished [1] - I am just sitting on the last fixes and will
release a PR in the next couple of days...

The security aspect however is not yet included. Taking this to a
more general approach (valid for not only the xbee device) is
however a very hot topic. Here I would indeed see a project for
GSOC. Do you have already any further ideas what you would like to
do in this direction? It would be nice, if you could roughly
sketch our your ideas, so we can discuss them further.

Cheers,
Hauke

[1] https://github.com/haukepetersen/RIOT/tree/add_driver_xbee




On 12.03.2015 15:46, Francesco Ermini wrote:


Hi,

my name is Francesco Ermini, and I'm student in electronics  and
telecommunication engineering at the University of Florence,Italy.

My current Ms.C. thesis is about IoT secure communications. Our
testbed is made by some UDOO Quad boards, with Linux + RiOT as
operating systems (the UDOO can host two OSes at once).
I checked the GSOC ideas page, and I found the Bluetooth Low
Energy driver one. Although interesting, using BTLE wouldn't
rally match my current work.
However, we also found that the XBee shield is not yet supported
in RiOT (open bug / feature request). This would match a bit more
my thesis work, and my (evil) tutor would be happier.

My question is: what about implementing the XBee driver
(including the dynamic security keys setup) ?

Best regards,

Francesco


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





--
Francesco Ermini
Via Abebe Bikila, 8 50012 (FI)
cell. 3338710609
tell. 055642820


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


Re: [riot-devel] Benchmarks

2015-03-19 Thread Oleg Hahm
Hi Simon!

 Yes I tried to compile the rpl_udp example for the samr21-xpro but it did
 not have enough RAM. Even with RPL in non-storing mode and a very small
 routing table it would not fit.

Well, in non-storing you basically don't need any routing table (except for
the root node), but still it sounds weird to me that it doesn't fit. I guess
some optimization could be doable but...

 Ultimately we would be looking to run UDP/RPL/COAP on top of the
 IPv6/6lowpan/802.15.4 stack.
 
 For the evaluation just UDP would be fine to give me an idea if a M0+ would
 be fast enough.
 
 Is the size of RAM/flash for RIOT likely to increase? Currently building the
 rpl_udp example results in 109K text+data, 37K bss. We were thinking of
 going for a M0+ with 128KB flash and 64KB RAM but this does not leave much
 room for expansion.

Hopefully and most likely the contrary will be the case. As the current network
stack could definitely need quite some memory optimizations and wastes a lot
of memory by many memcpy operations, we decided to completely redesign it, in
order come up with a much slimmer solution. (Apart of having identified other
drawbacks of the old solution.)

This new stack should definitely fit on the 32 kB RAM of the SAMr21 including
UDP/RPL/CoAP, but I cannot give any concrete numbers by now. Hauke, Martine,
can you give some rough numbers for the current state of the implementation?

Another advantage of the redesigned network stack will be its configurability.
The current version, for example, always expects the default minimum MTU for
IPv6 of 1280 bytes and thus reserves this once in the outgoing and once for
the incoming buffer.

For more information on the new network stack, see our paper on
http://arxiv.org/abs/1502.01968 and the minutes from the meeting in February:
https://github.com/RIOT-OS/RIOT/wiki/minutes-network-task-force-feb-2015

There is also most of the functionality already out there on Github as Pull
Requests.

 Am I correct in thinking that the IPv6/6lowpan/UDP/TCP/RPL stacks are fairly
 complete but there is quite a bit missing at the 802.15.4 mac layer such as
 beacons and security? I assume this will increase the code size of RIOT?

Yes, this assumption is mostly correct. The biggest limitations for the upper
layer stack are:
 - In the current version, 6LoWPAN and IPv6 are mostly entangled and therefore
   IPv6 cannot be used standalone.
 - Without support for multiple radios on one board, similar to Contiki, the
   border router will work only over stdio over a serial port (and haven't
   been tested for quite a while).
 - Only the basic TCP feature set is implemented. Due to memory constraints,
   the window size is fixed to one.

However, as I said before, we can expect rather a _de_creasing code size for
the new version of the network stack, eliminating these shortcomings.

Cheers,
Oleg
-- 
printk (Barf\n);
linux-2.6.6/arch/v850/kernel/module.c


pgppxxts9bQVP.pgp
Description: PGP signature
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] Regarding Project A2

2015-03-19 Thread Hiesgen, Raphael
Hi Dinuka,

welcome to RIOT! 

 I would like to know whether for what platform(ARM,Intel Galileo) we have to 
 develop the applications?

You can target any platform you want, as long as it runs RIOT. If you want 
adapt the project idea as is, the biggest constraint for target hardware is 
memory size. We use the stm32f4discovery boards ourselves for testing with 
RIOT, CAF and C++. The board is already supported by RIOT and has 1MB ROM and 
192 KB RAM if I am not mistaken.

Here are some more thoughts on the project, which I have posted on the mailing 
list earlier:

 The idea is to use the C++ Actor Framework for programming. It is an 
 implementation of the actor model [1] and can be found on Github [2]. The 
 project itself features some examples and documentation how to use it. It 
 should be noted that RIOT support is still in development, see the topic/caf 
 branch of my RIOT fork [3] and the topic/riot branch of CAF [4]. For now, you 
 can use actors on the board, but the network communication is not implemented 
 (yet).
 
 The network stack we want to deploy is based on IEEE 802.15.4, 6LoWPAN, UDP 
 and CoAP. To enable IEEE 802.15.4 and 6LoWPAN on desktop machines we acquired 
 some usb dongles [4]. For testing CAF with RIOT, we use stm32f4discovery 
 boards which have a lot of memory available, but do not have a transceiver. 
 Getting that to work is required at some point.
 
 In any case, I would suggest to start by developing the application logic on 
 a desktop machine. It allows for easier debugging and should allow you to use 
 basically the same code on RIOT later on. Further, it is helpful to have a 
 small setup for testing your deployment later on. 

Hope this answers your question.

Raphael

[1] http://en.wikipedia.org/wiki/Actor_model
[2] https://github.com/actor-framework/actor-framework
[3] https://github.com/josephnoir/RIOT
[4] http://rosand-tech.com/products/r-idge/prod.html

 On Mar 18, 2015, at 6:09 PM, Dinuka Salwathura dinuka...@cse.mrt.ac.lk 
 wrote:
 
 Hello RIOT community,
 
 I am Dinuka Sawlathura from University of Moratuwa, Sri Lanka. 
 I am doing Computer Science  Engineering(Integrated Computer Engineering).
 
 I like to work on following project,
 
 Project A2: Intelligently Interacting Light Switches
 I would like to know whether for what platform(ARM,Intel Galileo) we have to 
 develop the applications?
 
 Thank you,
 best regards,
 Dinuka
 ___
 devel mailing list
 devel@riot-os.org
 http://lists.riot-os.org/mailman/listinfo/devel

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


Re: [riot-devel] Project S2: RIOT as an RPython Module

2015-03-19 Thread Kaspar Schleiser

Hi AAshish,

Thanks for your interest!

On 03/12/15 19:36, Regmi, Aashish wrote:

I was wondering if you could provide more information about the project
so that I can get a clear understanding about the project and about how
to get started with project.
Well, some of us think that it would be nice to be able to write RIOT 
applications in a language different than C.


RPython would be one way, as it allows compiling Python code to plain C, 
which could be linked to RIOT.


Another way would be to port e.g., micropython[1], to RIOT as a package.

Any print(Hello World!) written in python but running on a RIOT node 
would probably an awesome outcome of this project.


While this needs some understanding of programming languages in general, 
it is more a project requiring knowledge about how to integrate and 
adapt a python interpreter or runtime into the ressource-constrained 
RIOT environment, with the involved challenges around memory management, 
linking, ...


If you are still interested, the next step for you would be to prepare a 
short application [1][2]. The main part of the application consists of 
your proposed (high-level) project plan. Maybe have also a look at our 
last dev-meeting minutes [3] for some more information.


Furthermore we would like to see some first involvement with RIOT by 
contributing a (simple) pull request to RIOT. The purpose of this is to 
get you an idea of how the community works and what RIOT development is 
about. Have a look at our development procedures [4] and contributing 
guidelines [5]. The easiest way to get involved is by looking at issues 
marked as 'Newbie-Task-Candidate' and to fix one (or more) of them.


Let us know if you have more specific questions!

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


[riot-devel] New Event: Hack'n'ACK @ Monthly from 5pm to 10pm on the last Tuesday (RIOT Events)

2015-03-19 Thread Martine Lenders
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
X-GOOGLE-CALID:k3ql8setv7l48ofnol0tfuu...@group.calendar.google.com
BEGIN:VTIMEZONE
TZID:Europe/Berlin
X-LIC-LOCATION:Europe/Berlin
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T03
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=Europe/Berlin:20150331T17
DTEND;TZID=Europe/Berlin:20150331T22
RRULE:FREQ=MONTHLY;BYDAY=-1TU
DTSTAMP:20150319T120715Z
UID:lbk4mfucqdomcf7c8o9cg4c...@google.com
CREATED:20150319T120715Z
DESCRIPTION:View your event at https://www.google.com/calendar/event?action
 =VIEWeid=bGJrNG1mdWNxZG9tY2Y3YzhvOWNnNGNtc2cgazNxbDhzZXR2N2w0OG9mbm9sMHRmd
 XU2dHNAZw.
LAST-MODIFIED:20150319T120715Z
LOCATION:c-base Berlin\; HAW Hamburg
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Hack'n'ACK
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] More convenient access to the IoT-LAB from a RIOT application

2015-03-19 Thread Gaëtan Harter

Hi Oleg,

I think it's a good idea, it will allow easier runnig RIOT code on the 
platform.

I will write feedback directly on the PR.

Regards,
Gaëtan

On 03/18/2015 07:23 PM, Oleg Hahm wrote:

Dear rewewing IoTlers,

I just opened a pull request in RIOT that should ease the work with RIOT
applications on the IoT-LAB testbed a little bit:
https://github.com/RIOT-OS/RIOT/pull/2640

Including the proposed Makefile like

  include $(RIOTBASE)/dist/Makefile.iot-lab

in an application's Makefile allows to create IoT-LAB experiments, flash,
reset and access the nodes right from the command line with Make in one go,
e.g. executing

export BOARD=iot-lab_M3
make iotlab-auth
make iotlab-exp IOTLAB_NODES=10 IOTLAB_DURATION=60 IOTLAB_SITE=grenoble
make iotlab-flash
make iotlab-term

will reserve an experiment for 10 nodes and 60 minutes in Grenoble, flash the
current application to all nodes and starts serial_aggregator for these nodes.

Let me know what you think about this idea and what could be improved.

Cheers,
Oleg


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


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


Re: [riot-devel] NFC Atmel AT86RF232B

2015-03-19 Thread Joel Chotard
Hi Thomas,

Thanks for your informations.
I'm checking the NXP NFC components and need a feedback from the NXP supplier 
for the best version. It's seems the NTAG I2C has interested functions.
When we will get the complet datasheet we will check the job we have to do.
Joël

-Message d'origine-
De : devel [mailto:devel-boun...@riot-os.org] De la part de Thomas Eichinger
Envoyé : jeudi 19 mars 2015 10:51
À : RIOT OS kernel developers
Objet : Re: [riot-devel] NFC  Atmel AT86RF232B

Hi Joël,

ad NFC:
I got me some NXP pn532 modules some time ago as I heard there is work on 
specifying 6LoWPAN over ISO 14443 (which NFC is part of). Beside this there are 
a lot of interesting applications you could build in combination with 
constraint networks.
Sadly, I didn’t come too far with the driver, as it includes a (more) complex 
communication with the module, at least for the pn532, and it was kind of a 
private side project. My initial work can be found in [1].

ad rf212b:
As Joakim stated, the existing at86rf231 driver supports the rf212b as the main 
functionality is the same for all current Atmel radio devices.
I’m also currently refactoring the driver, providing the ability to extend the 
common functionality by very device specific features without writing it from 
scratch. I have it running for the rf231 already but need some more time to 
debug and entangle it correctly with all the other new network stack work. I 
will open a WIP PR for this today.

Best, Thomas


 On 18 Mar 2015, at 22:04, Joël Chotard joel.chot...@xsoen.com wrote:
 
 Hi all,
 
 Does somebody is working on a RIOT NFC device driver ? and the ATMEL sub-G 
 AT86RF212B driver ?
 
 Joël
 ___
 devel mailing list
 devel@riot-os.org
 http://lists.riot-os.org/mailman/listinfo/devel

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

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