Re: [riot-devel] Some thoughts on the typical RIOT workflow

[Baptiste Clenet]

Hi,

That's great to discuss before developping new feature.

Why don't we use a idea voting system platform or +1 button of ideas in
github issue to vote and discuss for most waited next feature?

Cheers,

Le jeu. 14 nov. 2019 à 12:43, Oleg Hahm  a écrit :

> Dear reviewing IOTlers,
>
> the RIOT maintainer meeting that happened yesterday triggered some thoughts
> about our common workflow [1] when it comes to pull request introducing new
> features, new hardware support, or new concepts.
>
> The first observation is that proposing something new goes often along with
> quite a bunch of implementation already done. On the one hand, this
> sometimes
> steer discussions into the wrong direction where some people already start
> to
> dig into implementation details while the discussion about the general
> approach haven't yet concluded. On the other hand, the contributor is much
> more reluctant to change his or her approach (or even give up on it)
> because
> so much time has been spent for implementing it.
>
> The second observation is that the typical scenario is that a single person
> proposes a pull request and then tries to convince the rest of the
> community
> that the idea and realization are good and worthwhile to be integrated into
> RIOT master. Depending on the openness of this person regarding feedback
> and
> his or her responsiveness the lifetime of the pull request and the effort
> spent on it (from both sides) can easily explode.
>
> As an idea how to tackle both problems, I think it could be useful to
> change
> this "one against all" approach (over-exaggerating here, of course). If
> someone wants to propose something new, he or she could ask for a somewhat
> experienced RIOT developer to pair up with (we could think of it as a
> sparring
> partner and sponsor if you like). So, one could first discuss the idea and
> the
> realization approach with this partner, before actually starting the
> implementation. Then, both (or potentially more people) would present the
> PR
> to the rest of the community and try to defend and improved it together.
>
> Cheers
> Oleg
>
> [1] Excuse me for still talking about "we" and "us" here although I haven't
> contributed anything for a long time. And also excuse me if I'm not
> taking
> recent developments in this respect into account.
> --
> panic("smp_callin() a\n");
> linux-2.6.6/arch/parisc/kernel/smp.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

Re: [riot-devel] Some thoughts on the typical RIOT workflow

[Baptiste Clenet]

Hi,

That's great to discuss before developping new feature.

Why don't we use a idea voting system platform or +1 button of ideas in
github issue to vote and discuss for most waited next feature?

Cheers,

Le jeu. 14 nov. 2019 à 12:43, Oleg Hahm  a écrit :

> Dear reviewing IOTlers,
>
> the RIOT maintainer meeting that happened yesterday triggered some thoughts
> about our common workflow [1] when it comes to pull request introducing new
> features, new hardware support, or new concepts.
>
> The first observation is that proposing something new goes often along with
> quite a bunch of implementation already done. On the one hand, this
> sometimes
> steer discussions into the wrong direction where some people already start
> to
> dig into implementation details while the discussion about the general
> approach haven't yet concluded. On the other hand, the contributor is much
> more reluctant to change his or her approach (or even give up on it)
> because
> so much time has been spent for implementing it.
>
> The second observation is that the typical scenario is that a single person
> proposes a pull request and then tries to convince the rest of the
> community
> that the idea and realization are good and worthwhile to be integrated into
> RIOT master. Depending on the openness of this person regarding feedback
> and
> his or her responsiveness the lifetime of the pull request and the effort
> spent on it (from both sides) can easily explode.
>
> As an idea how to tackle both problems, I think it could be useful to
> change
> this "one against all" approach (over-exaggerating here, of course). If
> someone wants to propose something new, he or she could ask for a somewhat
> experienced RIOT developer to pair up with (we could think of it as a
> sparring
> partner and sponsor if you like). So, one could first discuss the idea and
> the
> realization approach with this partner, before actually starting the
> implementation. Then, both (or potentially more people) would present the
> PR
> to the rest of the community and try to defend and improved it together.
>
> Cheers
> Oleg
>
> [1] Excuse me for still talking about "we" and "us" here although I haven't
> contributed anything for a long time. And also excuse me if I'm not
> taking
> recent developments in this respect into account.
> --
> panic("smp_callin() a\n");
> linux-2.6.6/arch/parisc/kernel/smp.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

Re: [riot-devel] Mutex and thread priority

[Baptiste Clenet]

I've opened an Issue on github showing how to reproduce:
https://github.com/RIOT-OS/RIOT/issues/10495


Le mer. 28 nov. 2018 12:03, Baptiste Clenet  a écrit :

> The behavior is only seen when ethos is used:
> Checkout my branch:
> https://github.com/biboc/RIOT/tree/uart_mutex_thread_pb
> And run example uart-thread-mutex_pb_BR on samr21-xpro (make flash
> BOARD=samr21-xpro)
>
> See output:
> 2018-11-28 11:58:50.71 ~~33 `@0909]!UHCP@~~}!main(): This is RIOT!
> (Version: 2018.10-RC1-330-gd8cfe-uart_mutex_thread_pb)
> 2018-11-28 11:58:50.71 ~~}!RIOT border router example application
> 2018-11-28 11:58:50.72 ~~}!THREAD
>
> 2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+
> 2018-11-28 11:58:50.74 ~~}!THREAD 2-|+2-|+2-|+2-|+THREAD
>
> 1_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*1
> 2018-11-28 11:58:50.75
>
> ~~}!2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+
> 2018-11-28 11:58:50.76 ~~}!THREAD
>
> 2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+
>
> Le jeu. 22 nov. 2018 à 15:44, Baptiste Clenet  a
> écrit :
> >
> > Thanks for your answer.
> >
> > Le jeu. 22 nov. 2018 12:51, Juan Ignacio Carrano 
> a écrit :
> >>
> >> Hi Baptiste,
> >>
> >> On 11/22/18 12:11 PM, Baptiste Clenet wrote:
> >> > Hi,
> >> > I have looked at mutex.c and thread.c and I've understood that a
> >> > thread with higher priority (it has priority) will unlock the mutex
> >> > even if thread with lower priority has not finished/unlock the mutex?
> >> > Am I right?
> >>
> >> You are referring to a situation in which a thread unlocks a mutex it
> >> did not lock before?
> >
> >
> > No. A thread A (high priority) locks a mutex which is locked by thread B
> (low priority)
> > And it seems that scheduler stops thread B and make thread A run.
> >>
> >>
> >> In that case the mutex is not behaving as such, but rather as a generic
> >> lock, and any thread can unlock it. See
> >> https://github.com/RIOT-OS/RIOT/issues/9594 .
> >>
> >> If you want the mutex to actually behave as a mutex you should ensure
> >> you never have an unlock without a matching lock (i.e. that the only
> >> thread that can unlock a mutex is the one that locked it and thus own
> >> it). RIOT's mutexes do not enforce that, so you must resolve it by
> >> careful usage.
> >>
> >> > Now, in my case, I use UART with ethos (which use a mutex) and what
> >> > happens on my case is:
> >> > * I have thread A (high priority), thread B (low priority)
> >> > * B starts to write on UART an long str
> >> > * A wants to write on UART an lock the mutex (ethos) but because it
> >> > has higher priority, it sends its message over UART until end of str
> >> > * B can continue and finish to send its str
> >> >
> >>
> >> So you are saying that the lower priority "B" thread is being preempted
> >> and it's output interrupted by A's output?
> >
> >
> > Yes exactly and this my problem. In my case, main thread with shell is
> being preempted by one of network stack threads
> >
> > Let le explain again what I see:
> > Context:
> > * two threads: main thread (low prio) with shell and ipv6 thread (high
> prio)
> > Sequence:
> > 1. Main thread starts to send a long str by UART via ethos
> (ethos_send_frame)
> > 2. Main thread locks ethos mutex in ethos_send_frame
> > 3. Ipv6 thread wants to send a str by UART, so ethos_send_frame is
> called and ipv6 thread tries to locks ethos mutex.
> >
> > Result: What I see is that main thread str is cut by ipv6 thread. Str
> seen from UART reception:
> > [START_STR_MAIN_THREAD][IPV6_THREAD_STR][END_STR_MAIN_THREAD]
> >
> > 4. IMO, ipv6 thread preempts main thread and, I don't really how,
> manages to access UART device and send its str before main thread can
> finish to send its str
> >
> > Result is that main thread str is cut
> >
> > Please have a look at ethos.c and especially ethos_send_frame() function
> to better understand what I say.
> >
> >
> >
> >
> >>
> >> I'm not familiar with ethos, but my intuition is that, while it may have
> >> a mutex, it may not be programmed in a way that the UART access is

Re: [riot-devel] Mutex and thread priority

[Baptiste Clenet]

The behavior is only seen when ethos is used:
Checkout my branch: https://github.com/biboc/RIOT/tree/uart_mutex_thread_pb
And run example uart-thread-mutex_pb_BR on samr21-xpro (make flash
BOARD=samr21-xpro)

See output:
2018-11-28 11:58:50.71 ~~33 `@0909]!UHCP@~~}!main(): This is RIOT!
(Version: 2018.10-RC1-330-gd8cfe-uart_mutex_thread_pb)
2018-11-28 11:58:50.71 ~~}!RIOT border router example application
2018-11-28 11:58:50.72 ~~}!THREAD
2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+
2018-11-28 11:58:50.74 ~~}!THREAD 2-|+2-|+2-|+2-|+THREAD
1_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*11_!*1
2018-11-28 11:58:50.75
~~}!2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+
2018-11-28 11:58:50.76 ~~}!THREAD
2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+2-|+

Le jeu. 22 nov. 2018 à 15:44, Baptiste Clenet  a écrit :
>
> Thanks for your answer.
>
> Le jeu. 22 nov. 2018 12:51, Juan Ignacio Carrano  a 
> écrit :
>>
>> Hi Baptiste,
>>
>> On 11/22/18 12:11 PM, Baptiste Clenet wrote:
>> > Hi,
>> > I have looked at mutex.c and thread.c and I've understood that a
>> > thread with higher priority (it has priority) will unlock the mutex
>> > even if thread with lower priority has not finished/unlock the mutex?
>> > Am I right?
>>
>> You are referring to a situation in which a thread unlocks a mutex it
>> did not lock before?
>
>
> No. A thread A (high priority) locks a mutex which is locked by thread B (low 
> priority)
> And it seems that scheduler stops thread B and make thread A run.
>>
>>
>> In that case the mutex is not behaving as such, but rather as a generic
>> lock, and any thread can unlock it. See
>> https://github.com/RIOT-OS/RIOT/issues/9594 .
>>
>> If you want the mutex to actually behave as a mutex you should ensure
>> you never have an unlock without a matching lock (i.e. that the only
>> thread that can unlock a mutex is the one that locked it and thus own
>> it). RIOT's mutexes do not enforce that, so you must resolve it by
>> careful usage.
>>
>> > Now, in my case, I use UART with ethos (which use a mutex) and what
>> > happens on my case is:
>> > * I have thread A (high priority), thread B (low priority)
>> > * B starts to write on UART an long str
>> > * A wants to write on UART an lock the mutex (ethos) but because it
>> > has higher priority, it sends its message over UART until end of str
>> > * B can continue and finish to send its str
>> >
>>
>> So you are saying that the lower priority "B" thread is being preempted
>> and it's output interrupted by A's output?
>
>
> Yes exactly and this my problem. In my case, main thread with shell is being 
> preempted by one of network stack threads
>
> Let le explain again what I see:
> Context:
> * two threads: main thread (low prio) with shell and ipv6 thread (high prio)
> Sequence:
> 1. Main thread starts to send a long str by UART via ethos (ethos_send_frame)
> 2. Main thread locks ethos mutex in ethos_send_frame
> 3. Ipv6 thread wants to send a str by UART, so ethos_send_frame is called and 
> ipv6 thread tries to locks ethos mutex.
>
> Result: What I see is that main thread str is cut by ipv6 thread. Str seen 
> from UART reception:
> [START_STR_MAIN_THREAD][IPV6_THREAD_STR][END_STR_MAIN_THREAD]
>
> 4. IMO, ipv6 thread preempts main thread and, I don't really how, manages to 
> access UART device and send its str before main thread can finish to send its 
> str
>
> Result is that main thread str is cut
>
> Please have a look at ethos.c and especially ethos_send_frame() function to 
> better understand what I say.
>
>
>
>
>>
>> I'm not familiar with ethos, but my intuition is that, while it may have
>> a mutex, it may not be programmed in a way that the UART access is
>> exclusive too. Exclusive access to UART would not be a good idea as in
>> cases like yours it opens the door to priority inversions.
>>
>> > So I'm wondering why a thread with higher priority should be able to
>> > unlock a mutex locked by a thread with lower priorty?
>> >
>>
>> Actually any thread can unlock a mutex locked by another thread. What
>> can never happen is that a thread _locks_ a mutex locked by another
>> thread. In your mind, replace the word "mutex" with "lock" and things
>> may become clearer.
>>
>> Regards,
>>
>> Juan.
>> ___
>> devel mailing list
>> devel@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel



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

Re: [riot-devel] Mutex and thread priority

[Baptiste Clenet]

Thanks for your answer.

Le jeu. 22 nov. 2018 12:51, Juan Ignacio Carrano  a
écrit :

> Hi Baptiste,
>
> On 11/22/18 12:11 PM, Baptiste Clenet wrote:
> > Hi,
> > I have looked at mutex.c and thread.c and I've understood that a
> > thread with higher priority (it has priority) will unlock the mutex
> > even if thread with lower priority has not finished/unlock the mutex?
> > Am I right?
>
> You are referring to a situation in which a thread unlocks a mutex it
> did not lock before?
>

No. A thread A (high priority) locks a mutex which is locked by thread B
(low priority)
And it seems that scheduler stops thread B and make thread A run.

>
> In that case the mutex is not behaving as such, but rather as a generic
> lock, and any thread can unlock it. See
> https://github.com/RIOT-OS/RIOT/issues/9594 .
>
> If you want the mutex to actually behave as a mutex you should ensure
> you never have an unlock without a matching lock (i.e. that the only
> thread that can unlock a mutex is the one that locked it and thus own
> it). RIOT's mutexes do not enforce that, so you must resolve it by
> careful usage.
>
> > Now, in my case, I use UART with ethos (which use a mutex) and what
> > happens on my case is:
> > * I have thread A (high priority), thread B (low priority)
> > * B starts to write on UART an long str
> > * A wants to write on UART an lock the mutex (ethos) but because it
> > has higher priority, it sends its message over UART until end of str
> > * B can continue and finish to send its str
> >
>
> So you are saying that the lower priority "B" thread is being preempted
> and it's output interrupted by A's output?
>

Yes exactly and this my problem. In my case, main thread with shell is
being preempted by one of network stack threads

Let le explain again what I see:
Context:
* two threads: main thread (low prio) with shell and ipv6 thread (high prio)
Sequence:
1. Main thread starts to send a long str by UART via ethos
(ethos_send_frame)
2. Main thread locks ethos mutex in ethos_send_frame
3. Ipv6 thread wants to send a str by UART, so ethos_send_frame is called
and ipv6 thread tries to locks ethos mutex.

Result: What I see is that main thread str is cut by ipv6 thread. Str seen
from UART reception:
[START_STR_MAIN_THREAD][IPV6_THREAD_STR][END_STR_MAIN_THREAD]

4. IMO, ipv6 thread preempts main thread and, I don't really how, manages
to access UART device and send its str before main thread can finish to
send its str

Result is that main thread str is cut

Please have a look at ethos.c and especially ethos_send_frame() function to
better understand what I say.





> I'm not familiar with ethos, but my intuition is that, while it may have
> a mutex, it may not be programmed in a way that the UART access is
> exclusive too. Exclusive access to UART would not be a good idea as in
> cases like yours it opens the door to priority inversions.
>
> > So I'm wondering why a thread with higher priority should be able to
> > unlock a mutex locked by a thread with lower priorty?
> >
>
> Actually any thread can unlock a mutex locked by another thread. What
> can never happen is that a thread _locks_ a mutex locked by another
> thread. In your mind, replace the word "mutex" with "lock" and things
> may become clearer.
>
> Regards,
>
> Juan.
> ___
> 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] Mutex and thread priority

[Baptiste Clenet]

Hi,
I have looked at mutex.c and thread.c and I've understood that a
thread with higher priority (it has priority) will unlock the mutex
even if thread with lower priority has not finished/unlock the mutex?
Am I right?
Now, in my case, I use UART with ethos (which use a mutex) and what
happens on my case is:
* I have thread A (high priority), thread B (low priority)
* B starts to write on UART an long str
* A wants to write on UART an lock the mutex (ethos) but because it
has higher priority, it sends its message over UART until end of str
* B can continue and finish to send its str

So I'm wondering why a thread with higher priority should be able to
unlock a mutex locked by a thread with lower priorty?

Cheers

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

Re: [riot-devel] IPSEC/IKEv2

[Baptiste Clenet]

Hi Tobias,
Great to hear that ESP is getting ported as well as G-IKEv2 and Diet-ESP.
A good Iot µOS must provide security features

I would like to contribute to the port of ESP. Could you create a WIP
merge request or a branch on a repo so I can see status of port and
test.

Have you thought about using an external library?

Cheers,

Le mer. 4 juil. 2018 à 14:50, Tobias Guggemos  a écrit :
>
> Hey
>
> Tobias Heider implemented G-IKEv2 [1], which should be fairly easy to port to 
> IKEv2 as the messages are more the less the same.
> It has some a dependency on gnrc_pktbuf_merge [2], which has not yet included 
> in RIOT (hopefully he will finish this soon).
> If you're interested I'm pretty sure that we can share the code with you.
>
> I had several students starting a RIOT port of ESP, but none finished it. I 
> probably have to do it myself when time allows...
> I heard that Olaf Bergmann had a student who wanted to implement Diet-ESP 
> [3], but I don't know a state of that. (obviously that would require an ESP 
> port)
>
> Cheers
> Tobias
>
> [1] https://tools.ietf.org/html/draft-yeung-g-ikev2-13
> [2] https://github.com/RIOT-OS/RIOT/pull/6487
> [3] https://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/
>
> > -Ursprüngliche Nachricht-
> > Von: devel  Im Auftrag von Thomas C. Schmidt
> > Gesendet: Dienstag, 3. Juli 2018 12:53
> > An: devel@riot-os.org
> > Betreff: Re: [riot-devel] IPSEC/IKEv2
> >
> > Hi Baptiste,
> >
> > as far as I remember, Tobias Guggemos http://www.mnm-
> > team.org/~guggemos/
> > from LMU Munich was working on this.
> >
> > Plese back check with him.
> >
> > Cheers,
> >   Thomas
> >
> > On 03/07/2018 08:50, Baptiste Clenet wrote:
> > > Hi,
> > > Is there any implementation of IPSEC/IKEv2 in RIOT network stack? Has
> > > anyone planned to implement it?
> > >
> > > Cheers,
> > >
> >
> > --
> >
> > Prof. Dr. Thomas C. Schmidt
> > ° Hamburg University of Applied Sciences  Berliner Tor 7 °
> > ° Dept. Informatik, Internet Technologies Group   20099 Hamburg, Germany °
> > ° http://inet.haw-hamburg.de/members/schmidt  Fon: +49-40-42875-8452
> > °
> >
> > ___
> > 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



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

[riot-devel] IPSEC/IKEv2

[Baptiste Clenet]

Hi,
Is there any implementation of IPSEC/IKEv2 in RIOT network stack? Has
anyone planned to implement it?

Cheers,

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

Re: [riot-devel] Re-transmission, interval 40ms problem

[Baptiste Clenet]

How does CSMA work on at86rf2xx driver?
Is error handled?

Cheers,

2018-01-29 20:26 GMT+01:00 Baptiste Clenet <bapcle...@gmail.com>:
> Application is based on gnrc_networking.
>
>> Can you check if the 802.15.4 sequence number of thesepackets is equal?
>
> Yes there are equal.
> Do you know how long automatic retransmission takes for atmel transceiver?
>
>
> 2018-01-29 10:30 GMT+01:00 Peter Kietzmann <peter.kietzm...@haw-hamburg.de>:
>> Hi Baptise,
>>
>> which software did you use on BOARD A and B? AFAIK there is not a known
>> problem with this in the stack. The Atmel radio does automatic
>> retransmission and carrier sensing which might take some milli seconds
>> (not 40!). Can you check if the 802.15.4 sequence number of these
>> packets is equal?
>>
>> Cheers
>> Peter
>>
>>
>> Am 26.01.2018 um 10:48 schrieb Baptiste Clenet:
>>> Hi,
>>> Some packet are lost while sending message between two samr21 so I use
>>> the sniffer application to check paquet over the air.
>>> I was surprised to see that sometime paquet are retransmitted without
>>> my consent!
>>> I mean:
>>> I send one paquet from BOARD A to BOARD B
>>> BOARD B does not receive it
>>> BOARD C (sniffer) sees two paquets with 40ms interval
>>>
>>> The interval is almost 40ms every time there is a paquet retransmission.
>>>
>>> Do you know why paquet is retransmitted 40ms after the first one?
>>> Is this a problem (or normal behaviour) in RIOT stack or transceiver?
>>>
>>> Cheers,
>>>
>>
>> --
>> 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
>> https://lists.riot-os.org/mailman/listinfo/devel
>
>
>
> --
> Baptiste



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

Re: [riot-devel] Re-transmission, interval 40ms problem

[Baptiste Clenet]

Application is based on gnrc_networking.

> Can you check if the 802.15.4 sequence number of thesepackets is equal?

Yes there are equal.
Do you know how long automatic retransmission takes for atmel transceiver?


2018-01-29 10:30 GMT+01:00 Peter Kietzmann <peter.kietzm...@haw-hamburg.de>:
> Hi Baptise,
>
> which software did you use on BOARD A and B? AFAIK there is not a known
> problem with this in the stack. The Atmel radio does automatic
> retransmission and carrier sensing which might take some milli seconds
> (not 40!). Can you check if the 802.15.4 sequence number of these
> packets is equal?
>
> Cheers
> Peter
>
>
> Am 26.01.2018 um 10:48 schrieb Baptiste Clenet:
>> Hi,
>> Some packet are lost while sending message between two samr21 so I use
>> the sniffer application to check paquet over the air.
>> I was surprised to see that sometime paquet are retransmitted without
>> my consent!
>> I mean:
>> I send one paquet from BOARD A to BOARD B
>> BOARD B does not receive it
>> BOARD C (sniffer) sees two paquets with 40ms interval
>>
>> The interval is almost 40ms every time there is a paquet retransmission.
>>
>> Do you know why paquet is retransmitted 40ms after the first one?
>> Is this a problem (or normal behaviour) in RIOT stack or transceiver?
>>
>> Cheers,
>>
>
> --
> 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
> https://lists.riot-os.org/mailman/listinfo/devel



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

[riot-devel] Re-transmission, interval 40ms problem

[Baptiste Clenet]

Hi,
Some packet are lost while sending message between two samr21 so I use
the sniffer application to check paquet over the air.
I was surprised to see that sometime paquet are retransmitted without
my consent!
I mean:
I send one paquet from BOARD A to BOARD B
BOARD B does not receive it
BOARD C (sniffer) sees two paquets with 40ms interval

The interval is almost 40ms every time there is a paquet retransmission.

Do you know why paquet is retransmitted 40ms after the first one?
Is this a problem (or normal behaviour) in RIOT stack or transceiver?

Cheers,

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

Re: [riot-devel] mBed default UART

[Baptiste Clenet]

Read the periph_conf.h file of your board and you'll find the required pins:
https://github.com/RIOT-OS/RIOT/blob/master/boards/mbed_lpc1768/include/periph_conf.h

Cheers,

Le 10 déc. 2017 10:33 AM, "tiago carvalho"  a
écrit :

> Hi guys,
>
> I'm wondering if you guys can help me out with the default UART device for
> the mbed_lpc1768 board, to see printf and puts outputs in a serial client
> like putty.
>
> I tried all pins (9/10/13/14/27/28) with several baudrates withouht
> success. Is there any other action I need to do before this works?
>
> Thanks in advance,
> Tiago 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] Warning on compilation

[Baptiste Clenet]

Hi,

I'm using samr21-xpro and I tried to add same warning options than
Atmel Studio for RIOT:

-pipe -fno-strict-aliasing -Wall -Wstrict-prototypes
-Wmissing-prototypes -Werror-implicit-function-declaration
-Wpointer-arith -std=gnu99 -ffunction-sections -fdata-sections
-Wchar-subscripts -Wcomment -Wformat=2 -Wimplicit-int -Wmain
-Wparentheses -Wsequence-point -Wreturn-type -Wswitch -Wtrigraphs
-Wunused -Wuninitialized -Wunknown-pragmas -Wfloat-equal -Wundef
-Wshadow -Wbad-function-cast -Wwrite-strings -Wsign-compare
-Waggregate-return  -Wmissing-declarations -Wformat
-Wmissing-format-attribute -Wno-deprecated-declarations -Wpacked
-Wredundant-decls -Wnested-externs -Wlong-long -Wunreachable-code
-Wcast-align --param max-inline-insns-single=500

I got long list of warnings.
Why RIOT does not used all the warning options?

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

Re: [riot-devel] 6lowpan is not answering address ff02::2

[Baptiste Clenet]

Don't have time to try new ND. BTW, great work martine, I hope to see
it merge soon.
I used border router and gnrc_networking to make everything works as expected

2017-09-04 23:11 GMT+02:00 Martine Lenders <m...@martine-lenders.eu>:
> Hi,
>
> can you try with the new neighbor discovery? [1]
>
> Cheers,
> Martine
>
> [1] https://github.com/RIOT-OS/RIOT/pull/7479
>
> 2017-09-04 20:09 GMT+02:00 Baptiste Clenet <bapcle...@gmail.com>:
>>
>> Hi,
>>
>> I've flashed gnrc_networking on two samr21-xpro. I've noticed that
>> they do not answer to router solicitation because "packet destination
>> is not this host" when source address is ff02::2 (gnrc_ipv6.c)[1].
>> On native, there is no problem.
>> By going deeper, I saw that the address ff02::2 is not added to the
>> interface because samr21-xpro uses sixlowpan (compare to native), the
>> function in question is [2]
>>
>> So basically, when the first samr21-xpro send a router solicitation,
>> nobody answers. Shouldn't the second samr21-xpro answer? What do you
>> think?
>>
>>
>> [1]
>> https://github.com/RIOT-OS/RIOT/blob/master/sys/net/gnrc/network_layer/ipv6/gnrc_ipv6.c#L905
>> [2]
>> https://github.com/RIOT-OS/RIOT/blob/master/sys/net/gnrc/network_layer/ipv6/netif/gnrc_ipv6_netif.c#L268
>> --
>> Baptiste
>> ___
>> 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
>



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

[riot-devel] 6lowpan is not answering address ff02::2

[Baptiste Clenet]

Hi,

I've flashed gnrc_networking on two samr21-xpro. I've noticed that
they do not answer to router solicitation because "packet destination
is not this host" when source address is ff02::2 (gnrc_ipv6.c)[1].
On native, there is no problem.
By going deeper, I saw that the address ff02::2 is not added to the
interface because samr21-xpro uses sixlowpan (compare to native), the
function in question is [2]

So basically, when the first samr21-xpro send a router solicitation,
nobody answers. Shouldn't the second samr21-xpro answer? What do you
think?


[1] 
https://github.com/RIOT-OS/RIOT/blob/master/sys/net/gnrc/network_layer/ipv6/gnrc_ipv6.c#L905
[2] 
https://github.com/RIOT-OS/RIOT/blob/master/sys/net/gnrc/network_layer/ipv6/netif/gnrc_ipv6_netif.c#L268
-- 
Baptiste
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] gnrc_border_router in native

[Baptiste Clenet]

Ok thanks Martine
Could I mount  a virtual SERIAL port (ptyp5 or with socat) so I can
simulate a serial communication. I see that there is a UART periph in
native. What do you think about this?

2017-08-24 19:36 GMT+02:00 Martine Lenders <m...@martine-lenders.eu>:
> Hi,
>
> 2017-08-24 19:08 GMT+02:00 Baptiste Clenet <bapcle...@gmail.com>:
>>
>> My goal is to simulate in native a setup with a border router and a
>> node (so without any hardware board)
>
>
> Then try socket_zep. It simulates IEEE 802.15.4 networks for native.
>
>>
>> No, what I want is to run gnrc_border_router in native and instead of
>> communicating with a serial port, I want to use tap0 (or something
>> else).
>> When we do make term, we open a connection between a node and linux
>> and we can send command. Why can't I use the connection to make ethos
>> communicate with gnrc_border_router?
>
>
> ethos (Ethernet over Serial) requires a serial port, which is not provided
> in the default config of native. You need something like socket_zep (for the
> non-ethernet interface), to have the normal 6LoWPAN configuration for the
> border router. Native usually uses netdev_tap in master, which is
> Ethernet-based.
>
>>
>>
>> Is it clearer?
>>
>> Cheers,
>>
>> 2017-08-24 16:56 GMT+02:00 Martine Lenders <m...@martine-lenders.eu>:
>> > Hi,
>> > I assume you want to use it with the xbee (otherwise it does make little
>> > sense, since this is the only non-Ethernet device we support for native,
>> > AFAIK)? If so, please don't use `ethos` as the second interface, but
>> > just
>> > `netdev_tap` (which is pulled in by default). If you want to be
>> > experimental
>> > you try to use socket_zep instead of xbee with native [1].
>> >
>> > Cheers,
>> > Martine
>> >
>> > [1] https://github.com/RIOT-OS/RIOT/pull/6121
>> >
>> > 2017-08-24 14:42 GMT+02:00 Baptiste Clenet <bapcle...@gmail.com>:
>> >>
>> >> Hi,
>> >> I try to compile and run gnrc_border_router in native so I can have
>> >> this
>> >> setup:
>> >> - LINUX
>> >> - tap0: gnrc_border_router
>> >> - tap1: gnrc_networking
>> >> - tapbr0 linking tap0 and tap1
>> >>
>> >> Then instead of using ping6 fe80:%tap1, I could use ping6
>> >> 2001:db8:.
>> >> Ouput:
>> >> RIOT/examples/gnrc_border_router$ make BOARD=native term
>> >> make -C ethos
>> >> make[2]: rien à faire pour « all ».
>> >> make -C uhcpd
>> >> make[2]: rien à faire pour « all ».
>> >> sudo sh RIOT/dist/tools/ethos/start_network.sh tap0 tap0 tap0
>> >> 2001:db8::/64
>> >> net.ipv6.conf.tap0.forwarding = 1
>> >> net.ipv6.conf.tap0.accept_ra = 0
>> >> Error: ??? prefix is expected rather than "tap0".
>> >> Cleaning up...
>> >> RIOT/dist/tools/ethos/start_network.sh: 23: kill: Usage: kill [-s
>> >> sigspec | -signum | -sigspec] [pid | job]... or
>> >> kill -l [exitstatus]
>> >> RIOT/examples/gnrc_border_router/../../Makefile.include:380 : la
>> >> recette pour la cible « term » a échouée
>> >> make: *** [term] Erreur 1
>> >>
>> >> First thing: A third tap0 appears I don't know how. If I replace :
>> >> TERMFLAGS ?= $(PORT) $(TAP) $(IPV6_PREFIX)
>> >> By
>> >> TERMFLAGS ?= $(TAP) $(IPV6_PREFIX)
>> >>
>> >> Output:
>> >> RIOT/examples/gnrc_border_router$ make BOARD=native term
>> >> make -C ethos
>> >> make[2]: rien à faire pour « all ».
>> >> make -C uhcpd
>> >> make[2]: rien à faire pour « all ».
>> >> sudo sh RIOT/dist/tools/ethos/start_network.sh tap0 tap0 2001:db8::/64
>> >> net.ipv6.conf.tap0.forwarding = 1
>> >> net.ipv6.conf.tap0.accept_ra = 0
>> >> Error opening serial device tap0
>> >> Error opening serial device tap0
>> >> Cleaning up...
>> >> RIOT/examples/gnrc_border_router/../../Makefile.include:380 : la
>> >> recette pour la cible « term » a échouée
>> >> make: *** [term] Erreur 1
>> >>
>> >> Of course, tap0 is not serial port so how to make border_router work in
>> >> native?
>> >>
>> >> Cheers,
>> >>
>> >> --
>> >> Baptiste
>> >> ___
>> >> 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
>> >
>>
>>
>>
>> --
>> Baptiste
>> ___
>> 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
>



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

Re: [riot-devel] gnrc_border_router in native

[Baptiste Clenet]

My goal is to simulate in native a setup with a border router and a
node (so without any hardware board)

No, what I want is to run gnrc_border_router in native and instead of
communicating with a serial port, I want to use tap0 (or something
else).
When we do make term, we open a connection between a node and linux
and we can send command. Why can't I use the connection to make ethos
communicate with gnrc_border_router?

Is it clearer?

Cheers,

2017-08-24 16:56 GMT+02:00 Martine Lenders <m...@martine-lenders.eu>:
> Hi,
> I assume you want to use it with the xbee (otherwise it does make little
> sense, since this is the only non-Ethernet device we support for native,
> AFAIK)? If so, please don't use `ethos` as the second interface, but just
> `netdev_tap` (which is pulled in by default). If you want to be experimental
> you try to use socket_zep instead of xbee with native [1].
>
> Cheers,
> Martine
>
> [1] https://github.com/RIOT-OS/RIOT/pull/6121
>
> 2017-08-24 14:42 GMT+02:00 Baptiste Clenet <bapcle...@gmail.com>:
>>
>> Hi,
>> I try to compile and run gnrc_border_router in native so I can have this
>> setup:
>> - LINUX
>> - tap0: gnrc_border_router
>> - tap1: gnrc_networking
>> - tapbr0 linking tap0 and tap1
>>
>> Then instead of using ping6 fe80:%tap1, I could use ping6
>> 2001:db8:.
>> Ouput:
>> RIOT/examples/gnrc_border_router$ make BOARD=native term
>> make -C ethos
>> make[2]: rien à faire pour « all ».
>> make -C uhcpd
>> make[2]: rien à faire pour « all ».
>> sudo sh RIOT/dist/tools/ethos/start_network.sh tap0 tap0 tap0
>> 2001:db8::/64
>> net.ipv6.conf.tap0.forwarding = 1
>> net.ipv6.conf.tap0.accept_ra = 0
>> Error: ??? prefix is expected rather than "tap0".
>> Cleaning up...
>> RIOT/dist/tools/ethos/start_network.sh: 23: kill: Usage: kill [-s
>> sigspec | -signum | -sigspec] [pid | job]... or
>> kill -l [exitstatus]
>> RIOT/examples/gnrc_border_router/../../Makefile.include:380 : la
>> recette pour la cible « term » a échouée
>> make: *** [term] Erreur 1
>>
>> First thing: A third tap0 appears I don't know how. If I replace :
>> TERMFLAGS ?= $(PORT) $(TAP) $(IPV6_PREFIX)
>> By
>> TERMFLAGS ?= $(TAP) $(IPV6_PREFIX)
>>
>> Output:
>> RIOT/examples/gnrc_border_router$ make BOARD=native term
>> make -C ethos
>> make[2]: rien à faire pour « all ».
>> make -C uhcpd
>> make[2]: rien à faire pour « all ».
>> sudo sh RIOT/dist/tools/ethos/start_network.sh tap0 tap0 2001:db8::/64
>> net.ipv6.conf.tap0.forwarding = 1
>> net.ipv6.conf.tap0.accept_ra = 0
>> Error opening serial device tap0
>> Error opening serial device tap0
>> Cleaning up...
>> RIOT/examples/gnrc_border_router/../../Makefile.include:380 : la
>> recette pour la cible « term » a échouée
>> make: *** [term] Erreur 1
>>
>> Of course, tap0 is not serial port so how to make border_router work in
>> native?
>>
>> Cheers,
>>
>> --
>> Baptiste
>> ___
>> 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
>



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

[riot-devel] gnrc_border_router in native

[Baptiste Clenet]

Hi,
I try to compile and run gnrc_border_router in native so I can have this setup:
- LINUX
- tap0: gnrc_border_router
- tap1: gnrc_networking
- tapbr0 linking tap0 and tap1

Then instead of using ping6 fe80:%tap1, I could use ping6 2001:db8:.
Ouput:
RIOT/examples/gnrc_border_router$ make BOARD=native term
make -C ethos
make[2]: rien à faire pour « all ».
make -C uhcpd
make[2]: rien à faire pour « all ».
sudo sh RIOT/dist/tools/ethos/start_network.sh tap0 tap0 tap0 2001:db8::/64
net.ipv6.conf.tap0.forwarding = 1
net.ipv6.conf.tap0.accept_ra = 0
Error: ??? prefix is expected rather than "tap0".
Cleaning up...
RIOT/dist/tools/ethos/start_network.sh: 23: kill: Usage: kill [-s
sigspec | -signum | -sigspec] [pid | job]... or
kill -l [exitstatus]
RIOT/examples/gnrc_border_router/../../Makefile.include:380 : la
recette pour la cible « term » a échouée
make: *** [term] Erreur 1

First thing: A third tap0 appears I don't know how. If I replace :
TERMFLAGS ?= $(PORT) $(TAP) $(IPV6_PREFIX)
By
TERMFLAGS ?= $(TAP) $(IPV6_PREFIX)

Output:
RIOT/examples/gnrc_border_router$ make BOARD=native term
make -C ethos
make[2]: rien à faire pour « all ».
make -C uhcpd
make[2]: rien à faire pour « all ».
sudo sh RIOT/dist/tools/ethos/start_network.sh tap0 tap0 2001:db8::/64
net.ipv6.conf.tap0.forwarding = 1
net.ipv6.conf.tap0.accept_ra = 0
Error opening serial device tap0
Error opening serial device tap0
Cleaning up...
RIOT/examples/gnrc_border_router/../../Makefile.include:380 : la
recette pour la cible « term » a échouée
make: *** [term] Erreur 1

Of course, tap0 is not serial port so how to make border_router work in native?

Cheers,

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

Re: [riot-devel] At86rf2xx ACK frame

[Baptiste Clenet]

OpenThread asks all new platform to use new function:
otPlatRadioTxDone that requires ACK frame.

If you get deeper, I think they use it to get the power of the
transmission and may be something else that I missed:
https://github.com/openthread/openthread/blob/master/src/core/mac/mac.cpp#L993

2017-06-16 11:57 GMT+02:00 Oleg <o...@riot-os.org>:
> Hi Baptiste!
>
> On 2017-06-16 11:27, Baptiste Clenet wrote:
>>
>> Yes Thomas I haven't tried yet but I don't think transceiver stores it.
>> Joakim, OpenThread requires it as explained here:
>> https://github.com/RIOT-OS/RIOT/pull/7149#issuecomment-308342978
>
>
> Sorry, I don't get the explanation. Why does OpenThread needs the pointer to
> the ACK frame?
>
> Cheers,
> Oleg



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

Re: [riot-devel] At86rf2xx ACK frame

[Baptiste Clenet]

Yes Thomas I haven't tried yet but I don't think transceiver stores it.
Joakim, OpenThread requires it as explained here:
https://github.com/RIOT-OS/RIOT/pull/7149#issuecomment-308342978

Shuguo, this a hack solution. There is a way to use old function which
does not required the ACK frame so we're going to use as long as it is
possible.

2017-06-16 9:47 GMT+02:00 Shuguo Zhuo <shuguo.z...@inria.fr>:
> I guess if you only want to use the ACK frame as an input of the function,
> given that it is hard to get from the extended mode, then, maybe one
> solution is that you can manually build one yourself (you can get the
> sequence number from the hardware) and pass it to the function.
>
> Cheers,
> Shuguo
>
> 
>
> 发件人: "Joakim Nohlgård" <joakim.nohlg...@eistec.se>
> 收件人: "RIOT OS kernel developers" <devel@riot-os.org>
> 发送时间: 星期四, 2017年 6 月 15日 下午 10:55:03
> 主题: Re: [riot-devel] At86rf2xx ACK frame
>
>
> Why do you need the actual ACK frame? It's only like 3 bytes + FCS and
> doesn't really contain anything interesting. The only interesting
> information is that the frame with the given sequence id was received
> properly, which is exactly the same information you get from the transceiver
> hardware.
>
> Regards,
> Joakim
>
> On Jun 15, 2017 8:18 AM, "Baptiste Clenet" <bapcle...@gmail.com> wrote:
>
> Which mean that automated ACK by the transceiver is fine.
> 1 - RIOT sends a frame
> 2 - Transceiver receives an ACK and transmit a
> AT86RF2XX_TRX_STATE__TRAC_SUCCESS
> 3 - Here I want to get the ACK frame content
> 4 - Use it with openthread (Have a look here [1] to understand why we need
> it)
>
> [1]
> https://github.com/openthread/openthread/blob/master/include/openthread/platform/radio.h#L404
>
> Cheers,
>
> 2017-06-13 15:46 GMT+02:00 Baptiste Clenet <bapcle...@gmail.com>:
>> 2017-06-13 14:45 GMT+02:00 Oleg <o...@riot-os.org>:
>>> Hi Baptiste!
>>>
>>> On 2017-06-13 12:30, Baptiste Clenet wrote:
>>>>
>>>> On netdev event: NETDEV_EVENT_TX_COMPLETE (after
>>>> AT86RF2XX_TRX_STATE__TRAC_SUCCESS state), how may I get the ACK frame
>>>> received by at86rf2xx?
>>>
>>>
>>> The ACK frame is processed automatically by the transceiver. There is no
>>> way
>>> to access it using the extended mode. If you use the base mode, you will
>>> have to send and process the ACK yourself.
>>>
>>
>> Ok I don't want to process the ACK myself, I only want to get the
>> frame on AT86RF2XX_TRX_STATE__TRAC_SUCCESS state. Is the ACK frame
>> store in a register/frame buffer? Or do we must use base mode to get
>> the ACK frame.
>>
>>>
>>> Cheers,
>>> Oleg
>>> ___
>>> devel mailing list
>>> devel@riot-os.org
>>> https://lists.riot-os.org/mailman/listinfo/devel
>>
>>
>>
>> --
>> Baptiste
>
>
>
> --
> Baptiste
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>



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

Re: [riot-devel] At86rf2xx ACK frame

[Baptiste Clenet]

Which mean that automated ACK by the transceiver is fine.
1 - RIOT sends a frame
2 - Transceiver receives an ACK and transmit a AT86RF2XX_TRX_STATE__TRAC_SUCCESS
3 - Here I want to get the ACK frame content
4 - Use it with openthread (Have a look here [1] to understand why we need it)

[1] 
https://github.com/openthread/openthread/blob/master/include/openthread/platform/radio.h#L404

Cheers,

2017-06-13 15:46 GMT+02:00 Baptiste Clenet <bapcle...@gmail.com>:
> 2017-06-13 14:45 GMT+02:00 Oleg <o...@riot-os.org>:
>> Hi Baptiste!
>>
>> On 2017-06-13 12:30, Baptiste Clenet wrote:
>>>
>>> On netdev event: NETDEV_EVENT_TX_COMPLETE (after
>>> AT86RF2XX_TRX_STATE__TRAC_SUCCESS state), how may I get the ACK frame
>>> received by at86rf2xx?
>>
>>
>> The ACK frame is processed automatically by the transceiver. There is no way
>> to access it using the extended mode. If you use the base mode, you will
>> have to send and process the ACK yourself.
>>
>
> Ok I don't want to process the ACK myself, I only want to get the
> frame on AT86RF2XX_TRX_STATE__TRAC_SUCCESS state. Is the ACK frame
> store in a register/frame buffer? Or do we must use base mode to get
> the ACK frame.
>
>>
>> Cheers,
>> Oleg
>> ___
>> devel mailing list
>> devel@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>
>
>
> --
> Baptiste



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

Re: [riot-devel] At86rf2xx ACK frame

[Baptiste Clenet]

2017-06-13 14:45 GMT+02:00 Oleg <o...@riot-os.org>:
> Hi Baptiste!
>
> On 2017-06-13 12:30, Baptiste Clenet wrote:
>>
>> On netdev event: NETDEV_EVENT_TX_COMPLETE (after
>> AT86RF2XX_TRX_STATE__TRAC_SUCCESS state), how may I get the ACK frame
>> received by at86rf2xx?
>
>
> The ACK frame is processed automatically by the transceiver. There is no way
> to access it using the extended mode. If you use the base mode, you will
> have to send and process the ACK yourself.
>

Ok I don't want to process the ACK myself, I only want to get the
frame on AT86RF2XX_TRX_STATE__TRAC_SUCCESS state. Is the ACK frame
store in a register/frame buffer? Or do we must use base mode to get
the ACK frame.

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



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

[riot-devel] At86rf2xx ACK frame

[Baptiste Clenet]

Hi,

On netdev event: NETDEV_EVENT_TX_COMPLETE (after
AT86RF2XX_TRX_STATE__TRAC_SUCCESS state), how may I get the ACK frame
received by at86rf2xx?
@Thomas, @Hauke ?

Cheers,

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

Re: [riot-devel] at86rf2xx: packet too large -> FCS check

[Baptiste Clenet]

I re-do my example again started at 0:
Example:
at86rf2xx_tx_load(dev, ptr->iov_base, length=5, 0);
FCS is calculated on bytes 0, 1 and 2 and bytes 3 and 4 are replaced by FCS

at86rf2xx_tx_load(dev, ptr->iov_base, length=126, 0);
FCS is calculated on bytes 0, to 123 and bytes 124 and 125 are replaced by FCS

In your example Alexandre:
> I think when the transmitter starts sending the FRAME -> going into
> BUSY. The transceiver will make some:
>
> init_fcs();
> for (b:each_bytes_to_tx) { <--- 127 - 2
>send(b);
>calc_fcs(b);
> }
> send_fcs(); <--- 2 bytes
>
> then you need to be sure you send 127 - 2 bytes out

You send to the radio driver N bytes, then the transceiver calculates
FCS on this N bytes and after sending these N bytes, send the
calculated FCS. So you say that transmitter appends FCS to the given
frame.

Now, I'm helping to port OpenThread on RIOT and OpenThread stack gives
sometimes to the radio driver a frame of 126 bytes. My team asks them
how is it possible:
Their answer:
> The IEEE 802.15.4 frame length includes the FCS bytes at the end of the 
> frame.  The radio driver should simply update the last two bytes of the frame 
> rather than extending it.

If I understand well, RIOT stack does not include FCS in its
ieee802154 layer and OpenThread stack includes it?

Am I right?


2017-05-17 21:26 GMT+02:00 Alexander Aring <alex.ar...@gmail.com>:
> Hi,
>
> On Wed, May 17, 2017 at 07:56:05PM +0200, Baptiste Clenet wrote:
>> 2017-05-17 17:47 GMT+02:00 Thomas Eichinger <tho...@riot-os.org>:
>> > Hi Baptiste,
>> >
>> > On 17 May 2017, at 1:14 PDT(-0700), Baptiste Clenet wrote:
>> >
>> >> According to their example:
>> >> Example:
>> >> A frame transmission of length five with TX_AUTO_CRC_ON set, is
>> >> started with a Frame Buffer write access of five bytes (the last two
>> >> bytes can be omitted). The first three bytes are used for FCS
>> >> generation; the last two bytes are replaced by the internally
>> >> calculated FCS.
>> >>
>> >> Even a five bytes frame would have its last two bytes overwritten. Is
>> >> my understanding correct?
>> >> So I don't understand why the driver limits the frame length to 127-2?
>> >
>> >
>> > The at86rf2xx driver doesn't limit the *frame length* to 127-2 octets
>> > because the
>> > FCS is part of the frame sent out. The driver just makes sure that no
>> > payload
>> > data is overwritten by the FCS.
>> >
>> > Every 802.15.4 frame has two bytes of FCS. So if we didn't use
>> > TX_AUTO_CRC_ON
>> > we would have to calculate the checksum in software and write it into the
>> > frame buffer, appended to the header, sequence number, addresses and 
>> > payload
>> > we
>> > want to send. All together (FCF + seq_num + addrs + payload + FCS) this can
>> > be 127 bytes max.
>> >
>> > Now RIOT's at86rf2xx driver uses TX_AUTO_CRC_ON thus we don't have to
>> > calculate
>> > the FCS, it's appended to the rest of the frame.
>>
>> I don't think it is appended to the frame but it really replace the
>> last two bytes of the frame
>> Example:
>> at86rf2xx_tx_load(dev, ptr->iov_base, 5, 0);
>> FCS is calculated on bytes 1, 2 and 3 and bytes 4 and 5 are replaced by FCS
>>
>
> starting here at 0 or 1? :S
>
> Replaced by FCS? I suppose this function loads frame into framebuffer,
> the FCS isn't calculated there. See below.
>
>> at86rf2xx_tx_load(dev, ptr->iov_base, 126, 0);
>> FCS is calculated on bytes 1, to 124 and bytes 125 and 126 are replaced by 
>> FCS
>>
>> So the stack which give the frame should give a frame  2bytes longer
>> to let the transceiver calculate the FCS.
>> This is why IMO this check is useless.
>>
>> After reading more the datasheet, it's not clear because it is written:
>> On transmission the radio transceiver generates and appends the FCS
>> bytes during the frame transmission. This
>> behavior can be disabled by setting register bit TX_AUTO_CRC_ON = 0
>> (register 0x04, TRX_CTRL_1).
>>
>
> I think when the transmitter starts sending the FRAME -> going into
> BUSY. The transceiver will make some:
>
> init_fcs();
> for (b:each_bytes_to_tx) { <--- 127 - 2
> send(b);
> calc_fcs(b);
> }
> send_fcs(); <--- 2 bytes
>
> then you need to be sure you send 127 - 2 bytes out. If you disable
>
> ---
>
> now if you disable AUTO_CRC then you can load 127 bytes into framebuffer
> and hopefully last 2 bytes are FCS (or doesn't need to be, but then you
> running out-of-spec).
>
> - Alex
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel



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

Re: [riot-devel] RIOT Package

[Baptiste Clenet]

Cool! Let's do a PR? Or is there any other problem?

Le 17 mai 2017 21:10, "Kaspar Schleiser" <kas...@schleiser.de> a écrit :

> Hey,
>
> On 05/17/2017 07:25 PM, Baptiste Clenet wrote:
> > I see.
> > Is there another way to initialize it inside RIOT repo instead of home
> > directory?
>
> Sure, just set the "GIT_CACHE_DIR" environment variable to the desired
> directory, then run "dist/tools/git/git-cache init".
>
> Kaspar
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] at86rf2xx: packet too large -> FCS check

[Baptiste Clenet]

2017-05-17 17:47 GMT+02:00 Thomas Eichinger <tho...@riot-os.org>:
> Hi Baptiste,
>
> On 17 May 2017, at 1:14 PDT(-0700), Baptiste Clenet wrote:
>
>> According to their example:
>> Example:
>> A frame transmission of length five with TX_AUTO_CRC_ON set, is
>> started with a Frame Buffer write access of five bytes (the last two
>> bytes can be omitted). The first three bytes are used for FCS
>> generation; the last two bytes are replaced by the internally
>> calculated FCS.
>>
>> Even a five bytes frame would have its last two bytes overwritten. Is
>> my understanding correct?
>> So I don't understand why the driver limits the frame length to 127-2?
>
>
> The at86rf2xx driver doesn't limit the *frame length* to 127-2 octets
> because the
> FCS is part of the frame sent out. The driver just makes sure that no
> payload
> data is overwritten by the FCS.
>
> Every 802.15.4 frame has two bytes of FCS. So if we didn't use
> TX_AUTO_CRC_ON
> we would have to calculate the checksum in software and write it into the
> frame buffer, appended to the header, sequence number, addresses and payload
> we
> want to send. All together (FCF + seq_num + addrs + payload + FCS) this can
> be 127 bytes max.
>
> Now RIOT's at86rf2xx driver uses TX_AUTO_CRC_ON thus we don't have to
> calculate
> the FCS, it's appended to the rest of the frame.

I don't think it is appended to the frame but it really replace the
last two bytes of the frame
Example:
at86rf2xx_tx_load(dev, ptr->iov_base, 5, 0);
FCS is calculated on bytes 1, 2 and 3 and bytes 4 and 5 are replaced by FCS

at86rf2xx_tx_load(dev, ptr->iov_base, 126, 0);
FCS is calculated on bytes 1, to 124 and bytes 125 and 126 are replaced by FCS

So the stack which give the frame should give a frame  2bytes longer
to let the transceiver calculate the FCS.
This is why IMO this check is useless.

After reading more the datasheet, it's not clear because it is written:
On transmission the radio transceiver generates and appends the FCS
bytes during the frame transmission. This
behavior can be disabled by setting register bit TX_AUTO_CRC_ON = 0
(register 0x04, TRX_CTRL_1).

>
> Personally, I never tried what happens if you remove this check for 127-2
> and
> fully fill the frame buffer but I would imagine that exactly that happens,
> the
> last two bytes are overwritten by the FCS and thus lost, unless it already
> was
> the exact same checksum.
>
> Best, Thomas
>
>
>>
>>
>> 2017-05-16 16:42 GMT+02:00 Thomas Eichinger <tho...@riot-os.org>:
>>>
>>> Hi Baptiste,
>>>
>>> If you take a look at figures 37-1 and 37-2 in the data sheet you linked
>>> you can see that IEEE 802.15.4 allows up to 127 bytes for the MPDU and this
>>> includes the FCS.
>>> So if the driver would allow writing 127 bytes into the frame buffer the
>>> last two bytes would indeed be overwritten which is undesired I guess.
>>>
>>> I hope I understood you correctly and this helps.
>>>
>>> Best, Thomas
>>>
>>>> On May 16, 2017, at 6:09 AM, Baptiste Clenet <bapcle...@gmail.com>
>>>> wrote:
>>>>
>>>> Thomas, Hauke, Martine, Kaspar what do you think about it?
>>>>
>>>> My last question: how do I send a packet with length 127 octets with
>>>> at86rf2xx transceiver?
>>>>
>>>> 2017-05-15 14:59 GMT+02:00 Baptiste Clenet <bapcle...@gmail.com>:
>>>>>
>>>>> Hi,
>>>>>
>>>>> When I want to send a pkt which is 126 Octet long, I get a message
>>>>> from [at86rf2xx]:
>>>>> [at86rf2xx] error: packet too large (2 byte) to be send
>>>>>
>>>>> IEE802.15.4 MAX length is 127 so it should be sent.
>>>>> #define IEEE802154_FRAME_LEN_MAX(127U)  /**< maximum frame
>>>>> length */
>>>>>
>>>>> I checked source code of at86rf2xx driver and I think I understand the
>>>>> magic number +2 in the if condition but I don't know why this is
>>>>> checked.
>>>>>
>>>>> at86rf2xx_netdev.c:110:
>>>>>
>>>>>/* current packet data + FCS too long */
>>>>>if ((len + ptr->iov_len + 2) > AT86RF2XX_MAX_PKT_LENGTH) {
>>>>>DEBUG("[at86rf2xx] error: packet too large (%u byte) to be
>>>>> send (iov_len %d, i %d, count %d)\n",
>>>>>  (unsigned)len + 2, ptr->iov_len, i, count);
>>>>>return -EOVERFLOW;
>>>&g

Re: [riot-devel] RIOT Package

[Baptiste Clenet]

2017-05-17 11:20 GMT+02:00 Cenk Gündoğan <list-r...@cgundogan.de>:
> Hi Baptiste, Oleg,
>
> On 17-05-17 11:07:25, Oleg Hahm wrote:
>> Hi!
>>
>> On Wed, May 17, 2017 at 10:21:45AM +0200, Baptiste Clenet wrote:
>> > I see! Very interesting feature and I really think it should be
>> > enabled by default! What's your opinion?
>>
>> Not sure what you mean. The feature is enabled by default, the only thing you
>> need to do is to add git-cache to your $PATH.
>
> That's not necessary. RIOT's build system looks explicitly in
> `dist/tools/git` for `git-cache`. However, it is necessary to initialize
> `git-cache` once with `$RIOT/dist/tools/git/git-cache init`. This will
> create an empty bare git reposiroty in $HOME that is used to cache
> the necessary git objects.

Yes it is what I mean, `git-cache` should be initialized automatically
at the first compilation. I do think it is possible and will avoid
people to forget to initialize it.

>
> Cheers,
> Cenk
>
>>
>> Cheers,
>> Oleg
>> --
>> /* Fuck me gently with a chainsaw... */
>> linux-2.0.38/arch/sparc/kernel/ptrace.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
>



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

Re: [riot-devel] RIOT Package

[Baptiste Clenet]

Thank you for your answers.

I see! Very interesting feature and I really think it should be
enabled by default! What's your opinion?

2017-05-17 10:12 GMT+02:00 Oleg Hahm <oliver.h...@inria.fr>:
> Hi Baptiste!
>
> On Wed, May 17, 2017 at 10:08:50AM +0200, Baptiste Clenet wrote:
>> So you mean that git-cache is already used and allow to download an
>> archive of a .git repo?
>
> Yes, but you have to "install" git-cache first (see dist/tools/git/README.md).
>
>> Could you give me an example of a package that is download as an
>> archive and store so you don't need to git clone again?
>
> Every git-based package uses git-cache, e.g. nanocoap or ccn-lite.
>
> Cheers,
> Oleg
> --
> Yo mamma is so fat that she sat on a binary tree and made it a linked list in
> constant time.
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel



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

Re: [riot-devel] at86rf2xx: packet too large -> FCS check

[Baptiste Clenet]

According to their example:
Example:
A frame transmission of length five with TX_AUTO_CRC_ON set, is
started with a Frame Buffer write access of five bytes (the last two
bytes can be omitted). The first three bytes are used for FCS
generation; the last two bytes are replaced by the internally
calculated FCS.

Even a five bytes frame would have its last two bytes overwritten. Is
my understanding correct?
So I don't understand why the driver limits the frame length to 127-2?


2017-05-16 16:42 GMT+02:00 Thomas Eichinger <tho...@riot-os.org>:
> Hi Baptiste,
>
> If you take a look at figures 37-1 and 37-2 in the data sheet you linked you 
> can see that IEEE 802.15.4 allows up to 127 bytes for the MPDU and this 
> includes the FCS.
> So if the driver would allow writing 127 bytes into the frame buffer the last 
> two bytes would indeed be overwritten which is undesired I guess.
>
> I hope I understood you correctly and this helps.
>
> Best, Thomas
>
>> On May 16, 2017, at 6:09 AM, Baptiste Clenet <bapcle...@gmail.com> wrote:
>>
>> Thomas, Hauke, Martine, Kaspar what do you think about it?
>>
>> My last question: how do I send a packet with length 127 octets with
>> at86rf2xx transceiver?
>>
>> 2017-05-15 14:59 GMT+02:00 Baptiste Clenet <bapcle...@gmail.com>:
>>> Hi,
>>>
>>> When I want to send a pkt which is 126 Octet long, I get a message
>>> from [at86rf2xx]:
>>> [at86rf2xx] error: packet too large (2 byte) to be send
>>>
>>> IEE802.15.4 MAX length is 127 so it should be sent.
>>> #define IEEE802154_FRAME_LEN_MAX(127U)  /**< maximum frame length */
>>>
>>> I checked source code of at86rf2xx driver and I think I understand the
>>> magic number +2 in the if condition but I don't know why this is
>>> checked.
>>>
>>> at86rf2xx_netdev.c:110:
>>>
>>>/* current packet data + FCS too long */
>>>if ((len + ptr->iov_len + 2) > AT86RF2XX_MAX_PKT_LENGTH) {
>>>DEBUG("[at86rf2xx] error: packet too large (%u byte) to be
>>> send (iov_len %d, i %d, count %d)\n",
>>>  (unsigned)len + 2, ptr->iov_len, i, count);
>>>return -EOVERFLOW;
>>>}
>>>
>>> +2 mean two FCS octets?
>>> In the samr21 datasheet, 37.3 Frame Check Sequence (FCS) [1]:
>>>
>>> For a frame with a frame length specified as N (3 ≤ N ≤ 127), the FCS
>>> is calculated on the first N-2 octets in the Frame Buffer, and the
>>> resulting FCS field is transmitted in place of the last two octets
>>> from the Frame Buffer.
>>> Example:
>>> A frame transmission of length five with TX_AUTO_CRC_ON set, is
>>> started with a Frame Buffer write access of five bytes (the last two
>>> bytes can be omitted). The first three bytes are used for FCS
>>> generation; the last two bytes are replaced by the internally
>>> calculated FCS.
>>>
>>> So while I think we should remove the +2 test and let the possibility
>>> to send packet up to 127 octets and I don't understand the part in
>>> datasheet: "the last two bytes are replaced by the internally
>>> calculated FCS". This mean that a part of data is erased? (for 5
>>> octets or 127)
>>>
>>> Cheers,
>>>
>>> [1] http://www.atmel.com/Images/Atmel-42223%E2%80%93SAM-R21_Datasheet.pdf
>>>
>>>
>>> --
>>> Baptiste
>>
>>
>>
>> --
>> Baptiste
>> ___
>> 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



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

Re: [riot-devel] RIOT Package

[Baptiste Clenet]

So you mean that git-cache is already used and allow to download an
archive of a .git repo?
Could you give me an example of a package that is download as an
archive and store so you don't need to git clone again?

2017-05-17 9:28 GMT+02:00 Oleg Hahm <oliver.h...@inria.fr>:
> Hi Baptiste,
>
> On Wed, May 17, 2017 at 08:24:50AM +0200, Baptiste Clenet wrote:
>> Concerning external package, I suggest that RIOT download and store
>> the archive in pkg folder then extract here in the right location to
>> be compiled. This is helpful when you work on a package so you don't
>> need to download it again every time after a `make clean` or when you
>> compile another example, you need to download it again.
>> What do you think?
>
> for Git-based packages you can use git-cache for exactly this purpose [1].
>
> Cheers,
> Oleg
>
> [1] https://github.com/kaspar030/git-cache
> --
> RAID joke are always redundant
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel



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

Re: [riot-devel] at86rf2xx: packet too large -> FCS check

[Baptiste Clenet]

Thomas, Hauke, Martine, Kaspar what do you think about it?

My last question: how do I send a packet with length 127 octets with
at86rf2xx transceiver?

2017-05-15 14:59 GMT+02:00 Baptiste Clenet <bapcle...@gmail.com>:
> Hi,
>
> When I want to send a pkt which is 126 Octet long, I get a message
> from [at86rf2xx]:
> [at86rf2xx] error: packet too large (2 byte) to be send
>
> IEE802.15.4 MAX length is 127 so it should be sent.
> #define IEEE802154_FRAME_LEN_MAX(127U)  /**< maximum frame length */
>
> I checked source code of at86rf2xx driver and I think I understand the
> magic number +2 in the if condition but I don't know why this is
> checked.
>
> at86rf2xx_netdev.c:110:
>
> /* current packet data + FCS too long */
> if ((len + ptr->iov_len + 2) > AT86RF2XX_MAX_PKT_LENGTH) {
> DEBUG("[at86rf2xx] error: packet too large (%u byte) to be
> send (iov_len %d, i %d, count %d)\n",
>   (unsigned)len + 2, ptr->iov_len, i, count);
> return -EOVERFLOW;
> }
>
> +2 mean two FCS octets?
> In the samr21 datasheet, 37.3 Frame Check Sequence (FCS) [1]:
>
> For a frame with a frame length specified as N (3 ≤ N ≤ 127), the FCS
> is calculated on the first N-2 octets in the Frame Buffer, and the
> resulting FCS field is transmitted in place of the last two octets
> from the Frame Buffer.
> Example:
> A frame transmission of length five with TX_AUTO_CRC_ON set, is
> started with a Frame Buffer write access of five bytes (the last two
> bytes can be omitted). The first three bytes are used for FCS
> generation; the last two bytes are replaced by the internally
> calculated FCS.
>
> So while I think we should remove the +2 test and let the possibility
> to send packet up to 127 octets and I don't understand the part in
> datasheet: "the last two bytes are replaced by the internally
> calculated FCS". This mean that a part of data is erased? (for 5
> octets or 127)
>
> Cheers,
>
> [1] http://www.atmel.com/Images/Atmel-42223%E2%80%93SAM-R21_Datasheet.pdf
>
>
> --
> Baptiste



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

[riot-devel] at86rf2xx: packet too large -> FCS check

[Baptiste Clenet]

Hi,

When I want to send a pkt which is 126 Octet long, I get a message
from [at86rf2xx]:
[at86rf2xx] error: packet too large (2 byte) to be send

IEE802.15.4 MAX length is 127 so it should be sent.
#define IEEE802154_FRAME_LEN_MAX(127U)  /**< maximum frame length */

I checked source code of at86rf2xx driver and I think I understand the
magic number +2 in the if condition but I don't know why this is
checked.

at86rf2xx_netdev.c:110:

/* current packet data + FCS too long */
if ((len + ptr->iov_len + 2) > AT86RF2XX_MAX_PKT_LENGTH) {
DEBUG("[at86rf2xx] error: packet too large (%u byte) to be
send (iov_len %d, i %d, count %d)\n",
  (unsigned)len + 2, ptr->iov_len, i, count);
return -EOVERFLOW;
}

+2 mean two FCS octets?
In the samr21 datasheet, 37.3 Frame Check Sequence (FCS) [1]:

For a frame with a frame length specified as N (3 ≤ N ≤ 127), the FCS
is calculated on the first N-2 octets in the Frame Buffer, and the
resulting FCS field is transmitted in place of the last two octets
from the Frame Buffer.
Example:
A frame transmission of length five with TX_AUTO_CRC_ON set, is
started with a Frame Buffer write access of five bytes (the last two
bytes can be omitted). The first three bytes are used for FCS
generation; the last two bytes are replaced by the internally
calculated FCS.

So while I think we should remove the +2 test and let the possibility
to send packet up to 127 octets and I don't understand the part in
datasheet: "the last two bytes are replaced by the internally
calculated FCS". This mean that a part of data is erased? (for 5
octets or 127)

Cheers,

[1] http://www.atmel.com/Images/Atmel-42223%E2%80%93SAM-R21_Datasheet.pdf


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

Re: [riot-devel] CC1200 Sub-GHz Transceiver

[Baptiste Clenet]

@Peter: Because we should up to date with transceiver driver if we
want RIOT on new product
@Anon: I didn't see that you worked on a specific device, thanks for
considering it. Since you'll have skills and knowledge about CC1200,
it will be easy for you to port CC1350 :-)

2017-01-16 13:58 GMT+01:00 Anon Mall <anon.m...@gt-arc.com>:
> Hi,
>
> @Baptiste: I am currently working with a Remote and a Firefly, so
> implementing the CC1350 won't do me much good for now. But I will
> consider it once I am finished ;-).
>
> @Peter: Okay I will see how far I'll get by extending the CC110X driver
> and will switch to standalone driver if it gets too tedious.
>
> An other question concerning the RIOT SPI implementation. According to
> the CC1101 and CC1200 datasheet, both chips require the chip-select line
> to wait for the MISO line to go low, before switching back to high, when
> a reset command is issued. I tried implementing it by having the driver
> wait for the MISO line after calling spi_transfer_byte(...), but my
> logic analyzer shows, that chip select is set after calling the function
> and before the MISO line is back to low, even though It should be busy
> waiting. I have tried an isolated SPI test, but the symptoms are the
> same. Also when I just stop the code after clearing the chip-select but
> before spi_transfer_byte(...) my logic analyzer shows, that the
> chip-select is not triggered at all. Is there some deeper connection
> between the chip select and the SPI driver I don't know? I believe that
> clearing and setting the chip select would be my responsibility, while
> transferring data over the bus is done by the SPI driver.
>
>
> Hopefully I could explain my problem understandable enough
>
> Cheers,
>
> Anon
>
>> Date: Thu, 12 Jan 2017 12:55:28 +0100
>> From: Peter Kietzmann <peter.kietzm...@haw-hamburg.de>
>> To: RIOT OS kernel developers <devel@riot-os.org>
>> Subject: Re: [riot-devel] CC1200 Sub-GHz Transceiver
>> Message-ID: <94c91607-4dd7-3e72-7af3-507aee8e3...@haw-hamburg.de>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hi,
>>
>> @Baptiste: How did the CC1350 get into this round :-)?  Is it similar to
>> the other mentioned radios? In any way, I would be pretty happy to see
>> support for that radio in RIOT. It would enhance the current SensorTag
>> support significantly.
>>
>> @Anon: I have no idea about the differences between CC1101 and CC1200
>> (and CC1350). Whenever possible we try to avoid code duplication so if
>> you think it's easily 'possible' so extend the CC1101 driver, you should
>> go that way. If that means `#ifndef CC1200` in every second code line,
>> you should probably avoid it and write a standalone driver.
>>
>> Cheers
>> Peter
>>
>>
>>
>> Am 10.01.2017 um 19:14 schrieb Baptiste Clenet:
>>> Anon, you should try to work on CC1350 which is the last one ;-)
>>>
>>> Cheers,
>>>
>>> 2017-01-10 11:32 GMT+01:00 Anon Mall <anon.m...@gt-arc.com>:
>>>> Dear all,
>>>>
>>>> thanks for the reply
>>>>
>>>>
>>>>
>>>> @Peter: I will then put it into the driver section, as you have suggested.
>>>>
>>>>
>>>>
>>>> @Antonio: Thanks for the offer. I will surely take you up on that.
>>>>
>>>>
>>>>
>>>> Also a small question concerning the location of the driver. The CC1200 
>>>> uses
>>>>
>>>> the same command strobes on the SPI like the CC1101. As there is already a
>>>>
>>>> CC110X driver implemented, should the CC1200 be added to that 
>>>> implementation
>>>>
>>>> and transceiver specific code just capsuled as defines or would a 
>>>> standalone
>>>> driver
>>>>
>>>> make more sense?
>>>>
>>>>
>>>>
>>>> Cheers,
>>>>
>>>> Anon
>>>>
>>>>
>>>>
>>>>> Hello Anon!
>>>>> If you need help (as in devices with the CC1200 on board) drop me a line
>>>>> Cheers,
>>>>> --Antonio
>>>>>> Hi Anon,
>>>>>> it seems no one is working on this driver so please go ahead :-)! As
>>>>>> long as the CC1200 is not part of the CC2538 I agree with you the the
>>>>>> driver should be implemented stand alone. Compare e.g. the at86rf2xx
>>>>>> driver.
>>>>>> Best
>>>>>> Peter

[riot-devel] Stacksize optimization

[Baptiste Clenet]

Hi,

In order to optimize the statcksize of a thread, I would like to know
when the thread uses the maximum of its stack (maximum can be 3/4 of
the stack for instance)
How can I find this "time"?

Cheers,

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

[riot-devel] Cortex M0 HardFault

[Baptiste Clenet]

Hi,

What could cause:
Stack pointer corrupted, reset to top of stack
l.238, vectors_cortexm.c
(then board is halted)

