Re: [riot-devel] Call for OTA (Over the Air Update) Task Force

[Arvid Picciani]

Thanks everyone for the input so far, it looks like there is a decent agreement 
on some core concepts,
and there is a strong interest to contribute them. 

I would like to propose to continue with a virtual meeting, to:

- present a summary(!) of the use cases and requirements posted on the ML
- break them down into layers (such as bootloader, flash, etc)
- for each of those layers, get a rough idea about what exists already today,
  or what we can do to help create them.

Since this is a fairly industry-heavy crowd, i would suggest having the meeting 
during central european work hours for 2 hours.

http://doodle.com/mtzr2s9fbdx72sun

I will read all the comments on this doodle and try to adjust accordingly, so 
please also post your preferred time of the day.

best,
Arvid


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

Re: [riot-devel] 'defalut' example on SAMR21 Xplained Pro

[Thomas Eichinger]

Hi Kévin,

just checked with RIOT’s master and default example works for me.
When you run `make term` is the yellow status LED on the board on?

Best, Thomas

> On 06 Feb 2015, at 11:57, Ludwig Ortmann  wrote:
> 
> Hi,
> 
> Please try connecting to a different USB port, I've seen this before.
> 
> Cheers, Ludwig
> 
> Am 6. Februar 2015 11:42:05 MEZ, schrieb "ROUSSEL Kévin" 
> :
>> Hello everyone,
>> 
>> Does the 'default' example work correctly on SAMR21 Xplained Pro? I 
>> compiled and flashed successfully this application on the Xplained Pro
>> I 
>> have; but when doing 'make term', I just can't obtain any output from 
>> the board (via the same debug USB port I used to flash).
>> 
>> Was anyone able to run this example successfully on the SAM R21, or 
>> there a known problem?
>> 
>> Thanks,
>> -- 
>> 
>> 
>> Kévin Roussel
>> Doctorant, projet LAR
>> Équipe MADYNES, INRIA Nancy Grand-Est / LORIA
>> Tél. : +33 3 54 95 86 27
>> kevin.rous...@inria.fr
>> 
>> ___
>> 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] Problem socket UDP

[Baptiste Clenet]

Yes sure

2015-02-06 15:07 GMT+01:00 Ludwig Ortmann :

> Hi Baptiste,
>
> could you open an issue please?
>
> Cheers, Ludwig
>
> On Fri, Feb 06, 2015 at 03:05:05PM +0100, Baptiste Clenet wrote:
> > After pluging a second sender, I got the problem:
> > if ((socket > MAX_SOCKETS) || (socket_base_sockets[socket -
> > 1].socket_id == 0)) {
> > return false;
> > }
> > socket = 11534388
> > socket_base_sockets[socket - 1].socket_id = 64
> >
> > And then the program goes to isr_hard_fault
> >
> > 2015-02-06 14:19 GMT+01:00 Baptiste Clenet :
> >
> > > I have let my program running with two boards: one sender and one
> > > receiver. It seems to work for the moment (longer than with three
> sender
> > > boards)
> > >
> > > 2015-02-06 10:53 GMT+01:00 Baptiste Clenet :
> > >
> > >> Hi Oleg,
> > >>
> > >> I tried on native by simulating the value from sensor and it works
> after
> > >> one hour of running.
> > >> So it seems to be a platform specific problem.
> > >>
> > >> Any clues? Which test shoud I do then? and where the variable socket
> is
> > >> incremented?
> > >>
> > >> Cheers,
> > >>
> > >> 2015-02-06 8:18 GMT+01:00 Oleg Hahm :
> > >>
> > >>> Hi Maxence!
> > >>>
> > >>> > You mean than I should slow down the number of transmission? I
> send a
> > >>> > packet every second on three boards which means that the other
> board
> > >>> > receives three packets a second.
> > >>> > How may I check apart from slowing down the rate of the
> transmission?
> > >>>
> > >>> Three packets every second shouldn't be a problem. Have you checked
> if
> > >>> same
> > >>> (or similar code) works on native. That would be always the first
> > >>> indicator if
> > >>> it's a general problem in - let's say the network stack - or if it's
> > >>> something
> > >>> particular to this hardware.
> > >>>
> > >>> Cheers,
> > >>> Oleg
> > >>> --
> > >>> panic ("Splunge!");
> > >>> linux-2.2.16/drivers/scsi/psi240i.c
> > >>>
> > >>> ___
> > >>> 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>*
> > >> *Élève-Ingénieur ESEO Angers, dernière année, spécialisation:
> Architecte
> > >> système temps réél embarqué*
> > >>
> > >>
> > >> *Bidiplôme Master Robotics à l'Université de Plymouth en 2013-2014*
> > >>
> > >
> > >
> > >
> > > --
> > >
> > > *Clenet BaptisteFR: +33 6 29 73 05 39 <%2B33%206%2029%2073%2005%2039>*
> > > *Élève-Ingénieur ESEO Angers, dernière année, spécialisation:
> Architecte
> > > système temps réél embarqué*
> > >
> > >
> > > *Bidiplôme Master Robotics à l'Université de Plymouth en 2013-2014*
> > >
> >
> >
> >
> > --
> >
> > *Clenet BaptisteFR: +33 6 29 73 05 39*
> > *Élève-Ingénieur ESEO Angers, dernière année, spécialisation: Architecte
> > système temps réél embarqué*
> >
> >
> > *Bidiplôme Master Robotics à l'Université de Plymouth en 2013-2014*
>
> > ___
> > 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*
*Élève-Ingénieur ESEO Angers, dernière année, spécialisation: Architecte
système temps réél embarqué*


