Re: [riot-devel] Interested in implementing a driver for MRF24J40MA
Hi Guillermo, and welcome to RIOT! Am 06.11.2014 um 06:45 schrieb Guillermo Reyes: Hi people. New comer to RIOT, working on an LPCxpresso board, got RIOT running at some extend in the board. Now I'm interested on implementing a driver for this transceiver, hardware timers, rtc, spi, etc... but don't really know which APIs should I use. I have been digging the source, doxygen documentation, mailing list, issues, etc. and don't have a clear vision of direction the development efforts are leaning to... Should I start using the Peripheral drivers APIs? I think the APIs are some what clean and clear, but I can't seem to find any consumers of those APIs in the main tree. Yes you should use the peripheral driver APIs in RIOT/drivers/include/periph. The reason why there are not too many consumers for these APIs is, that this design is relatively new. But nevertheless, you can find some peripheral tests in RIOT/tests. They're named like "periph_xyz". Also in RIOT/drivers you can find one or two drivers which use these APIs, for example the isl29020 light sensor uses i2c. Also you'll maybe find some interesting open pull requests. If those APIs are going to be the HAL for RIOT I could start using them and contribute some feedback and testing of hardware independent drivers with those APIs. This would be a nice proof of concept in addition :-) ! Implementing a good HAL is fundamental to a portable OS, like *BSDs ( I specially like the NetBSD APIs), and for making RIOT a big player in the IoT. Could someone orient me in the right direction. Thanks. Cheers, Peter ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Dedicated RIOT Testing Meeting
On 5.11.2014, at 17:42, Martine Lenders wrote: > 2014-11-05 16:24 GMT+01:00 Philipp Rosenkranz > : > Dear RIOTers, > > in order to discuss possible enhancements to our current test > setup I would like to invite you to a dedicated RIOT testing meeting. > > The main topics to discuss will be: > > * Automated hardware based regression testing. This is where we have existing code for Robot Framework. ELL-i is able to run unit tests in real hardware and apply tests with a logic analyser. > * CI systems: Jenkins / buildbot or both? > * Simulations / Virtualization as part of our testing strategy. I'd like that whatever test system it is, an individual developer could run it even offline. For this goal, virtualization seems to be the easiest path. > We also should discuss robot framework [1] as suggested by ELL-i at the > workshop. I did not look into it too much, but from as much as I gathered it > might be helpful to automate a lot of already existing tests in our `tests/` > directory. It's also integratable into Jenkins if this is important to you > [2]. RF is Python and its test cases are in wiki markdown format. This makes it easy to separate test spec from the testing framework itself allows nonprogrammers to participate in some of the generating of test cases. I'm hoping Asif can join the meeting as he is the key RF person for ELL-i and has written bidirectional Python<->C hooks for running unit tests against the ELL-i emulator. The emulator itself is emulating a MCU including register controlled peripherals so we have some interesting tests coming up. It could be used in Riot OS context as well. - t signature.asc Description: Message signed with OpenPGP using GPGMail ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Interested in implementing a driver for MRF24J40MA
Hi people. New comer to RIOT, working on an LPCxpresso board, got RIOT running at some extend in the board. Now I'm interested on implementing a driver for this transceiver, hardware timers, rtc, spi, etc... but don't really know which APIs should I use. I have been digging the source, doxygen documentation, mailing list, issues, etc. and don't have a clear vision of direction the development efforts are leaning to... Should I start using the Peripheral drivers APIs? I think the APIs are some what clean and clear, but I can't seem to find any consumers of those APIs in the main tree. If those APIs are going to be the HAL for RIOT I could start using them and contribute some feedback and testing of hardware independent drivers with those APIs. Implementing a good HAL is fundamental to a portable OS, like *BSDs ( I specially like the NetBSD APIs), and for making RIOT a big player in the IoT. Could someone orient me in the right direction. Thanks. ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Dedicated RIOT Testing Meeting
On 2014-11-06 02:54, Philipp Rosenkranz wrote: @Martine: Good point. We should definitely discuss the robot framework as well. Something like this : ? - https://www.facebook.com/video.php?v=818668814853955&fref=nf ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Dedicated RIOT Testing Meeting
On 2014-11-06 02:24, Philipp Rosenkranz wrote: Dear RIOTers, in order to discuss possible enhancements to our current test setup I would like to invite you to a dedicated RIOT testing meeting. The main topics to discuss will be: * Automated hardware based regression testing. * CI systems: Jenkins / buildbot or both? * Simulations / Virtualization as part of our testing strategy. * Integration of additional static code analyzers (like coverity) into our CI system. * Hello, You don't have to, but being a commercial and old-school developer I would definitely add: - Sell to customers. Let them test it - Make some useful applications with it and install it on those devices. - Just put it in production - sort out problems as they arise. Regards David ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Dedicated RIOT Testing Meeting
Hi, it would probably better if we have this meeting sooner than later. That is why I deleted the last three days from the dudle (26-/27-/28- th of November). This has the nice side-effect that the form is now less of a hassle to fill out. regards, Philipp 2014-11-05 16:43 GMT+01:00 Martine Lenders : > Hi again, > > 2014-11-05 16:42 GMT+01:00 Martine Lenders : > >> >> >> 2014-11-05 16:24 GMT+01:00 Philipp Rosenkranz < >> philipp.rosenkr...@fu-berlin.de>: >> >>> Dear RIOTers, >>> >>> in order to discuss possible enhancements to our current test >>> setup I would like to invite you to a dedicated RIOT testing meeting. >>> >>> The main topics to discuss will be: >>> >>> * Automated hardware based regression testing. >>> * CI systems: Jenkins / buildbot or both? >>> * Simulations / Virtualization as part of our testing strategy. >>> * Integration of additional static code analyzers (like coverity) into >>> our CI system. >>> * >>> >> >> We also should discuss robot framework [1] as suggested by ELL-i at the >> workshop. >> > > s/ELL-i/Pekka from ELL-i/ ;-) > > Cheers, > Martine > > ___ > devel mailing list > devel@riot-os.org > http://lists.riot-os.org/mailman/listinfo/devel > > ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Refectoring the network stack
Sorry for the many errors in grammar and spelling (and the missing complimentary close). Accidentaly hit the send button before reading through the mail again… Kind regards, Martine 2014-11-05 18:15 GMT+01:00 Martine Lenders : > Hi, > as discussed on the virtual meeting we aim to have the new network stack > running with the next release (end of November or before christmas). > Currently, I'm the only one directly involved into the development (appart > from several radio driver implementations), and while parts of the model > come from me, Hauke is currently refining it. As for development it is > clear, that I can't be the only one working on it. > > I'm currently in the testing stage of 6LoWPAN but it is mostly done, but I > still need some kind of way to communicate with the transceiver module for > older boards (alternative would be to remove it, but for this we need #1772 > and #1733 merged and all boards moved to the low-level driver model). I > hope I have this done at the end of next week. > > All in all it's still a long way to the transport layer and to speed > things up, I thought some of you guys may want to help me. I tried to split > down the tasks at hand and assigned preliminary some people who might be > able to do it. If you do not want/can not do this task, please notify this. > Also if you want to take over a task do tell so too, please. Every > assignment with a question mark is not fixed yet. > > * Model (Martine? and Hauke) > * 6LoWPAN > - backwards compatibility with transceiver module (Martine) > - bug-hunting (Martine) > - ND according to https://tools.ietf.org/html/rfc6775 (Martine?, > depends on a running ND for IPv6) > - optional: Next header compression (Oleg?) > * IPv6 > - port to netapi and pktbuf and remove 6LoWPAN dependency (Martine?) > - consistent and extendable IPv6 Extension Header API (Martine?) > - consistent and extendable ICMPv6 API (Lotte?) > - Neighbor discovery according to http://tools.ietf.org/html/rfc4861 > (Martine?, depends maybe on ICMPv6 API, but can be done without it, I guess) > * Transport layer > - port to netapi and pktbuf (Cenk?) > > * optional tasks for full deprecation of `transceiver`: > - port OpenWSN (would this also include an IEEE 802.15.4e MAC layer?) > and CCNlite to netapi or netdev > - port boards that use cc110x to periph API or port cc110x_legacy and > cc110x_legacy_csma to netdev > - either removal or port to netdev of redbee-econotag > > ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Refectoring the network stack
Hi, as discussed on the virtual meeting we aim to have the new network stack running with the next release (end of November or before christmas). Currently, I'm the only one directly involved into the development (appart from several radio driver implementations), and while parts of the model come from me, Hauke is currently refining it. As for development it is clear, that I can't be the only one working on it. I'm currently in the testing stage of 6LoWPAN but it is mostly done, but I still need some kind of way to communicate with the transceiver module for older boards (alternative would be to remove it, but for this we need #1772 and #1733 merged and all boards moved to the low-level driver model). I hope I have this done at the end of next week. All in all it's still a long way to the transport layer and to speed things up, I thought some of you guys may want to help me. I tried to split down the tasks at hand and assigned preliminary some people who might be able to do it. If you do not want/can not do this task, please notify this. Also if you want to take over a task do tell so too, please. Every assignment with a question mark is not fixed yet. * Model (Martine? and Hauke) * 6LoWPAN - backwards compatibility with transceiver module (Martine) - bug-hunting (Martine) - ND according to https://tools.ietf.org/html/rfc6775 (Martine?, depends on a running ND for IPv6) - optional: Next header compression (Oleg?) * IPv6 - port to netapi and pktbuf and remove 6LoWPAN dependency (Martine?) - consistent and extendable IPv6 Extension Header API (Martine?) - consistent and extendable ICMPv6 API (Lotte?) - Neighbor discovery according to http://tools.ietf.org/html/rfc4861 (Martine?, depends maybe on ICMPv6 API, but can be done without it, I guess) * Transport layer - port to netapi and pktbuf (Cenk?) * optional tasks for full deprecation of `transceiver`: - port OpenWSN (would this also include an IEEE 802.15.4e MAC layer?) and CCNlite to netapi or netdev - port boards that use cc110x to periph API or port cc110x_legacy and cc110x_legacy_csma to netdev - either removal or port to netdev of redbee-econotag ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Periodical (virtual) meetings
Hi everyone, as Oleg promised below, we are going to try out Daviko's PlaceCam for todays meeting. Joining the meeting should be fairly easy, just follow this link: http://placecam.de/call.php?c=0~dA5j0OrfTdsesyQKlqIZvQi7bo1YKYGdMORGFmqL8- Again, linux users have to install the software beforehand, everyone else should be able to join by starting the software that is downloaded at the link's address... See you! Hauke On 04.11.2014 12:47, Oleg Hahm wrote: Hi Lotte! Since it turned out that Monday afternoon (CET) is not feasible for everyone willing to attend, I propose to use a polling tool to determine the next date: https://dudle.inf.tu-dresden.de/RIOT-virt-dev-1/ Did you reach any conclusion from this dudle yet? (i.e. will there be a meeting today?) Sorry that I missed to announce that: the poll indicates that we'll have the meeting tomorrow at 5pm CET. I can see that this date doesn't fit for you, but I hope we can find a convenient date for you the next time. Concerning the video conferencing tool, we decided to use PlaceCam[1] by daviko[2]. Hauke or I will send around an invitation link which includes a link to download the tool. Unfortunately, for now, Linux users have to download and install the tool beforehand from the daviko web page[3]. Cheers, Oleg [1] http://www.daviko.com/videokonferenz/22-1-PlaceCam-3.html [2] http://www.daviko.com [3] http://www.daviko.com/videokonferenz/3-1-Download.html ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Dedicated RIOT Testing Meeting
Hi, @Kasper: more options means a higher probability that we will find a day on which everyone can attend the meeting. However, I do understand that it is quite a hassle to fill out a form with that many options (I only realized that after sending the mail). @Martine: Good point. We should definitely discuss the robot framework as well. regards, Philipp 2014-11-05 16:43 GMT+01:00 Martine Lenders : > Hi again, > > 2014-11-05 16:42 GMT+01:00 Martine Lenders : > >> >> >> 2014-11-05 16:24 GMT+01:00 Philipp Rosenkranz < >> philipp.rosenkr...@fu-berlin.de>: >> >>> Dear RIOTers, >>> >>> in order to discuss possible enhancements to our current test >>> setup I would like to invite you to a dedicated RIOT testing meeting. >>> >>> The main topics to discuss will be: >>> >>> * Automated hardware based regression testing. >>> * CI systems: Jenkins / buildbot or both? >>> * Simulations / Virtualization as part of our testing strategy. >>> * Integration of additional static code analyzers (like coverity) into >>> our CI system. >>> * >>> >> >> We also should discuss robot framework [1] as suggested by ELL-i at the >> workshop. >> > > s/ELL-i/Pekka from ELL-i/ ;-) > > Cheers, > Martine > > ___ > devel mailing list > devel@riot-os.org > http://lists.riot-os.org/mailman/listinfo/devel > > ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Dedicated RIOT Testing Meeting
Hi again, 2014-11-05 16:42 GMT+01:00 Martine Lenders : > > > 2014-11-05 16:24 GMT+01:00 Philipp Rosenkranz < > philipp.rosenkr...@fu-berlin.de>: > >> Dear RIOTers, >> >> in order to discuss possible enhancements to our current test >> setup I would like to invite you to a dedicated RIOT testing meeting. >> >> The main topics to discuss will be: >> >> * Automated hardware based regression testing. >> * CI systems: Jenkins / buildbot or both? >> * Simulations / Virtualization as part of our testing strategy. >> * Integration of additional static code analyzers (like coverity) into >> our CI system. >> * >> > > We also should discuss robot framework [1] as suggested by ELL-i at the > workshop. > s/ELL-i/Pekka from ELL-i/ ;-) Cheers, Martine ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Dedicated RIOT Testing Meeting
2014-11-05 16:24 GMT+01:00 Philipp Rosenkranz < philipp.rosenkr...@fu-berlin.de>: > Dear RIOTers, > > in order to discuss possible enhancements to our current test > setup I would like to invite you to a dedicated RIOT testing meeting. > > The main topics to discuss will be: > > * Automated hardware based regression testing. > * CI systems: Jenkins / buildbot or both? > * Simulations / Virtualization as part of our testing strategy. > * Integration of additional static code analyzers (like coverity) into our > CI system. > * > We also should discuss robot framework [1] as suggested by ELL-i at the workshop. I did not look into it too much, but from as much as I gathered it might be helpful to automate a lot of already existing tests in our `tests/` directory. It's also integratable into Jenkins if this is important to you [2]. Cheers, Martine [1] http://robotframework.org/ [2] https://wiki.jenkins-ci.org/display/JENKINS/Robot+Framework+Plugin ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Regular Hack'n'ACK meetings at c-base, Berlin
Hi, this is a reminder to attend the poll regarding regular Hack'n'ACKs at c-base [1]. I plan to contact the orga team at c-base on sunday. Cheers, Martine [1] https://dudle.inf.tu-dresden.de/riot-hacknack-regular-dow/ 2014-11-01 23:08 GMT+01:00 Martine Lenders : > Hi, > as previously discussed we want to move our regular Hack'n'ACK meetings > out of the context of FU and into the Berlin-based hacker space c-base [1] > [2]. First of all, the c-base is approving our presence there, so we only > have to communicate (fixed) date for our monthly meetings. Since the > schedule of c-base is weekly I opened a doodle [3] to determine week (1st > of month, 2nd of month, 2nd to last of month and last of month) and day of > week for our future meetings. So if you live in or near Berlin, feel free > to fill it out. > > Kind regards, > Martine > > [1] https://www.c-base.org/ > [2] http://www.openstreetmap.org/#map=17/52.51297/13.42013 > [3] https://dudle.inf.tu-dresden.de/riot-hacknack-regular-dow/ > ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Dedicated RIOT Testing Meeting
Hi, On 11/05/2014 04:24 PM, Philipp Rosenkranz wrote: If you are interested, please take part in the dudle poll [1]. The meeting [1] https://dudle.inf.tu-dresden.de/testingtheriot/ Aren't there a bit too many options? Kaspar ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Dedicated RIOT Testing Meeting
Dear RIOTers, in order to discuss possible enhancements to our current test setup I would like to invite you to a dedicated RIOT testing meeting. The main topics to discuss will be: * Automated hardware based regression testing. * CI systems: Jenkins / buildbot or both? * Simulations / Virtualization as part of our testing strategy. * Integration of additional static code analyzers (like coverity) into our CI system. * If you are interested, please take part in the dudle poll [1]. The meeting will probably take place at FU Berlin but we could also organize it as a virtual meeting (similar to the virtual developer meeting) if necessary. [1] https://dudle.inf.tu-dresden.de/testingtheriot/ Best, Philipp ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] FIB redesign
Hi all, I started a prototype implementation [1] under consideration of the diagram on the wiki page [2]. - It provides a generic address handling and access - a basic FIB table management (add, remove, update) - collision detection for next_hops and resolving the conflict based on a preference table - reactive RP signalling using `msg_send_receive()` This prototype is not included between any RP and the `get_next_hop()` right now. Best regards, Martin [1] git pull https://github.com/BytesGalore/RIOT add_fib [2] https://github.com/RIOT-OS/RIOT/wiki/Rough-sketch-of-a-possible-FIB-modularization On 04.11.2014 11:05, Martin wrote: Hi Martine, thx for the input :) > Are you planning to only consider stateless compression (Prefix is assumed link-local) or also stateful compression (Prefix is determined by a 4-bit context ID [1] ... I plan to make it more generic, e.g. allow for providing even proprietary "solutions" for FIB table entry compression. LOWPAN_IPHC provides wonderful mechanisms to save bytes in transmissions, but there are probably (most likely) more possibilities to save bytes on the individual nodes RAM when maintaining a FIB table. Eventually the FIB will "resolve" the applied compression to provide the type required by a `get_next_hop()` request. >... we might want to consider to put those information into the same data structure (so the later of my 2 suggestions above would be) Indeed, that would by great. That's the reason I want to outsource the "Generic address" from the FIB table entry. These blobs can be shared among processes, e.g. FIB, routing protocol and ND. Liftime invalidation and such is controlled by the individual process. For instance, an expired FIB table entry would mark its internal structure as invalid and decrease the usecount of the "Generic address". > Also: have you considered Mesh-under routing [5]? (Do we have to consider this here I wonder myself? We don't have support for it anyways, so far.) [6] states some requirements for this. No, I only considered to "play" at the network layer level for now. But I will have a look. Best Regards, Martin Hi, I finally came to it to read your suggestions, too. Regarding the fact that you keep 6LoWPAN header compression in mind, too: Are you planning to only consider stateless compression (Prefix is assumed link-local) or also stateful compression (Prefix is determined by a 4-bit context ID [1], disseminated through the PAN via the context identifier option in RS [2]). Since Neighbor Cache [3], Prefix Information [4], Forwarding information, and Context Information are all very related, and we may want to save memory, we might want to consider to put those information into the same data structure (so the later of my 2 suggestions above would be). Keep in mind though, that both Prefix Information Base and Context information Base have their own lifecycles (see regarding RFCs). Also: have you considered Mesh-under routing [5]? (Do we have to consider this here I wonder myself? We don't have support for it anyways, so far.) [6] states some requirements for this. Hope this was more helpful, than confusing ;-). Cheers, Martine [1] https://tools.ietf.org/html/rfc6282#section-3.1.2 [2] https://tools.ietf.org/html/rfc6775#section-4.2 [3] http://tools.ietf.org/html/rfc4861#section-5.1 [4] https://tools.ietf.org/html/rfc4861#section-4.6.2 [5] https://tools.ietf.org/html/rfc4944#section-11 [6] http://tools.ietf.org/html/rfc6606 ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
