Re: [riot-devel] N2 Project
The way I envision it is as a starting point for RIOT, a base. Once the project is integrated, then we can make changes to it as we see fit. Is that an accurate picture or is it more a case of utilizing the project and handling changes to that project that affect RIOT as they occur on Wakaama independently through patches? Perhaps some combination of those? > On Mar 23, 2015, at 4:33 PM, Hauke Petersen > wrote: > > Hi David, > > when using Wakaama (which is certainly an option), the way would be to > include it in RIOT as a package and include some Makefiles that are able to > download/checkout the library and build it into RIOT. When choosing this > path, one important thing is to think of a concept for continuous > integration, so that the Makefiles and patches can be adjusted to changes of > the Wakaama implementation in an easy way. > > Cheers, > Hauke > > >> On 23.03.2015 19:45, David Reinert wrote: >> I am almost certainly planning on using the Wakaama project(formerly >> liblwM2M) for this project. A possibly silly question but, would a final >> port of this implementation look similar to the various ports under >> RIOT/pkg/ or is it more involved than that? I am just trying to get a >> picture of what the final project would look like so I can better form a >> clear timeline. Thanks! >> >> -David >> >> >> ___ >> 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
Re: [riot-devel] N2 Project
Hi David, when using Wakaama (which is certainly an option), the way would be to include it in RIOT as a package and include some Makefiles that are able to download/checkout the library and build it into RIOT. When choosing this path, one important thing is to think of a concept for continuous integration, so that the Makefiles and patches can be adjusted to changes of the Wakaama implementation in an easy way. Cheers, Hauke On 23.03.2015 19:45, David Reinert wrote: I am almost certainly planning on using the Wakaama project(formerly liblwM2M) for this project. A possibly silly question but, would a final port of this implementation look similar to the various ports under RIOT/pkg/ or is it more involved than that? I am just trying to get a picture of what the final project would look like so I can better form a clear timeline. Thanks! -David ___ 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] NSTF radio driver
Hi Joakim, as of today, I PRed a new version of the Xbee S1 radio driver[1], which is build 100% on the new netdev interface. I think it makes a good reference implementation for radio drivers, even if it is through it's UART interface a little different from others drivers we are supporting... So to my opinion, the netdev interface can be considere as stable (I expect only very minor changes). So if you want to go ahead implementing your new driver, now is a good time as any! Cheers, Hauke [1] https://github.com/RIOT-OS/RIOT/pull/2695 On 20.02.2015 07:25, Joakim Gebart wrote: Dear RIOT developers, - Which radio driver is the most up to date with regards to the network stack restructuring work being done in #2278? - How stable is the radio device API currently? Are there any more API changes coming? - Would it be wise to wait until the restructuring todo list is mostly checked off until starting work on implementing a new radio device driver? - Which driver would be best to use as an example of a fully compliant radio driver? I am looking at implementing a driver for a new radio chip, but I do not want to have to redo the work again in a couple of weeks because of the network refactoring... https://github.com/RIOT-OS/RIOT/issues/2278 Best regards, Joakim Gebart Managing Director Eistec AB Aurorum 1C 977 75 Luleå Tel: +46(0)730-65 13 83 joakim.geb...@eistec.se www.eistec.se ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] N2 Project
I am almost certainly planning on using the Wakaama project(formerly liblwM2M) for this project. A possibly silly question but, would a final port of this implementation look similar to the various ports under RIOT/pkg/ or is it more involved than that? I am just trying to get a picture of what the final project would look like so I can better form a clear timeline. Thanks! -David ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] CSMA MAC-layer, Open Issues
Hi Jonas, On 20.03.2015 18:02, Jonas Remmert wrote: 1. Both, the upper layer and the current implementations of the ng_netdev radio drivers use task messages to signalize an event (Packet to be sent or Packet to receive waiting). Both message mechanisms send their messages to the mac_pid and therefore use the same message queue. If the mac-layer and the transceiver is busy with sending a message out or waiting for an ACK it might wait for a signal from the driver (RX-ready, ACK-received...). In the same time there might also be messages from the upper layers that can not be handled until the previous packet is sent out. - I handled this problem in using the drivers call-back function in combination with different task lock mechanisms for upper layer (msg_receive) and for driver events 2x(mutex_lock), which causes in TASK_BLOCKED state. That method worked very well, even if I fired the mac-layer continously with upper layer messages. Though this probably works fine, this is not quite how the concept was meant. The problem is of course there: when the MAC layer is getting spammed by upper layer messages, the reaction time for device driver messages might be not as fast... Though the messages should not be los (as they are queued...). The concept is based on the assumption, that the time needed for handling incoming messages in the MAC layer is very short. Also so far we basically assumed, that the MAC layer has a higher priority then the upper layers. This way, the MAC layer will always finish processing all it's queued messages before the upper layers get scheduled again. 2. The drivers send function builds the IEEE 802.15.4 MAC header on its own. The alternative would be to let the MAC layer do this job. This would avoid code duplication and make it easier to implement new radio drivers. Is there any reason to do this in the driver implementation? I don't really understand the code duplication issue here... The MAC layer should actually not know anything about the radio frame format or the like, as the idea behing the MAC layer in the current form is to make them interchangable and usable with different network devices (not only 802.15.4 devices)... So to answer your question: yes! 3. Introduction of PHY dependant constants: The constants (e.g. SYMBOL_LENGTH used in backoff intervall, MAX_BE, MIN_BE, TURNAROUND_TIME, MAC_ACK_WAIT_DURATION, MAX_RETRIES..). As these constants are different for each type of PHY (2,5 Ghz, subGhz and also Modulation specific) we could put them in a struct that would be linked to the device descriptor. Actually, these constants should not be constants :-) The way I would implement them is by naming these defines something like xx_DEFAULT_MAX_BE, xx_DEFAULT_TURNAROUND_TIME, etc. The you include fields in your device descriptor for these values and initialize them with these values. This way you can change them during runtime and define different values if you run more then 1 device concurrently... 4. Generally, a successfull TX of a packet is not signalized to upper layers. But how do we handle a packet that could not be sent to the channel (e.g. channel busy)? Should upper layer be informed about the failure? So far the packets are just silently dropped. The plain netapi_send() does not support feedback to upper layers on the success of the send process - this we did to avoid deadlock scenarios and synchronization issues... Cheers, Hauke A WIP state of the ng_kw2xrf-driver that I used for testing can be found in my repo [2]. a nice Weekend, Jonas [1] - https://github.com/RIOT-OS/RIOT/pull/2467 [2] - https://github.com/jremmert-phytec-iot/RIOT/tree/wip%40kw2xrf_ng ___ devel mailing list devel@riot-os.org http://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] BLE project N2
Hi Kausthub, with a clean hardware abstraction the BLE implementation should be mostly independent of hardware. For the small hardware dependent part we propose the NRF51822 SoC (as it is broadly available and cheap), that is correct. But as a basic driver for the SoC's radio is already available, we sure think that the implementation is doable in the given timeframe. There is no general answer regarding the deliverables: they depend on your proposed architecture and timetable. In the beginning of the project we will plan with you, which milestones are realistic and plan the deliverables on top of these. Cheers, Hauke On 21.03.2015 03:27, Kausthub Naarayan wrote: hi all , the BLE stack needs to be developed first on nrf52822 ? and is it possible to develop all these within 2 months ? And how do we go about giving deliverables for this project proposal ? Sorry if this is a trivial question , i am new to gsoc procedure thanks in advance -- Regards Kausthub Naarayan B 9535264688 ___ devel mailing list devel@riot-os.org http://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] Removing thirdparty repositories
Hi! Okay, I removed it from the organization on Github. To be on the safe side I just moved it to my personal repos. Cheers, Oleg -- printk(KERN_DEBUG "%s: Flex. T...\n", DRV_NAME); linux-2.6.6/drivers/net/wan/dscc4.c pgpPOJlgt5sAT.pgp Description: PGP signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Iotivity, AllJoyn, Thread, Ipso Alliance
Hi! At least for IoTivity it should be fairly simple to port it to RIOT according to the response I got on their mailing list: http://lists.iotivity.org/pipermail/iotivity-dev/2015-March/000600.html The only problem I see is the incompatible license of their implementation. (Btw. the Contiki port seems to be more or less vaporware according to http://lists.iotivity.org/pipermail/iotivity-dev/2015-March/000606.html). Cheers, Oleg -- if (user_specified) /* Didn't work, but the user is convinced this is the * place. */ linux-2.4.0-test2/drivers/parport/parport_pc.c pgpYfYZcXTzql.pgp Description: PGP signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
