Re: [riot-devel] Example/test ng_udp
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
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
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
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
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
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
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
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
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
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