*Bidiplôme Master Robotics à l'Université de Plymouth en 2013-2014*
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Problem socket UDP

[Ludwig Ortmann]

Hi Baptiste,

could you open an issue please?

Cheers, Ludwig

On Fri, Feb 06, 2015 at 03:05:05PM +0100, Baptiste Clenet wrote:
> After pluging a second sender, I got the problem:
> if ((socket > MAX_SOCKETS) || (socket_base_sockets[socket -
> 1].socket_id == 0)) {
> return false;
> }
> socket = 11534388
> socket_base_sockets[socket - 1].socket_id = 64
> 
> And then the program goes to isr_hard_fault
> 
> 2015-02-06 14:19 GMT+01:00 Baptiste Clenet :
> 
> > I have let my program running with two boards: one sender and one
> > receiver. It seems to work for the moment (longer than with three sender
> > boards)
> >
> > 2015-02-06 10:53 GMT+01:00 Baptiste Clenet :
> >
> >> Hi Oleg,
> >>
> >> I tried on native by simulating the value from sensor and it works after
> >> one hour of running.
> >> So it seems to be a platform specific problem.
> >>
> >> Any clues? Which test shoud I do then? and where the variable socket is
> >> incremented?
> >>
> >> Cheers,
> >>
> >> 2015-02-06 8:18 GMT+01:00 Oleg Hahm :
> >>
> >>> Hi Maxence!
> >>>
> >>> > You mean than I should slow down the number of transmission? I send a
> >>> > packet every second on three boards which means that the other board
> >>> > receives three packets a second.
> >>> > How may I check apart from slowing down the rate of the transmission?
> >>>
> >>> Three packets every second shouldn't be a problem. Have you checked if
> >>> same
> >>> (or similar code) works on native. That would be always the first
> >>> indicator if
> >>> it's a general problem in - let's say the network stack - or if it's
> >>> something
> >>> particular to this hardware.
> >>>
> >>> Cheers,
> >>> Oleg
> >>> --
> >>> panic ("Splunge!");
> >>> linux-2.2.16/drivers/scsi/psi240i.c
> >>>
> >>> ___
> >>> 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>*
> >> *Élève-Ingénieur ESEO Angers, dernière année, spécialisation: Architecte
> >> système temps réél embarqué*
> >>
> >>
> >> *Bidiplôme Master Robotics à l'Université de Plymouth en 2013-2014*
> >>
> >
> >
> >
> > --
> >
> > *Clenet BaptisteFR: +33 6 29 73 05 39 <%2B33%206%2029%2073%2005%2039>*
> > *Élève-Ingénieur ESEO Angers, dernière année, spécialisation: Architecte
> > système temps réél embarqué*
> >
> >
> > *Bidiplôme Master Robotics à l'Université de Plymouth en 2013-2014*
> >
> 
> 
> 
> -- 
> 
> *Clenet BaptisteFR: +33 6 29 73 05 39*
> *Élève-Ingénieur ESEO Angers, dernière année, spécialisation: Architecte
> système temps réél embarqué*
> 
> 
> *Bidiplôme Master Robotics à l'Université de Plymouth en 2013-2014*

> ___
> 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] Problem socket UDP

[Baptiste Clenet]

Here is the backtrace