Any program I flash on the samr21 goes directly to hard_fault_handler()

Board dead or something missing?

Cheers,

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

Re: [riot-devel] RIOT Release 2016.10

[Baptiste Clenet]

Great job Martine!

2016-11-14 12:05 GMT+01:00 Francisco Javier Acosta Padilla
:
> Hello!
>
> Thanks Martine for the marvellous work! And also thanks to al RIOTers who
> made it possible.
>
> Cheers!
>
> --
> Francisco Javier Acosta Padilla
> Research Engineer at INRIA Saclay
> INFINE Team
>
> On 11 November 2016 at 17:39:33, Oleg Hahm (oliver.h...@inria.fr) wrote:
>
> Hi!
>
> That's awesome and I'm really happy to see another RIOT release out there to
> conquer the IoT! ;-)
>
> Many thanks to Martine for thoroughly managing this release and putting so
> much work into it. And congrats for the fastest release - only 100 days! [1]
>
> And of course, also many thanks to the whole RIOT community for having
> contributed
> another great set of new features, bug fixes, and new hardware support!
>
> Cheers,
> Oleg
>
> [1] https://github.com/RIOT-OS/RIOT/wiki/release-statistics
>
> On Fri, Nov 11, 2016 at 04:07:46PM +0100, Martine Lenders wrote:
>> Dear RIOTers,
>>
>> we are happy to announce the ninth official release of the RIOT:
>>
>> --- * RIOT 2016.10 *
>> ---
>>
>> This release provides a lot of new features as well as it fixes several
>> major
>> bugs. Among these new features are the new simplified network socket API
>> called sock, the GNRC specific CoAP implementation gcoap and several new
>> packages: TinyDTLS, the Aversive++ microcontroller library for robotics,
>> the
>> u8g2 graphic library, and nanocoap.
>> Using the new sock API an implementation of the Simple Time Network
>> Protocol
>> (SNTP) was also introduced, allowing for time synchronization between
>> nodes.
>> New platforms include the Arduino Uno, the Arduino Duemilanove, the
>> Arduino
>> Zero, SODAQ Autonomo, and the Zolertia remote (rev. B).
>> The most significant bug fix was done in native which led to a
>> significantly
>> more robust handling of ISRs and now allows for at least 1,000 native
>> instances running stably on one machine.
>>
>> About 263 pull requests with about 398 commits have been merged since the
>> last
>> release and about 42 issues have been solved. 37 people contributed with
>> code
>> in 100 days. 1006 files have been touched with 166500 insertions and 26926
>> deletions.
>>
>> You can download the RIOT release from Github by cloning the
>> repository [1] or by
>> downloading the tarball [2], and look up the release notes for further
>> details [3].
>>
>> Thanks everyone for your contributions, discussions, testing efforts,
>> and keep RIOTing!
>>
>> Kind regards and wishing you a great weekend,
>> Martine
>>
>> [1] https://github.com/RIOT-OS/RIOT/releases/tag/2016.10
>> [2] https://github.com/RIOT-OS/RIOT/archive/2016.10.tar.gz
>> [3] https://github.com/RIOT-OS/RIOT/blob/master/release-notes.txt
>> ___
>> devel mailing list
>> devel@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>
> --
> panic("IRQ, you lose...");
> linux-2.2.16/arch/mips/sgi/kernel/indy_int.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
>



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

Re: [riot-devel] Easy ping

[Baptiste Clenet]

Thanks Martine!
I do need timeout, otherwise I won't know if the node is connected.
Sock is in PR so I prefer not to use it for the moment

2016-09-23 20:37 GMT+02:00 Martine Lenders :
> Hi Baptiste,
> that depends on what you mean by reachable. Even for ICMPv6 ping (which is
> used with the shell ping command) you need some "server", that handles the
> request and issues a reply. If that server is not present the node will not
> reply to pings, even if it is reachable in the sense that you can send IPv6
> packets to it and it will handle them (to see what I mean comment out the
> `USEMODULE += gnrc_icmpv6_echo` line in gnrc_networking's Makefile for the
> receiver, you will be able to still send UDP packets, but ping will always
> fail).
>
> If there is a server running somewhere you can just use conn (note that
> timeouts are not possible with conn, if you need them use sock [1] instead
> [which is also a little easier to handle]):
>
>> #include "net/af.h"
>> #include "net/conn/ip.h" /* you need to include gnrc_conn_ip to your app
>> for that */
>> #include "net/icmpv6.h"
>> #include "net/ipv6.h"
>> #include "net/protnum.h"
>> #include "byteorder.h"
>> #include "xtimer.h"
>>
>> /* ... */
>>
>> conn_ip_t c;
>> ipv6_addr_t tmp = IPV6_ADDR_UNSPECIFIED;
>> ipv6_addr_t dst = SOME_ADDR;
>> icmpv6_echo_t echo_req, echo_rep;
>> uint16_t seq = 0;
>>
>> echo_req.type = ICMPV6_ECHO_REQ;
>> echo_req.code = 0;
>> echo_req.id = byteorder_htons(SOME_ID);
>> conn_ip_create(, , sizeof(tmp), AF_INET6, PROTNUM_ICMPV6
>> while (true) {
>> int reply = 0;
>> echo_req.seq = byteorder_htons(seq++);
>> echo_req.csum.u16 = 0; /* will be recalculated by stack */
>> conn_ip_sendto(_req, sizeof(echo_req), NULL, 0, dst, sizeof(dst),
>> AF_INET6, PROTNUM_IPV6_NONXT);
>> while (!reply) {
>> if (conn_ip_recvfrom(, _rep, sizeof(echo_rep), ,
>> sizeof(tmp)) == sizeof(echo_rep)) {
>> /* could be any ICMPv6 packet so check type */
>> if (echo_rep.type == ICMPV6_ECHO_REP) {
>> printf("Received ping seq %u\n",
>> (unsigned)ntohs_byteorder(echo_rep.seq));
>> reply = 1;
>> }
>> }
>> }
>> xtimer_sleep(DELAY);
>> }
>
> Did not test the application, but I hope you get the idea.
>
> Cheers,
> Martine
>
> [1]
> https://github.com/RIOT-OS/RIOT/pull/5772/files#diff-0fb2e56aa53bfaac6b1189715662110cR89
>
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>



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

Re: [riot-devel] Easy ping

[Baptiste Clenet]

Yes it would work, but I prefer a simple ping, two gnrc_networking
running and one wants to ping the other one, that's all what I want.
ICMPV6 is great because I don't need to deal with the request on the
second board.

2016-09-23 18:30 GMT+02:00 Marc Sissom <msis...@krypton-solutions.com>:
> I assume the device you are trying to reach has some purpose. If so send it a 
> purposeful packet. For example, you are running a web server on the device in 
> question, open a connection to port  80 with your telnet utility and talk to 
> it.
>
>
> Marc Sissom
> Krypton Solutions
>
> -Original Message-
> From: devel [mailto:devel-boun...@riot-os.org] On Behalf Of Baptiste Clenet
> Sent: Friday, September 23, 2016 11:21 AM
> To: RIOT OS kernel developers <devel@riot-os.org>
> Subject: Re: [riot-devel] Easy ping
>
> Yes but it's not as easy as I want (shell command) Tell me the easiest 
> possible function to know if an address is reachable or not :-)
>
> 2016-09-23 17:56 GMT+02:00 Martine Lenders <m...@martine-lenders.eu>:
>> Hi Baptiste,
>> have you had a look at the implementation of the ping shell command?
>> Another way would be to (re-)implement ping using conn_ip (or sock if
>> merged). In that case, if you want it relly easy you don't even
>> have to implement ICMPv6 ping but can do whatever you want ;-).
>>
>> Cheers,
>> Martine
>>
>> 2016-09-23 17:18 GMT+02:00 Baptiste Clenet <bapcle...@gmail.com>:
>>> Hi,
>>>
>>> How can I easily ping a board by software (without using shell) so I
>>> ping( IPV6_address) and I get -1 for error (not reachable) or 0 for
>>> success?
>>>
>>> Cheers,
>>>
>>> --
>>> Baptiste
>>> ___
>>> 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
>
>
>
> --
> Baptiste
> ___
> 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



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

Re: [riot-devel] Easy ping

[Baptiste Clenet]

Yes but it's not as easy as I want (shell command)
Tell me the easiest possible function to know if an address is
reachable or not :-)

2016-09-23 17:56 GMT+02:00 Martine Lenders <m...@martine-lenders.eu>:
> Hi Baptiste,
> have you had a look at the implementation of the ping shell command?
> Another way would be to (re-)implement ping using conn_ip (or sock if
> merged). In that case, if you want it relly easy you don't even
> have to implement ICMPv6 ping but can do whatever you want ;-).
>
> Cheers,
> Martine
>
> 2016-09-23 17:18 GMT+02:00 Baptiste Clenet <bapcle...@gmail.com>:
>> Hi,
>>
>> How can I easily ping a board by software (without using shell) so I
>> ping( IPV6_address) and I get -1 for error (not reachable) or 0 for
>> success?
>>
>> Cheers,
>>
>> --
>> Baptiste
>> ___
>> 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



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

[riot-devel] Easy ping

[Baptiste Clenet]

Hi,

How can I easily ping a board by software (without using shell) so I
ping( IPV6_address) and I get -1 for error (not reachable) or 0 for
success?

Cheers,

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

Re: [riot-devel] Observable resource

[Baptiste Clenet]

Hi,
Microcoap does not offer OBSERVE resource type. Use libcoap instead or
add it to the current microcoap implementation.
You may use Soletta Project, they have OBSERVE capability but it's
heavy package, might need to port only required stuff from the
package.

Cheers,

2016-09-19 11:50 GMT+02:00 ALESSANDRO NICOLI
:
> Hi all!
> I would try to add an observable resource to my microCoap_server but, there
> is already a way to do that in RIOT?
> Thanks all,
>
> best regards,
> Alessandro
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>



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

Re: [riot-devel] BorderRouter: Global IPV6 address lost in ncache after UDP message sent

[Baptiste Clenet]

Thanks Martine,
The issue you mentioned seems to be different.

Did you see the neighbor discovery implementation of OpenThread? How
your new implementation will be able to dicuss with OpenThread
implementation?

Cheers,

2016-08-29 19:56 GMT+02:00 Martine Lenders <m...@martine-lenders.eu>:
> Hi,
> can you check if this is https://github.com/RIOT-OS/RIOT/issues/5467?
>
>> Why or how can a node be removed from ncache? Why the node does not
> automatically reconnect with BR?
>
> As the implementer of the neighbor discovery I can say this: because
> the neighbor discovery is sh** ;-). It was written in a haste and has
> a lot of design flaws. I'm working on a replacement (see
> https://github.com/RIOT-OS/RIOT/issues/5704, happy to hear your
> thoughts ;-)), but sadly I did not find some time to put heavy
> implementation efforts into this yet (hopefully in autumn though, so
> we have something for the October release, fingers crossed).
>
> Thanks for reporting and kind regards,
> Martines
>
> 2016-08-29 17:54 GMT+02:00 Baptiste Clenet <bapcle...@gmail.com>:
>> Hi,
>> I'm using two SAMR21, one with BR (on A) and the other (on B) with
>> gnrc_networking example.
>> I'm on April release.
>> Switch on A (border router) then switch on B, I'm able to send UDP
>> message from Linux to 2001:db8 address of B.
>> If I try to send lot of data (every 100ms), it works for a while and
>> then B does not receive message anymore. After I see it failed, I
>> stopped the loop sending UDP message, I checked on BR and 2001:db8
>> address of B was not here anymore. I can ping B with fe80:: address on
>> iface 6 but can't with 2001:db8.
>>
>> Why or how can a node be removed from ncache? Why the node does not
>> automatically reconnect with BR?
>>
>> Cheers
>>
>> --
>> Baptiste
>> ___
>> 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



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

[riot-devel] BorderRouter: Global IPV6 address lost in ncache after UDP message sent

[Baptiste Clenet]

Hi,
I'm using two SAMR21, one with BR (on A) and the other (on B) with
gnrc_networking example.
I'm on April release.
Switch on A (border router) then switch on B, I'm able to send UDP
message from Linux to 2001:db8 address of B.
If I try to send lot of data (every 100ms), it works for a while and
then B does not receive message anymore. After I see it failed, I
stopped the loop sending UDP message, I checked on BR and 2001:db8
address of B was not here anymore. I can ping B with fe80:: address on
iface 6 but can't with 2001:db8.

Why or how can a node be removed from ncache? Why the node does not
automatically reconnect with BR?

Cheers

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

Re: [riot-devel] Global IPV6

[Baptiste Clenet]

I would prefer to get an event when a global IPV6 is added so I'm sure
it is otherwise if a new prefix is advertised/seen, i'm not sure an
IPV6 is added. So what Martine suggested  should be ok for my purpose.

2016-07-13 21:39 GMT+02:00 Thomas C. Schmidt <t.schm...@haw-hamburg.de>:
> Hi Baptiste,
>
> are you in search for a trigger that fires every time a new prefix is
> advertised/seen? Or do you refer to the event of a new IPv6 interface being
> configured?
>
> Cheers,
>  Thomas
>
> On 13.07.2016 16:51, Baptiste Clenet wrote:
>>
>> Hi,
>>
>> How can I be informed that my node has got a new global IPV6? I would
>> like to call a function every time the node get a new global IPV6
>> address. How can I do that?
>>
>> Cheers,
>>
>
> --
>
> Prof. Dr. Thomas C. Schmidt
> ° Hamburg University of Applied Sciences   Berliner Tor 7 °
> ° Dept. Informatik, Internet Technologies Group20099 Hamburg, Germany °
> ° http://www.haw-hamburg.de/inet   Fon: +49-40-42875-8452 °
> ° http://www.informatik.haw-hamburg.de/~schmidtFax: +49-40-42875-8409 °
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel



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

Re: [riot-devel] Global IPV6

[Baptiste Clenet]

Thanks Martine!

2016-07-13 17:07 GMT+02:00 Martine Lenders <m...@martine-lenders.eu>:
> Hi,
> the the end of the `add` handler [1] for the IPv6 interfaces should be the
> best place for that.
>
> Cheers,
> Martine
>
> [1]
> https://github.com/RIOT-OS/RIOT/blob/master/sys/net/gnrc/network_layer/ipv6/netif/gnrc_ipv6_netif.c#L160
>
> 2016-07-13 17:04 GMT+02:00 Baptiste Clenet <bapcle...@gmail.com>:
>>
>> Ok, it's what I thought. How can I temporary hack the source code to
>> get this event handler? Where should I add my function. I need it for
>> some tests
>>
>> 2016-07-13 16:55 GMT+02:00 Martine Lenders <m...@martine-lenders.eu>:
>> > Hi Baptiste,
>> > as of now no such event handler exist, but I note such feature it down
>> > for
>> > the network layer overhaul (previously known as neighbor discovery
>> > overhaul). Expect some early API proposals the week after IETF.
>> >
>> > Cheers,
>> > Martine
>> >
>> > 2016-07-13 16:51 GMT+02:00 Baptiste Clenet <bapcle...@gmail.com>:
>> >>
>> >> Hi,
>> >>
>> >> How can I be informed that my node has got a new global IPV6? I would
>> >> like to call a function every time the node get a new global IPV6
>> >> address. How can I do that?
>> >>
>> >> Cheers,
>> >>
>> >> --
>> >> Baptiste
>> >> ___
>> >> 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
>> >
>>
>>
>>
>> --
>> Baptiste
>> ___
>> 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
>



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

[riot-devel] Global IPV6

[Baptiste Clenet]

Hi,

How can I be informed that my node has got a new global IPV6? I would
like to call a function every time the node get a new global IPV6
address. How can I do that?

Cheers,

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

Re: [riot-devel] Stop other thread

[Baptiste Clenet]

Should I simply run a thread with highest priority so I'm sure it will
be run before running other thread?

2016-07-13 13:32 GMT+02:00 Baptiste Clenet <bapcle...@gmail.com>:
> Hi,
>
> I've got a chip which needs precise timing to be read. A year ago, I
> was able to communicate with this chip but now, even if I go as fast I
> can it seems that timing have increased with same source code.
> So is there a way to force the CPU to do only one task at the time for
> the duration of the function. Can we tell the scheduler to stop other thread?
>
> Cheers,
>
> 2016-07-13 13:32 GMT+02:00 Baptiste Clenet <bapcle...@gmail.com>:
>> Hi,
>>
>> I've got a chip which needs precise timing to be read. A year ago, I
>> was able to communicate with this chip but now, even if I go as fast I
>> can it seems that timing have increased with same source code.
>> So is there a way to force the CPU to do only one task at the time for
>> the duration of the function. Ca
>>
>> --
>> Baptiste
>
>
>
> --
> Baptiste



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

Re: [riot-devel] Stop other thread

[Baptiste Clenet]

Hi,

I've got a chip which needs precise timing to be read. A year ago, I
was able to communicate with this chip but now, even if I go as fast I
can it seems that timing have increased with same source code.
So is there a way to force the CPU to do only one task at the time for
the duration of the function. Can we tell the scheduler to stop other thread?

Cheers,

2016-07-13 13:32 GMT+02:00 Baptiste Clenet <bapcle...@gmail.com>:
> Hi,
>
> I've got a chip which needs precise timing to be read. A year ago, I
> was able to communicate with this chip but now, even if I go as fast I
> can it seems that timing have increased with same source code.
> So is there a way to force the CPU to do only one task at the time for
> the duration of the function. Ca
>
> --
> Baptiste



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

[riot-devel] Stop other thread

[Baptiste Clenet]

Hi,

I've got a chip which needs precise timing to be read. A year ago, I
was able to communicate with this chip but now, even if I go as fast I
can it seems that timing have increased with same source code.
So is there a way to force the CPU to do only one task at the time for
the duration of the function. Ca

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

Re: [riot-devel] Is samr21-xpro SPI working

[Baptiste Clenet]

I didn't know this exist! [1] but I'll vote for it. First, you need to
know if something goes on SPI MOSI line and if timing is ok.



[1] 
http://www.ebay.de/itm/24MHz-8-Channel-USB-Logic-Analyzer-8-CH-Logic-Analyzer-for-Arduino-MCU-/131840997125?hash=item1eb255f705:g:FEUAAOSwQupXVjOq

2016-07-11 9:17 GMT+02:00 Peter Kietzmann <peter.kietzm...@haw-hamburg.de>:
> Hi Kees,
>
> stupid question: How do you know SPI is not working? "GPIO_1090536471" was a
> formatting bug, compare:
>
> https://github.com/RIOT-OS/RIOT/pull/5619
>
> Would you try to initialize an other pin as CS line? If I see it correctly
> you decided for PA23. Maybe just try it with PB2 (in case you don't use it
> for other things).
>
> Best
> Peter
>
>
>
> Am 08.07.2016 um 20:16 schrieb Kees Bakker:
>>
>> This very same setup works perfectly with Arduino.
>> It is a SAMD21 on a Autonomo (very much like Arduine Zero).
>> It has a 16Mb "serial flash" chip on it.
>>
>> I started with the code from cpu/samd21 that was developed for
>> the samr21-xpro board.
>>
>> The "only" thing I had to change is the pins for the SPI. And with the
>> pins I also had to change the SERCOM, the PADs and the pin MUX.
>> And yes, I checked the SS pin (and all other pins) over and over.
>>
>> So far I was able to get UART and I2C working. But for more than a
>> week now I am stuck at SPI. I use the tests/periph_spi test program.
>>
>> �main(): This is RIOT! (Version:
>> 2016.07-devel-336-g38dc1-rapper-add-sodaq-autonomo)
>>
>> RIOT low-level SPI driver test
>> This application enables you to test a platforms SPI driver
>> implementation.
>> Enter 'help' to get started
>>
>>  > �main(): This is RIOT! (Version:
>> 2016.07-devel-336-g38dc1-rapper-add-sodaq-autonomo)
>>
>> RIOT low-level SPI driver test
>> This application enables you to test a platforms SPI driver
>> implementation.
>> Enter 'help' to get started
>>
>>  > help
>> Command  Description
>> ---
>> init_master  Initialize node as SPI master
>> init_slave   Initialize node as SPI slave
>> send Transfer string to slave (only in master mode)
>> print_rx Print the received string (only in slave mode)
>> reboot   Reboot the node
>>  >
>>  > init_master 0 0 23
>> SPI_0 successfully initialized as master, cs: GPIO_1090536471, mode: 0,
>> speed: 2
>>  >
>>  > send
>> Transfered 5 bytes:
>> MOSI   01234
>>   0x9f 0x00 0x00 0x00 0x00
>>??   ??   ??   ??   ??
>>
>> MISO   01234
>>   0xff 0xff 0xff 0xff 0xff
>>??   ??   ??   ??   ??
>>
>> It drives me nuts. Any hint is greatly appreciated.
>> -- Kees
>>
>> On 08-07-16 19:03, Baptiste Clenet wrote:
>>>
>>> Autonomo  uses samd21 CPU? You use same driver as samr21?
>>> What's your problem?
>>> Are you sure your SPI Slave chip is working correctly?
>>>
>>> 2016-07-07 21:01 GMT+02:00 Kees Bakker <k...@sodaq.com>:
>>>>
>>>> Ah, _now_ it makes sense. :-) Thanks for letting me know.
>>>>
>>>> That leaves me with my own SPI problem. On my Autonomo I can't get
>>>> it to work. It is working with Arduino, but with RIOT (under
>>>> construction)
>>>> it's
>>>> not :-(
>>>>
>>>>
>>>>
>>>> On 06-07-16 22:53, Baptiste Clenet wrote:
>>>>>
>>>>> Yes I know, I changed it to make it work :)  (SPI1)
>>>>>
>>>>> 2016-07-06 22:48 GMT+02:00 Kees Bakker <k...@sodaq.com>:
>>>>>>
>>>>>> OK thanks. However, your remark about SPI1 puzzles me a bit,
>>>>>> because it
>>>>>> was
>>>>>> using
>>>>>> an incorrect PAD setting. PR #5609 fixed today.
>>>>>>
>>>>>>
>>>>>> On 05-07-16 23:21, Baptiste Clenet wrote:
>>>>>>>
>>>>>>> I can confirm that it works properly.
>>>>>>> SPI is used to communicate with the transceiver on samr21-xpro and
>>>>>>> communication works so SPI works, I used SPI1 also with no problem
>>>>>>>
>>>>>>> 2016-07-05 21:50 GMT+02:00 Kees Bakker <k...@sodaq.com>:
>>>>>>>>
>>>>>>>>

Re: [riot-devel] Is samr21-xpro SPI working

[Baptiste Clenet]

Autonomo  uses samd21 CPU? You use same driver as samr21?
What's your problem?
Are you sure your SPI Slave chip is working correctly?

2016-07-07 21:01 GMT+02:00 Kees Bakker <k...@sodaq.com>:
> Ah, _now_ it makes sense. :-) Thanks for letting me know.
>
> That leaves me with my own SPI problem. On my Autonomo I can't get
> it to work. It is working with Arduino, but with RIOT (under construction)
> it's
> not :-(
>
>
>
> On 06-07-16 22:53, Baptiste Clenet wrote:
>>
>> Yes I know, I changed it to make it work :)  (SPI1)
>>
>> 2016-07-06 22:48 GMT+02:00 Kees Bakker <k...@sodaq.com>:
>>>
>>> OK thanks. However, your remark about SPI1 puzzles me a bit, because it
>>> was
>>> using
>>> an incorrect PAD setting. PR #5609 fixed today.
>>>
>>>
>>> On 05-07-16 23:21, Baptiste Clenet wrote:
>>>>
>>>> I can confirm that it works properly.
>>>> SPI is used to communicate with the transceiver on samr21-xpro and
>>>> communication works so SPI works, I used SPI1 also with no problem
>>>>
>>>> 2016-07-05 21:50 GMT+02:00 Kees Bakker <k...@sodaq.com>:
>>>>>
>>>>> Hey,
>>>>>
>>>>> Can someone confirm that SPI is working on the samr21-xpro board?
>>>>>
>>>>> I'm trying to make SPI work on my Autonomo board, but I haven't
>>>>> succeeded yet. FYI, I'm also reorganizing the code so there are a lot
>>>>> of parameters that can be of influence. I can't use the current code
>>>>> because the pins and the SERCOMs are different.
>>>>>
>>>>> It would help me to know that it works on samr21-xpro.
>>>>>
>>>>> --
>>>>> Kees Bakker
>>>>> Founder
>>>>> SODAQ
>>>>> M. 0031617737165
>>>>> www.sodaq.com
>>>>>
>>>>> ___
>>>>> devel mailing list
>>>>> devel@riot-os.org
>>>>> https://lists.riot-os.org/mailman/listinfo/devel
>>>>
>>>>
>>>>
>>>
>>> --
>>> Kees Bakker
>>> Founder
>>> SODAQ
>>> M. 0031617737165
>>> www.sodaq.com
>>>
>>> ___
>>> devel mailing list
>>> devel@riot-os.org
>>> https://lists.riot-os.org/mailman/listinfo/devel
>>
>>
>>
>
>
> --
> Kees Bakker
> Founder
> SODAQ
> M. 0031617737165
> www.sodaq.com
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel



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

Re: [riot-devel] Is samr21-xpro SPI working

[Baptiste Clenet]

Yes I know, I changed it to make it work :)  (SPI1)

2016-07-06 22:48 GMT+02:00 Kees Bakker <k...@sodaq.com>:
> OK thanks. However, your remark about SPI1 puzzles me a bit, because it was
> using
> an incorrect PAD setting. PR #5609 fixed today.
>
>
> On 05-07-16 23:21, Baptiste Clenet wrote:
>>
>> I can confirm that it works properly.
>> SPI is used to communicate with the transceiver on samr21-xpro and
>> communication works so SPI works, I used SPI1 also with no problem
>>
>> 2016-07-05 21:50 GMT+02:00 Kees Bakker <k...@sodaq.com>:
>>>
>>> Hey,
>>>
>>> Can someone confirm that SPI is working on the samr21-xpro board?
>>>
>>> I'm trying to make SPI work on my Autonomo board, but I haven't
>>> succeeded yet. FYI, I'm also reorganizing the code so there are a lot
>>> of parameters that can be of influence. I can't use the current code
>>> because the pins and the SERCOMs are different.
>>>
>>> It would help me to know that it works on samr21-xpro.
>>>
>>> --
>>> Kees Bakker
>>> Founder
>>> SODAQ
>>> M. 0031617737165
>>> www.sodaq.com
>>>
>>> ___
>>> devel mailing list
>>> devel@riot-os.org
>>> https://lists.riot-os.org/mailman/listinfo/devel
>>
>>
>>
>
>
> --
> Kees Bakker
> Founder
> SODAQ
> M. 0031617737165
> www.sodaq.com
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel



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

Re: [riot-devel] OpenThread port: IEEE802.15 ACK

[Baptiste Clenet]

Very nice!
I won't be there, I hope you will upload a video as well as your
source code example on github.

Cheers,

2016-07-06 12:41 GMT+02:00 Jose Alamos :
> Hi Baptiste
>
> Yes, I'm still working on it.
> I'm planning to show a demo of the port in RIOT summit.
>
> Cheers.
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>



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

Re: [riot-devel] OpenThread port: IEEE802.15 ACK

[Baptiste Clenet]

Jose, is the following PR yours?
https://github.com/RIOT-OS/RIOT/pull/5552
What's the status of the PR, are you still working on it?

2016-06-16 17:30 GMT+02:00 Oleg Hahm :
> Hi José!
>
> On Thu, Jun 16, 2016 at 05:18:32PM +0200, Jose Alamos wrote:
>> I'm porting the OpenThread stack to RIOT. I have hooks for sending and
>> receiving frames and for transmision/reception "Done" signals (TransmitDone
>> and ReceiveDone)
>>
>> In their examples they are manually checking/sending IEEE802.15 ACK before
>> calling the corresponding Done hook, but I'm not sure if I should do the
>> same from RIOT. Are drivers in charge of handling these ACKs (so RIOT's
>> TX_COMPLETE is triggered after receiving ACK)?
>>
>> Basically I have to call the TransmitDone hook when the transmission is
>> done, and that's only if the ACK is received.
>
> That's dependent on the driver and (at least in principle) on its
> configuration. For the at86rf2xx the current driver sends ACKs automatically
> and the caller will get the TX_COMPLETE if an ACK was received (or
> transmissions was broadcast).
>
> Cheers,
> Oleg
> --
> printk(CARDNAME": Bad Craziness - sent packet while busy.\n" );
> linux-2.6.6/drivers/net/smc9194.c
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>



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

Re: [riot-devel] Transceiver : Reception level

[Baptiste Clenet]

Thanks Martine, I'll try when I've got time

2016-07-02 12:27 GMT+02:00 Martine Lenders <m...@martine-lenders.eu>:
> Hi Baptiste,
> if you can read it on the driver level, you can adapt
> gnrc_netdev2_hdr_t to add that value as a field and add it via the
> rx_info struct handed to the recv function of the netdev2-driver.
>
> Hope that was helpful feel free to ask for further details.
>
> Cheers,
> Martine
>
> 2016-07-01 21:57 GMT+02:00 Baptiste Clenet <bapcle...@gmail.com>:
>> Hi,
>> When I receive a UDP frame, may I see the level (dB) of the received frame ?
>> I know that we can see it in driver source code but How can I acces it from
>> socket level ?
>> Cheers，
>>
>>
>> ___
>> 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



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

[riot-devel] Transceiver : Reception level

[Baptiste Clenet]

Hi,
When I receive a UDP frame, may I see the level (dB) of the received frame
? I know that we can see it in driver source code but How can I acces it
from socket level ?
Cheers，
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RIOT Vs Iotivity, AllJoyn, Thread

[Baptiste Clenet]

2016-06-09 1:29 GMT+02:00 Martine Lenders <m...@martine-lenders.eu>:

> Hi,
>
> 2016-06-08 20:29 GMT+02:00 Iván Briano <ivan.bri...@intel.com>:
>
>> On Wed, 08 Jun 2016 19:58:50 +0200, Baptiste Clenet wrote:
>> > 2016-06-08 17:14 GMT+02:00 Emmanuel Baccelli <
>> emmanuel.bacce...@inria.fr>:
>> >
>> > > Hi Ivan,
>> > > it would be great to have it as a pkg indeed!
>> > > That's the standard way third-party stacks are integrated in RIOT.
>> > > Looking forward to that,
>> > > Emmanuel
>> > >
>> > > On Wed, Jun 8, 2016 at 3:41 PM, Iván Briano <ivan.bri...@intel.com>
>> wrote:
>> > >
>> > >> On Wed, 08 Jun 2016 09:46:31 +0200, Baptiste Clenet wrote:
>> > >> > Thanks for your answers.
>> > >> > Could we integrate Soletta OIC implementation part as a pkg in
>> RIOT?
>> > >> >
>> > >>
>> > >> The OIC implementation is tightly integrated to the core of Soletta,
>> so
>> > >> you need the whole thing in.
>> > >
>> > > Yes but could we find a way to separate it a bit so we can run a OIC
>> > server using GNRC quickly?
>>
>> That's not straight forward. The OIC implementation uses the CoAP one in
>> Soletta, which uses the socket abstractions as well. GNRC is all the way
>> under that. Using Soletta means that you'll need one thread to run the
>> main loop, from where all events will be dispatched.
>>
>
> Do you use your own implementation of CoAP? (or microcoap or libcoap)
Soletta definies socket over RIOT socket? Why?
There is some work, we need to dig inside but I think it's a good idea to
port your OIC implementation as RIOT package, so RIOT will be an OIC
compliant OS and this is important to uniform exchanged data between
devices.
Let Martine know if you need any help about the porting, you can include me
in the PR, I don't know if I'll have time to work on it, but I will follow
your porting.



> Porting to GNRC won't be necessary for early integration (maybe later on
> we can cherry-pick the best parts to make it work with GNRC). The emb6
> stack (a fork of Contiki's uIP) [1] I ported for RIOT [2] had similar
> requirements for running in a single thread. If you want to I can help you
> with integrating a foreign network stack into RIOT using `pkg`.
> It's mainly about providing an adaption layer between whatever HAL the
> stack uses and `netdev2`. `conn` can also be ported, but as your
> descriptions sounds like Soletta is running above transport layer, this
> might not be needed/suitable.
>
> Cheers,
> Martine
>
> [1] https://github.com/hso-esk/emb6
> [2] https://github.com/RIOT-OS/RIOT/tree/master/pkg/emb6
>



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

Re: [riot-devel] RIOT Vs Iotivity, AllJoyn, Thread

[Baptiste Clenet]

Thanks for your answers.
Could we integrate Soletta OIC implementation part as a pkg in RIOT?

2016-06-07 12:58 GMT+02:00 Emmanuel Baccelli <emmanuel.bacce...@inria.fr>:

> Hi Gustavo, Hi Ivan,
> ok I see. thanks for your answers.
> That's too bad. It would have been great to gather OIC/OCF people in the
> same room with W3C, IETF and OpenThread people (who are attending the RIOT
> Summit) to discuss various IoT network stack approaches, and various IoT
> open source software approaches. Pitching Intel's approach to IoT in this
> context would also have been a good occasion, in the opinion of many among
> us.
> If there's anything we can do to help you or someone else from your
> community attend/present, let us know.
> Else, maybe next time.
> Cheers,
> Emmanuel
>
> On Mon, Jun 6, 2016 at 11:26 PM, Gustavo Lima Chaves <
> gustavo.lima.cha...@intel.com> wrote:
>
>> Hi,
>>
>> > Sorry, I was under the assumption that this had been settled in private
>> > conversations already, but now I see that's not the case (and the person
>> > involved is not even copied).
>> >
>> > Soletta has an implementation of OIC, the protocol that IoTivity
>> > implements, but there's nothing about AllJoyn or Thread.
>> >
>> > I'm in no position to talk about anything now, so I have to decline the
>> > invitation, but maybe some of the others listed that have been more
>> > involved with Soletta and OIC can respond.
>> >
>> > On Mon, 06 Jun 2016 22:40:34 +0200, Baptiste Clenet wrote:
>> > > Could some of you answer please?
>> > > Thanks
>> > >
>> > > Baptiste
>> > >
>> > > 2016-05-31 17:30 GMT+02:00 Thiago Macieira <thiago.macie...@intel.com
>> >:
>> > >
>> > > > Hello Baptiste, Emmanuel
>> > > >
>> > > > I'll let the people more familiar (in cc) with it reply.
>> > > >
>> > > > On terça-feira, 31 de maio de 2016 16:05:22 BRT Emmanuel Baccelli
>> wrote:
>> > > > > Hi Thiago,
>> > > > > basically, we are interested in learning more about it.
>> > > > > And in particular, we were wondering whether it could be a good
>> idea to
>> > > > > present this at the RIOT Summit [1].
>> > > > > What do you think about this idea?
>> > > > > Best,
>> > > > > Emmanuel
>>
>> Oh, sorry, I was also in the private thread (was going to respond
>> soon, but now let's do it here). I have to say that I'm not very
>> comfortable to do a skype-based presentation. Given that the changes
>> of getting funds to travel to the summit are vague now, maybe I'll
>> have to decline as well, unfortunately.
>>
>> [...]
>>
>> > > > > >>>> Hi!
>> > > > > >>>>
>> > > > > >>>> On Mon, May 30, 2016 at 09:16:17AM +0200, Baptiste Clenet
>> wrote:
>> > > > > >>>> > - Iotivity would be great in RIOT, Soletta project [1]
>> imported it
>> > > > > >>>> > for
>> > > > > >>>> > RIOT, I haven't tried it but it seems to work. I think
>> Riot should
>> > > > > >>>>
>> > > > > >>>> have an
>> > > > > >>>>
>> > > > > >>>> > implementation of Iotivity directly in its repo (package)
>> so it
>> > > > will
>> > > > > >>>>
>> > > > > >>>> be
>> > > > > >>>>
>> > > > > >>>> > better maintain.
>>
>> If all of OIC/OCF is to be supported, that's quite a bit of code and
>> using Soletta is a much simpler path.
>>
>> --
>> Gustavo Lima Chaves
>> Intel - Open Source Technology Center
>>
>
>


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

Re: [riot-devel] RIOT Vs Iotivity, AllJoyn, Thread

[Baptiste Clenet]

Not really but I saw him answering some post on Iotivity and Soletta
project for people asking to port Iotivity to constraint object.

Thiago, could you explain Soletta Project and the relation with OIC and
RIOT please?

2016-05-30 21:07 GMT+02:00 Emmanuel Baccelli <emmanuel.bacce...@inria.fr>:

> Hi Baptiste,
>
> Thanks for the clarification.
>
> Have you already been in contact personally with Thiago?
>
> It may be interesting if they attend and/or present something on this
> topic at the upcoming RIOT Summit [1].
>
> Cheers,
>
> Emmanuel
>
> [1] summit.riot-os.org
> On May 30, 2016 4:19 PM, "Baptiste Clenet" <bapcle...@gmail.com> wrote:
>
>> Hi, I correct what I said, Soletta Project is not an implementation of
>> Iotivity but an implementation of OIC specification (Iotivity too) so
>> Iotivity and Soletta project can communicate together since they use same
>> specification.
>>
>> Intel Open Source is in charge of this project and you can ask
>> thiago.macie...@intel.com for more information.
>>
>> Cheers,
>>
>> 2016-05-30 10:41 GMT+02:00 Oleg Hahm <oliver.h...@inria.fr>:
>>
>>> Hi!
>>>
>>> On Mon, May 30, 2016 at 09:16:17AM +0200, Baptiste Clenet wrote:
>>> > - Iotivity would be great in RIOT, Soletta project [1] imported it for
>>> > RIOT, I haven't tried it but it seems to work. I think Riot should
>>> have an
>>> > implementation of Iotivity directly in its repo (package) so it will be
>>> > better maintain.
>>>
>>> Very interesting and good to know. I was not aware of this project (and I
>>> think most of the RIOT maintainers weren't either). And yes, for
>>> maintainability a package in RIOT might make sense. We just need a
>>> maintainer
>>> willing to do so. ;-)
>>>
>>> Baptiste, do you know the people behind Soletta?
>>>
>>> Cheers,
>>> Oleg
>>>
>>> --
>>> printk("Entering UltraSMPenguin Mode...\n");
>>> linux-2.2.16/arch/sparc64/kernel/smp.c
>>>
>>> ___
>>> devel mailing list
>>> devel@riot-os.org
>>> https://lists.riot-os.org/mailman/listinfo/devel
>>>
>>>
>>
>>
>> --
>> Baptiste
>>
>> ___
>> 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
>
>


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

Re: [riot-devel] RIOT Vs Iotivity, AllJoyn, Thread

[Baptiste Clenet]

Hi, I correct what I said, Soletta Project is not an implementation of
Iotivity but an implementation of OIC specification (Iotivity too) so
Iotivity and Soletta project can communicate together since they use same
specification.

Intel Open Source is in charge of this project and you can ask
thiago.macie...@intel.com for more information.

Cheers,

2016-05-30 10:41 GMT+02:00 Oleg Hahm <oliver.h...@inria.fr>:

> Hi!
>
> On Mon, May 30, 2016 at 09:16:17AM +0200, Baptiste Clenet wrote:
> > - Iotivity would be great in RIOT, Soletta project [1] imported it for
> > RIOT, I haven't tried it but it seems to work. I think Riot should have
> an
> > implementation of Iotivity directly in its repo (package) so it will be
> > better maintain.
>
> Very interesting and good to know. I was not aware of this project (and I
> think most of the RIOT maintainers weren't either). And yes, for
> maintainability a package in RIOT might make sense. We just need a
> maintainer
> willing to do so. ;-)
>
> Baptiste, do you know the people behind Soletta?
>
> Cheers,
> Oleg
>
> --
> printk("Entering UltraSMPenguin Mode...\n");
> linux-2.2.16/arch/sparc64/kernel/smp.c
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>


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

Re: [riot-devel] RIOT Vs Iotivity, AllJoyn, Thread

[Baptiste Clenet]

What I can answer from my point of view:
- Iotivity would be great in RIOT, Soletta project [1] imported it for
RIOT, I haven't tried it but it seems to work. I think Riot should have an
implementation of Iotivity directly in its repo (package) so it will be
better maintain.
- AllJoyn, I haven't heard about a port to RIOT but is big and I would
better in Iotivity
- Thread is not high level, it is a network stack based on 6Lowpan and
CoAP. You could add Iotivity in top of Thread for instance. Nevertheless,
it would be great to use Thread on RIOT! By the way, Nest has just released
open source  version of Thread weeks ago called openthread [2]. You could
try to add it to RIOT?


[1]https://github.com/solettaproject/soletta
[2] https://github.com/openthread/openthread



2016-05-27 10:13 GMT+02:00 MATTIA ANTONINI <
mattia.antoni...@studenti.unipr.it>:

> Dear  RIOTers ,
> I'm a MSc student and I'm working on RIOT for my thesis. I ask you what is
> the future of RIOT in term of high level protocol like IoTivity, AllJoyn
> and Thread. Is anyone writing a porting of these protocols or is anything
> planned? or, which is the most suitable high level protocol for RIOT? I
> found a thread in this mailing list about this topic, but it is quite old
> and I think something is changed.
> I hope I explained myself well.
> Regards,
> Mattia Antonini
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>


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

Re: [riot-devel] Border-router and multicast

[Baptiste Clenet]

Martine?

2016-05-13 20:45 GMT+02:00 Baptiste Clenet <bapcle...@gmail.com>:
> 2016-05-12 21:03 GMT+02:00 Baptiste Clenet <bapcle...@gmail.com>:
>> Thanks Martine, I will try tomorrow
>>
>> 2016-05-12 14:10 GMT+02:00 Martine Lenders <m...@martine-lenders.eu>:
>>> Hi,
>>>
>>> Ah the problem seems to be that for some reason Linux elects a link-local
>>> address for the ping, which is of course due to the fact, that there is no
>>> global address assigned to the interface and that the hop limit seems to be
>>> set to short (it is 1). So I did the following
>>>
>>> sudo ip route add ff1e::/16 dev tap0 table local  # add routing entry for
>>> ff1e::1
>>> sudo ip addr add affe::dc53:7dff:fe99:516e/64 dev tap0 # add global unicast
>>> address for tap0
>>> ping6 -t 2 ff1e::1 # ping with hop limit 2
>>>
> I did try but ping6 does not receive anything
> Did you do any more set up?
> What is this address dc53:7dff:fe99:516e?
>
> #ip -6 route list table local
> ...
> ff1e::/16 dev tap0  metric 1024
> ...
>
> #ifconfig tap0
> tap0  Link encap:Ethernet  HWaddr 26:C5:07:2F:43:E0
>   inet6 addr: fe80::24c5:7ff:fe2f:43e0/64 Scope:Link
>   inet6 addr: fe80::1/64 Scope:Link
>   inet6 addr: affe::dc53:7dff:fe99:516e/64 Scope:Global
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:58 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:326 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:500
>   RX bytes:4706 (4.5 KiB)  TX bytes:29442 (28.7 KiB)
>
>
>>> Now I get one reply back, and if you add affe::/64 to the fib of the border
>>> router the ethos interface (wasn't able to test that) it should work.
>>>
>>> Cheers,
>>> Martine
>>>
>>>
>>> 2016-05-12 13:34 GMT+02:00 Martine Lenders <m...@martine-lenders.eu>:
>>>>
>>>> Hi Baptiste,
>>>> yeah in that case multicast seems like the best thing to go. But how about
>>>> using an actual global address then: (ff:1e::1 e.g.; 10 flag =
>>>> non-permanent, e scope = global). With the hint by Kaspar I was able to get
>>>> the pings through the interface, but apparently the border router does not
>>>> forward the address.
>>>> Will investigate.
>>>>
>>>> Cheers,
>>>> Martine
>>>>
>>>> 2016-05-12 11:39 GMT+02:00 Baptiste Clenet <bapcle...@gmail.com>:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Martine, what I want:
>>>>> My set up:
>>>>> |Linux + RIOT BORDER ROUTER|
>>>>>
>>>>> |RIOT gnrc_networking A|
>>>>> |RIOT gnrc_networking B|
>>>>> |RIOT gnrc_networking C|
>>>>> |RIOT gnrc_networking D|
>>>>>
>>>>> I run a program on Linux which sends some UDP data to A B C D nodes.
>>>>> I want to use multicast in my program instead of one board by one bard
>>>>> Is it clearer?
>>>>>
>>>>> Cheers,
>>>>>
>>>>> 2016-05-11 21:55 GMT+02:00 Kaspar Schleiser <kas...@schleiser.de>:
>>>>> > Hey,
>>>>> >
>>>>> > On 05/11/2016 09:42 PM, Martine Lenders wrote:
>>>>> >> (2) I'm not sure you add multicast routing entries this way in Linux.
>>>>> >
>>>>> > You don't. If really desired, you have to use the "local" routing
>>>>> > table.
>>>>> >
>>>>> > # ip -6 route list table local
>>>>> >
>>>>> > Kaspar
>>>>> > ___
>>>>> > devel mailing list
>>>>> > devel@riot-os.org
>>>>> > https://lists.riot-os.org/mailman/listinfo/devel
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Baptiste
>>>>> ___
>>>>> 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
>>>
>>
>>
>>
>> --
>> Baptiste
>
>
>
> --
> Baptiste



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

Re: [riot-devel] Border-router and multicast

[Baptiste Clenet]

2016-05-12 21:03 GMT+02:00 Baptiste Clenet <bapcle...@gmail.com>:
> Thanks Martine, I will try tomorrow
>
> 2016-05-12 14:10 GMT+02:00 Martine Lenders <m...@martine-lenders.eu>:
>> Hi,
>>
>> Ah the problem seems to be that for some reason Linux elects a link-local
>> address for the ping, which is of course due to the fact, that there is no
>> global address assigned to the interface and that the hop limit seems to be
>> set to short (it is 1). So I did the following
>>
>> sudo ip route add ff1e::/16 dev tap0 table local  # add routing entry for
>> ff1e::1
>> sudo ip addr add affe::dc53:7dff:fe99:516e/64 dev tap0 # add global unicast
>> address for tap0
>> ping6 -t 2 ff1e::1 # ping with hop limit 2
>>
I did try but ping6 does not receive anything
Did you do any more set up?
What is this address dc53:7dff:fe99:516e?

#ip -6 route list table local
...
ff1e::/16 dev tap0  metric 1024
...

#ifconfig tap0
tap0  Link encap:Ethernet  HWaddr 26:C5:07:2F:43:E0
  inet6 addr: fe80::24c5:7ff:fe2f:43e0/64 Scope:Link
  inet6 addr: fe80::1/64 Scope:Link
  inet6 addr: affe::dc53:7dff:fe99:516e/64 Scope:Global
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:58 errors:0 dropped:0 overruns:0 frame:0
  TX packets:326 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:500
  RX bytes:4706 (4.5 KiB)  TX bytes:29442 (28.7 KiB)


>> Now I get one reply back, and if you add affe::/64 to the fib of the border
>> router the ethos interface (wasn't able to test that) it should work.
>>
>> Cheers,
>> Martine
>>
>>
>> 2016-05-12 13:34 GMT+02:00 Martine Lenders <m...@martine-lenders.eu>:
>>>
>>> Hi Baptiste,
>>> yeah in that case multicast seems like the best thing to go. But how about
>>> using an actual global address then: (ff:1e::1 e.g.; 10 flag =
>>> non-permanent, e scope = global). With the hint by Kaspar I was able to get
>>> the pings through the interface, but apparently the border router does not
>>> forward the address.
>>> Will investigate.
>>>
>>> Cheers,
>>> Martine
>>>
>>> 2016-05-12 11:39 GMT+02:00 Baptiste Clenet <bapcle...@gmail.com>:
>>>>
>>>> Hi,
>>>>
>>>> Martine, what I want:
>>>> My set up:
>>>> |Linux + RIOT BORDER ROUTER|
>>>>
>>>> |RIOT gnrc_networking A|
>>>> |RIOT gnrc_networking B|
>>>> |RIOT gnrc_networking C|
>>>> |RIOT gnrc_networking D|
>>>>
>>>> I run a program on Linux which sends some UDP data to A B C D nodes.
>>>> I want to use multicast in my program instead of one board by one bard
>>>> Is it clearer?
>>>>
>>>> Cheers,
>>>>
>>>> 2016-05-11 21:55 GMT+02:00 Kaspar Schleiser <kas...@schleiser.de>:
>>>> > Hey,
>>>> >
>>>> > On 05/11/2016 09:42 PM, Martine Lenders wrote:
>>>> >> (2) I'm not sure you add multicast routing entries this way in Linux.
>>>> >
>>>> > You don't. If really desired, you have to use the "local" routing
>>>> > table.
>>>> >
>>>> > # ip -6 route list table local
>>>> >
>>>> > Kaspar
>>>> > ___
>>>> > devel mailing list
>>>> > devel@riot-os.org
>>>> > https://lists.riot-os.org/mailman/listinfo/devel
>>>>
>>>>
>>>>
>>>> --
>>>> Baptiste
>>>> ___
>>>> 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
>>
>
>
>
> --
> Baptiste



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

Re: [riot-devel] Border-router and multicast

[Baptiste Clenet]

Thanks Martine, I will try tomorrow

2016-05-12 14:10 GMT+02:00 Martine Lenders <m...@martine-lenders.eu>:
> Hi,
>
> Ah the problem seems to be that for some reason Linux elects a link-local
> address for the ping, which is of course due to the fact, that there is no
> global address assigned to the interface and that the hop limit seems to be
> set to short (it is 1). So I did the following
>
> sudo ip route add ff1e::/16 dev tap0 table local  # add routing entry for
> ff1e::1
> sudo ip addr add affe::dc53:7dff:fe99:516e/64 dev tap0 # add global unicast
> address for tap0
> ping6 -t 2 ff1e::1 # ping with hop limit 2
>
> Now I get one reply back, and if you add affe::/64 to the fib of the border
> router the ethos interface (wasn't able to test that) it should work.
>
> Cheers,
> Martine
>
>
> 2016-05-12 13:34 GMT+02:00 Martine Lenders <m...@martine-lenders.eu>:
>>
>> Hi Baptiste,
>> yeah in that case multicast seems like the best thing to go. But how about
>> using an actual global address then: (ff:1e::1 e.g.; 10 flag =
>> non-permanent, e scope = global). With the hint by Kaspar I was able to get
>> the pings through the interface, but apparently the border router does not
>> forward the address.
>> Will investigate.
>>
>> Cheers,
>> Martine
>>
>> 2016-05-12 11:39 GMT+02:00 Baptiste Clenet <bapcle...@gmail.com>:
>>>
>>> Hi,
>>>
>>> Martine, what I want:
>>> My set up:
>>> |Linux + RIOT BORDER ROUTER|
>>>
>>> |RIOT gnrc_networking A|
>>> |RIOT gnrc_networking B|
>>> |RIOT gnrc_networking C|
>>> |RIOT gnrc_networking D|
>>>
>>> I run a program on Linux which sends some UDP data to A B C D nodes.
>>> I want to use multicast in my program instead of one board by one bard
>>> Is it clearer?
>>>
>>> Cheers,
>>>
>>> 2016-05-11 21:55 GMT+02:00 Kaspar Schleiser <kas...@schleiser.de>:
>>> > Hey,
>>> >
>>> > On 05/11/2016 09:42 PM, Martine Lenders wrote:
>>> >> (2) I'm not sure you add multicast routing entries this way in Linux.
>>> >
>>> > You don't. If really desired, you have to use the "local" routing
>>> > table.
>>> >
>>> > # ip -6 route list table local
>>> >
>>> > Kaspar
>>> > ___
>>> > devel mailing list
>>> > devel@riot-os.org
>>> > https://lists.riot-os.org/mailman/listinfo/devel
>>>
>>>
>>>
>>> --
>>> Baptiste
>>> ___
>>> 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
>



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

[riot-devel] SAMR21: Event

[Baptiste Clenet]

Hi,

Has anyone tried to use Event peripheral on samr21?
p401/1204
http://www.mouser.com/ds/2/36/Atmel-42223-SAM-R21_Datasheet-604417.pdf

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

Re: [riot-devel] Border-router and multicast

[Baptiste Clenet]

Thanks Alex for your answer.

2016-05-09 19:07 GMT+02:00 Alexander Aring <alex.ar...@gmail.com>:
> Hi,
>
> On Mon, May 09, 2016 at 06:20:48PM +0200, Baptiste Clenet wrote:
>> 2016-05-09 16:44 GMT+02:00 Alexander Aring <alex.ar...@gmail.com>:
>> > On Mon, May 09, 2016 at 04:24:34PM +0200, Baptiste Clenet wrote:
>> >> Hi Martine,
>> >> Thank you for the answer.
>> >> Ok ff04::1 is also a multicast address so I add it to every board with
>> >> gnrc_networking and I should be able to ping them with this multicast
>> >> address.
>> >> Shouldn't I use:
>> >> ifconfig 7 add multicast ff04::1
>> >> ?
>> >>
>> >> I'm missing something here, could give me an explanation please:
>> >> Before, I had a transceiver plugged on my linux so I was able to ping
>> >> my board directly using fe80::address so I was able to use the local
>> >> multicast address ff02::1, now that I use border router, I'm using a
>> >> prefix 2001::db8 (why? and why documentation prefix?) Why can't I use
>> >> fe80 as before?
>> >
>> > because link-local ff80::/10 will not be routed, between lowpan and
>> > ethernet interface, so far I know.
>>
>> ff80? You meant fe80? I was able to do ping with fe80 and lowpan0.
>
> Sorry, I think I misunderstood here something completely.
>
> Your setup what is it?
>
> Linux (802.15.4/6LoWPAN) <-> RIOT
>
I used this and I was able to ping6 -I lowpan0 fe80:: but now I use second one

> or
>
> Linux -> TAP (ethernet) <-> RIOT BORDER ROUTER <-> RIOT

Now my setup is like this, yes and so what you explain make sense for
the RIOT border router, they do what you explain but with RIOT instead
of Linux :)

My last question is how to send multicast information from Linux to my
local network? What Martine tell me to try did not work

>
> You say something with lowpan0 then I think it's the first one, but I am
> not sure now and confused. :-)
>
> It's a important information, if it's the second one then better
> completely ignore what I said before, because I don't know how this
> works exactly.
>
> - Alex
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel



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

Re: [riot-devel] Border-router and multicast

[Baptiste Clenet]

Martine, I added ifconfig 7 add ff04::1 to board B and I couldn't ping
f04::1 from Linux.
Any other solution?

2016-05-09 18:20 GMT+02:00 Baptiste Clenet <bapcle...@gmail.com>:
> 2016-05-09 16:44 GMT+02:00 Alexander Aring <alex.ar...@gmail.com>:
>> On Mon, May 09, 2016 at 04:24:34PM +0200, Baptiste Clenet wrote:
>>> Hi Martine,
>>> Thank you for the answer.
>>> Ok ff04::1 is also a multicast address so I add it to every board with
>>> gnrc_networking and I should be able to ping them with this multicast
>>> address.
>>> Shouldn't I use:
>>> ifconfig 7 add multicast ff04::1
>>> ?
>>>
>>> I'm missing something here, could give me an explanation please:
>>> Before, I had a transceiver plugged on my linux so I was able to ping
>>> my board directly using fe80::address so I was able to use the local
>>> multicast address ff02::1, now that I use border router, I'm using a
>>> prefix 2001::db8 (why? and why documentation prefix?) Why can't I use
>>> fe80 as before?
>>
>> because link-local ff80::/10 will not be routed, between lowpan and
>> ethernet interface, so far I know.
>
> ff80? You meant fe80? I was able to do ping with fe80 and lowpan0.
>>
>> I think what you want to have is the npd proxy magic stuff. See [0].
>> Just plugin the ethernet cable and your network will be extended with
>> the 6LoWPAN nodes.
>
> What I want is to understand a bit better how my network works.
> Each node is inside the same PAN (let's say 0x23 by default on RIOT,
> any reason why you choose 0x23?)
> RIOT starts and we affect an link-local address fe80 so every RIOT
> node can ping another one with its link-local address.
> Then comes border-router, border router will tell every node to add a
> new ip with prefix 2001:db8::, is this right?
> How often does border router send a message to other node to say to
> add this new ip address?
> Why 2001:db8 has been chosen? and how should I choose this prefix if I
> want to use my product for commercial use?
>
> Why can't I ping a link-local address from Linux with the border router?
> I've got ten nodes and one linux with a border router, what I want is
> to be able to send messages to each of them (or all of them by
> multicast) at any moment, here I don't understand why I should use
> global address 2001:db8 instead of fe80::
>
> Thanks for your time,
>
>>
>> I need to admit, I tested the manual stuff "ip -6 neigh add proxy ..."
>> only and never the ndppd (btw, there exists some offers to move this
>> handling into kernelspace to make it more easier for users).
>>
>> If you want to test it, please share your expierence.
>>
>> - Alex
>>
>> [0] https://github.com/DanielAdolfsson/ndppd
>> ___
>> devel mailing list
>> devel@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>
>
>
> --
> Baptiste



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

Re: [riot-devel] Border-router and multicast

[Baptiste Clenet]

Hi Martine,
Thank you for the answer.
Ok ff04::1 is also a multicast address so I add it to every board with
gnrc_networking and I should be able to ping them with this multicast
address.
Shouldn't I use:
ifconfig 7 add multicast ff04::1
?

I'm missing something here, could give me an explanation please:
Before, I had a transceiver plugged on my linux so I was able to ping
my board directly using fe80::address so I was able to use the local
multicast address ff02::1, now that I use border router, I'm using a
prefix 2001::db8 (why? and why documentation prefix?) Why can't I use
fe80 as before?
It's not clear in my mind so I'm not sure my question are clear as well.
Thanks

2016-05-09 16:01 GMT+02:00 Martine Lenders <authmille...@gmail.com>:
> Hi Baptiste,
> are you sending from your Linux host or your border router? Because
> `ff02::1` is link-local and should not be forwarded by a border router. Try
> set-up a multicast address with a broader scope than link-local at your
> nodes, e.g.
>
> ifconfig 7 add ff04::1
>
> And try if that works.
>
> Cheers,
> Martine
>
> 2016-05-09 15:44 GMT+02:00 Baptiste Clenet <bapcle...@gmail.com>:
>>
>> Hi,
>>
>> My set up:
>> Linux -> board A (border router) board B (gnrc_networking)
>>
>> I've set up the border router, I can ping board B by changing fe80 by
>> 2001:db8:: inside Linux, but I used the multicast address ff02::1 to
>> send frames to all my nodes and this does not work. How can I do that
>> with the border router? (send frames to all my nodes from linux and
>> not by using the shell of the border router)
>>
>> Cheers,
>>
>> --
>> Baptiste
>> ___
>> 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
>



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

[riot-devel] Border-router and multicast

[Baptiste Clenet]

Hi,

My set up:
Linux -> board A (border router) board B (gnrc_networking)

I've set up the border router, I can ping board B by changing fe80 by
2001:db8:: inside Linux, but I used the multicast address ff02::1 to
send frames to all my nodes and this does not work. How can I do that
with the border router? (send frames to all my nodes from linux and
not by using the shell of the border router)

Cheers,

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

Re: [riot-devel] Add static library to Makefile

[Baptiste Clenet]

Weird, Oleg, did you try to use the library? Could you include .h file
which are inside .a library and use some functions. It was able to
find the library .a but couldn't link with function inside the library

2016-03-30 15:53 GMT+02:00 Oleg Hahm <oliver.h...@inria.fr>:
> Hi Baptiste!
>
> On Wed, Mar 30, 2016 at 09:26:01AM +0200, Baptiste Clenet wrote:
>> I tried to use
>> APPDEPS +=  libexample.a
>> Does not work
>
> Strange, for me it works like charm:
> https://github.com/OlegHahm/miniature-dangerzone/tree/master/static_linked
>
> Cheers,
> Oleg
> --
> /* When we have more time, we can teach the penguin to say
>  * "By your command" or "Activating turbo boost, Michael".
>  */
> linux-2.2.16/arch/sparc/prom/sun4prom.c
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>



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

Re: [riot-devel] Add static library to Makefile

[Baptiste Clenet]

BASELIBS +=  libexample.a makes it work!

2016-03-30 12:04 GMT+02:00 Oleg Hahm <oliver.h...@inria.fr>:
> Hi Kaspar!
>
> On Wed, Mar 30, 2016 at 10:51:03AM +0200, Kaspar Schleiser wrote:
>> On 03/30/2016 09:26 AM, Baptiste Clenet wrote:
>> > I tried to use
>> > APPDEPS +=  libexample.a
>> > Does not work
>>
>> Try copying it into the bin/$BOARD folder, then add
>> "USEMODULE += libexample" to your makefile.
>
> That sounds more like a workaround since you would have to copy it again after
> every `make clean`. IMO APPDEPS should fit. Will investigate, why it doesn't
> work.
>
> Cheers,
> Oleg
> --
> printk (KERN_DEBUG "Somebody wants the port\n");
> linux-2.6.6/drivers/parport/parport_pc.c
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>



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

Re: [riot-devel] Add static library to Makefile

[Baptiste Clenet]

I tried to use
APPDEPS +=  libexample.a
Does not work

2016-03-30 9:23 GMT+02:00 Baptiste Clenet <bapcle...@gmail.com>:
> Hi,
>
> I would like to link libexample.a in my RIOT example, what should I
> add in the Makefile?
>
> Thanks,
>
> --
> Baptiste



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

Re: [riot-devel] Encoder Drivers

[Baptiste Clenet]

Hi,
Could you link the PR please?

Thanks
Baptiste

2016-03-17 13:16 GMT+01:00 Marc :
> Hi,
>
> sure, I'll try to push that in few days.
>
> Marc
>
>
> On 2016-03-17 12:54, Emmanuel Baccelli wrote:
>>
>> Hi Marc,
>>  Could you PR this (as WIP, if needed)?
>>  Would be great.
>>  Cheers,
>>  Emmanuel
>>
>> On Mar 17, 2016 12:30 PM, "Marc"  wrote:
>>
>>> On 2016-03-17 11:54, Loïc Dauphin wrote:
>>> Le 17/03/2016 11:12, Marc a écrit :
>>> No, it's not in the repository, but I can make it available for you
>>> to
>>> test. It is still in a Q state.
>>>
>>> Yes, it can be interesting. For stm32f4 ?
>>
>>
>>  I've been using it on lm4f120, but it's not specific to any hw... It
>> only uses 2 gpio with interrupt.
>>
>>  Marc
>>  ___
>>  devel mailing list
>>  devel@riot-os.org
>>  https://lists.riot-os.org/mailman/listinfo/devel [1]
>>
>>
>> Links:
>> --
>> [1] https://lists.riot-os.org/mailman/listinfo/devel
>>
>> ___
>> devel mailing list
>> devel@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel



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

Re: [riot-devel] RIOT: Production ready?

[Baptiste Clenet]

Let's say that the production-ready RIOT could be announced for the
next release (when network bugs will be solved) for 6LoWPAN-CoAP +
SAUL stack.

Thanks for your answer Martine.

2016-03-09 15:12 GMT+01:00 Martine Lenders <authmille...@gmail.com>:
> Hi,
>
> apart from a few known bugs (and required API changes in the lower to
> mid-high levels) in the network stack we still have, I would give the
> (optimistic) answer that RIOT is production-ready. However, this
> evaluation only refers to a 6LoWPAN-CoAP + SAUL stack, as the full
> stack demos we run a few weeks ago were quite successful to my
> knowledge. Other popular features like e.g. MQTT(-SN) are still in
> development or not even touched upon currently. This is however my
> personal opinion and maybe does not reflect the opinion of the
> majority of the community. Also, some user-level APIs for CoAP (in the
> spirit of "I want to run a CoAP server on this port which publishes
> these actuators/sensors" in less then 10 lines) might be something
> that a client wants to see.
>
> Cheers,
> Martine
>
> 2016-03-09 15:02 GMT+01:00 Baptiste Clenet <bapcle...@gmail.com>:
>> Hi,
>>
>> Do you think that RIOT is production-ready? What is still missing
>> according to you to run RIOT on an IOT device in production?
>>
>> Cheers,
>>
>> --
>> Baptiste
>> ___
>> 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



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

[riot-devel] RIOT: Production ready?

[Baptiste Clenet]

Hi,

Do you think that RIOT is production-ready? What is still missing
according to you to run RIOT on an IOT device in production?

Cheers,

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

Re: [riot-devel] Bridge border router and 6LowPan interfaces

[Baptiste Clenet]

@Kaspar, @Daniel?
I think I'm close to make it work but I think I miss something about
bridge and network here.

2016-03-07 17:19 GMT+01:00 Baptiste Clenet <bapcle...@gmail.com>:
> @kaspar, @Daniel I'm goint to try to sum up:
>
> Node A (border router on samr21):
> Iface 5: inet6 addr: fe80::585a:4b52:7476:b996
>> ifconfig 6 add affe::2(Is that necessary then?)
>> ncache add 6 affe::1
>> ifconfig 6 add dead::585a:4b52:7476:b996
>
> 2016-03-07 17:10:09,884 - INFO # > ifconfig
> 2016-03-07 17:10:09,889 - INFO # Iface  5   HWaddr: 39:96  Channel: 26
>  Page: 0  NID: 0x23
> 2016-03-07 17:10:09,894 - INFO #Long HWaddr: 
> 5a:5a:4b:52:74:76:b9:96
> 2016-03-07 17:10:09,903 - INFO #TX-Power: 0dBm  State:
> IDLE  max. Retrans.: 3  CSMA Retries: 4
> 2016-03-07 17:10:09,913 - INFO #AUTOACK  CSMA  MTU:1280
> HL:64  6LO  RTR  IPHC
> 2016-03-07 17:10:09,916 - INFO #Source address length: 8
> 2016-03-07 17:10:09,918 - INFO #Link type: wireless
> 2016-03-07 17:10:09,924 - INFO #inet6 addr: ff02::1/128
> scope: local [multicast]
> 2016-03-07 17:10:09,931 - INFO #inet6 addr:
> fe80::585a:4b52:7476:b996/64  scope: local
> 2016-03-07 17:10:09,936 - INFO #inet6 addr:
> ff02::1:ff76:b996/128  scope: local [multicast]
> 2016-03-07 17:10:09,938 - INFO # Iface  6
> 2016-03-07 17:10:09,939 - INFO #
> 2016-03-07 17:10:09,943 - INFO #MTU:1280  HL:64  RTR  RTR_ADV
> 2016-03-07 17:10:09,945 - INFO #Link type: wired
> 2016-03-07 17:10:09,951 - INFO #inet6 addr: ff02::1/128
> scope: local [multicast]
> 2016-03-07 17:10:09,956 - INFO #inet6 addr: ff02::2/128
> scope: local [multicast]
> 2016-03-07 17:10:09,962 - INFO #inet6 addr:
> dead::585a:4b52:7476:b996/64  scope: global
> 2016-03-07 17:10:09,969 - INFO #inet6 addr:
> ff02::1:ff00:2/128  scope: local [multicast]
> 2016-03-07 17:10:09,974 - INFO #inet6 addr:
> ff02::1:ff76:b996/128  scope: local [multicast]
> 2016-03-07 17:10:09,978 - INFO #inet6 addr: affe::2/64
> scope: global
>
>
>
> Node B (gnrc_networking on samr21):
> 2016-03-07 17:09:28,005 - INFO # > ifconfig
> 2016-03-07 17:09:28,010 - INFO # Iface  7   HWaddr: 52:be  Channel: 26
>  Page: 0  NID: 0x23
> 2016-03-07 17:09:28,014 - INFO #Long HWaddr: 
> 5a:5a:45:5f:0d:d7:52:be
> 2016-03-07 17:09:28,021 - INFO #TX-Power: 0dBm  State:
> IDLE  max. Retrans.: 3  CSMA Retries: 4
> 2016-03-07 17:09:28,029 - INFO #AUTOACK  CSMA  MTU:1280
> HL:64  6LO  RTR  IPHC
> 2016-03-07 17:09:28,031 - INFO #Source address length: 8
> 2016-03-07 17:09:28,032 - INFO #Link type: wireless
> 2016-03-07 17:09:28,037 - INFO #inet6 addr: ff02::1/128
> scope: local [multicast]
> 2016-03-07 17:09:28,043 - INFO #inet6 addr:
> fe80::585a:455f:dd7:52be/64  scope: local
> 2016-03-07 17:09:28,050 - INFO #inet6 addr:
> ff02::1:ffd7:52be/128  scope: local [multicast]
>
>
>
> Linux:
> /RIOT/dist/tools/tunslip$ sudo ./tunslip6 affe::1/64 -t tun0 -s /dev/ttyUSB0
> SLIP started on ``/dev/ttyUSB0''
> opened tun device ``/dev/tun0''
> ifconfig tun0 inet `hostname` up
> ifconfig tun0 add affe::1/64
> ifconfig tun0 add fe80::0:0:0:1/64
> ifconfig tun0
>
> tun0  Link encap:UNSPEC  HWaddr
> 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
>   inet adr:127.0.1.1  P-t-P:127.0.1.1  Masque:255.255.255.255
>   adr inet6: fe80::1/64 Scope:Lien
>   adr inet6: affe::1/64 Scope:Global
>   UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
>   Packets reçus:0 erreurs:0 :0 overruns:0 frame:0
>   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 lg file transmission:500
>   Octets reçus:0 (0.0 B) Octets transmis:0 (0.0 B)
>
> Instead of adding a route, I want to try to ping beforehand:
> ping6 -I tun0 affe::2ACK
> ping6 -I tun0 affe::585a:455f:dd7:52be NACK
> ping6 -I tun0 dead::585a:455f:dd7:52be   NACK
> ping6 -I tun0 fe80::585a:455f:dd7:52beNACK
>
> Which one should be ok?
>
> 2016-03-07 11:48 GMT+01:00 Kaspar Schleiser <kas...@schleiser.de>:
>> Hey,
>>
>> On 03/07/2016 11:29 AM, Daniel Krebs wrote:
>>> I guess what you're trying to achieve is the common use case of the
>>> border router AFAIK.
>>
>> Yes. Guess we need more documentation / FAQ for this.
>>
>>> Did you try to setup an "affe::x"-style address on
>>> node B? I'm still not too familiar with IPv6 

Re: [riot-devel] Bridge border router and 6LowPan interfaces

[Baptiste Clenet]

@kaspar, @Daniel I'm goint to try to sum up:

Node A (border router on samr21):
Iface 5: inet6 addr: fe80::585a:4b52:7476:b996
> ifconfig 6 add affe::2(Is that necessary then?)
> ncache add 6 affe::1
> ifconfig 6 add dead::585a:4b52:7476:b996

2016-03-07 17:10:09,884 - INFO # > ifconfig
2016-03-07 17:10:09,889 - INFO # Iface  5   HWaddr: 39:96  Channel: 26
 Page: 0  NID: 0x23
2016-03-07 17:10:09,894 - INFO #Long HWaddr: 5a:5a:4b:52:74:76:b9:96
2016-03-07 17:10:09,903 - INFO #TX-Power: 0dBm  State:
IDLE  max. Retrans.: 3  CSMA Retries: 4
2016-03-07 17:10:09,913 - INFO #AUTOACK  CSMA  MTU:1280
HL:64  6LO  RTR  IPHC
2016-03-07 17:10:09,916 - INFO #Source address length: 8
2016-03-07 17:10:09,918 - INFO #Link type: wireless
2016-03-07 17:10:09,924 - INFO #inet6 addr: ff02::1/128
scope: local [multicast]
2016-03-07 17:10:09,931 - INFO #inet6 addr:
fe80::585a:4b52:7476:b996/64  scope: local
2016-03-07 17:10:09,936 - INFO #inet6 addr:
ff02::1:ff76:b996/128  scope: local [multicast]
2016-03-07 17:10:09,938 - INFO # Iface  6
2016-03-07 17:10:09,939 - INFO #
2016-03-07 17:10:09,943 - INFO #MTU:1280  HL:64  RTR  RTR_ADV
2016-03-07 17:10:09,945 - INFO #Link type: wired
2016-03-07 17:10:09,951 - INFO #inet6 addr: ff02::1/128
scope: local [multicast]
2016-03-07 17:10:09,956 - INFO #inet6 addr: ff02::2/128
scope: local [multicast]
2016-03-07 17:10:09,962 - INFO #inet6 addr:
dead::585a:4b52:7476:b996/64  scope: global
2016-03-07 17:10:09,969 - INFO #inet6 addr:
ff02::1:ff00:2/128  scope: local [multicast]
2016-03-07 17:10:09,974 - INFO #inet6 addr:
ff02::1:ff76:b996/128  scope: local [multicast]
2016-03-07 17:10:09,978 - INFO #inet6 addr: affe::2/64
scope: global



Node B (gnrc_networking on samr21):
2016-03-07 17:09:28,005 - INFO # > ifconfig
2016-03-07 17:09:28,010 - INFO # Iface  7   HWaddr: 52:be  Channel: 26
 Page: 0  NID: 0x23
2016-03-07 17:09:28,014 - INFO #Long HWaddr: 5a:5a:45:5f:0d:d7:52:be
2016-03-07 17:09:28,021 - INFO #TX-Power: 0dBm  State:
IDLE  max. Retrans.: 3  CSMA Retries: 4
2016-03-07 17:09:28,029 - INFO #AUTOACK  CSMA  MTU:1280
HL:64  6LO  RTR  IPHC
2016-03-07 17:09:28,031 - INFO #Source address length: 8
2016-03-07 17:09:28,032 - INFO #Link type: wireless
2016-03-07 17:09:28,037 - INFO #inet6 addr: ff02::1/128
scope: local [multicast]
2016-03-07 17:09:28,043 - INFO #inet6 addr:
fe80::585a:455f:dd7:52be/64  scope: local
2016-03-07 17:09:28,050 - INFO #inet6 addr:
ff02::1:ffd7:52be/128  scope: local [multicast]



Linux:
/RIOT/dist/tools/tunslip$ sudo ./tunslip6 affe::1/64 -t tun0 -s /dev/ttyUSB0
SLIP started on ``/dev/ttyUSB0''
opened tun device ``/dev/tun0''
ifconfig tun0 inet `hostname` up
ifconfig tun0 add affe::1/64
ifconfig tun0 add fe80::0:0:0:1/64
ifconfig tun0

tun0  Link encap:UNSPEC  HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
  inet adr:127.0.1.1  P-t-P:127.0.1.1  Masque:255.255.255.255
  adr inet6: fe80::1/64 Scope:Lien
  adr inet6: affe::1/64 Scope:Global
  UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
  Packets reçus:0 erreurs:0 :0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 lg file transmission:500
  Octets reçus:0 (0.0 B) Octets transmis:0 (0.0 B)

Instead of adding a route, I want to try to ping beforehand:
ping6 -I tun0 affe::2ACK
ping6 -I tun0 affe::585a:455f:dd7:52be NACK
ping6 -I tun0 dead::585a:455f:dd7:52be   NACK
ping6 -I tun0 fe80::585a:455f:dd7:52beNACK

Which one should be ok?

2016-03-07 11:48 GMT+01:00 Kaspar Schleiser :
> Hey,
>
> On 03/07/2016 11:29 AM, Daniel Krebs wrote:
>> I guess what you're trying to achieve is the common use case of the
>> border router AFAIK.
>
> Yes. Guess we need more documentation / FAQ for this.
>
>> Did you try to setup an "affe::x"-style address on
>> node B? I'm still not too familiar with IPv6 terms, but I think that
>> those fe80:: addresses are in a local scope and therefore not forwarded
>> by a router, while the "affe::x" addresses are global.
>>
>> Node B:
>> # ifconfig 7 add affe::3
>> # udp server start 
> No, that won't work. 6lowpan expects addresses to be based on a node's
> eui64.
>
> @babtiste, add address "dead::" to node A 6lowpan interface.
>  must be the same as that interfaces link-local address,
> eg., fe80::aa:bb:cc:dd:ee:ff -> deaf::aa:bb:cc:dd:ee:ff.
>
> Then, on linux, you have to add a route to dead::/64 via node a's affe::
> address (from the tun interface).
>
> Kaspar
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Bridge border router and 6LowPan interfaces

[Baptiste Clenet]

I want to be able to send a packet from LINUX to board B through board
A (border router)
LINUX -> A -> B

and then receive the answer from B to LINUX through A
LINUX <- A <- B

So I will be able to open an UDP socket on my LINUX on the interface
tun which will receive packets from board B.
Does it make sense?

Baptiste

2016-03-07 10:52 GMT+01:00 Kaspar Schleiser <kas...@schleiser.de>:
> Hey,
>
> On 03/07/2016 08:43 AM, Baptiste Clenet wrote:
>> @Cenk (or anyone), could you give me some help on that please?
>
> Just so I understand correctly: you basically want to sniff traffic that
> passes between the two samr21 on linux via the tun interface?
> There's currently no support for that.
>
> Do you have a third samr21? We usually set that up as sniffer.
>
> Kapsar
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel



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

Re: [riot-devel] Bridge border router and 6LowPan interfaces

[Baptiste Clenet]

From LINUX:
@/RIOT-2016.02/examples/gnrc_networking$ ping6 -I tun0 affe::2
PING affe::2(affe::2) from affe::1 tun0: 56 data bytes
64 bytes from affe::2: icmp_seq=1 ttl=64 time=974 ms
64 bytes from affe::2: icmp_seq=2 ttl=64 time=21.7 ms
64 bytes from affe::2: icmp_seq=3 ttl=64 time=22.3 ms
^C
--- affe::2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 21.747/339.440/974.234/448.867 ms

2016-03-04 19:34 GMT+01:00 Jose Alamos :
> Hi Bernhard:
>
> I think power consumption is a good reason for having a RIOT border router.
>
> I worked in some WSNs that measured the isotherm level of snow in a mountain
> (data sent via GPRS), it was not easy to get there and you don't have power
> lines. So you need batteries.
>
> Considering you are using batteries as a power supply, a Zolertia Z1 (for
> example) consumes 20-25 mA in average, and 200uA in idle. A PI Zero consumes
> 140 mA in average, and 65mA while in idle.
>
> If you send data every 5 minutes (4:50 minutes in idle, wake up and 10
> seconds for sending data) from a Pi Zero, while in idle you are using more
> than 300 times the power consumption of the Z1. You get a major improvement
> in battery life using a node as a border router.
>
>
> Also if you are measuring a critical process, you could need redundant
> border routers to make sure that data is sent. In that case it's nice to
> have the same hardware for border routers and nodes (you just need to add a
> GPRS module to a node and with "a few tweaks" is a new border router).
>
> Cheers!
>
>
>
>
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>



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

Re: [riot-devel] Bridge border router and 6LowPan interfaces

[Baptiste Clenet]

Also I can ping from BOARD A to B and reverse
I tired on LINUX: netcat -6u affe::585a:455f:dd7:52be  but it
doesn't seem to go through tun0, may I should reroute something?

2016-03-04 18:54 GMT+01:00 Baptiste Clenet <bapcle...@gmail.com>:
> May I come back to my problem? :-)
>
> @Cenk, I read the discussion but it still doesn't seem to work.
> I want LINUX to send UDP to BOARD B via BOARD A (border router)
> Here is my setup:
>
> Linux computer:
> @RIOT-2016.02/dist/tools/tunslip$ sudo ./tunslip6 affe::1/64 -t tun0
> -s /dev/ttyUSB0
> SLIP started on ``/dev/ttyUSB0''
> opened tun device ``/dev/tun0''
> ifconfig tun0 inet `hostname` up
> ifconfig tun0 add affe::1/64
> ifconfig tun0 add fe80::0:0:0:1/64
> ifconfig tun0
>
> tun0  Link encap:UNSPEC  HWaddr
> 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
>   inet adr:127.0.1.1  P-t-P:127.0.1.1  Masque:255.255.255.255
>   adr inet6: fe80::1/64 Scope:Lien
>   adr inet6: affe::1/64 Scope:Global
>   UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
>   Packets reçus:0 erreurs:0 :0 overruns:0 frame:0
>   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 lg file transmission:500
>   Octets reçus:0 (0.0 B) Octets transmis:0 (0.0 B)
>
> BOARD A:
> @/RIOT-2016.02/examples/gnrc_border_router$ make term BOARD=samr21-xpro
> /RIOT-2016.02/dist/tools/pyterm/pyterm -p "/dev/ttyACM0" -b "115200"
> 2016-03-04 17:36:05,543 - INFO # Connect to serial port /dev/ttyACM0
> Welcome to pyterm!
> Type '/exit' to exit.
> 2016-03-04 17:36:12,125 - INFO # main(): This is RIOT! (Version:
> 2016.03-devel-615-ga6fae-ubuntu)
> 2016-03-04 17:36:12,128 - INFO # RIOT border router example application
> 2016-03-04 17:36:12,131 - INFO # All up, running the shell now
> help
> 2016-03-04 17:37:05,971 - INFO # > help
> 2016-03-04 17:37:05,974 - INFO # Command  Description
> 2016-03-04 17:37:05,978 - INFO # ---
> 2016-03-04 17:37:05,983 - INFO # udp  send data over
> UDP and listen on UDP ports
> 2016-03-04 17:37:05,985 - INFO # reboot   Reboot the node
> 2016-03-04 17:37:05,990 - INFO # ps   Prints
> information about running threads.
> 2016-03-04 17:37:05,993 - INFO # ping6Ping via ICMPv6
> 2016-03-04 17:37:05,997 - INFO # random_init  initializes the PRNG
> 2016-03-04 17:37:06,002 - INFO # random_get   returns 32 bit
> of pseudo randomness
> 2016-03-04 17:37:06,016 - INFO # ifconfig Configure
> network interfaces
> 2016-03-04 17:37:06,017 - INFO # txtsnd   send raw data
> 2016-03-04 17:37:06,019 - INFO # fibroute Manipulate the
> FIB (info: 'fibroute [add|del]')
> 2016-03-04 17:37:06,027 - INFO # ncache   manage neighbor
> cache by hand
> 2016-03-04 17:37:06,029 - INFO # routers  IPv6 default router list
> 2016-03-04 17:37:06,030 - INFO # 6ctx 6LoWPAN context
> configuration tool
> ifconfig 6 add affe::2
> 2016-03-04 17:37:20,786 - INFO # > ifconfig 6 add affe::2
> 2016-03-04 17:37:20,790 - INFO # success: added affe::2/64 to interface 6
> ncache add 6 affe::1
> 2016-03-04 17:37:26,155 - INFO # > ncache add 6 affe::1
> 2016-03-04 17:37:26,159 - INFO # success: added IPv6 address affe::1
> to neighbor cache
> ifconfig
> 2016-03-04 18:40:03,163 - INFO # > ifconfig
> 2016-03-04 18:40:03,168 - INFO # Iface  5   HWaddr: 39:96  Channel: 26
>  Page: 0  NID: 0x23
> 2016-03-04 18:40:03,172 - INFO #Long HWaddr: 
> 5a:5a:4b:52:74:76:b9:96
> 2016-03-04 18:40:03,179 - INFO #TX-Power: 0dBm  State:
> IDLE  max. Retrans.: 3  CSMA Retries: 4
> 2016-03-04 18:40:03,192 - INFO #AUTOACK  CSMA  MTU:1280
> HL:64  6LO  RTR  IPHC
> 2016-03-04 18:40:03,193 - INFO #Source address length: 8
> 2016-03-04 18:40:03,194 - INFO #Link type: wireless
> 2016-03-04 18:40:03,205 - INFO #inet6 addr: ff02::1/128
> scope: local [multicast]
> 2016-03-04 18:40:03,206 - INFO #inet6 addr:
> fe80::585a:4b52:7476:b996/64  scope: local
> 2016-03-04 18:40:03,208 - INFO #inet6 addr:
> ff02::1:ff76:b996/128  scope: local [multicast]
> 2016-03-04 18:40:03,209 - INFO #
> 2016-03-04 18:40:03,211 - INFO # Iface  6
> 2016-03-04 18:40:03,212 - INFO #
> 2016-03-04 18:40:03,223 - INFO #MTU:1280  HL:64  RTR  RTR_ADV
> 2016-03-04 18:40:03,226 - INFO #Link type: wired
> 2016-03-04 18:40:03,227 - INFO #inet6 addr: ff02::1/128
> scope: local [multicast]
> 2016-03-04 18:40:03,229 - INFO #inet6 a

Re: [riot-devel] Bridge border router and 6LowPan interfaces

[Baptiste Clenet]

May I come back to my problem? :-)

@Cenk, I read the discussion but it still doesn't seem to work.
I want LINUX to send UDP to BOARD B via BOARD A (border router)
Here is my setup:

Linux computer:
@RIOT-2016.02/dist/tools/tunslip$ sudo ./tunslip6 affe::1/64 -t tun0
-s /dev/ttyUSB0
SLIP started on ``/dev/ttyUSB0''
opened tun device ``/dev/tun0''
ifconfig tun0 inet `hostname` up
ifconfig tun0 add affe::1/64
ifconfig tun0 add fe80::0:0:0:1/64
ifconfig tun0

tun0  Link encap:UNSPEC  HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
  inet adr:127.0.1.1  P-t-P:127.0.1.1  Masque:255.255.255.255
  adr inet6: fe80::1/64 Scope:Lien
  adr inet6: affe::1/64 Scope:Global
  UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
  Packets reçus:0 erreurs:0 :0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 lg file transmission:500
  Octets reçus:0 (0.0 B) Octets transmis:0 (0.0 B)

BOARD A:
@/RIOT-2016.02/examples/gnrc_border_router$ make term BOARD=samr21-xpro
/RIOT-2016.02/dist/tools/pyterm/pyterm -p "/dev/ttyACM0" -b "115200"
2016-03-04 17:36:05,543 - INFO # Connect to serial port /dev/ttyACM0
Welcome to pyterm!
Type '/exit' to exit.
2016-03-04 17:36:12,125 - INFO # main(): This is RIOT! (Version:
2016.03-devel-615-ga6fae-ubuntu)
2016-03-04 17:36:12,128 - INFO # RIOT border router example application
2016-03-04 17:36:12,131 - INFO # All up, running the shell now
help
2016-03-04 17:37:05,971 - INFO # > help
2016-03-04 17:37:05,974 - INFO # Command  Description
2016-03-04 17:37:05,978 - INFO # ---
2016-03-04 17:37:05,983 - INFO # udp  send data over
UDP and listen on UDP ports
2016-03-04 17:37:05,985 - INFO # reboot   Reboot the node
2016-03-04 17:37:05,990 - INFO # ps   Prints
information about running threads.
2016-03-04 17:37:05,993 - INFO # ping6Ping via ICMPv6
2016-03-04 17:37:05,997 - INFO # random_init  initializes the PRNG
2016-03-04 17:37:06,002 - INFO # random_get   returns 32 bit
of pseudo randomness
2016-03-04 17:37:06,016 - INFO # ifconfig Configure
network interfaces
2016-03-04 17:37:06,017 - INFO # txtsnd   send raw data
2016-03-04 17:37:06,019 - INFO # fibroute Manipulate the
FIB (info: 'fibroute [add|del]')
2016-03-04 17:37:06,027 - INFO # ncache   manage neighbor
cache by hand
2016-03-04 17:37:06,029 - INFO # routers  IPv6 default router list
2016-03-04 17:37:06,030 - INFO # 6ctx 6LoWPAN context
configuration tool
ifconfig 6 add affe::2
2016-03-04 17:37:20,786 - INFO # > ifconfig 6 add affe::2
2016-03-04 17:37:20,790 - INFO # success: added affe::2/64 to interface 6
ncache add 6 affe::1
2016-03-04 17:37:26,155 - INFO # > ncache add 6 affe::1
2016-03-04 17:37:26,159 - INFO # success: added IPv6 address affe::1
to neighbor cache
ifconfig
2016-03-04 18:40:03,163 - INFO # > ifconfig
2016-03-04 18:40:03,168 - INFO # Iface  5   HWaddr: 39:96  Channel: 26
 Page: 0  NID: 0x23
2016-03-04 18:40:03,172 - INFO #Long HWaddr: 5a:5a:4b:52:74:76:b9:96
2016-03-04 18:40:03,179 - INFO #TX-Power: 0dBm  State:
IDLE  max. Retrans.: 3  CSMA Retries: 4
2016-03-04 18:40:03,192 - INFO #AUTOACK  CSMA  MTU:1280
HL:64  6LO  RTR  IPHC
2016-03-04 18:40:03,193 - INFO #Source address length: 8
2016-03-04 18:40:03,194 - INFO #Link type: wireless
2016-03-04 18:40:03,205 - INFO #inet6 addr: ff02::1/128
scope: local [multicast]
2016-03-04 18:40:03,206 - INFO #inet6 addr:
fe80::585a:4b52:7476:b996/64  scope: local
2016-03-04 18:40:03,208 - INFO #inet6 addr:
ff02::1:ff76:b996/128  scope: local [multicast]
2016-03-04 18:40:03,209 - INFO #
2016-03-04 18:40:03,211 - INFO # Iface  6
2016-03-04 18:40:03,212 - INFO #
2016-03-04 18:40:03,223 - INFO #MTU:1280  HL:64  RTR  RTR_ADV
2016-03-04 18:40:03,226 - INFO #Link type: wired
2016-03-04 18:40:03,227 - INFO #inet6 addr: ff02::1/128
scope: local [multicast]
2016-03-04 18:40:03,229 - INFO #inet6 addr: ff02::2/128
scope: local [multicast]
2016-03-04 18:40:03,232 - INFO #inet6 addr: affe::2/64
scope: global
2016-03-04 18:40:03,238 - INFO #inet6 addr:
ff02::1:ff00:2/128  scope: local [multicast]
2016-03-04 18:40:03,239 - INFO #
ping6 affe::1
2016-03-04 18:41:33,960 - INFO # > ping6 affe::1
2016-03-04 18:41:33,979 - INFO # 12 bytes from affe::1: id=85 seq=1
hop limit=64 time = 12.285 ms
2016-03-04 18:41:34,998 - INFO # 12 bytes from affe::1: id=85 seq=2
hop limit=64 time = 12.799 ms
2016-03-04 18:41:36,019 - INFO # 12 bytes from affe::1: id=85 seq=3
hop limit=64 time = 12.902 ms
2016-03-04 18:41:36,022 - INFO # --- affe::1 ping statistics ---
2016-03-04 18:41:36,028 - INFO # 3 packets transmitted, 3 received, 0%

Re: [riot-devel] Opinion on ARM mbed

[Baptiste Clenet]

