Re: [riot-devel] Example/test ng_udp

2015-04-29 Thread Baptiste Clenet
Thanks Martine!
Will try this tomorrow!

2015-04-29 22:04 GMT+02:00 Martine Lenders :

> Hey Baptiste,
> though there is no example yet you can use the new network stack never the
> less. Just take one of the test applications for the device you want to use
> and compile them with the modules `ng_ipv6` and `ng_udp`. If you use an
> IEEE 802.15.4 device (which are currently the only ones in master) you need
> to add `ng_sixlowpan_frag`, too. The threads will be started properly by
> `auto_init` (which should have been initialized automatically).
>
> If you want to listen on a port just call
>
> ng_netreg_t entry = { thread_getpid(), port };
> ng_netreg_register(NG_NETTYPE_UDP, &entry);
>
> while (1) {
> msg_receive(&msg);
>
> switch (msg.type) {
> NG_NETAPI_MSG_TYPE_RCV:
> /* do something with the ng_pktsnip_t* at msg.content.ptr */
> break;
> }
> }
>
> If you want to send a pktsnip payload via UDP use:
>
> ng_netreg_t *sendto = ng_netreg_lookup(NG_NETTYPE_UDP,
> NG_NETREG_DEMUX_CTX_ALL);
> udp = ng_udp_hdr_build(payload, sport, 2, dport, 2);
> ipv6 = ng_ipv6_hdr_build(udp, NULL, 0, (uint8_t *)dst_addr, 16);
>
> ng_pktbuf_hold(ipv6, ng_netreg_num(NG_NETTYPE_UDP,
> NG_NETREG_DEMUX_CTX_ALL) - 1);
> while (sendto) {
> ng_netapi_send(sendto->pid, ipv6);
> sendto = sendto->next;
> }
>
> Be adviced that it is always a good idea to check if the returned values
> are not NULL (in case of a full packet buffer). Also: I did not compile
> this, so be warned of syntax errors ;-)
>
> Cheers,
> Martine
>
> 2015-04-28 13:54 GMT+02:00 Baptiste Clenet :
>
>> Great Hauke! I'm looking forward to using the all new network stack from
>> UDP to the transceiver :-)
>>
>> 2015-04-28 13:16 GMT+02:00 Hauke Petersen :
>>
>>>  Hi Baptiste,
>>>
>>> there is one small thing missing, namely a concept for initializing
>>> radio drivers and MAC layers in an automated fashion (as in auto_init). But
>>> I have already a concept in mind, hopefully I will get it done tomorrow -
>>> and with that I will update the example for UDP. So stay tuned :-)
>>>
>>> Cheers,
>>> Hauke
>>>
>>>
>>> On 28.04.2015 10:10, Baptiste Clenet wrote:
>>>
>>> Hi,
>>>
>>>  Could you add an example/test for the new ng_udp? It will be easier to
>>> use it then.
>>> *@haukepetersen @authmillenon *
>>>
>>>  Cheers,
>>>
>>>  --
>>>
>>> *Clenet Baptiste *
>>>
>>>
>>>
>>>
>>> ___
>>> devel mailing 
>>> listdevel@riot-os.orghttps://lists.riot-os.org/mailman/listinfo/devel
>>>
>>>
>>>
>>> ___
>>> devel mailing list
>>> devel@riot-os.org
>>> https://lists.riot-os.org/mailman/listinfo/devel
>>>
>>>
>>
>>
>> --
>> *Clenet 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
>
>


-- 

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


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


Re: [riot-devel] Example/test ng_udp

2015-04-29 Thread Martine Lenders
Hey Baptiste,
though there is no example yet you can use the new network stack never the
less. Just take one of the test applications for the device you want to use
and compile them with the modules `ng_ipv6` and `ng_udp`. If you use an
IEEE 802.15.4 device (which are currently the only ones in master) you need
to add `ng_sixlowpan_frag`, too. The threads will be started properly by
`auto_init` (which should have been initialized automatically).

If you want to listen on a port just call

ng_netreg_t entry = { thread_getpid(), port };
ng_netreg_register(NG_NETTYPE_UDP, &entry);