bt
#0  isr_hard_fault () at RIOT/cpu/samd21/startup.c:104
#1  
#2  0x06ec in clist_advance (list=0x20001c30 ) at
RIOT/core/include/clist.h:80
#3  0x08d4 in thread_yield () at RIOT/core/thread.c:99
#4  0x000167fe in isr_eic () at RIOT/cpu/samd21/periph/gpio.c:1027
#5  
#6  0x147a in ?? ()

2015-02-06 15:05 GMT+01:00 Baptiste Clenet :

> After pluging a second sender, I got the problem:
> if ((socket > MAX_SOCKETS) || (socket_base_sockets[socket -
> 1].socket_id == 0)) {
> return false;
> }
> socket = 11534388
> socket_base_sockets[socket - 1].socket_id = 64
>
> And then the program goes to isr_hard_fault
>
> 2015-02-06 14:19 GMT+01:00 Baptiste Clenet :
>
>> I have let my program running with two boards: one sender and one
>> receiver. It seems to work for the moment (longer than with three sender
>> boards)
>>
>> 2015-02-06 10:53 GMT+01:00 Baptiste Clenet :
>>
>>> Hi Oleg,
>>>
>>> I tried on native by simulating the value from sensor and it works after
>>> one hour of running.
>>> So it seems to be a platform specific problem.
>>>
>>> Any clues? Which test shoud I do then? and where the variable socket is
>>> incremented?
>>>
>>> Cheers,
>>>
>>> 2015-02-06 8:18 GMT+01:00 Oleg Hahm :
>>>
 Hi Maxence!

 > You mean than I should slow down the number of transmission? I send a
 > packet every second on three boards which means that the other board
 > receives three packets a second.
 > How may I check apart from slowing down the rate of the transmission?

 Three packets every second shouldn't be a problem. Have you checked if
 same
 (or similar code) works on native. That would be always the first
 indicator if
 it's a general problem in - let's say the network stack - or if it's
 something
 particular to this hardware.

 Cheers,
 Oleg
 --
 panic ("Splunge!");
 linux-2.2.16/drivers/scsi/psi240i.c

 ___
 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>*
>>> *Élève-Ingénieur ESEO Angers, dernière année, spécialisation: Architecte
>>> système temps réél embarqué*
>>>
>>>
>>> *Bidiplôme Master Robotics à l'Université de Plymouth en 2013-2014*
>>>
>>
>>
>>
>> --
>>
>> *Clenet BaptisteFR: +33 6 29 73 05 39 <%2B33%206%2029%2073%2005%2039>*
>> *Élève-Ingénieur ESEO Angers, dernière année, spécialisation: Architecte
>> système temps réél embarqué*
>>
>>
>> *Bidiplôme Master Robotics à l'Université de Plymouth en 2013-2014*
>>
>
>
>
> --
>
> *Clenet BaptisteFR: +33 6 29 73 05 39 <%2B33%206%2029%2073%2005%2039>*
> *Élève-Ingénieur ESEO Angers, dernière année, spécialisation: Architecte
> système temps réél embarqué*
>
>
> *Bidiplôme Master Robotics à l'Université de Plymouth en 2013-2014*
>



-- 

*Clenet BaptisteFR: +33 6 29 73 05 39*
*Élève-Ingénieur ESEO Angers, dernière année, spécialisation: Architecte
système temps réél embarqué*


*Bidiplôme Master Robotics à l'Université de Plymouth en 2013-2014*
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Problem socket UDP

[Baptiste Clenet]

After pluging a second sender, I got the problem:
if ((socket > MAX_SOCKETS) || (socket_base_sockets[socket -
1].socket_id == 0)) {
return false;
}
socket = 11534388
socket_base_sockets[socket - 1].socket_id = 64

And then the program goes to isr_hard_fault

2015-02-06 14:19 GMT+01:00 Baptiste Clenet :

> I have let my program running with two boards: one sender and one
> receiver. It seems to work for the moment (longer than with three sender
> boards)
>
> 2015-02-06 10:53 GMT+01:00 Baptiste Clenet :
>
>> Hi Oleg,
>>
>> I tried on native by simulating the value from sensor and it works after
>> one hour of running.
>> So it seems to be a platform specific problem.
>>
>> Any clues? Which test shoud I do then? and where the variable socket is
>> incremented?
>>
>> Cheers,
>>
>> 2015-02-06 8:18 GMT+01:00 Oleg Hahm :
>>
>>> Hi Maxence!
>>>
>>> > You mean than I should slow down the number of transmission? I send a
>>> > packet every second on three boards which means that the other board
>>> > receives three packets a second.
>>> > How may I check apart from slowing down the rate of the transmission?
>>>
>>> Three packets every second shouldn't be a problem. Have you checked if
>>> same
>>> (or similar code) works on native. That would be always the first
>>> indicator if
>>> it's a general problem in - let's say the network stack - or if it's
>>> something
>>> particular to this hardware.
>>>
>>> Cheers,
>>> Oleg
>>> --
>>> panic ("Splunge!");
>>> linux-2.2.16/drivers/scsi/psi240i.c
>>>
>>> ___
>>> 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>*
>> *Élève-Ingénieur ESEO Angers, dernière année, spécialisation: Architecte
>> système temps réél embarqué*
>>
>>
>> *Bidiplôme Master Robotics à l'Université de Plymouth en 2013-2014*
>>
>
>
>
> --
>
> *Clenet BaptisteFR: +33 6 29 73 05 39 <%2B33%206%2029%2073%2005%2039>*
> *Élève-Ingénieur ESEO Angers, dernière année, spécialisation: Architecte
> système temps réél embarqué*
>
>
> *Bidiplôme Master Robotics à l'Université de Plymouth en 2013-2014*
>



-- 

*Clenet BaptisteFR: +33 6 29 73 05 39*
*Élève-Ingénieur ESEO Angers, dernière année, spécialisation: Architecte
système temps réél embarqué*


*Bidiplôme Master Robotics à l'Université de Plymouth en 2013-2014*
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Problem socket UDP

[Baptiste Clenet]

I have let my program running with two boards: one sender and one receiver.
It seems to work for the moment (longer than with three sender boards)

2015-02-06 10:53 GMT+01:00 Baptiste Clenet :

> Hi Oleg,
>
> I tried on native by simulating the value from sensor and it works after
> one hour of running.
> So it seems to be a platform specific problem.
>
> Any clues? Which test shoud I do then? and where the variable socket is
> incremented?
>
> Cheers,
>
> 2015-02-06 8:18 GMT+01:00 Oleg Hahm :
>
>> Hi Maxence!
>>
>> > You mean than I should slow down the number of transmission? I send a
>> > packet every second on three boards which means that the other board
>> > receives three packets a second.
>> > How may I check apart from slowing down the rate of the transmission?
>>
>> Three packets every second shouldn't be a problem. Have you checked if
>> same
>> (or similar code) works on native. That would be always the first
>> indicator if
>> it's a general problem in - let's say the network stack - or if it's
>> something
>> particular to this hardware.
>>
>> Cheers,
>> Oleg
>> --
>> panic ("Splunge!");
>> linux-2.2.16/drivers/scsi/psi240i.c
>>
>> ___
>> 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>*
> *Élève-Ingénieur ESEO Angers, dernière année, spécialisation: Architecte
> système temps réél embarqué*
>
>
> *Bidiplôme Master Robotics à l'Université de Plymouth en 2013-2014*
>



-- 

*Clenet BaptisteFR: +33 6 29 73 05 39*
*Élève-Ingénieur ESEO Angers, dernière année, spécialisation: Architecte
système temps réél embarqué*


*Bidiplôme Master Robotics à l'Université de Plymouth en 2013-2014*
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] 'defalut' example on SAMR21 Xplained Pro

[Ludwig Ortmann]

Hi,

Please try connecting to a different USB port, I've seen this before.

Cheers, Ludwig

Am 6. Februar 2015 11:42:05 MEZ, schrieb "ROUSSEL Kévin" 
:
>Hello everyone,
>
>Does the 'default' example work correctly on SAMR21 Xplained Pro? I 
>compiled and flashed successfully this application on the Xplained Pro
>I 
>have; but when doing 'make term', I just can't obtain any output from 
>the board (via the same debug USB port I used to flash).
>
>Was anyone able to run this example successfully on the SAM R21, or 
>there a known problem?
>
>Thanks,
>-- 
>
>
>  Kévin Roussel
>  Doctorant, projet LAR
>  Équipe MADYNES, INRIA Nancy Grand-Est / LORIA
>  Tél. : +33 3 54 95 86 27
>  kevin.rous...@inria.fr
>
>___
>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

[riot-devel] 'defalut' example on SAMR21 Xplained Pro

[ROUSSEL Kévin]

Hello everyone,

Does the 'default' example work correctly on SAMR21 Xplained Pro? I 
compiled and flashed successfully this application on the Xplained Pro I 
have; but when doing 'make term', I just can't obtain any output from 
the board (via the same debug USB port I used to flash).


Was anyone able to run this example successfully on the SAM R21, or 
there a known problem?