2016-03-04 12:15 GMT+01:00 Ilias Seitanidis <iliasseitani...@gmail.com>:
> Dear all,
> Mbed has a community (of course not like the Riot's one).
> Footprint(based on articles and datasheets of some Mbed supported devices):
> ROM : 64kB , RAM: 8kB and there are several memory allocation services.

Ok but is the network stack included with this footprint? If this is
just to run hello-world, RIOT is much better!


> The ROM & RAM are not the min values ,but the specs of the lowest hardware
> device supported from Mbed.
>
> 2016-03-04 12:04 GMT+01:00 Baptiste Clenet <bapcle...@gmail.com>:
>>
>> Thanks Oleg for your input!
>>
>> 2016-03-01 20:23 GMT+01:00 Oleg Hahm <oliver.h...@inria.fr>:
>> > Hi Baptiste!
>> >
>> > On Tue, Mar 01, 2016 at 07:14:50PM +0100, Baptiste Clenet wrote:
>> >> This is just to know your opinion about this OS:
>> >> https://www.mbed.com/en/
>> >> Why RIOT is better than mbed (apart from being a multi thread OS)? It
>> >> seems to support lot of boards and has a rich network stack.
>> >
>> > Disclaimer: I don't know any details about mbed, but from what I know
>> > the main
>> > differences are:
>> > * RIOT is open source, mbed uses some blobs (e.g. for the network stack)
>> > * RIOT believes in the power of open source and therefore uses a
>> > copyleft
>> >   license (LGPL), where mbed OS uses Apache license which encourages
>> > hardware
>> >   vendors to provide closed source drivers (see openness of Android for
>> > a bad
>> >   example)
>> > * RIOT is a community powered OS, out there for almost three years now
>> > with a
>> >   lot of experience in IoT and (constrained) wireless networks, mbed is
>> >   driven by one commercial entity (ARM) which got released only have a
>> > year
>> >   ago as beta version from some hardware folks
>> > * RIOT supports basically all kind of architectures for the IoT (AVR
>> > 8bit, TI
>> >   MSP430 16bit, ARM7 and ARM Cortex-M, x86...) and is vendor independent
>> > -
>> >   well, for mbed this should be quite obvious... (do they even support
>> > ARM7)
>> >
>> > Do you know anything about the memory footprint of mbed OS?
>> > What about standard compliance of mbed OS? I cannot remember that I have
>> > met
>> > an mbed team on any of the five ETSI plugtests I participated with/for
>> > RIOT.
>> >
>> > Cheers,
>> > Oleg
>> > --
>> > printk("WE HAVE A BUG HERE!!! stk=0x%p\n", stk);
>> > linux-2.6.6/drivers/block/cciss_scsi.c
>> >
>> > ___
>> > devel mailing list
>> > devel@riot-os.org
>> > https://lists.riot-os.org/mailman/listinfo/devel
>> >
>>
>>
>>
>> --
>> Baptiste
>> ___
>> 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
>



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

[riot-devel] Bridge border router and 6LowPan interfaces

[Baptiste Clenet]

Hi,

On one SAMR21 (A), I set up the gnrc_border_router so I've got two
interfaces (with at86rf2xx and SLIP). I've got another SAMR21 (B) with
gnrc_networking example.
When I send an UDP packet from B to A, is it possible to bridge the
two interfaces on A in order to receive my UDP packet on my linux
interface "tun0" ?
I couldn't find how to do it on those examples and I think this is a
really important feature for a border router.

Cheers,

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

[riot-devel] Opinion on ARM mbed

[Baptiste Clenet]

Hi all,

This is just to know your opinion about this OS:
https://www.mbed.com/en/
Why RIOT is better than mbed (apart from being a multi thread OS)? It
seems to support lot of boards and has a rich network stack.

Cheers,

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

Re: [riot-devel] IPV6 address

[Baptiste Clenet]

2015-11-04 16:31 GMT+01:00 Baptiste Clenet <bapcle...@gmail.com>:
> Oleg, where did RIOT find those values for CPUID:
> #define SAMD21_CPUID_WORD0 (*(volatile uint32_t *)0x0080A00C)
> #define SAMD21_CPUID_WORD1 (*(volatile uint32_t *)0x0080A040)
> #define SAMD21_CPUID_WORD2 (*(volatile uint32_t *)0x0080A044)
> #define SAMD21_CPUID_WORD3 (*(volatile uint32_t *)0x0080A048)
>

My bad, I didn't see it was addresses corresponding to the serial
number of the board!

> Basically, if I fill the CPUID with my new EUI64 (in correct order) at
> boot time (before reset at86rf2xx), it will update all iface values (I
> tried it) or I should edit cpuid_get as I want.
>
> Last question, I saw that RIOT automatically edits the universal/local
> (U/L) flag (bit 7) in the OUI portion
> Long HWaddr: 5a:5a:XX
> inet addr fe80::585a:XX
>
> If I've got a global EUI64, not local, how should I proceed to tell
> RIOT to not create local address? Or did I misunderstand something?
>
> Baptiste
>
> 2015-11-04 11:40 GMT+01:00 Baptiste Clenet <bapcle...@gmail.com>:
>> Thanks Oleg, I will have a look at it.
>>
>> 2015-11-04 10:05 GMT+01:00 Oleg Hahm <oliver.h...@inria.fr>:
>>> Baptiste,
>>>
>>>> I wanted to update all ifconfig (Pv6 link-local address, Short
>>>> address, Long HW address) information from a new EUI-64.
>>>> I see that it's what RIOT does at build time then. So I should edit
>>>> the EUI64 before IPV6-link-local address is calculated. What should I
>>>> edit?  (and where in Riot source code)
>>>
>>> take a look at, e.g.
>>> https://github.com/RIOT-OS/RIOT/blob/master/drivers/at86rf2xx/at86rf2xx.c#L124
>>>
>>> Cheers,
>>> Oleg
>>> --
>>> Chuck Norris has only one OSI layer - Physical
>>>
>>> ___
>>> devel mailing list
>>> devel@riot-os.org
>>> https://lists.riot-os.org/mailman/listinfo/devel
>>>
>>
>>
>>
>> --
>> Baptiste
>
>
>
> --
> Baptiste



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

Re: [riot-devel] IPV6 address

[Baptiste Clenet]

Ok I edit my question:
How to add a global unique IPV6 address to RIOT iface? (IPV6 will be
built from a unique EUI64)

2015-11-04 16:35 GMT+01:00 Baptiste Clenet <bapcle...@gmail.com>:
> 2015-11-04 16:31 GMT+01:00 Baptiste Clenet <bapcle...@gmail.com>:
>> Oleg, where did RIOT find those values for CPUID:
>> #define SAMD21_CPUID_WORD0 (*(volatile uint32_t *)0x0080A00C)
>> #define SAMD21_CPUID_WORD1 (*(volatile uint32_t *)0x0080A040)
>> #define SAMD21_CPUID_WORD2 (*(volatile uint32_t *)0x0080A044)
>> #define SAMD21_CPUID_WORD3 (*(volatile uint32_t *)0x0080A048)
>>
>
> My bad, I didn't see it was addresses corresponding to the serial
> number of the board!
>
>> Basically, if I fill the CPUID with my new EUI64 (in correct order) at
>> boot time (before reset at86rf2xx), it will update all iface values (I
>> tried it) or I should edit cpuid_get as I want.
>>
>> Last question, I saw that RIOT automatically edits the universal/local
>> (U/L) flag (bit 7) in the OUI portion
>> Long HWaddr: 5a:5a:XX
>> inet addr fe80::585a:XX
>>
>> If I've got a global EUI64, not local, how should I proceed to tell
>> RIOT to not create local address? Or did I misunderstand something?
>>
>> Baptiste
>>
>> 2015-11-04 11:40 GMT+01:00 Baptiste Clenet <bapcle...@gmail.com>:
>>> Thanks Oleg, I will have a look at it.
>>>
>>> 2015-11-04 10:05 GMT+01:00 Oleg Hahm <oliver.h...@inria.fr>:
>>>> Baptiste,
>>>>
>>>>> I wanted to update all ifconfig (Pv6 link-local address, Short
>>>>> address, Long HW address) information from a new EUI-64.
>>>>> I see that it's what RIOT does at build time then. So I should edit
>>>>> the EUI64 before IPV6-link-local address is calculated. What should I
>>>>> edit?  (and where in Riot source code)
>>>>
>>>> take a look at, e.g.
>>>> https://github.com/RIOT-OS/RIOT/blob/master/drivers/at86rf2xx/at86rf2xx.c#L124
>>>>
>>>> Cheers,
>>>> Oleg
>>>> --
>>>> Chuck Norris has only one OSI layer - Physical
>>>>
>>>> ___
>>>> devel mailing list
>>>> devel@riot-os.org
>>>> https://lists.riot-os.org/mailman/listinfo/devel
>>>>
>>>
>>>
>>>
>>> --
>>> Baptiste
>>
>>
>>
>> --
>> Baptiste
>
>
>
> --
> Baptiste



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

Re: [riot-devel] IPV6 address

[Baptiste Clenet]

> Not sure, what you're trying to achieve. The IPv6 link-local address is
> calculated at boot time from the node's EUI-64 address and won't be updated
> automatically by just changing the node's HW addresses later on. You can
> however remove the IPv6 address from the given interface and add a new one.
> Another way would be to preconfigure a different EUI-64 at build time.

I wanted to update all ifconfig (Pv6 link-local address, Short
address, Long HW address) information from a new EUI-64.
I see that it's what RIOT does at build time then. So I should edit
the EUI64 before IPV6-link-local address is calculated. What should I
edit?  (and where in Riot source code)


2015-11-04 0:00 GMT+01:00 Oleg Hahm :
> Hi Baptiste!
>
>> I want to edit the IPV6 address with a new EUI64. Which is the correct
>> way to edit the IPV6 address? I tried to edit the Long HWaddr with
>> gnrc_netapi_set but it doesn't automatically update inet6 addr.
>> Do I have to update each value (ie Short/Long addr and inet6 addr) or
>> is there a way to provide an EUI64 value and get those value updated?
>
> Not sure, what you're trying to achieve. The IPv6 link-local address is
> calculated at boot time from the node's EUI-64 address and won't be updated
> automatically by just changing the node's HW addresses later on. You can
> however remove the IPv6 address from the given interface and add a new one.
> Another way would be to preconfigure a different EUI-64 at build time.
>
> Cheers,
> Oleg
> --
> printk("CPU[%d]: Giving pardon to imprisoned penguins\n", smp_processor_id());
> linux-2.4.8/arch/sparc64/kernel/smp.c
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>



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

Re: [riot-devel] IPV6 address

[Baptiste Clenet]

Thanks Oleg, I will have a look at it.

2015-11-04 10:05 GMT+01:00 Oleg Hahm :
> Baptiste,
>
>> I wanted to update all ifconfig (Pv6 link-local address, Short
>> address, Long HW address) information from a new EUI-64.
>> I see that it's what RIOT does at build time then. So I should edit
>> the EUI64 before IPV6-link-local address is calculated. What should I
>> edit?  (and where in Riot source code)
>
> take a look at, e.g.
> https://github.com/RIOT-OS/RIOT/blob/master/drivers/at86rf2xx/at86rf2xx.c#L124
>
> Cheers,
> Oleg
> --
> Chuck Norris has only one OSI layer - Physical
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>



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

[riot-devel] IPV6 address

[Baptiste Clenet]

Hi,

I want to edit the IPV6 address with a new EUI64. Which is the correct
way to edit the IPV6 address? I tried to edit the Long HWaddr with
gnrc_netapi_set but it doesn't automatically update inet6 addr.
Do I have to update each value (ie Short/Long addr and inet6 addr) or
is there a way to provide an EUI64 value and get those value updated?

Cheers,

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

Re: [riot-devel] CoAP

[Baptiste Clenet]

Hi Illias,

There is an example of the use of microcoap [1] but it hasn't been
updated with the new network stack so it might not work.
No microcoap doesn't take care about socket so you have to register a
new UDP socket which will be redirected to your microcoap handle
function.


[1] https://github.com/RIOT-OS/applications/blob/master/microcoap/main.c


2015-10-29 12:52 GMT+01:00 Ilias Seitanidis :
> Hi ! To use CoAP in my R21 boards should I rite the code of socket
> programming (open a udp port ,etc) or just use the coap library and it takes
> care about the socket?
> Thank you in advance!!!
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>



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

Re: [riot-devel] CoAP

[Baptiste Clenet]

I didn't try it since it's big comparing to microcoap (because it
implements both client and server).
There is no example for libcoap so you will have to register an UDP
socket to the new network stack as well.
IMHO, if you don't need a CoAP client , you should use microcoap.

Baptiste

2015-10-29 15:02 GMT+01:00 Ilias Seitanidis <iliasseitani...@gmail.com>:
> Hi Baptiste,
> do you know if libcoap is working on the new stack?
> Best,
> Ilias
>
> 2015-10-29 14:56 GMT+01:00 Baptiste Clenet <bapcle...@gmail.com>:
>>
>> Hi Illias,
>>
>> There is an example of the use of microcoap [1] but it hasn't been
>> updated with the new network stack so it might not work.
>> No microcoap doesn't take care about socket so you have to register a
>> new UDP socket which will be redirected to your microcoap handle
>> function.
>>
>>
>> [1] https://github.com/RIOT-OS/applications/blob/master/microcoap/main.c
>>
>>
>> 2015-10-29 12:52 GMT+01:00 Ilias Seitanidis <iliasseitani...@gmail.com>:
>> > Hi ! To use CoAP in my R21 boards should I rite the code of socket
>> > programming (open a udp port ,etc) or just use the coap library and it
>> > takes
>> > care about the socket?
>> > Thank you in advance!!!
>> >
>> > ___
>> > devel mailing list
>> > devel@riot-os.org
>> > https://lists.riot-os.org/mailman/listinfo/devel
>> >
>>
>>
>>
>> --
>> Baptiste
>> ___
>> 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
>



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

Re: [riot-devel] CoAP

[Baptiste Clenet]

Hi Lennart,

>Also, you'd probably have to port it to RIOT first
Just to let you know, libcoap has already been ported to RIOT (as a
pkg as microcoap) [1]
Yes it does network registering automatically but I don't if this port
does it with the new network stack, need testing.

[1] https://github.com/RIOT-OS/RIOT/tree/master/pkg/libcoap

2015-10-29 15:19 GMT+01:00 Lennart Dührsen :
> Hi Ilias,
>
>> To use CoAP in my R21 boards should I rite the code of socket
>> programming (open a udp port ,etc) or just use the coap library and it
>> takes care about the socket?
>
> all the microcoap library does is create and parse payloads (CoAP
> packets), and it let's you register callback functions for each URI.
>
> You have to handle all the networking stuff, i.e. sending and receiving
> UDP packets, yourself.
>
> I'm currently working on the mostly absent documentation of microcoap,
> you can find it in this fork:
>
> https://github.com/i2ot/microcoap
>
> It's not finished yet, but it might help you. For the networking stuff
> on RIOT OS, check out
>
> https://github.com/RIOT-OS/RIOT/tree/master/examples/gnrc_networking
>
> and
>
> https://github.com/RIOT-OS/RIOT/tree/master/examples/posix_sockets
>
> if you haven't already done so.
>
> The example code Baptiste pointed you to is indeed out of date, but the
> CoAP parts in it are still correct and should work, so you'd just have
> to change the socket calls etc.
>
> Regarding libcoap: It's a *lot* more code than microcoap, and yes, it
> does all the socket stuff for you. But its documentation, too, is pretty
> much nonexistent. Also, you'd probably have to port it to RIOT first, so
> I suggest you use microcoap for devices that will run RIOT OS.
>
> If you run into problems with microcoap, feel free to send me an e-mail.
>
> Best,
> Lennart
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel



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

Re: [riot-devel] Energy Consumption on samr21_xpro

[Baptiste Clenet]

@Hauke, we add some results around 1,62mA some months ago [0]

Cheers,

Baptiste

[0] https://github.com/RIOT-OS/RIOT/pull/2309


2015-10-26 11:24 GMT+01:00 Hauke Petersen <hauke.peter...@fu-berlin.de>:
> Hi,
>
> if you decide to measure the energy consumption through those external pins,
> keep in mind, that you are measuring the consumption of the complete board -
> not only the MCU+radio. Last time I tried, I always got something around
> 100mA. This is fairly high for this kind of board (the STM32F4discovery was
> around ~15mA for the full board). Not sure where this high consumption comes
> from - but maybe you can measure your board and share your results with us?
>
> Cheers,
> Hauke
>
>
>
> On 26.10.2015 10:59, Baptiste Clenet wrote:
>>
>> @Illias, the current monitor header pins are the only way I know to
>> measure the current consumption. If you see a better way to do that,
>> It would be great to try it, let us know.
>>
>> Baptiste
>>
>> 2015-10-23 11:37 GMT+02:00 Peter Kietzmann
>> <peter.kietzm...@haw-hamburg.de>:
>>>
>>> Hi Ilias,
>>>
>>> I'd love to have such possibility, but from my knowledge there is no
>>> coulomb
>>> counter (or similar) on that board or on any common hardware. If you find
>>> a
>>> way, please let me know :-) !
>>>
>>> Cheers,
>>> Peter
>>>
>>> Am 23.10.2015 um 11:31 schrieb Ilias Seitanidis:
>>>
>>> Hi Peter,
>>> First of all I want to thank you for your fast reply.I want to measure
>>> the
>>> energy consumption from the board using software without external tools
>>> as
>>> an ammeter.
>>> Thank you.
>>> Best ,
>>> Ilias
>>>
>>> 2015-10-23 11:22 GMT+02:00 Peter Kietzmann
>>> <peter.kietzm...@haw-hamburg.de>:
>>>>
>>>> Hi Ilias,
>>>>
>>>> and welcome to RIOT! This board has a jumper on it's current monitor
>>>> header pins (next to the user programmable button). You can replace the
>>>> jumper by an ammeter and measure the current. Compare the boards user
>>>> guide
>>>>
>>>> http://www.atmel.com/Images/Atmel-42243-SAMR21-Xplained-Pro_User-Guide.pdf
>>>>
>>>> Best,
>>>> Peter
>>>>
>>>>
>>>>
>>>>
>>>> Am 23.10.2015 um 11:07 schrieb Ilias Seitanidis:
>>>>
>>>> Hi , I am new to wsn and I am wondering if there is a way to measure the
>>>> energy consumption of the atmel samr21_xpro .Thank you in advance!
>>>>
>>>>
>>>> ___
>>>> devel mailing list
>>>> devel@riot-os.org
>>>> https://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
>>>> https://lists.riot-os.org/mailman/listinfo/devel
>>>>
>>>
>>>
>>> ___
>>> devel mailing list
>>> devel@riot-os.org
>>> https://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
>>> https://lists.riot-os.org/mailman/listinfo/devel
>>>
>>
>>
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel



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

Re: [riot-devel] Include in Makefile

[Baptiste Clenet]

Anyone? @OlegHahm , @daniel-k ?

2015-10-09 16:50 GMT+02:00 Baptiste Clenet <bapcle...@gmail.com>:
> Hi all,
>
> I'm building an example (let's called it "app") for RIOT with the
> following structure:
> app/*.c
> app/include/*.h
> app/thingA/*.c
> app/thingA/include*.h
> app/thingB/*.c
> app/thingB/include*.h
>
> How to add the required path in the Makefile? Should I add
> Makefile.base in each folder or is there another way to do it with
> RIOT Makefile ? I couldn't find any example of this structure.
>
> Cheers,
>
>
> --
> Baptiste



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

Re: [riot-devel] Include in Makefile

[Baptiste Clenet]

Thanks Thomas and Rakendra. I didn't try it but it will work as good
as Attilio solution expect from the fact that it will use only one
module APPLICATION.

Thanks again!

Cheers,

Baptiste

2015-10-14 14:03 GMT+02:00 Thomas Eichinger <thomas.eichin...@fu-berlin.de>:
> Baptist,
>
> Did you try the following?
>
> app/Makefile:
> ```
> ...
> DIRS += thingA thingB
> INCLUDES += -I$(CURDIR)/include -I$(CURDIR)/thingA -I$(CURDIR)/thingB
> ...
> ```
>
> app/thingA/Makefile, app/thingB/Makefile
> ```
> module = $(APPLICATION)
>
> include $(RIOTBASE)/Makefile.base
> ```
>
> This way all code in `app` should form one module.
> Let me know if this helps.
>
> Best,
> Thomas
>
> On 14 Oct 2015, at 9:05 CEST(+0200), Baptiste Clenet wrote:
>
>> Anyone? @OlegHahm , @daniel-k ?
>>
>> 2015-10-09 16:50 GMT+02:00 Baptiste Clenet <bapcle...@gmail.com>:
>>> Hi all,
>>>
>>> I'm building an example (let's called it "app") for RIOT with the
>>> following structure:
>>> app/*.c
>>> app/include/*.h
>>> app/thingA/*.c
>>> app/thingA/include*.h
>>> app/thingB/*.c
>>> app/thingB/include*.h
>>>
>>> How to add the required path in the Makefile? Should I add
>>> Makefile.base in each folder or is there another way to do it with
>>> RIOT Makefile ? I couldn't find any example of this structure.
>>>
>>> Cheers,
>>>
>>>
>>> --
>>> Baptiste
>>
>>
>>
>> --
>> Baptiste
>> ___
>> 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



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

[riot-devel] Include in Makefile

[Baptiste Clenet]

Hi all,

I'm building an example (let's called it "app") for RIOT with the
following structure:
app/*.c
app/include/*.h
app/thingA/*.c
app/thingA/include*.h
app/thingB/*.c
app/thingB/include*.h

How to add the required path in the Makefile? Should I add
Makefile.base in each folder or is there another way to do it with
RIOT Makefile ? I couldn't find any example of this structure.

Cheers,


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

Re: [riot-devel] Save data in ROM

[Baptiste Clenet]

Sounds great Hauke! I like the multiplexing, it will allow all kind of
storage to be implemented and to separate device driver and the user
space (API).
This could be used by OTAU as well!

By config module for the msba2 and msb-430, did you mean [1]?


Frank, flashrom.h is for me one part of the global architecture, this is
for low level on-chip flash driver. Other kind of storage should be taken
into account as Hauke mentionned.

For my purpose, I would only need to create the driver flashrom.c for the
SAMR21. Hauke, do you think that is possible with the SAMD21?
By the way, flashrom.h should provide a flashrom_read() function or I don't
see the utility.

Baptiste

[1]
https://github.com/RIOT-OS/RIOT/blob/master/boards/msb-430-common/board_config.c


2015-08-27 11:01 GMT+02:00 Frank Holtz frank-riot2...@holtznet.de:

 Hello,

 first we need an interface to read and write data to flash. An
 specification can be found in RIOT/drivers/include/flashrom.h or another
 specification in my pull request https://github.com/RIOT-OS/RIOT/pull/2239

 At the moment i'm on the way to port http://bitlash.net/ to RIOT. For
 full functionality i need an interface to flash or access to an file
 system.

 My idea was to build an configuration store which is compatible with
 various flash types. In MCU supported by RIOT there are build in Flash
 with Error Correction or without error correction. There are many
 different page sizes. There are Platforms with the possibility to
 overwrite single bits without erasing pages (e.g. NRF51) and i think
 there are platforms with error correction where i can only write an page
 once. This is also an memory alignment problem. In my PR i have written
 code to allow unaligned access but i don't know if this is portable to
 any platform.

 Another problem is how often an page can erased. On many platforms
 10.000 erase cycles are possible. This is not enough for counters in
 flash. My idea was to create an object store starting at top of flash
 memory. Every write allocates a new space until there are no free pages
 available. When no page is available the flash memory needs cleaning.

 If possible counter objects are placed in a whole page and changed at
 bitlevel. So its possible to count 8,000,000 times per 1k page with
 10.000 erase cycles.

 At the moment i have no time to work on this topic.

 Regards,

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




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

Re: [riot-devel] Save data in ROM

[Baptiste Clenet]

2015-08-27 11:50 GMT+02:00 Kaspar Schleiser kas...@schleiser.de:

 Hey,

 On 08/27/2015 11:39 AM, Baptiste Clenet wrote:

 By the way, flashrom.h should provide a flashrom_read() function or I
 don't see the utility.


 Flash is usually directly accessible, no need for read(), unless the flash
 chip is somehow externally connected.

Yes but it will avoid to have unreadble code on the top of the interface
and it will clearer for future reader to have a write and read function.



 Kaspar

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




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

[riot-devel] Save data in ROM

[Baptiste Clenet]

Hi,

I know that Riot hasn't got a file system but I'm wondering if we could
still save some raw data in the ROM which would be available after reset?
Could we allow some space in the ROM and write some data?

By the way, have you planned to design a file system for Riot?

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

Re: [riot-devel] OTA update

[Baptiste Clenet]

 Here is the licence:

 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions are
met:
 *
 * 1. Redistributions of source code must retain the above copyright notice,
 *this list of conditions and the following disclaimer.
 *
 * 2. Redistributions in binary form must reproduce the above copyright
notice,
 *this list of conditions and the following disclaimer in the
documentation
 *and/or other materials provided with the distribution.
 *
 * 3. The name of Atmel may not be used to endorse or promote products
derived
 *from this software without specific prior written permission.
 *
 * 4. This software may only be redistributed and used in connection with an
 *Atmel microcontroller product.
 *
 * THIS SOFTWARE IS PROVIDED BY ATMEL AS IS AND ANY EXPRESS OR IMPLIED
 * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
 * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT
ARE
 * EXPRESSLY AND SPECIFICALLY DISCLAIMED. IN NO EVENT SHALL ATMEL BE LIABLE
FOR
 * ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
 * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
 * ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
 * POSSIBILITY OF SUCH DAMAGE.




2015-06-16 21:10 GMT+02:00 Adam Hunt voxa...@gmail.com:

 What license have they released their code under? I'd look myself but I'm
 away from my desk.

 Adam

 On Tue, Jun 16, 2015, 7:41 AM Baptiste Clenet bapcle...@gmail.com wrote:

 Those example are provided with the last version of Atmel Studio (which
 is free). See here [1], the two examples:

 - 6LoWPAN OTA Client Application SAMR21  atsamr21g18a
 - 6LoWPAN OTA Server Application SAMR21 atsamr21g18a

 You will need Atmel Studio to get the source. (Download at [2])

 [1]
 http://194.19.124.62/docs/latest/search.html?board=SAM%20R21%20Xplained%20Pro
 [2] http://www.atmel.com/tools/atmelstudio.aspx

 Baptiste


 2015-06-16 14:45 GMT+02:00 Emmanuel Baccelli emmanuel.bacce...@inria.fr
 :

 Hi Baptiste,
 do you have an URL to share pointing to the Atmel OTA you're mentioning?
 Thanks,
 Emmanuel

 On Tue, Jun 16, 2015 at 10:34 AM, Baptiste Clenet bapcle...@gmail.com
 wrote:

 By the way, ATMEL has just released an app with OTA on its last Atmel
 Studio version. I think iit could be a good start to develop RIOT's
 OTA.

 Baptiste

 2015-06-09 15:16 GMT+02:00 Kaspar Schleiser kas...@schleiser.de:
  Hey,
 
  On 06/09/2015 01:37 PM, Baptiste Clenet wrote:
 
  - Take into account GSOC project about dynamic linking (Could someone
  provide the name of the guy who is going to work on?)
 
 
  He's called Kushal, I'm his mentor.
 
 
  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



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

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


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


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