[riot-devel] Board documentation in Doxygen
Hello, There is this PR [1] about moving all board documentation (specs, how to flash, etc) from the wiki to Doxygen, which I would like to know your thoughts since it's a major change in the RIOT documentation. As stated there, the main motivation is to help developers keep the documentation up to date, and also provide the same entry point for board related stuff. Board content was not modified during the process, but some broken links were fixed Doxygen is probably not the best for non-API documentation, and there are some on going discussions: - Board documentation would be in boards//doc.txt in Markdown format, but with C style comments as seen here [2]. The way Doxygen processes .md files is different and somehow breaks the left navigation bar. - There's now mixed logic parts (definitions, periph config) with non logic parts (hardware TODOs, how to flash, etc). Also, there are some offline comments about the need of unifying the board documentation (e.g all boards should have at least Specs, periphs, etc. which is not present in the current wiki). This goes beyond the scope of this PR but could give some clues about how to proceed. There are some PRs [3] that depend on the resolution of this, so I wanted to ask your opinion/comments on the discussions above. Is this concept OK to be merged and keep improving later? I appreciate all comments about this. Cheers, José [1]: https://github.com/RIOT-OS/RIOT/pull/8516 [2]: https://github.com/RIOT-OS/RIOT/pull/8516/files#diff-52f923e555f1076b7f5e7ecc92e61a37 [3]: https://github.com/RIOT-OS/RIOT/pull/8651 ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Auto init in OpenThread
OK, I will go with the #ifdef proposal. Thanks :) Cheers ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] flash command without compiling
Dear RIOTers, I noticed the 'make flash' recompiles everything before flashing. What's the reason behind this? I'm working with some packages that require some time to configure/compile, and everytime I run 'flash' I have to wait the whole process to finish. I cannot even flash 2 boards at the same time because the compile process is concurrent. As always, any ideas would be appreciated :) Cheers! ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] LoRa support
Hello cr0s, Thank you for the information. I just noticed Emmanuel asked about the same thing a couple of days ago. Great to hear that! :) We just did some test on the PR and it's working OK for us. We are really interested in the development of the netdev2 adoption for the SX1276 driver. We will let you know how it goes. Cheers! ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] OpenThread port: IEEE802.15 ACK
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
[riot-devel] Raw communication between native nodes
Hi, I was wondering if there's a way to send raw data between nodes running on native. I need to send OpenThread packets between nodes (through a radio abstraction), and I'm having problems with TAP interface since they only process ethernet frames. I tried to hack a little bit (put these OT packets in ethernet frames) but is not working well. Basically, I need to emulate a radio device. Is there an easy way to achieve this? Best regards. ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Hardfault when linking OpenThread library
Hi Joakim and Daniel, Thank you for the response. Here's the gist of the .map file: https://gist.github.com/jia200x/55f87ac2d966bafb604fb17ff577a7d8 I'm using a SAMR21-xpro. I have only written the platform abstraction hook functions, so I haven't initialized objects. I'm checking all pointers now. Best regards, Jose ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] OpenThread port: IEEE802.15 ACK
Hi community, 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. Best regards ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Propagation of prefix
Thank you Kaspar! :) I will check it. ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Generic GSM/UMTS/HSDPA driver
Hi community! I have been working on a SIM900 [1] driver and a PPP stack for allowing GSM internet access in RIOT. The driver has to handle AT commands (for accessing modem's data mode) through UART and manage the PPP connection. Since most mobile devices work in the same way, I was thinking about developing something like a "generic mobile AT based device driver". For example, linux handles the dial-up part with a chat script (that consists in a list of AT commands), and then pppd does the rest. I would like to replicate the same thing in RIOT. What do you think about the idea? Best. [1]: http://www.simcom.ee/modules/gsm-gprs/sim900/ ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Usage of gnrc_pktbuf_mark
Hello community! I'm implementing a PPP stack for communication with a GPRS module. Each PPP frame is different, can carry control data or IP data, and each one has a lot of options and sub options (nested headers, etc). For example, a control frame looks like this: |--HDLC frame--|--LCP header--|LCP_option_1|LCP_option_2|... Each LCP option have it's own header too, so you could have 8-9 pktsnips per PPP frame if every LCP option is treated as a pktsnip. I'm using gnrc_pktbuf_mark to mark the HDLC header, the LCP header and each LCP options. The LCP_options header have "type" and "length" header, so I was thinking in manually parse each option without using gnrc_pktbuf_mark. As gnrc_pktbuf_mark reallocates memory with each call, which approach do you think is better? Cheers! ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Bridge border router and 6LowPan interfaces
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