while (1) {
msg_receive(&msg);

switch (msg.type) {
NG_NETAPI_MSG_TYPE_RCV:
/* do something with the ng_pktsnip_t* at msg.content.ptr */
break;
}
}

If you want to send a pktsnip payload via UDP use:

ng_netreg_t *sendto = ng_netreg_lookup(NG_NETTYPE_UDP,
NG_NETREG_DEMUX_CTX_ALL);
udp = ng_udp_hdr_build(payload, sport, 2, dport, 2);
ipv6 = ng_ipv6_hdr_build(udp, NULL, 0, (uint8_t *)dst_addr, 16);

ng_pktbuf_hold(ipv6, ng_netreg_num(NG_NETTYPE_UDP, NG_NETREG_DEMUX_CTX_ALL)
- 1);
while (sendto) {
ng_netapi_send(sendto->pid, ipv6);
sendto = sendto->next;
}

Be adviced that it is always a good idea to check if the returned values
are not NULL (in case of a full packet buffer). Also: I did not compile
this, so be warned of syntax errors ;-)

Cheers,
Martine

2015-04-28 13:54 GMT+02:00 Baptiste Clenet :

> Great Hauke! I'm looking forward to using the all new network stack from
> UDP to the transceiver :-)
>
> 2015-04-28 13:16 GMT+02:00 Hauke Petersen :
>
>>  Hi Baptiste,
>>
>> there is one small thing missing, namely a concept for initializing radio
>> drivers and MAC layers in an automated fashion (as in auto_init). But I
>> have already a concept in mind, hopefully I will get it done tomorrow - and
>> with that I will update the example for UDP. So stay tuned :-)
>>
>> Cheers,
>> Hauke
>>
>>
>> On 28.04.2015 10:10, Baptiste Clenet wrote:
>>
>> Hi,
>>
>>  Could you add an example/test for the new ng_udp? It will be easier to
>> use it then.
>> *@haukepetersen @authmillenon *
>>
>>  Cheers,
>>
>>  --
>>
>> *Clenet Baptiste *
>>
>>
>>
>>
>> ___
>> devel mailing 
>> listdevel@riot-os.orghttps://lists.riot-os.org/mailman/listinfo/devel
>>
>>
>>
>> ___
>> devel mailing list
>> devel@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>>
>>
>
>
> --
> *Clenet 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


Re: [riot-devel] NTSF: FIB status and future plans

2015-04-29 Thread Oleg Hahm
Hi Martin!
 