Thanks,
--


 Kévin Roussel
 Doctorant, projet LAR
 Équipe MADYNES, INRIA Nancy Grand-Est / LORIA
 Tél. : +33 3 54 95 86 27
 kevin.rous...@inria.fr

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

Re: [riot-devel] How low can you go?

[Joakim Gebart]

On Fri, Feb 6, 2015 at 10:10 AM, Thomas Eichinger
 wrote:
> Hi,
>
>> On 06 Feb 2015, at 09:36, Ludwig Ortmann  wrote:
>>
>> Hi,
>>
>> On Fri, Feb 06, 2015 at 09:03:31AM +0100, Oleg Hahm wrote:
>>> Am Thu, Feb 05, 2015 at 02:09:52PM -0800 schrieb Adam Hunt:
 There's already a driver for for Atmel's AT86RF231 in the tree and while
 the AT86RF230 on the Raven boards are nearly the same the 230 lacks a
 couple minor features, namely a crypto processor and RNG. So, the RF link
 would be wide open but for experimentation and learning sacrifices are
 often necessary.
>>>
>>> As far as I know there were some considerations and work done towards a
>>> generic AT86RF23x or even AT86RF2xx driver. Thomas, am I right?
>>
>> Yes, I'm working on that (almost done).
> Yes, I will take up work on this again next week, as we have a stable netdev
> interface by today.
>

That's great news!
I have seen some compatibility issues when I have been attempting to
use the 231 driver for the 212B (sub-GHz band), but I assume this is
because every limit etc. is configured to work with the 2.4 GHz
register values on the 231.

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

Re: [riot-devel] Problem socket UDP

[Baptiste Clenet]

Hi Oleg,

I tried on native by simulating the value from sensor and it works after
one hour of running.
So it seems to be a platform specific problem.

Any clues? Which test shoud I do then? and where the variable socket is
incremented?

Cheers,

2015-02-06 8:18 GMT+01:00 Oleg Hahm :

> Hi Maxence!
>
> > You mean than I should slow down the number of transmission? I send a
> > packet every second on three boards which means that the other board
> > receives three packets a second.
> > How may I check apart from slowing down the rate of the transmission?
>
> Three packets every second shouldn't be a problem. Have you checked if same
> (or similar code) works on native. That would be always the first
> indicator if
> it's a general problem in - let's say the network stack - or if it's
> something
> particular to this hardware.
>
> Cheers,
> Oleg
> --
> panic ("Splunge!");
> linux-2.2.16/drivers/scsi/psi240i.c
>
> ___
> devel mailing list
> devel@riot-os.org
> http://lists.riot-os.org/mailman/listinfo/devel
>
>


-- 

*Clenet BaptisteFR: +33 6 29 73 05 39*
*Élève-Ingénieur ESEO Angers, dernière année, spécialisation: Architecte
système temps réél embarqué*


*Bidiplôme Master Robotics à l'Université de Plymouth en 2013-2014*
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] How low can you go?

[Thomas Eichinger]

Hi,

> On 06 Feb 2015, at 09:36, Ludwig Ortmann  wrote:
> 
> Hi,
> 
> On Fri, Feb 06, 2015 at 09:03:31AM +0100, Oleg Hahm wrote:
>> Am Thu, Feb 05, 2015 at 02:09:52PM -0800 schrieb Adam Hunt:
>>> There's already a driver for for Atmel's AT86RF231 in the tree and while
>>> the AT86RF230 on the Raven boards are nearly the same the 230 lacks a
>>> couple minor features, namely a crypto processor and RNG. So, the RF link
>>> would be wide open but for experimentation and learning sacrifices are
>>> often necessary.
>> 
>> As far as I know there were some considerations and work done towards a
>> generic AT86RF23x or even AT86RF2xx driver. Thomas, am I right?
> 
> Yes, I'm working on that (almost done).
Yes, I will take up work on this again next week, as we have a stable netdev
interface by today.

Best, Thomas

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

Re: [riot-devel] Network Stack Task Force

[Hauke Petersen]

Good Morning again,

we will continue with the network stack soon.

If you want to join remotely, here is the PlaceCam link:
http://placecam.de/call.php?c=0~dA5j0OrfTdsesyQKlqIZvQi7bo1YKYGdMORGFmqL8- 



How-To use it? 
https://github.com/RIOT-OS/RIOT/wiki/Instructions-for-remote-participation


Cheers,
Hauke


On 05.02.2015 10:03, Martine Lenders wrote:

Good Morning,

here is the placecam link 
http://placecam.de/call.php?c=0~dA5j0OrfTdsesyQKlqIZvQi7bo1YKYGdMORGFmqL8- 



How-To use it? 
https://github.com/RIOT-OS/RIOT/wiki/Instructions-for-remote-participation


Cheers,
Martine

2015-02-04 22:32 GMT+01:00 Matthias Waehlisch 
mailto:m.waehli...@fu-berlin.de>>:


Hi Jan,

On Wed, 4 Feb 2015, Jan Wagner wrote:

> i just installed placecam, do you send out the meeting link to this
> mailing list or person based emails?. i would like to join tomorrow
> and if needed would request that link.
>
  Hauke will provide the link tomorrow via the mailing list.

>  ps. do i need a cam or is audiio only ok?
>
  You don't need a cam, audio is fine.


Cheers
  matthias

--
Matthias Waehlisch
.  Freie Universitaet Berlin, Inst. fuer Informatik, AG CST
.  Takustr. 9, D-14195 Berlin, Germany
.. mailto:waehli...@ieee.org  ..
http://www.inf.fu-berlin.de/~waehl

:. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net
___
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] Call for OTA (Over the Air Update) Task Force

[Joel Chotard]

Hi All,

 

We are also looking for the OTA function for the SAM R21 (ATMEL). What we
need would be:

-Use of an external SPI 256KB Flash ( Microchip SST25VF020B cost by 5K
is 0.42USD). 

-The integrated startup code (bootloader) and update code are located in
a non-updateable memory location in the internal Flash protected by the
BOOTPROT bit active. (datasheet p 350)

   

-Secured update will use AES128 (coprocessor) and key exchange (hardware
RNG).

 

-The current firmware will write the new firmware into the external SPI
Flash memory. The integrity of every firmware segment is ensured by a 32 Bit
CRC Checksum. A function “Verify packets” will inform the number of pages
sent to the device (each function contain a 32 Bit CRC Checksum). When the
complete procedure is finished, (all pages of packets was verified) set a
flag in the EEPROM (emulation zone in internal Flash).

 

-Start the update code in internal Flash (protected bootloader area)and
erase the old firmware located in the internal Flash.

 

- Copy the new firmware in the Internal Flash from the SPI external
Flash, reset the update flag and restart the SAM R21.

 

-If the power is interrupted during the update process, the bootloader
must check if the update bit in emulated EEPROM is set, if yes, must to
restart the update process, if not start RIOT.

 

-Each firmware specify :

 The Supplier ID (32 bit ID, for testing or without protection one
reserved supplier ID can be defined, the update will work if only this ID
has a valid checksum), 

 Product ID will be define by the developer and will offer to update
same products with this firmware,

 Firmware version with major or minor version (only newer firmware
versions are accepted).

 

-Functions :

Each function include a Supplier ID, Product ID, Firmware version, Packet
CRC32 and …

oFirmware version

oSupplier IDIPV6 ID global ???

oProduct ID

oTarget IP  IPV6 address to which device the firmware is send.
Can be a multicast address.

oInterface  which interface will be use

oOTA port   UDP port

oFragment size  size of the packets should be send. Small value if
multicast is use.

oPacket Period  value to define for not stopped an application

oVerify Packets number of pages sent, the receiver need to verify if
the checksums of the packets received are OK. If not the page number will be
resend. If   all are OK, the sender will receive “OK”

oExecute Packetsthe server will send this command when it will have
the confirmation for all packets were received are OK to one or all devices
(multicast or unicast).

 

Next step will be to implement a dynamic loader (remove cost of the external
Flash), but it should be a long development and RIOT will have during this
time many improvements. (Here is maybe a good start:

https://github.com/SGSSGene/RIOT/blob/pr_dynamic_loader/sys/elfloader/README
.md)

Waiting for your feedback !

 


--

De : devel [mailto:devel-boun...@riot-os.org] De la part de Joaquín Cabezas
Envoyé : mercredi 4 février 2015 08:35
À : devel@riot-os.org
Objet : Re: [riot-devel] Call for OTA (Over the Air Update) Task Force

 

Hi everybody,

we are also interested in this feature, and we are willing to collaborate to
achieve it. We have already looked at LWM2M and find it quite suitable for
our needs. Plus it's telco-friendly.

Best Regards,
Joaquín. 



El 22/01/2015 a las 21:20, Joakim Gebart escribió:

On 01/20/2015 06:47 PM, Arvid Picciani wrote:

As discussed during Hack'n'Ack, let’s organize a task force to address
a currently hot feature in RIOT: Over the Air Updates.
In Q1 2015 the company I work for is planning to contribute that
feature, so i would like to call everyone who is planning or
interested in the same feature to align goals.
 
- Who is interested in such feature, and what is your approach to OTA?

 
We (Eistec) are interested in this feature as well.
 

- When can we meet virtually (or physically in case anyone is in Berlin)?

 
Initially I would prefer to have a virtual meeting, but I think it would
be beneficial to have a physical meeting once a task force/working group
has been formed.
 

 
While “when” and “from which buffer” is totally application specific,
there are some
common Ideas how to approach OTA in the core os itself that i have
collected from people so far:
 
- Simply over-writing RIOT in flash with a new copy, by keeping the
flasher code external.
- Insert SD cards with a new image and reboot
- Two copies of RIOT on the same flash, with a boot loader selecting
the active one
- Re-flashing only the application part of RIOT over the air while
keeping the OS part forev

Re: [riot-devel] How low can you go?

[Ludwig Ortmann]

Hi,

On Fri, Feb 06, 2015 at 09:03:31AM +0100, Oleg Hahm wrote:
> Am Thu, Feb 05, 2015 at 02:09:52PM -0800 schrieb Adam Hunt:
> > There's already a driver for for Atmel's AT86RF231 in the tree and while
> > the AT86RF230 on the Raven boards are nearly the same the 230 lacks a
> > couple minor features, namely a crypto processor and RNG. So, the RF link
> > would be wide open but for experimentation and learning sacrifices are
> > often necessary.
> 
> As far as I know there were some considerations and work done towards a
> generic AT86RF23x or even AT86RF2xx driver. Thomas, am I right?

Yes, I'm working on that (almost done).

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

Re: [riot-devel] Network Stack Task Force

[Martine Lenders]

Hello Martin,

2015-02-06 9:02 GMT+01:00 Martin :
>
> thx again for recording the audio for the introducing presentation.
> It was a great help to get a more descend look at the information from the
> slides and the idea for the message based network stack approach.
>

Great!


> Yesterday we got the foundamental concept how the new network stack will
> evolve, which  "modules" are covered yet and what parts are open for
> discussion/definition.
> As I couldn't attend, I humbly ask how the meeting will proceed today, and
> if there was discussion/consensus on open topics?
>

Yesterday after the talk we discussed how to solve routing in the network
stack. Basically we decided, that for proactive routing the FIB (for a
given destination address it gives an PID/interface + next hop address) you
proposed is sufficient. For reactive routing we concluded, that it is
probably best for the FIB to return for a given destination address the PID
of the routing protocol with next hop address == NULL, if a next hop is not
available. This way we only need to check in IP if the next hop address is
!= NULL to lookup the link layer address in the NIB and then send the
packet to the given PID. The routing protocol is in case of reactive
routing then responsible for the packet and might either send it itself to
the link layer or resend it to IP after a next hop was found or drop it if
not.

We also discussed error management for sending and receiving. The result
was, that we introduce a 6th message type for netapi to communicate the
status of a packet for a certain layer, and a protocol can register to
those via netreg. I'll propose an interface for this at today's meeting.

The plan for today is to discuss Header Options, ICMPv6, neighbor discovery
and something something I forgot right now ^^

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

Re: [riot-devel] Network Stack Task Force

[Martin]

Hi,

thx again for recording the audio for the introducing presentation.
It was a great help to get a more descend look at the information from 
the slides and the idea for the message based network stack approach.


Yesterday we got the foundamental concept how the new network stack will 
evolve, which  "modules" are covered yet and what parts are open for 
discussion/definition.
As I couldn't attend, I humbly ask how the meeting will proceed today, 
and if there was discussion/consensus on open topics?


Best regards,
Martin

On 05.02.2015 15:22, Landsmann, Martin wrote:

Hi,

thx

Best regards,
Martin

*Von:* devel [devel-boun...@riot-os.org]" im Auftrag von "Martine 
Lenders [authmille...@gmail.com]

*Gesendet:* Donnerstag, 5. Februar 2015 15:08
*An:* RIOT OS kernel developers
*Betreff:* Re: [riot-devel] Network Stack Task Force

Hello,
attached you find the links to the audio recordings of the talks of 
the network stack task force meeting.


http://download.riot-os.org/nstf/meeting1/nstf-meeting1.mp3
http://download.riot-os.org/nstf/meeting1/nstf-meeting2.mp3

Regards,
Martine

2015-02-05 11:18 GMT+01:00 Jan Wagner >:


they mean this in a context of a mutli user operating system? or not?

Emmanuel Baaccelli mailto:emmanuel.bacce...@inria.fr>> hat am 5. Februar 2015 um
11:16 geschrieben:

the paper I'm about to mention in the meeting:
https://www.usenix.org/system/files/conference/osdi12/osdi12-final-183.pdf


On Thu, Feb 5, 2015 at 10:03 AM, Martine Lenders
mailto:authmille...@gmail.com>> wrote:

Good Morning,

here is the placecam link

http://placecam.de/call.php?c=0~dA5j0OrfTdsesyQKlqIZvQi7bo1YKYGdMORGFmqL8-




How-To use it?

https://github.com/RIOT-OS/RIOT/wiki/Instructions-for-remote-participation


Cheers,
Martine

2015-02-04 22:32 GMT+01:00 Matthias Waehlisch
mailto:m.waehli...@fu-berlin.de>>:

Hi Jan,

On Wed, 4 Feb 2015, Jan Wagner wrote:

> i just installed placecam, do you send out the meeting
link to this
> mailing list or person based emails?. i would like to
join tomorrow
> and if needed would request that link.
>
Hauke will provide the link tomorrow via the mailing list.

> ps. do i need a cam or is audiio only ok?
>
You don't need a cam, audio is fine.


Cheers
matthias

--
Matthias Waehlisch
. Freie Universitaet Berlin, Inst. fuer Informatik, AG CST
. Takustr. 9, D-14195 Berlin, Germany
.. mailto:waehli...@ieee.org 
.. http://www.inf.fu-berlin.de/~waehl

:. Also: http://inet.cpt.haw-hamburg.de ..
http://www.link-lab.net
___
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




___
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] How low can you go?

[Oleg Hahm]

Hey Adam!

Am Thu, Feb 05, 2015 at 02:09:52PM -0800 schrieb Adam Hunt:
> The other day I ran across a few Atmel Raven[0] development boards that I'd
> forgotten I had (it never ceases to amaze the amount of random electronics I
> own and have completely forgotten about).

Sounds familiar. ;-)

> It got me thinking, now that heavy lifting of porting RIOT ​ to its
> first 8 bit micro and running on the Arduino Mega with its ATmega2560 how
> small of an ​ micro​ would it be possible to port RIOT to?

In principle, I would guess that this is possible.

> ​A quick look at the data sheets seems to show
> 
> ​that the ​​ 1284P ​ and its much larger cousin,
> the​ 2560 ​ are quite similar.

 
> 1284P | 2560 | 3290P
> --|--|---
> Flash:   128  | 256  | 32
> SRAM:16   | 8| 2
> MHz: 16   | 20   | 20
> EEPROM:  4096 | 4096 | 1024
> Max I/O: 86   | 32   | 69

Knowing that the 2560 is working somehow, this looks promising for the 1284P:
RAM is usually a bigger issue than ROM.
 
> ​The 3290 is a little on the small side but I wonder if someone could cram
> RIOT in there. Is it possible to build RIOT without a networking stack; how
> much could that reduce the memory footprint? What are RIOT's hardware
> requirements? The homepage says the minimum RAM is about 1.5k and 5k of
> ROM, are those numbers still accurate?

These numbers were taken from the output of size [1] for a TI MSP430 (and thus
a 16bit) platform. A quick check for the MSB-430 platform revealed, that this
would still hold more or less. For the default example (which is a basic RIOT
application without network stack) you'll have about 17k ROM and 1.5k RAM (I
think the numbers were taken for hello-world, where it is 7.9k ROM and 1.2k
RAM).

For the ATmega2560 it shows 16.1k ROM and 2.1k RAM for default and 8.8k ROM
and 1.3k RAM for hello-world. So, even the 3290P might be feasible for some
constrained application.

> There's already a driver for for Atmel's AT86RF231 in the tree and while
> the AT86RF230 on the Raven boards are nearly the same the 230 lacks a
> couple minor features, namely a crypto processor and RNG. So, the RF link
> would be wide open but for experimentation and learning sacrifices are
> often necessary.

As far as I know there were some considerations and work done towards a
generic AT86RF23x or even AT86RF2xx driver. Thomas, am I right?

Cheers,
Oleg

[1] https://sourceware.org/binutils/docs/binutils/size.html
-- 
printk("CPU[%d]: Sending penguins to jail...",smp_processor_id());
linux-2.4.8/arch/sparc64/kernel/smp.c


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