> unfortunately I cannot attend the NTSF meeting tomorrow :(
> So I hacked some words on the current status and the future palns of the FIB
> on a wiki page [1].

Thanks for the effort and the nice overview.

Cheers,
Oleg
-- 
# Okay, what on Earth is this one supposed to be used for?
linux-2.4.0/drivers/char/cp437.uni


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


[riot-devel] NTSF: FIB status and future plans

2015-04-29 Thread Martin

Hi all,

unfortunately I cannot attend the NTSF meeting tomorrow :(
So I hacked some words on the current status and the future palns of the 
FIB on a wiki page [1].


Best regards,
Martin

[1] https://github.com/RIOT-OS/RIOT/wiki/NSTF:-FIB-Status-and-future-plans
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] WDT questions

2015-04-29 Thread Joakim Gebart
An idea:
Create a multi-channel software watchdog that in turn pokes the hardware
watchdog when all parameters are met.
We could configure different timeouts for different channels and each
critical process can have its own channel(s) which they update
independently.

Some risks of this approach is that it will be possible for software errors
to make the software watchdog misbehave and poke the hardware watchdog and
keep the system running when it should be reset.

Best regards,
Joakim
Thanks for your explanations. I understand why it is counter productive.
But how RIOT will make sure that the board is not stuck in a deadlock? This
is mandatory for industrial context.

Cheers,


2015-04-29 15:07 GMT+02:00 Joakim Gebart :

> It has to do with the difficulty of providing a reliable way of poking the
> watchdog in an event driven, tickless, system such as RIOT. Maybe it is
> time to start discussing a watchdog api?
> In order to get any traction within industry applications I believe it
> will be necessary to at least provide an api for applications to use the
> watchdog.
>
> Best regards,
> Joakim Gebart
> Eistec AB
> www.eistec.se
> On Apr 29, 2015 2:43 PM, "Baptiste Clenet"  wrote:
>
>> Hi,
>>
>> I've got two questions concerning WDT:
>>  - Why do we disable it on the samr21 at launch time?
>>  - Why doesn't RIOT provide a wdt.h in drivers/include/periph?
>>
>> Cheers,
>>
>> --
>>
>> *Clenet 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
>
>


-- 
*Clenet 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


Re: [riot-devel] WDT questions

2015-04-29 Thread Baptiste Clenet
Thanks for your explanations. I understand why it is counter productive.
But how RIOT will make sure that the board is not stuck in a deadlock? This
is mandatory for industrial context.

Cheers,


2015-04-29 15:07 GMT+02:00 Joakim Gebart :

> It has to do with the difficulty of providing a reliable way of poking the
> watchdog in an event driven, tickless, system such as RIOT. Maybe it is
> time to start discussing a watchdog api?
> In order to get any traction within industry applications I believe it
> will be necessary to at least provide an api for applications to use the
> watchdog.
>
> Best regards,
> Joakim Gebart
> Eistec AB
> www.eistec.se
> On Apr 29, 2015 2:43 PM, "Baptiste Clenet"  wrote:
>
>> Hi,
>>
>> I've got two questions concerning WDT:
>>  - Why do we disable it on the samr21 at launch time?
>>  - Why doesn't RIOT provide a wdt.h in drivers/include/periph?
>>
>> Cheers,
>>
>> --
>>
>> *Clenet 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
>
>


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


Re: [riot-devel] WDT questions

2015-04-29 Thread Joakim Gebart
It has to do with the difficulty of providing a reliable way of poking the
watchdog in an event driven, tickless, system such as RIOT. Maybe it is
time to start discussing a watchdog api?
In order to get any traction within industry applications I believe it will
be necessary to at least provide an api for applications to use the
watchdog.

Best regards,
Joakim Gebart
Eistec AB
www.eistec.se
On Apr 29, 2015 2:43 PM, "Baptiste Clenet"  wrote:

> Hi,
>
> I've got two questions concerning WDT:
>  - Why do we disable it on the samr21 at launch time?
>  - Why doesn't RIOT provide a wdt.h in drivers/include/periph?
>
> Cheers,
>
> --
>
> *Clenet 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


Re: [riot-devel] WDT questions

2015-04-29 Thread Hauke Petersen

Hi,

very simple: A watchdog timer does not at all fit into the context of a 
tickless-system. We want to sleep as long as possible, so waking up just 
to please the WDT is very counter productive...


A WDT interface we could actually introduce, I guess just nobody did it 
so far...


Cheers,
Hauke


On 29.04.2015 14:43, Baptiste Clenet wrote:

Hi,

I've got two questions concerning WDT:
 - Why do we disable it on the samr21 at launch time?
 - Why doesn't RIOT provide a wdt.h in drivers/include/periph?

Cheers,

--
/Clenet 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


[riot-devel] WDT questions

2015-04-29 Thread Baptiste Clenet
Hi,

I've got two questions concerning WDT:
 - Why do we disable it on the samr21 at launch time?
 - Why doesn't RIOT provide a wdt.h in drivers/include/periph?

Cheers,

-- 

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


[riot-devel] upcoming RIOT engineering positions at Inria

2015-04-29 Thread Emmanuel Baccelli
Dear RIOTers

more good news for our community: Inria [1] will soon open 3 engineer
positions to work full-time on RIOT development and maintenance.

These positions last 2 years, and are planned to debut this fall
(Sept-Oct).

Applicants must hold a Masters degree or equivalent. More details and links
to application forms will follow soon.

In the mean time, if you have specific questions, PM me.

Cheers,

Emmanuel


[1] http://www.inria.fr/en
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel