[riot-devel] cpu/samd21 is currently filled with SAMR21 files, not SAMD21
Hi, The files in cpu/samd21 are not really for SAMD21 but for SAMR21. The two cpu variants are very similar but not quite the same. The files in cpu/samd21 have been added because of the addition of the samr21-xpro board. I'm trying to figure out if I can add my board in RIOT. It is the SODAQ Autonomo which is derived from Arduino Zero. It has an Atmel SAMD21J18A (Cortex M0). Plus we have a new board, the LoRaONE which is a SAMD21G18A. As said, the files currently in cpu/samd21 tree are meant for the SAMR21. Now, if I wanted to add my SAMD21 boards, how should I proceed? -- Kees Bakker ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] cpu/samd21 is currently filled with SAMR21 files, not SAMD21
Well, then why does Atmel supply different trees for SAMR21 and SAMD21? And why are the include files different? Not a whole lot, but still. The CPU may be the same but there is (much) more than that. Furthermore, the SAMD21 has several variants and so does the SAMR21. Each have small difference in their specific include files. It feels very uncomfortable to have just one "samd21" in RIOT. So, if it was up to me, I would like to see that * all files in cpu/samd21 are moved to cpu/samr21 (to make room for the real samd21 tree) * some document is written explaining where these files came from (version, URL, etc) * write up some procedure that describes what to do when the CMSIS source is updated (bug fixes, new release, etc) * preferably no CMSIS files are changed, unless properly documented BTW. Where are these CMSIS files coming from anyway? I see them in the Arduino Zero distribution too, but I couldn't find them anywhere else on the web. They are from Atmel, but nothing on Atmel's website gives a clue. On 24-04-16 18:59, Andrew Ruder wrote: The SAMR21 is just a SAMD21 with several of the GPIOs and one of the SPI buses internally connected to the at86rf233. The CPU support would be exactly the same. -- Kees Bakker ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Working on port to SODAQ Autonomo (SAMD21)
Hi, This is a heads up to let you know I'm working on a port of RIOT to SODAQ Autonomo, which has an Atmel samd21 (like Arduino Zero). First I moved the existing cpu/samd21 tree to cpu/samr21. Then I added the samd21 CMSIS files from Arduino and the board files for the SODAQ Autonomo. For that, I copied several files from samr21-xpro. In the process I learned how to use the Atmel-ICE and how to debug via openocd. Nice :-) At the moment I can step through the hello world example. But I have no idea where the output is going. That's my next challenge. Meanwhile the changes and additions are available in my fork at g...@github.com:keestux/RIOT-OS Branch sodaq-autonomo. -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Working on port to SODAQ Autonomo (SAMD21)
On 13-06-16 09:56, Peter Kietzmann wrote: Hi Kees, Hi Peter, nice to see your interest in RIOT! Find some comments inline. Am 12.06.2016 um 21:14 schrieb Kees Bakker: Hi, This is a heads up to let you know I'm working on a port of RIOT to SODAQ Autonomo, which has an Atmel samd21 (like Arduino Zero). First I moved the existing cpu/samd21 tree to cpu/samr21. Then Why? Well *if* there is a need to change the current RIOT code base, you should open a separate PR for that. That seems like a good aproach, but I asked a related question before and I was stuck with the answer. The answer was something like: the samr21 processor is the same as the samd21, so for RIOT that's good enough. This is a question to all: How comes the Atmel samr21-xplained pro board has "samd21" CPU in RIOT? I don't know the history of how it was added. I like to understand what happened when cpu/samd21 was added. Where did the files come from? I'm guessing they're from ASF 3.18 or 3.19. ASF => Atmel Software Framework I added the samd21 CMSIS files from Arduino and the board files for the SODAQ Autonomo. For that, I copied several files from samr21-xpro. What was wrong with current CMSIS headers? https://github.com/RIOT-OS/RIOT/tree/master/cpu/samd21/include Well, these files are from the samr21 tree in ASF, yes samr21, not samd21 SAMR21 and SAMD21 have the same cpu. But there are tens of derivatives. The differences are in memory size (RAM, ROM), peripherals, etc. So if you select a board, you also want to select the particular flavor of the SAMx21. Another issue here is maintenance. How do we want to follow upgrades from Atmel? New cpu variants, bug fixes, etc. The best would be to have the files in RIOT as close as possible to the original. And a description somewhere how to do an upgrade. To answer the question why I wanted to move cpu/samd21 to cpu/samr21, it is basically driven by the need for SAMD21J18A. In the process I learned how to use the Atmel-ICE and how to debug via openocd. Nice :-) Yepp :-) At the moment I can step through the hello world example. But I have no idea where the output is going. That's my next challenge. By default the STDIO is mapped to UART_DEV(0) which will generally be the first device defined in the periph_conf.h file of the board. E.g.: https://github.com/RIOT-OS/RIOT/blob/master/boards/samr21-xpro/include/periph_conf.h#L108 The driver used should be common for samX21 MCUs but is currently not. https://github.com/RIOT-OS/RIOT/blob/master/cpu/samd21/periph/uart.c For Kinetis there already is a great code reusability: https://github.com/RIOT-OS/RIOT/tree/master/cpu/kinetis_common/periph However, you could try to set up a different STDIO UART device and connect an external UART/USB converter to see if it's about conflicting pins. That is more or less already what I did. I filled in uart_config[] with two devices and I have a serial line connect to my PC. This configuration works with the Arduino setup. But not yet with RIOT. Meanwhile the changes and additions are available in my fork at g...@github.com:keestux/RIOT-OS Branch sodaq-autonomo. Best Peter -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Working on port to SODAQ Autonomo (SAMD21)
Hey Kaspar, You added initial commit for saml21. Do you remember the origin of the saml21 include files? And now that we mention it, shouldn't we think about a structure that would nicely fit SAMD21, SAML21 and SAMR21? And move common stuff in cpu/sam21_common? On 13-06-16 14:59, Kaspar Schleiser wrote: Hey, On 06/13/2016 10:33 AM, Peter Kietzmann wrote: not 100% sure but probably it is related :-)! Thanks for pointing that out. IMO the naming is a bit weird though... Why? The MCU is an samd21. The board which has the samd21 soldered on is called samr21. How would you sort them in? Kaspar ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Working on port to SODAQ Autonomo (SAMD21)
On 13-06-16 20:55, Kees Bakker wrote: That is more or less already what I did. I filled in uart_config[] with two devices and I have a serial line connect to my PC. This configuration works with the Arduino setup. But not yet with RIOT. I almost gave up ..., but then ... �main(): This is RIOT! (Version: 2016.07-devel-191-g42127-rapper-sodaq-autonomo) Hello World! You are running RIOT on a(n) sodaq-autonomo board. This board features a(n) samd21 MCU. Yeah, it's working. Well, hello world is. (( It's getting too late now. I'll explain later this week what was needed to make it work. )) -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Working on port to SODAQ Autonomo (SAMD21)
On 13-06-16 22:39, Peter Kietzmann wrote: Hi Kees, honestly just now I got your actual problem and I remember what I stumbled upon this morning: # define the cpu used by SAMR21 Xplained Pro board export CPU = samd21 export CPU_MODEL = samr21x18a https://github.com/RIOT-OS/RIOT/blob/master/boards/samr21-xpro/Makefile.include However, I won't say "for RIOT that's good enough". To summarize: The main questions are (i) how to split different CPUs/MCUs with rather small differences and (ii) how to reuse most of the code. Right? Correct. For (ii) it would obviously be the best way to have drivers and stuff in the common folder. Personally I have no idea if this is possible or not, it depends on the differences. If these are too big, one needs to stay with a separate CPU folder for each "family". Yes, that is certainly possible. All these SAM devices can be handled with a common code base. Someone already started such a common place: cpu/sam21_common. We should continue with that. If you ask me, I'd say that already a lot of files from cpu/samd21/periph can be moved to cpu/sam21_common. For (i) won't it be enough to export the CPU_MODEL by the board and adjust the include paths properly, as done e.g. here? Yes, that is the right thing to do. For Atmel there is one more thing: CFLAGS must have a define like -D__SAMD21J18A__, otherwise the correct include files aren't selected. https://github.com/RIOT-OS/RIOT/blob/master/cpu/stm32f3/include/cpu_conf.h#L27 One other question is the need for changing the CPU name of the Atmel samr21-xpro board from "samd21" to "samr21". In your regards I think it could make sense but with a solution as described in (i) above, there won't be a need for that. Do I see that correctly? I don't care too much how the CPU is called. But maybe it is useful to know which CPU variant it is, like SAMD21J18A. Generally I'm not too much into Atmels product series and I would like to hear Kaspar's opinion as he knows RIOTs architecture much better than me. I'd be interested to know what Kaspar thinks about it. ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Working on port to SODAQ Autonomo (SAMD21)
As promissed ... The final change to make it work was selecting the correct "mux". There were a few hardcoded things in * boards/samr21-xpro/include/periph_conf.h * cpu/samd21/periph/uart.c SAMR21_XPRO has the first serial connected to: RX - PA5 TX - PA4 static const uart_conf_t uart_config[] = { /* device, RX pin, TX pin, mux */ {&SERCOM0->USART, GPIO_PIN(PA,5), GPIO_PIN(PA,4), GPIO_MUX_D}, My SODAQ Autonomo board has the first serial connected to: RX - PA9 TX - PA10 static const uart_conf_t uart_config[] = { /* device, RX pin, TX pin, mux */ {&SERCOM0->USART, GPIO_PIN(PA,9), GPIO_PIN(PA,10), GPIO_MUX_C}, Is that all? No, welcome to the SERCOM world of ARM Cortex M0. In cpu/sam???/periph/uart.c some changes are needed too. In the next diff, the samr21 is the "old" samd21. --- cpu/samd21/periph/uart.c2016-06-13 22:41:15.358773522 +0200 +++ cpu/samr21/periph/uart.c2016-05-31 19:57:02.788554067 +0200 @@ -86,10 +86,9 @@ /* reset the UART device */ dev->CTRLA.reg = SERCOM_USART_CTRLA_SWRST; while (dev->SYNCBUSY.reg & SERCOM_USART_SYNCBUSY_SWRST) {} -/* set asynchronous mode w/o parity, LSB first, PAD2 to TX, PAD1 to RX, sample rate 16x and +/* set asynchronous mode w/o parity, LSB first, PAD0 to TX, PAD1 to RX and * use internal clock */ dev->CTRLA.reg = (SERCOM_USART_CTRLA_DORD | - SERCOM_USART_CTRLA_TXPO(0x1) | SERCOM_USART_CTRLA_RXPO(0x1) | SERCOM_USART_CTRLA_SAMPR(0x1) | SERCOM_USART_CTRLA_MODE_USART_INT_CLK); Notice the TXPO and RXPO. These indicate which "pads" the pin can use on a certain SERCOM. So, what we can learn from this is that we need to expand uart_conf_t. We need PAD configuration too. (BTW, Arduino Core is doing similar things.) Was this a TL;DR? Sorry about it then. -- Kees On 13-06-16 23:28, Peter Kietzmann wrote: Congrats! Looking forward to hear the trick that did it :-). Good night Peter Am 13.06.2016 um 23:21 schrieb Kees Bakker: On 13-06-16 20:55, Kees Bakker wrote: That is more or less already what I did. I filled in uart_config[] with two devices and I have a serial line connect to my PC. This configuration works with the Arduino setup. But not yet with RIOT. I almost gave up ..., but then ... �main(): This is RIOT! (Version: 2016.07-devel-191-g42127-rapper-sodaq-autonomo) Hello World! You are running RIOT on a(n) sodaq-autonomo board. This board features a(n) samd21 MCU. Yeah, it's working. Well, hello world is. (( It's getting too late now. I'll explain later this week what was needed to make it work. )) -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Working on port to SODAQ Autonomo (SAMD21)
On 15-06-16 09:32, Peter Kietzmann wrote: Hi Kees, if you volunteer you could start with moving code to samd21_common and open PR(s) for that :-). Well, OK. I'll give it a try. Seems like a step in the right direction. I personally won't find time for that unfortunately. On our side we could test your PR(s) with the samr21-xpro board and AFAIK Kaspar has a saml21-xpro board. Do you have a "build farm" of some sorts? Or do you run tests manually? Regarding the UART issue, could you give some more insights about the pad you want to add to uart_conf_t? I just gave it a quick look into the reference manual http://www.atmel.com/images/atmel-42181-sam-d21_datasheet.pdf but on the first sight I didn't see a difference to http://www.atmel.com/Images/Atmel-42223%E2%80%93SAM-R21_Datasheet.pdf My UART changes have nothing to do with samd21 versus samr21. It's about selecting a pin for RX, TX. For example, on Autonomo use pin PA10 for TX. PA10 is PAD2 of SERCOM0, with MUX C. The samr21_xpro has PA4 as TX, PA4 is PAD0 of SERCOM0 (ALT) with MUX D. -- Kees ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Working on port to SODAQ Autonomo (SAMD21)
On 13-06-16 14:59, Kaspar Schleiser wrote: Hey, On 06/13/2016 10:33 AM, Peter Kietzmann wrote: not 100% sure but probably it is related :-)! Thanks for pointing that out. IMO the naming is a bit weird though... Why? The MCU is an samd21. The board which has the samd21 soldered on is called samr21. How would you sort them in? Sorry to revive this thread. But I don't agree. I don't think there is such a thing as a samd21 MCU. (Perhaps you can point me to Atmel documentation to prove otherwise.) The samd21 and the samr21 are very much alike, but so is the saml21, and the saml22, and quite a few more. On Atmel's website the samr21 is described as "Single-chip ARM® Cortex®-M0+ based 32-bit Microcontroller ...". -- Kees ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Progress of port to SODAQ Autonomo
Despite the ongoing discussion of how cpu/sam* should be configured I am continuing with my effort to port RIOT to SODAQ Autonomo. The changes are available in my add-sodaq-autonomo branch at g...@github.com:keestux/RIOT.git UART and I2C are working now, and so is xtimer. Next on my list is SPI. For I2C there are a few changes in gpio that make the code simpler and configuration easier to understand. (At least, that's what I think :-) Coding. While going through the code I notice that there are too many "magic" constants. Hard coded numbers that are obvious for some, but not obvious for others. My advise: always try to use defines and add a comment about what constants mean. Or point to datasheet sections explaining the constants. One example (not to blame, but to hopefully improve in the future). cpu/samd21/cpu.c: /* redirect all peripherals to a disabled clock generator (7) by default */ for (int i = 0x3; i <= 0x22; i++) { What is that 0x22? It probably is SAMR21's GCLK_PTC, the last non-reserved Generic Clock Selection ID. BTW, the last non-reserved ID for SAMD21 is 0x24 which is GCLK_I2S_1. This particular should probable disable all peripherals, even the reserved ones. But the point is, the number 0x22 should explained. -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Byte array should be uint8_t, not char
Hi, The Coding Convention is clear about it. "Guidelines for pointer types (as long as it is reasonable): * use |char *| for strings and only for strings * use |uint8_t[]| as type for arbitrary byte buffers, but use |void *| to pass them around. |uint8_t[]| because we're dealing with bytes and not characters, |void *| to avoid unnecessary casting shall the need arise to have their content to have a certain type * use |uint8_t *| to pass "typed" byte buffers, e.g., link-layer addresses, where it avoids unnecessary temporary variable * use |void *| for generic typing" In the SPI driver however the transfer functions use char * parameters, but SPI is usually dealing with binary information (bytes), not strings. This leads to unnecessary casts in other parts of the code. (E.g. nvram_spi). What is our policy about this? Are we going to correct this at some point? Is it too late already (I hope not)? -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Byte array should be uint8_t, not char
Thank you for the info. It seems that gebart noticed it too :-) There is a fresh reply in #4780. On 04-07-16 19:49, Joakim Nohlgård wrote: Hi Kees, Like Ludwig wrote, there are some places which haven't followed the coding conventions because the CC weren't as clear before as they are now with regards to this. Since RIOT is relying on its community for code contributions, these kinds of clean ups may take a long time after the documentation has been updated until someone decides to fix them. The SPI periph driver is going through some rework, see https://github.com/RIOT-OS/RIOT/pull/4780 and https://github.com/RIOT-OS/RIOT/issues/4758, but it has not yet been merged because of various other things getting in the way. Best regards, Joakimr On Mon, Jul 4, 2016 at 7:23 AM, Ludwig Knüpfer mailto:ludwig.knuep...@fu-berlin.de>> wrote: Hi Kees, Unless there is a good reason to deviate from this guideline all violations should be corrected. This particular rule was added relatively recently, so it would not surprise me if not all occurrences in RIOT have been adapted yet. Cheers, Ludwig Am 3. Juli 2016 22:50:10 MESZ, schrieb Kees Bakker mailto:k...@sodaq.com>>: >Hi, > >The Coding Convention is clear about it. > >"Guidelines for pointer types (as long as it is reasonable): > > * use |char *| for strings and only for strings > * use |uint8_t[]| as type for arbitrary byte buffers, but use |void *| >to pass them around. |uint8_t[]| because we're dealing with bytes >and not characters, |void *| to avoid unnecessary casting shall the >need arise to have their content to have a certain type > * use |uint8_t *| to pass "typed" byte buffers, e.g., link-layer >addresses, where it avoids unnecessary temporary variable > * use |void *| for generic typing" > > >In the SPI driver however the transfer functions use char * parameters, > >but SPI is usually dealing with binary >information (bytes), not strings. This leads to unnecessary casts in >other parts of the code. (E.g. nvram_spi). > >What is our policy about this? Are we going to correct this at some >point? Is it too late already (I hope not)? ___ devel mailing list devel@riot-os.org <mailto: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 -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Byte array should be uint8_t, not char
Hi Ludwig, Well, it will be a challenge to smootly correct this. There are 16 CPU's that use spi_transfer_byte(s) and 6 drivers. I won't mind creating a PR, but of course I can only test it by building examples for all boards that support SPI. And look at compile errors. Or are there other procedures? On 04-07-16 07:23, Ludwig Knüpfer wrote: Hi Kees, Unless there is a good reason to deviate from this guideline all violations should be corrected. This particular rule was added relatively recently, so it would not surprise me if not all occurrences in RIOT have been adapted yet. Cheers, Ludwig Am 3. Juli 2016 22:50:10 MESZ, schrieb Kees Bakker : Hi, The Coding Convention is clear about it. "Guidelines for pointer types (as long as it is reasonable): * use |char *| for strings and only for strings * use |uint8_t[]| as type for arbitrary byte buffers, but use |void *| to pass them around. |uint8_t[]| because we're dealing with bytes and not characters, |void *| to avoid unnecessary casting shall the need arise to have their content to have a certain type * use |uint8_t *| to pass "typed" byte buffers, e.g., link-layer addresses, where it avoids unnecessary temporary variable * use |void *| for generic typing" In the SPI driver however the transfer functions use char * parameters, but SPI is usually dealing with binary information (bytes), not strings. This leads to unnecessary casts in other parts of the code. (E.g. nvram_spi). What is our policy about this? Are we going to correct this at some point? Is it too late already (I hope not)? ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Is samr21-xpro SPI working
Hey, Can someone confirm that SPI is working on the samr21-xpro board? I'm trying to make SPI work on my Autonomo board, but I haven't succeeded yet. FYI, I'm also reorganizing the code so there are a lot of parameters that can be of influence. I can't use the current code because the pins and the SERCOMs are different. It would help me to know that it works on samr21-xpro. -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Is samr21-xpro SPI working
OK thanks. However, your remark about SPI1 puzzles me a bit, because it was using an incorrect PAD setting. PR #5609 fixed today. On 05-07-16 23:21, Baptiste Clenet wrote: I can confirm that it works properly. SPI is used to communicate with the transceiver on samr21-xpro and communication works so SPI works, I used SPI1 also with no problem 2016-07-05 21:50 GMT+02:00 Kees Bakker : Hey, Can someone confirm that SPI is working on the samr21-xpro board? I'm trying to make SPI work on my Autonomo board, but I haven't succeeded yet. FYI, I'm also reorganizing the code so there are a lot of parameters that can be of influence. I can't use the current code because the pins and the SERCOMs are different. It would help me to know that it works on samr21-xpro. -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Is samr21-xpro SPI working
Ah, _now_ it makes sense. :-) Thanks for letting me know. That leaves me with my own SPI problem. On my Autonomo I can't get it to work. It is working with Arduino, but with RIOT (under construction) it's not :-( On 06-07-16 22:53, Baptiste Clenet wrote: Yes I know, I changed it to make it work :) (SPI1) 2016-07-06 22:48 GMT+02:00 Kees Bakker : OK thanks. However, your remark about SPI1 puzzles me a bit, because it was using an incorrect PAD setting. PR #5609 fixed today. On 05-07-16 23:21, Baptiste Clenet wrote: I can confirm that it works properly. SPI is used to communicate with the transceiver on samr21-xpro and communication works so SPI works, I used SPI1 also with no problem 2016-07-05 21:50 GMT+02:00 Kees Bakker : Hey, Can someone confirm that SPI is working on the samr21-xpro board? I'm trying to make SPI work on my Autonomo board, but I haven't succeeded yet. FYI, I'm also reorganizing the code so there are a lot of parameters that can be of influence. I can't use the current code because the pins and the SERCOMs are different. It would help me to know that it works on samr21-xpro. -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Is samr21-xpro SPI working
This very same setup works perfectly with Arduino. It is a SAMD21 on a Autonomo (very much like Arduine Zero). It has a 16Mb "serial flash" chip on it. I started with the code from cpu/samd21 that was developed for the samr21-xpro board. The "only" thing I had to change is the pins for the SPI. And with the pins I also had to change the SERCOM, the PADs and the pin MUX. And yes, I checked the SS pin (and all other pins) over and over. So far I was able to get UART and I2C working. But for more than a week now I am stuck at SPI. I use the tests/periph_spi test program. �main(): This is RIOT! (Version: 2016.07-devel-336-g38dc1-rapper-add-sodaq-autonomo) RIOT low-level SPI driver test This application enables you to test a platforms SPI driver implementation. Enter 'help' to get started > �main(): This is RIOT! (Version: 2016.07-devel-336-g38dc1-rapper-add-sodaq-autonomo) RIOT low-level SPI driver test This application enables you to test a platforms SPI driver implementation. Enter 'help' to get started > help Command Description --- init_master Initialize node as SPI master init_slave Initialize node as SPI slave send Transfer string to slave (only in master mode) print_rx Print the received string (only in slave mode) reboot Reboot the node > > init_master 0 0 23 SPI_0 successfully initialized as master, cs: GPIO_1090536471, mode: 0, speed: 2 > > send Transfered 5 bytes: MOSI 01234 0x9f 0x00 0x00 0x00 0x00 ?? ?? ?? ?? ?? MISO 01234 0xff 0xff 0xff 0xff 0xff ?? ?? ?? ?? ?? It drives me nuts. Any hint is greatly appreciated. -- Kees On 08-07-16 19:03, Baptiste Clenet wrote: Autonomo uses samd21 CPU? You use same driver as samr21? What's your problem? Are you sure your SPI Slave chip is working correctly? 2016-07-07 21:01 GMT+02:00 Kees Bakker : Ah, _now_ it makes sense. :-) Thanks for letting me know. That leaves me with my own SPI problem. On my Autonomo I can't get it to work. It is working with Arduino, but with RIOT (under construction) it's not :-( On 06-07-16 22:53, Baptiste Clenet wrote: Yes I know, I changed it to make it work :) (SPI1) 2016-07-06 22:48 GMT+02:00 Kees Bakker : OK thanks. However, your remark about SPI1 puzzles me a bit, because it was using an incorrect PAD setting. PR #5609 fixed today. On 05-07-16 23:21, Baptiste Clenet wrote: I can confirm that it works properly. SPI is used to communicate with the transceiver on samr21-xpro and communication works so SPI works, I used SPI1 also with no problem 2016-07-05 21:50 GMT+02:00 Kees Bakker : Hey, Can someone confirm that SPI is working on the samr21-xpro board? I'm trying to make SPI work on my Autonomo board, but I haven't succeeded yet. FYI, I'm also reorganizing the code so there are a lot of parameters that can be of influence. I can't use the current code because the pins and the SERCOMs are different. It would help me to know that it works on samr21-xpro. -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Is samr21-xpro SPI working
On 08-07-16 20:39, Kaspar Schleiser wrote: Hey, On 07/08/2016 08:16 PM, Kees Bakker wrote: It drives me nuts. Any hint is greatly appreciated. Do you have a logic analyzer? No, I don't have one. At some point I shall buy one, I guess. But that introduces new challenges. The SPI signals are not easily accessible. -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Is samr21-xpro SPI working
:-) I made a local change to the format of that message, using %lx because that way I can look up the address in the data sheet. The last two hex digits are good enough for me to see that 17 is 23. But yeah, the GPIO_PIN() is perhaps a better idea. I am using an Atmel ICE that connects via openocd. I can single step through the code with gdb (from Emacs). That way I can confirm that the CS line is indeed the expected PA23. On 11-07-16 09:17, Peter Kietzmann wrote: Hi Kees, stupid question: How do you know SPI is not working? "GPIO_1090536471" was a formatting bug, compare: https://github.com/RIOT-OS/RIOT/pull/5619 Would you try to initialize an other pin as CS line? If I see it correctly you decided for PA23. Maybe just try it with PB2 (in case you don't use it for other things). Best Peter Am 08.07.2016 um 20:16 schrieb Kees Bakker: This very same setup works perfectly with Arduino. It is a SAMD21 on a Autonomo (very much like Arduine Zero). It has a 16Mb "serial flash" chip on it. I started with the code from cpu/samd21 that was developed for the samr21-xpro board. The "only" thing I had to change is the pins for the SPI. And with the pins I also had to change the SERCOM, the PADs and the pin MUX. And yes, I checked the SS pin (and all other pins) over and over. So far I was able to get UART and I2C working. But for more than a week now I am stuck at SPI. I use the tests/periph_spi test program. �main(): This is RIOT! (Version: 2016.07-devel-336-g38dc1-rapper-add-sodaq-autonomo) RIOT low-level SPI driver test This application enables you to test a platforms SPI driver implementation. Enter 'help' to get started > �main(): This is RIOT! (Version: 2016.07-devel-336-g38dc1-rapper-add-sodaq-autonomo) RIOT low-level SPI driver test This application enables you to test a platforms SPI driver implementation. Enter 'help' to get started > help Command Description --- init_master Initialize node as SPI master init_slave Initialize node as SPI slave send Transfer string to slave (only in master mode) print_rx Print the received string (only in slave mode) reboot Reboot the node > > init_master 0 0 23 SPI_0 successfully initialized as master, cs: GPIO_1090536471, mode: 0, speed: 2 > > send Transfered 5 bytes: MOSI 01234 0x9f 0x00 0x00 0x00 0x00 ?? ?? ?? ?? ?? MISO 01234 0xff 0xff 0xff 0xff 0xff ?? ?? ?? ?? ?? It drives me nuts. Any hint is greatly appreciated. -- Kees On 08-07-16 19:03, Baptiste Clenet wrote: Autonomo uses samd21 CPU? You use same driver as samr21? What's your problem? Are you sure your SPI Slave chip is working correctly? 2016-07-07 21:01 GMT+02:00 Kees Bakker : Ah, _now_ it makes sense. :-) Thanks for letting me know. That leaves me with my own SPI problem. On my Autonomo I can't get it to work. It is working with Arduino, but with RIOT (under construction) it's not :-( On 06-07-16 22:53, Baptiste Clenet wrote: Yes I know, I changed it to make it work :) (SPI1) 2016-07-06 22:48 GMT+02:00 Kees Bakker : OK thanks. However, your remark about SPI1 puzzles me a bit, because it was using an incorrect PAD setting. PR #5609 fixed today. On 05-07-16 23:21, Baptiste Clenet wrote: I can confirm that it works properly. SPI is used to communicate with the transceiver on samr21-xpro and communication works so SPI works, I used SPI1 also with no problem 2016-07-05 21:50 GMT+02:00 Kees Bakker : Hey, Can someone confirm that SPI is working on the samr21-xpro board? I'm trying to make SPI work on my Autonomo board, but I haven't succeeded yet. FYI, I'm also reorganizing the code so there are a lot of parameters that can be of influence. I can't use the current code because the pins and the SERCOMs are different. It would help me to know that it works on samr21-xpro. -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com _______ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com _______ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Is samr21-xpro SPI working
On 10-07-16 19:43, Kaspar Schleiser wrote: Hey, On 07/10/2016 01:13 PM, Kees Bakker wrote: It drives me nuts. Any hint is greatly appreciated. Do you have a logic analyzer? No, I don't have one. At some point I shall buy one, I guess. But that introduces new challenges. The SPI signals are not easily accessible. I've made good experiences with the cheap Saleae ones (I've been using cheap remakes from ebay like [1]). It's easy to hook them up between MCU and SPI-device, and they come with simple but usable Linux software that can decode SPI signals. Tremendously useful for spotting timing errors ... Ah, thanks for the pointer. I'll have a look. Kaspar [1] http://www.ebay.de/itm/24MHz-8-Channel-USB-Logic-Analyzer-8-CH-Logic-Analyzer-for-Arduino-MCU-/131840997125?hash=item1eb255f705:g:FEUAAOSwQupXVjOq ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Is samr21-xpro SPI working
It was staring me in the face but I didn't see it. It was a wrong mux for the MOSI pin. I finally found by single stepping through the Arduino code. Stupid mistake that took me almost a week :-) Here's proof. > init_master 0 0 23 SPI_0 successfully initialized as master, cs: GPIO_0x41004417, mode: 0, speed: 2 > > send Transfered 5 bytes: MOSI 01234 0x9f 0x00 0x00 0x00 0x00 ?? ?? ?? ?? ?? MISO 01234 0xff 0x1f 0x26 0x00 0x01 ?? ??& ?? ?? Anyway, I have to tidy up the code and then I consider the Autonomo ready for RIOT. On 11-07-16 09:17, Peter Kietzmann wrote: Hi Kees, stupid question: How do you know SPI is not working? "GPIO_1090536471" was a formatting bug, compare: https://github.com/RIOT-OS/RIOT/pull/5619 Would you try to initialize an other pin as CS line? If I see it correctly you decided for PA23. Maybe just try it with PB2 (in case you don't use it for other things). Best Peter Am 08.07.2016 um 20:16 schrieb Kees Bakker: This very same setup works perfectly with Arduino. It is a SAMD21 on a Autonomo (very much like Arduine Zero). It has a 16Mb "serial flash" chip on it. I started with the code from cpu/samd21 that was developed for the samr21-xpro board. The "only" thing I had to change is the pins for the SPI. And with the pins I also had to change the SERCOM, the PADs and the pin MUX. And yes, I checked the SS pin (and all other pins) over and over. So far I was able to get UART and I2C working. But for more than a week now I am stuck at SPI. I use the tests/periph_spi test program. �main(): This is RIOT! (Version: 2016.07-devel-336-g38dc1-rapper-add-sodaq-autonomo) RIOT low-level SPI driver test This application enables you to test a platforms SPI driver implementation. Enter 'help' to get started > �main(): This is RIOT! (Version: 2016.07-devel-336-g38dc1-rapper-add-sodaq-autonomo) RIOT low-level SPI driver test This application enables you to test a platforms SPI driver implementation. Enter 'help' to get started > help Command Description --- init_master Initialize node as SPI master init_slave Initialize node as SPI slave send Transfer string to slave (only in master mode) print_rx Print the received string (only in slave mode) reboot Reboot the node > > init_master 0 0 23 SPI_0 successfully initialized as master, cs: GPIO_1090536471, mode: 0, speed: 2 > > send Transfered 5 bytes: MOSI 01234 0x9f 0x00 0x00 0x00 0x00 ?? ?? ?? ?? ?? MISO 01234 0xff 0xff 0xff 0xff 0xff ?? ?? ?? ?? ?? It drives me nuts. Any hint is greatly appreciated. -- Kees On 08-07-16 19:03, Baptiste Clenet wrote: Autonomo uses samd21 CPU? You use same driver as samr21? What's your problem? Are you sure your SPI Slave chip is working correctly? 2016-07-07 21:01 GMT+02:00 Kees Bakker : Ah, _now_ it makes sense. :-) Thanks for letting me know. That leaves me with my own SPI problem. On my Autonomo I can't get it to work. It is working with Arduino, but with RIOT (under construction) it's not :-( On 06-07-16 22:53, Baptiste Clenet wrote: Yes I know, I changed it to make it work :) (SPI1) 2016-07-06 22:48 GMT+02:00 Kees Bakker : OK thanks. However, your remark about SPI1 puzzles me a bit, because it was using an incorrect PAD setting. PR #5609 fixed today. On 05-07-16 23:21, Baptiste Clenet wrote: I can confirm that it works properly. SPI is used to communicate with the transceiver on samr21-xpro and communication works so SPI works, I used SPI1 also with no problem 2016-07-05 21:50 GMT+02:00 Kees Bakker : Hey, Can someone confirm that SPI is working on the samr21-xpro board? I'm trying to make SPI work on my Autonomo board, but I haven't succeeded yet. FYI, I'm also reorganizing the code so there are a lot of parameters that can be of influence. I can't use the current code because the pins and the SERCOMs are different. It would help me to know that it works on samr21-xpro. -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com _______ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com _______ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com _______ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] LITTLE_ENDIAN conflicts
What is the story of LITTLE_ENDIAN? Recently a change was made in cpu/samd21 and cpu/saml21. The include files from Atmel contain #define LITTLE_ENDIAN 1 But it was changed to surround it with #ifndef / #endif Commits: d2e8efc6, 7275f98 Is it too late to say that I don't like them? What problem was being solved by adding the #ifndef/#endif ? BTW. I'm about to add a whole bunch of samXYZ.h files that all have that same define set. And I'm also planning to update the existing include files. And this process of updates and additions may happen again in the (near) future when we want to update these Atmel CMSIS files. -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] char* to int and vice versa
(( Meanwhile the original question was clarified. )) Still I wanted to say that, in C99 there are specific types to convert a pointer to an integer type. Don't just cast a pointer to an int or a long. It is not portable. On 05-09-16 18:10, Simon Brummer wrote: Well, in c any Pointer is an integer. If you want the plain numeric value, you can just cast the pointer to int. There is no conversion function Am 05.09.2016 5:58 nachm. schrieb "Adeel Mohammad Malik" <mailto:adeel.mohammad.ma...@ericsson.com>>: Hi, A quick question, what functions should I use to convert between a char * and int in RIOT? /Adeel ___ devel mailing list devel@riot-os.org <mailto:devel@riot-os.org> https://lists.riot-os.org/mailman/listinfo/devel <https://lists.riot-os.org/mailman/listinfo/devel> ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Support for SODAQ Autonomo was added
Hi, It is my pleasure to announce that a new board is supported in RIOT, SODAQ Autonomo. The board has many similarities to the Arduino Zero, so it shouldn't be too hard to get that board supported as well. If anyone feels the need to pick that up, be my guest. Meanwhile I'll continue to work on improving the support of my own board. And all the devices that I'm interested in, such as: * data flash AT45DB161 * SODAQ 3G/2G (Bee slot device with UBlox modem) * BME280 -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Byte array should be uint8_t, not char
Hi Joakim, I've done a PR for SPI. https://github.com/RIOT-OS/RIOT/pull/5901 If you have a chance, can you have a look at it/ What this set of changes shows is that several developers have been inserting casts to be able to get SPI code compile without errors. These casts (from uint8_t to char) are now not needed anymore. Yes, there were quite a few files to be modified, but the changes were straightforward. I even patched a patch file :-) See pkg/u8g2/patches/0002-u8g2-add-riot-os-interface.patch -- Kees On 17-07-16 18:40, Joakim Nohlgård wrote: Hi Kees, Do you have the time/energy to resume the effort of updating the periph/spi interface in where Hauke left off in https://github.com/RIOT-OS/RIOT/pull/4780? There are a lot of device drivers which need updating, and also some existing comments on the PR. I can assist in reviewing the changes and updating device drivers, but I don't have a lot of time to spend on this right now. Best regards, Joakim On Wed, Jul 6, 2016 at 7:00 AM, Ludwig Knüpfer mailto:ludwig.knuep...@fu-berlin.de>> wrote: Hi Kees, I assume there are more violations than the ones in the SPI drivers... But of course every step forward is great! Testing can be done by the community. We have plans to create a distributed test system with actual hardware attached, but sadly that has not become reality yet. Compilation can be tested automatically by running `make buildtest` for the respective test application (tests/periph_spi). Cheers, Ludwig Am 5. Juli 2016 21:31:49 MESZ, schrieb Kees Bakker mailto:k...@sodaq.com>>: >Hi Ludwig, > >Well, it will be a challenge to smootly correct this. >There are 16 CPU's that use spi_transfer_byte(s) and 6 drivers. > >I won't mind creating a PR, but of course I can only test it by >building >examples for all boards that support SPI. And look at compile errors. >Or are >there other procedures? > >On 04-07-16 07:23, Ludwig Knüpfer wrote: >> Hi Kees, >> >> Unless there is a good reason to deviate from this guideline all >violations should be corrected. This particular rule was added >relatively recently, so it would not surprise me if not all occurrences >in RIOT have been adapted yet. >> >> Cheers, >> Ludwig >> >> Am 3. Juli 2016 22:50:10 MESZ, schrieb Kees Bakker mailto:k...@sodaq.com>>: >>> Hi, >>> >>> The Coding Convention is clear about it. >>> >>> "Guidelines for pointer types (as long as it is reasonable): >>> >>> * use |char *| for strings and only for strings >>> * use |uint8_t[]| as type for arbitrary byte buffers, but use |void >*| >>> to pass them around. |uint8_t[]| because we're dealing with >bytes >>> and not characters, |void *| to avoid unnecessary casting shall >the >>> need arise to have their content to have a certain type >>> * use |uint8_t *| to pass "typed" byte buffers, e.g., link-layer >>> addresses, where it avoids unnecessary temporary variable >>> * use |void *| for generic typing" >>> >>> >>> In the SPI driver however the transfer functions use char * >parameters, >>> >>> but SPI is usually dealing with binary >>> information (bytes), not strings. This leads to unnecessary casts in >>> other parts of the code. (E.g. nvram_spi). >>> >>> What is our policy about this? Are we going to correct this at some >>> point? Is it too late already (I hope not)? >> ___ >> devel mailing list >> devel@riot-os.org <mailto:devel@riot-os.org> >> https://lists.riot-os.org/mailman/listinfo/devel > > >-- >Kees Bakker >Founder >SODAQ >M. 0031617737165 >www.sodaq.com <http://www.sodaq.com> > >___ >devel mailing list >devel@riot-os.org <mailto:devel@riot-os.org> >https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org <mailto: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 -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] I2C driver function to read a register with 16 bits address
Hi, The SHT2x I2C device has a register with a 16 bits address. If I'm correct we don't have a function in the I2C driver to do that. Right? Assuming we need to extend the driver API, what would be a good name for such a function? All I can come up with is i2c_read_regs2: /** * @brief Read multiple bytes from a register at the I2C slave with the given * address * * @param[in] dev I2C peripheral device * @param[in] address bus address of the target device * @param[in] reg the 16 bits register address on the targeted I2C device * @param[out] data array holding the received bytes * @param[in] length the number of bytes to read into `data` * * @return the number of bytes that were read * @return -1 on undefined device given */ int i2c_read_regs2(i2c_t dev, uint8_t address, uint16_t reg, char *data, int length); -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Coding conventions amendment
On 12-10-16 12:57, Ludwig Knüpfer wrote: Hi, Am 12. Oktober 2016 09:48:28 MESZ, schrieb Oleg Hahm : Dear rolling IoTlers, as far I'm concerned it has been an undocumented coding convention so far to use `int` or `unsigned int` for iterator variables in a loop instead of fixed width integer types. Does anybody object to adding this to the coding conventions explicitly? What about `size_t`? +1 for size_t -- Kees ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] I2C driver function to read a register with 16 bits address
Ah, thanks. On 12-10-16 09:48, Hauke Petersen wrote: Hi Kees, you are right, the current interface does not support 16-bit registers. We are however overhauling the I2C interface as we speak, and the re-worked interface does have support for them (see [1]). Feel free to take a look and comment on the proposal! Cheers, Hauke [1] https://github.com/RIOT-OS/RIOT/pull/4926 On 11.10.2016 21:29, Kees Bakker wrote: Hi, The SHT2x I2C device has a register with a 16 bits address. If I'm correct we don't have a function in the I2C driver to do that. Right? Assuming we need to extend the driver API, what would be a good name for such a function? All I can come up with is i2c_read_regs2: /** * @brief Read multiple bytes from a register at the I2C slave with the given * address * * @param[in] dev I2C peripheral device * @param[in] address bus address of the target device * @param[in] reg the 16 bits register address on the targeted I2C device * @param[out] data array holding the received bytes * @param[in] length the number of bytes to read into `data` * * @return the number of bytes that were read * @return -1 on undefined device given */ int i2c_read_regs2(i2c_t dev, uint8_t address, uint16_t reg, char *data, int length); ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Coding conventions amendment
On 13-10-16 22:42, Kaspar Schleiser wrote: Hi, On 10/13/2016 09:43 PM, Kees Bakker wrote: Does anybody object to adding this to the coding conventions explicitly? What about `size_t`? +1 for size_t Well, any convention would need careful wording. ``` for (uint32_t timeout = 1; timeout < (10LU*1000*1000); timeout *= 2) { if(try()) break; } ``` ... cannot blindly by convention converted to size_t as loop variable. Of course not. But I believe the question was more, in case of an unsigned type, should we use "unsigned int" or size_t. In that case I would go for size_t. IMHO this example also answers Oleg's initial concern: sometimes int or unsigned int or size_t just don't work. Sure. -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Coding conventions amendment
On 14-10-16 10:05, Oleg Hahm wrote: Hi Kees! On Fri, Oct 14, 2016 at 08:05:51AM +0200, Kees Bakker wrote: On 13-10-16 22:42, Kaspar Schleiser wrote: On 10/13/2016 09:43 PM, Kees Bakker wrote: Does anybody object to adding this to the coding conventions explicitly? What about `size_t`? +1 for size_t Well, any convention would need careful wording. ``` for (uint32_t timeout = 1; timeout < (10LU*1000*1000); timeout *= 2) { if(try()) break; } ``` ... cannot blindly by convention converted to size_t as loop variable. Of course not. But I believe the question was more, in case of an unsigned type, should we use "unsigned int" or size_t. In that case I would go for size_t. No, the initial question was whether we should recommend (unsigned) int (or (s)size_t) as loop iterator variable types. OK. In that case I wouldn't recommend anything. -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] bitfeilds
On 26-10-16 16:52, Neil Jones wrote: Hi, What is RIOT's position on using named bitfields for register definitions ? I know they are frown upon as there are no endian guarantees in the C standard, personally I don't use them, but the PIC32 device files supplied by Microchip do include bitfield structures for most registers so could make life easier ? (thankfully there are #define for most register fields too, if the answer is not to use them). I can't speak for RIOT, but personally I don't have a problem with them when they are used for register definitions. And I know that SAMD21 uses them too in Atmel's CMSIS include files. In many cases it makes the code much nicer. That doesn't mean the SAMD21 already uses them a lot. For example, we currently have code like dev(bus)->CTRLA.reg |= SERCOM_SPI_CTRLA_SWRST; while ((dev(bus)->CTRLA.reg & SERCOM_SPI_CTRLA_SWRST) || (dev(bus)->SYNCBUSY.reg & SERCOM_SPI_SYNCBUSY_SWRST)); ... while (!(dev(bus)->INTFLAG.reg & SERCOM_SPI_INTFLAG_DRE)) {} ... dev(bus)->CTRLA.reg &= ~(SERCOM_SPI_CTRLA_ENABLE); which could use bitfields and be written like this dev(bus)->CTRLA.bit.SWRST = 1; while ((dev(bus)->CTRLA.bit.SWRST) || (dev(bus)->SYNCBUSY.bit.SWRST)) {} ... while (!(dev(bus)->INTFLAG.bit.DRE)) {} ... dev(bus)->CTRLA.bit.ENABLE = 0; -- Kees ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] bitfeilds
Hey Hauke, I have a hard time to believe that a modern compiler makes worse code for bitfields. Volatile or otherwise. When I convert sam21_common spi.c to use the bitfields, the code becomes 4 bytes less. Of course it is a different story if you want to modify several bits together. Splitting it, just to use the bitfields can increase the code size. -- Kees On 27-10-16 09:05, Hauke Petersen wrote: Hi Neil, hi Kees, though named bitfields are kind of nice when it comes to code readability, they behave very poorly when it comes to code size. This is especially true for register maps, as these are typically volatile. For this reason, we don't use them in RIOT and I strongly advice not to use those. As example I was able to save several 100 bytes of ROM when removing the named bitfield use from the samr21s peripheral drivers. Cheers, Hauke On 26.10.2016 21:24, Kees Bakker wrote: On 26-10-16 16:52, Neil Jones wrote: Hi, What is RIOT's position on using named bitfields for register definitions ? I know they are frown upon as there are no endian guarantees in the C standard, personally I don't use them, but the PIC32 device files supplied by Microchip do include bitfield structures for most registers so could make life easier ? (thankfully there are #define for most register fields too, if the answer is not to use them). I can't speak for RIOT, but personally I don't have a problem with them when they are used for register definitions. And I know that SAMD21 uses them too in Atmel's CMSIS include files. In many cases it makes the code much nicer. That doesn't mean the SAMD21 already uses them a lot. For example, we currently have code like dev(bus)->CTRLA.reg |= SERCOM_SPI_CTRLA_SWRST; while ((dev(bus)->CTRLA.reg & SERCOM_SPI_CTRLA_SWRST) || (dev(bus)->SYNCBUSY.reg & SERCOM_SPI_SYNCBUSY_SWRST)); ... while (!(dev(bus)->INTFLAG.reg & SERCOM_SPI_INTFLAG_DRE)) {} ... dev(bus)->CTRLA.reg &= ~(SERCOM_SPI_CTRLA_ENABLE); which could use bitfields and be written like this dev(bus)->CTRLA.bit.SWRST = 1; while ((dev(bus)->CTRLA.bit.SWRST) || (dev(bus)->SYNCBUSY.bit.SWRST)) {} ... while (!(dev(bus)->INTFLAG.bit.DRE)) {} ... dev(bus)->CTRLA.bit.ENABLE = 0; ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] bitfeilds
On 30-10-16 10:55, Juergen Stuber wrote: On Fri, 28 Oct 2016 10:03:17 +0200 Juergen Stuber wrote: When you use shift and mask you usually do a single access for all fields of a register. Note that you shouldn't do it in two assignments (I'm seeing this in cpu/stm32l1/periph/gpio.c): port &= ~mask; port |= (new_value << shift); This will result in bigger code and the first assignment will write a spurious value to the register, which might cause problems. port = (port & ~mask) | (new_value << shift); is better. Or port = (port & ~mask) | (new_value1 << shift1) ... | (new_valueN << shiftN); for multiple fields. True. But this would not be a good example for (named) bitfields, because in this example the bitfield is dynamic. (Depends on runtime value of pin number.) -- Kees ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] BIN FILES
Yes, I have one, and I use it to burn and to debug. I'm using openocd. What do you want to know? On 03-11-16 16:25, Ilias Seitanidis wrote: Hi again, I was given an Atmel Ice device, has anyone used it? Thank you in advance! Your Faithfully, Ilias Seitanidis 2016-10-07 15:57 GMT+02:00 Oleg Hahm <mailto:oliver.h...@inria.fr>>: Hi Ilias! On Fri, Oct 07, 2016 at 03:51:48PM +0200, Ilias Seitanidis wrote: > The problem is that I have a board based on samr21 but there is no edbg usb > port, on the datasheet it mentions only > reprogramming using a usb pen drive and a .bin file, I know nothing about > the bootloader. In this case, Joakim's advice should work. I think a similar trick is used for the mbed_lpc1768. Cheers, Oleg -- Yo mamma is so fat that she sat on a binary tree and made it a linked list in constant time. ___ devel mailing list devel@riot-os.org <mailto:devel@riot-os.org> https://lists.riot-os.org/mailman/listinfo/devel <https://lists.riot-os.org/mailman/listinfo/devel> ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] BIN FILES
To burn a program you only need the ELF file. No need to convert it to BIN. Notice that I'm using a SODAQ Autonomo, with an Atmel SAMD21J18A. The openocd command is: $ MYELF=tests/driver_bme280/bin/sodaq-autonomo/driver_bme280.elf $ openocd -d2 -f boards/sodaq-autonomo/dist/openocd.cfg -c "telnet_port disabled; init; halt; at91samd bootloader 0; program {{$MYELF}} verify reset; shutdown" To be able to debug you must start openocd as a daemon waiting for GDB to connect. (You are using GNU I hope. :-) $ openocd -d2 -f boards/sodaq-autonomo/dist/openocd.cfg -c "init; halt; at91samd bootloader 0" Then start gdb with the ELF file. $ arm-none-eabi-gdb -i=mi tests/driver_bmp180/bin/sodaq-autonomo/driver_bmp180.elf In gdb you first connect to the target, give it a reset, set breakpoints and give it a go. (gdb) target remote localhost: (gdb) monitor reset halt (gdb) b main (gdb) c And of course, YMMV On 06-11-16 21:08, Ilias Seitanidis wrote: Thank you very much for your reply! I'm starting from scratch on using an external debugger. Everything is valuable :) On Nov 6, 2016 20:30, "Kees Bakker" <mailto:k...@sodaq.com>> wrote: Yes, I have one, and I use it to burn and to debug. I'm using openocd. What do you want to know? On 03-11-16 16:25, Ilias Seitanidis wrote: Hi again, I was given an Atmel Ice device, has anyone used it? Thank you in advance! Your Faithfully, Ilias Seitanidis 2016-10-07 15:57 GMT+02:00 Oleg Hahm mailto:oliver.h...@inria.fr>>: Hi Ilias! On Fri, Oct 07, 2016 at 03:51:48PM +0200, Ilias Seitanidis wrote: > The problem is that I have a board based on samr21 but there is no edbg usb > port, on the datasheet it mentions only > reprogramming using a usb pen drive and a .bin file, I know nothing about > the bootloader. In this case, Joakim's advice should work. I think a similar trick is used for the mbed_lpc1768. Cheers, Oleg -- Yo mamma is so fat that she sat on a binary tree and made it a linked list in constant time. ___ devel mailing list devel@riot-os.org <mailto:devel@riot-os.org> https://lists.riot-os.org/mailman/listinfo/devel <https://lists.riot-os.org/mailman/listinfo/devel> ___ devel mailing list devel@riot-os.org <mailto:devel@riot-os.org> https://lists.riot-os.org/mailman/listinfo/devel <https://lists.riot-os.org/mailman/listinfo/devel> -- Kees Bakker Founder SODAQ M.0031617737165 www.sodaq.com <http://www.sodaq.com> ___ devel mailing list devel@riot-os.org <mailto:devel@riot-os.org> https://lists.riot-os.org/mailman/listinfo/devel <https://lists.riot-os.org/mailman/listinfo/devel> _______ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Colorized compiler output not for Emacs users
Hey, Since commit 2811adc0 we get colorized gcc output. Hmm. That's unfortunate for Emacs users (I'm probably one of the very few). Emacs parses the compiler output and now it cannot match the error messages anymore. Would it be possible to add some variable to disable the coloring? (There's more than just this GCC diagnostics-color.) Something like DONOT_COLOR. This would be in the same category as QUIET, I guess. But really, I'm curious what people use to develop RIOT-OS. VIM?, Eclipse? Atom? Emacs? -- Kees ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] End of I2C embargo
Great! This is quite an achievement, and something to be proud of. On 02-08-18 12:49, Dylan Laduranty wrote: Dear RIOTers, The I2C rework is now merged into RIOT's master branch, then I am really happy to announce you the end of the I2C embargo ! Don't hesitate to ping pending PRs that were blocked by this embargo so maintainers can have a look at it. This rework will not be present in the 2018.07 release as we lack of time to get things merged, but you can use the master branch if you want to use it. We also create a wiki page [1] to summarize the changes introduced by this rework. We will keep working to improve this documentation. Of course, we cannot guarantee that the new I2C interface is completely bug-free. So if you encounter any errors, weird behaviour or if you have any questions, don't hesitate to send an email to the mailing list or create an issue on Github. We will continue to improve our work. Finally, I would like to deeply thanks every people involved in this huge rework, thank you for your time and your hard will. I'm really proud of what we have done here ! You guys are amazing :) Keep RIOTing ! [1] https://github.com/RIOT-OS/RIOT/wiki/I2C-rework -- Dylan Laduranty ___ 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] Driver AT, what is the concept of process_urc
Hey, First of all, who is the maintainer of driver_at? In other words, who should I be asking questions about this driver? I have a bunch of modems that I am considering to write drivers for (SIM800/900, several Ublox). There is this concept of URC, Unsolicited Response Code, that some of the modems can emit. I don't quite grasp how this is supposed to work with our AT driver. There are no examples or uses of the AT driver. Before throwing in my first question, here is an excerpt of the Ublox datasheet "The DCE/MT interface can operate in these modes: • Command mode: the DCE waits for AT command instructions. The DCE interprets all the characters received as commands to execute. The DCE may send responses back to the DTE indicating the outcome of the command or further information without having received any commands by the DTE (e.g. unsolicited response code - URC). Any communication in the command mode (in both directions) is terminated by the command line termination character. ..." The way I interpret this is that the device may or may not output URCs after sending a command. And it is not clear to me in which order URCs are mixed with the normal output. To be able to handle both normal output and URC there must be a single function that reads responses from the device and while doing so it should handle URCs. In any case, our (SODAQ) Arduino libraries do it that way. The function process_urc has a while loop that reads lines from the device, it processes URCs, but it also throws away anything else. That doesn't feel right. Or does it? Is somebody using the AT driver? Is somebody using the URC facility? -- Kees ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Driver AT, what is the concept of process_urc
Hi, There wasn't any reaction to my question, so I'm trying again. Or, should I be opening an issue at GitHub? Besides my question about the handling of URCs, I'm quite curious if there are people using the generic AT module. -- Kees On 05-08-18 13:20, Kees Bakker wrote: Hey, First of all, who is the maintainer of driver_at? In other words, who should I be asking questions about this driver? I have a bunch of modems that I am considering to write drivers for (SIM800/900, several Ublox). There is this concept of URC, Unsolicited Response Code, that some of the modems can emit. I don't quite grasp how this is supposed to work with our AT driver. There are no examples or uses of the AT driver. Before throwing in my first question, here is an excerpt of the Ublox datasheet "The DCE/MT interface can operate in these modes: • Command mode: the DCE waits for AT command instructions. The DCE interprets all the characters received as commands to execute. The DCE may send responses back to the DTE indicating the outcome of the command or further information without having received any commands by the DTE (e.g. unsolicited response code - URC). Any communication in the command mode (in both directions) is terminated by the command line termination character. ..." The way I interpret this is that the device may or may not output URCs after sending a command. And it is not clear to me in which order URCs are mixed with the normal output. To be able to handle both normal output and URC there must be a single function that reads responses from the device and while doing so it should handle URCs. In any case, our (SODAQ) Arduino libraries do it that way. The function process_urc has a while loop that reads lines from the device, it processes URCs, but it also throws away anything else. That doesn't feel right. Or does it? Is somebody using the AT driver? Is somebody using the URC facility? ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Driver AT, what is the concept of process_urc
On 10-08-18 09:10, Kaspar Schleiser wrote: He Kees, On 08/05/2018 01:20 PM, Kees Bakker wrote: First of all, who is the maintainer of driver_at? In other words, who should I be asking questions about this driver? As I'm the original author, I'd consider myself the author, but Vincent has contributed a lot. Asking on this mailing list was probably the best. Sorry for the delayed answer. What would be the best medium for me to start shooting at it? Shall I start an "issue", so that we can keep everything together? -- Kees ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Driver AT, what is the concept of process_urc
On 13-08-18 10:04, Vincent Dupont wrote: Hi Kees, Le dimanche 12 août 2018 à 14:44 +0200, Kees Bakker a écrit : On 10-08-18 09:10, Kaspar Schleiser wrote: He Kees, On 08/05/2018 01:20 PM, Kees Bakker wrote: First of all, who is the maintainer of driver_at? In other words, who should I be asking questions about this driver? As I'm the original author, I'd consider myself the author, but Vincent has contributed a lot. Asking on this mailing list was probably the best. Sorry for the delayed answer. Sorry for the late answer! I also contributed to this driver indeed, and wrote this part originally. The idea was to find a simple way to parse URC and let the user code decide when to parse them. The design is inspired by the AT parser from MBED. My understanding of the documentations from u-blox is that in between the command echo and OK, there should not be any URC other than for the given command. So parsing them in background while not doing anything else should be fine. The use-case and design have been discussed in [1] with @maxvankessel who use this code in combination with the ring indicator interrupt. As Kaspar said before, I'm also sure URC handling could be improved but this might need a big rework of the UART interface and would involve threads, which so far are kept out of this driver. Anyway, do not hesitate to open an issue or a PR if the current code is not good enough for you. [1]: https://github.com/RIOT-OS/RIOT/pull/8542 I started an issue [1]. Let me know if this is a good way to approach this. [1]: https://github.com/RIOT-OS/RIOT/issues/9785 -- Kees ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] What's the password of the user in RIOT-LORA-VM
Hey Alexandre, It was nice to meet you at the RIOT event. Thanks for all the work you put into this. For me it was also beneficial because I never had much experience with LoRa, and with your tutorial I learned about how to use the keys and such. Anyway, what is the password of the user "user" in the VM? -- Kees Bakker ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Hello world stopped working
Hi, This may sound like a stupid question, but I can't get output from hello world anymore. On my Sodaq Explorer and also on my Sodaq One. I have been away from RIOT for a few weeks and now that I get back there is no output on UART0, and the LEDs don't work either. Since last time, I upgraded my Ubuntu to 18.04. It has a newer compiler. Could that be it? binutils-arm-none-eabi 2.27-9ubuntu1+9 gcc-arm-none-eabi 15:6.3.1+svn253039-1build1 gdb-arm-none-eabi 7.10-1ubuntu3+9 libnewlib-arm-none-eabi 2.4.0.20160527-3 libstdc++-arm-none-eabi-newlib 15:6.3.1+svn253039-1+10 If not, what else could it be? It must be something obvious, but so far I haven't found it. -- Kees ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Hello world stopped working
Hey Alex, Thanks, that did the trick. Wow, what happened with that compiler? I now see that we have PR #10404 and a few issues about it. Hmm, that PR could have given me a warning. -- Kees On 05-12-18 21:20, Alexandre Abadie wrote: Hi Kees, You need a more recent version of the GNU ARM compiler, 7.x, and you only have 6.3. The recommended toolchain is the official one from ARM that can be downloaded at [1]. Just uncompress the archive somewhere in your filesystem (in /opt for example) and update your PATH variable. This is what I do and it works well. Cheers! Alex [1] https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads - Le 5 Déc 18, à 21:09, Kees Bakker k...@sodaq.com a écrit : Hi, This may sound like a stupid question, but I can't get output from hello world anymore. On my Sodaq Explorer and also on my Sodaq One. I have been away from RIOT for a few weeks and now that I get back there is no output on UART0, and the LEDs don't work either. Since last time, I upgraded my Ubuntu to 18.04. It has a newer compiler. Could that be it? binutils-arm-none-eabi 2.27-9ubuntu1+9 gcc-arm-none-eabi 15:6.3.1+svn253039-1build1 gdb-arm-none-eabi 7.10-1ubuntu3+9 libnewlib-arm-none-eabi 2.4.0.20160527-3 libstdc++-arm-none-eabi-newlib 15:6.3.1+svn253039-1+10 If not, what else could it be? It must be something obvious, but so far I haven't found it. -- Kees ___ 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] Hello world stopped working
For Ubuntu 18.04 there is a possibility to install the PPA. See [1]. What I did was to first remove (uninstall) all arm-none-eabi packages, and I also had to uninstall the gcc-avr packages due to a conflict with /usr/lib/libcc1.so.0.0.0 Next, enable the PPA and install gcc-arm-embedded. That's it. [1] https://launchpad.net/~team-gcc-arm-embedded/+archive/ubuntu/ppa On 06-12-18 08:49, smlng wrote: Hi all, Joakim is right - there are several reports of broken/non-working firmwares compiled with the arm-none-eabi-gcc and libs provided by Ubuntu:Bionic see for instance: - https://bugs.launchpad.net/ubuntu/+source/gcc-arm-none-eabi/+bug/1767223 - https://bugs.launchpad.net/ubuntu/+source/newlib/+bug/1768125 That's why our riotdocker image (and with that the Murdock-CI) uses the official releases instead of the apt-packages. Best, Sebastian On 6. Dec 2018, at 08:43, Joakim Nohlgård wrote: Hi, I don't believe that we require GCC 7 anywhere, it should still work fine to build with for example the ARM provided GCC 6 release, or the older Ubuntu/Debian toolchains. It seemed more like there is a problem with the Ubuntu packaged arm-none-eabi toolchain that produces broken binaries. /Joakim On Wed, Dec 5, 2018 at 10:05 PM Kees Bakker wrote: Hey Alex, Thanks, that did the trick. Wow, what happened with that compiler? I now see that we have PR #10404 and a few issues about it. Hmm, that PR could have given me a warning. -- Kees On 05-12-18 21:20, Alexandre Abadie wrote: Hi Kees, You need a more recent version of the GNU ARM compiler, 7.x, and you only have 6.3. The recommended toolchain is the official one from ARM that can be downloaded at [1]. Just uncompress the archive somewhere in your filesystem (in /opt for example) and update your PATH variable. This is what I do and it works well. Cheers! Alex [1] https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads - Le 5 Déc 18, à 21:09, Kees Bakker k...@sodaq.com a écrit : Hi, This may sound like a stupid question, but I can't get output from hello world anymore. On my Sodaq Explorer and also on my Sodaq One. I have been away from RIOT for a few weeks and now that I get back there is no output on UART0, and the LEDs don't work either. Since last time, I upgraded my Ubuntu to 18.04. It has a newer compiler. Could that be it? binutils-arm-none-eabi 2.27-9ubuntu1+9 gcc-arm-none-eabi 15:6.3.1+svn253039-1build1 gdb-arm-none-eabi 7.10-1ubuntu3+9 libnewlib-arm-none-eabi 2.4.0.20160527-3 libstdc++-arm-none-eabi-newlib 15:6.3.1+svn253039-1+10 If not, what else could it be? It must be something obvious, but so far I haven't found it. -- Kees ___ 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 ___ 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] Hello world stopped working
:-) Thanks I was also trying to find a way to report the conflict between the packages gcc-avr and gcc-arm-embedded. It will be a tough one to get it recognized by the right people. On 06-12-18 21:24, Ken Bannister wrote: I replaced the package using this same approach. [1] Ken [1] https://github.com/RIOT-OS/RIOT/issues/9248#issuecomment-416532408 On 12/6/18 8:11 PM, Kees Bakker wrote: For Ubuntu 18.04 there is a possibility to install the PPA. See [1]. What I did was to first remove (uninstall) all arm-none-eabi packages, and I also had to uninstall the gcc-avr packages due to a conflict with /usr/lib/libcc1.so.0.0.0 Next, enable the PPA and install gcc-arm-embedded. That's it. [1] https://launchpad.net/~team-gcc-arm-embedded/+archive/ubuntu/ppa On 06-12-18 08:49, smlng wrote: Hi all, Joakim is right - there are several reports of broken/non-working firmwares compiled with the arm-none-eabi-gcc and libs provided by Ubuntu:Bionic see for instance: - https://bugs.launchpad.net/ubuntu/+source/gcc-arm-none-eabi/+bug/1767223 - https://bugs.launchpad.net/ubuntu/+source/newlib/+bug/1768125 That's why our riotdocker image (and with that the Murdock-CI) uses the official releases instead of the apt-packages. Best, Sebastian On 6. Dec 2018, at 08:43, Joakim Nohlgård wrote: Hi, I don't believe that we require GCC 7 anywhere, it should still work fine to build with for example the ARM provided GCC 6 release, or the older Ubuntu/Debian toolchains. It seemed more like there is a problem with the Ubuntu packaged arm-none-eabi toolchain that produces broken binaries. /Joakim On Wed, Dec 5, 2018 at 10:05 PM Kees Bakker wrote: Hey Alex, Thanks, that did the trick. Wow, what happened with that compiler? I now see that we have PR #10404 and a few issues about it. Hmm, that PR could have given me a warning. -- Kees On 05-12-18 21:20, Alexandre Abadie wrote: Hi Kees, You need a more recent version of the GNU ARM compiler, 7.x, and you only have 6.3. The recommended toolchain is the official one from ARM that can be downloaded at [1]. Just uncompress the archive somewhere in your filesystem (in /opt for example) and update your PATH variable. This is what I do and it works well. Cheers! Alex [1] https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads - Le 5 Déc 18, à 21:09, Kees Bakker k...@sodaq.com a écrit : Hi, This may sound like a stupid question, but I can't get output from hello world anymore. On my Sodaq Explorer and also on my Sodaq One. I have been away from RIOT for a few weeks and now that I get back there is no output on UART0, and the LEDs don't work either. Since last time, I upgraded my Ubuntu to 18.04. It has a newer compiler. Could that be it? binutils-arm-none-eabi 2.27-9ubuntu1+9 gcc-arm-none-eabi 15:6.3.1+svn253039-1build1 gdb-arm-none-eabi 7.10-1ubuntu3+9 libnewlib-arm-none-eabi 2.4.0.20160527-3 libstdc++-arm-none-eabi-newlib 15:6.3.1+svn253039-1+10 If not, what else could it be? It must be something obvious, but so far I haven't found it. -- Kees ___ 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 ___ 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 ___ 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] RN2xx3, MAC status stuck at 4
Hey Alexandre, Sorry to bother you with a question about the RN2483. I am playing with your rn2xx3 driver in RIOT, with the test program. I have a test account at KPN and I have the necessary keys to send messages. Joining ABP to keep it simple. Here is something weird that I can't get right. I'm sending a test message and it gets to my server alright. But the RN2483 gives a timeout on the TX command. Next, the RN2483 goes into a state that I can't recover from. If I read the MAC status (with a slightly modified driver), it gives 0x000D Meaning, 110 1 110 -> Ack_timeout 1 -> network joined Then, after a while (several minutes) it goes to state 0x0009 Meaning, 100 1 100 -> Between Receive window 1 and Receive window 2 1 -> network joined And it stays in that state forever. When I try a new message it fails with an error "MAC state is in an Idle state". Now, all that I can do is to do a reset. After that I can send again. Would you have a hint as to what this can be? -- Kees Bakker ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Eliminating casts
Hey, In general, I'm not happy with casts when they are not really needed. A cast takes away an opportunity for the compiler to check things. Sometimes a cast is there to get rid of "const". That's not good. Sometimes a cast is there to get rid of "volatile". That's not good either. Suppose I make a Pull Request to eliminate casts, would that be picked up? Who would pick them up? Who decides if the PR is valid? What the general opinion about these sorts of PRs? If you want examples, here are some, from various drivers. 8X8X--- void at86rf2xx_tx_exec(const at86rf2xx_t *dev) { netdev_t *netdev = (netdev_t *)dev; 8X8X--- 8X8X--- void kw2xrf_setup(kw2xrf_t *dev, const kw2xrf_params_t *params) { netdev_t *netdev = (netdev_t *)dev; 8X8X--- 8X8X--- static void _isr(netdev_t *netdev) { ethos_t *dev = (ethos_t *) netdev; dev->netdev.event_callback((netdev_t*) dev, NETDEV_EVENT_RX_COMPLETE); 8X8X--- Cast flipflop. 8X8X--- void tcs37727_read(const tcs37727_t *dev, tcs37727_data_t *data) { ... tcs37727_trim_gain((tcs37727_t *)dev, tmpc); 8X8X--- Here tcs37727_trim_gain is actually modifying the const object. Bad. 8X8X--- return cc2420_init((cc2420_t *)dev); 8X8X--- In this case, dev is already of that type. In the Coding Conventions I like to see something written about casts. I'm not sure exactly about the wording. Here is an attempt. Casts * Try to avoid casts (a bit vague, but it should get people's attention) * Introduce helper variables to avoid multiple casts within a function * Don't cast a const pointer into a non-const pointer without an explanation in a comment. * Don't cast a pointer to a volatile object dropping the volatile without an explanation in a comment. * ... -- Kees ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Eliminating casts
On 27-12-18 13:54, Kaspar Schleiser wrote: Hi, On 12/26/18 11:16 PM, Kees Bakker wrote: Suppose I make a Pull Request to eliminate casts, would that be picked up? Always welcome! +1 on Joakim's hint to keep the PR's small. Sure void at86rf2xx_tx_exec(const at86rf2xx_t *dev) { netdev_t *netdev = (netdev_t *)dev; What would be the way to go here? 'netdev_t netdev = &dev->netdev;'? Yes, please. It's already done in several drivers. In this case, it won't work. Would need to recurse into netdev_ieee802154_t, like 'netdev_t *netdev = &dev->netdev.netdev;'. That might be less error.prone, but more confusing. Unfortunately C is not much help here. Is it more confusing? I don't think so. Personally, I prefer the &dev->netdev.netdev above the (netdev_t *)dev. Casts * Try to avoid casts (a bit vague, but it should get people's attention) * Introduce helper variables to avoid multiple casts within a function * Don't cast a const pointer into a non-const pointer without an explanation in a comment. * Don't cast a pointer to a volatile object dropping the volatile without an explanation in a comment. * ... * use dereferenced superclass field instead of "blind" cast (the netdev case above). Kaspar ___ 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] Eliminating casts
PR per driver sounds good to me. The required change in tcs37727 indeed involves a bit more. But I hope that everyone agrees that you cannot change a const object into a non-const object. Take a look at the doxygen. The param[in] is misleading, the object will be modified. Ha, it even says so in the description. /** * @brief Read sensor's data * * Besides an Autogain routine is called. If a maximum or minimum threshold * value of the channel clear is reached, then the gain will be changed * correspond to max or min threshold. * * @param[in] dev device descriptor of sensor * @param[out] data device sensor data, MUST not be NULL */ void tcs37727_read(const tcs37727_t *dev, tcs37727_data_t *data); On 26-12-18 23:29, Joakim Nohlgård wrote: I agree with your arguments. Placing casts where they are not needed may introduce errors in a future refactoring where a variable changes type. If you want your changes merged as smoothly as possible you should open a separate PR for each module you modify. It will make the review much easier. Stuff like the cc2420 change is going to get merged right away pretty much since it's obvious that there are no side effects. The tcs37727 change requires more thought for the correct change to make and may lead to some review comments. Best regards, Joakim Den ons 26 dec. 2018 23:17 skrev Kees Bakker <mailto:k...@sodaq.com>>: Hey, In general, I'm not happy with casts when they are not really needed. A cast takes away an opportunity for the compiler to check things. Sometimes a cast is there to get rid of "const". That's not good. Sometimes a cast is there to get rid of "volatile". That's not good either. Suppose I make a Pull Request to eliminate casts, would that be picked up? Who would pick them up? Who decides if the PR is valid? What the general opinion about these sorts of PRs? If you want examples, here are some, from various drivers. 8X8X--- void at86rf2xx_tx_exec(const at86rf2xx_t *dev) { netdev_t *netdev = (netdev_t *)dev; 8X8X--- 8X8X--- void kw2xrf_setup(kw2xrf_t *dev, const kw2xrf_params_t *params) { netdev_t *netdev = (netdev_t *)dev; 8X8X--- 8X8X--- static void _isr(netdev_t *netdev) { ethos_t *dev = (ethos_t *) netdev; dev->netdev.event_callback((netdev_t*) dev, NETDEV_EVENT_RX_COMPLETE); 8X8X--- Cast flipflop. 8X8X--- void tcs37727_read(const tcs37727_t *dev, tcs37727_data_t *data) { ... tcs37727_trim_gain((tcs37727_t *)dev, tmpc); 8X8X--- Here tcs37727_trim_gain is actually modifying the const object. Bad. 8X8X--- return cc2420_init((cc2420_t *)dev); 8X8X--- In this case, dev is already of that type. In the Coding Conventions I like to see something written about casts. I'm not sure exactly about the wording. Here is an attempt. Casts * Try to avoid casts (a bit vague, but it should get people's attention) * Introduce helper variables to avoid multiple casts within a function * Don't cast a const pointer into a non-const pointer without an explanation in a comment. * Don't cast a pointer to a volatile object dropping the volatile without an explanation in a comment. * ... -- Kees ___ devel mailing list devel@riot-os.org <mailto: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
[riot-devel] sched_active_thread is a volatile pointer, but volatile is ignored
Hey, Sorry if this has been discussed in the past, I couldn't find anything much about it. In a lot of our code sched_active_thread is converted into a non-volatile pointer. Is that correct? Here [1] it is described that such conversion is undefined behavior. Interestingly, there was an issue [2] which was closed with the following remark: "Abandoned, since I don't think that there are two reviewers that understand the meaning of volatile." Some more food for thought, from an artical by John Regehr [3] "Arch Robison says that volatile is almost useless for multi-threaded programming. [4]" [1] https://en.cppreference.com/w/c/language/volatile [2] https://github.com/RIOT-OS/RIOT/issues/252 [3] https://blog.regehr.org/archives/28 [4] http://software.intel.com/en-us/blogs/2007/11/30/volatile-almost-useless-for-multi-threaded-programming/ -- Kees ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] sched_active_thread is a volatile pointer, but volatile is ignored
On 07-01-19 11:21, Juan Ignacio Carrano wrote: Hi Kees, Hey Juan, On 1/4/19 10:18 PM, Kees Bakker wrote: In a lot of our code sched_active_thread is converted into a non-volatile pointer. Is that correct? Here [1] it is described that such conversion is undefined behavior. My understanding is that `sched_active_thread` is volatile in a thread context, but not in the kernel context. Therefore I thought that discarding the qualifier in code that runs in the scheduler should be OK, although a bit dirty. Now, if you tell me it's undefined behavior then it is NOT OK. I had thought of two ways to fix this: * Linker-level aliasing: define `sched_active_thread` once (in the scheduler, as non volatile) and declare it as `extern volatile` in those headers that are seen by user applications, and as `extern` in headers seen by the kernel. * C-level aliasing: redefine sched_active_thread as a union of a volatile and non-volatile. AFAICT neither of those ways of accessing should result in undefined behavior, as there as no casts being performed. What do you think? My main concern is: who made it volatile in the first place? And what was the reasoning behind it? Volatile is one of the least understood properties of the C language (my personal opinion). I'm hoping that the volatile was not just thrown in because it feels good when doing threads. And in other places the volatile is ignored, hopefully for a good reason (optimisation is _not_ a good reason). Your two alternatives result in basically the same situation as the casted pointer. The problem will always be that we need someone to judge whether the cast is correct (in the case of the union, do I need the volatile or the non volatile version). -- Kees ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] sched_active_thread is a volatile pointer, but volatile is ignored
On 08-01-19 16:10, Kaspar Schleiser wrote: Hi Kees, Hey Kaspar, On 1/7/19 9:19 PM, Kees Bakker wrote: My main concern is: who made it volatile in the first place? I did, almost a decade ago. And what was the reasoning behind it? Volatile is one of the least understood properties of the C language (my personal opinion). I'm hoping that the volatile was not just thrown in because it feels good when doing threads. And in other places the volatile is ignored, hopefully for a good reason (optimisation is _not_ a good reason). IIRC the intention was so the IPC code would create read / write accesses whenever accessing fields of thread_t. E.g.: void msg_recv(...) { if (!sched_active_thread->waiters) { // platform specific macro to suspend thread } thread_t *waiter = sched_active_thread->waiters; // ... } (or similar) My understanding of volatile back then was that the compiler could, without volatile, assume that sched_active_thread->waiters equals NULL. Well, in the example code, the compiler would just read sched_active_thread->waiters once and keep it in a register. If either sched_active_thread or waiters can change in between the uses in that function you must declare some things volatile. What is also interesting here is to ask ourselves, can sched_active_thread change in between? If so you would need to declare that variable as thread_t * volatile sched_active_thread; (( This was mentioned in one of the Github issues, but the discussion stalled. )) This was certainly a case of only (at most) half-understanding volatile, Which proves my point :-) which then turned into "if it is not broken, don't fix it". I'm not a fan of that. It is like looking away and hoping there are no problems. No matter how hard it is, we need to fully understand, especially a thing like a scheduler. Nowadays such code is always guarded with disabled IRQs. I seem to remember that we tried making sched_active_thread non-volatile at some point, breaking things, but that has also been a long time ago. I'm all for removing the qualifier. But we do have to make sure to thoroughly test core/ on all platforms. Of course we need thorough testing. Let's not rush. If I wanted to experiment with volatile changes, what would be good test programs for this? -- Kees ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] SAM Flash Read-While-Write
Hey Federico, Thanks for doing the flashpage stuff. I have some SODAQ boards, basically all SAMD21, that I use to run the flashpage test. Unfortunately, the test program crashes for read_rwwee main(): This is RIOT! (Version: 2019.04-devel-16-gc2c6f-sam_rwee_support) ROM flash read write test Please refer to the README.md for further information Flash start addr: 0x Page size: 256 Number of pages: 1024 RWWEE Flash start addr: 0x0040 RWWEE Number of pages: 8 > read_rwwee 0 Context before hardfault: r0: 0x2c24 r1: 0x0040 r2: 0x0100 r3: 0x r12: 0x lr: 0x381b pc: 0x3f78 psr: 0x2100 Misc EXC_RET: 0xfffd Attempting to reconstruct state for debugging... In GDB: set $pc=0x3f78 frame 0 bt ISR stack overflowed by at least 8 bytes. What can that be? -- Kees On 28-01-19 04:32, Federico Pellegrin wrote: Hi Marian, Sure, no problem. I just created a PR at https://github.com/RIOT-OS/RIOT/pull/10884 As it was still very early and uncertain how to structure I've started like this, but indeed maybe easier to keep track directly as a PR. Thanks! Federico Il giorno dom 27 gen 2019 alle ore 13:08 Marian Buschsieweke ha scritto: Hi, do you mind to create a pull request for it? This imho would make discussion of the code easier. You can add [WIP] in the title to highlight it's work in progress. Cheers, Marian Am 27. Januar 2019 11:44:21 MEZ schrieb Federico Pellegrin : Hi, I did a mostly working (please see below for why mostly!) scratch of the implementation and put it here for now: https://github.com/fedepell/RIOT/commit/3b9de66ce0a9d722460c3b236ef67835df91cd90 I tested it and it is working on my saml21-xpro board. I can write on the 8KBs of RWWEE memory and read it and see that it is still there after rebooting and stuff. I took care to make it compile also on saml11 (define names are different) although I cannot test this. As you will see the code is mostly a copy & paste of the standard flashpage, with a bunch of different defines used (for base adresses and registers). As I presumed in previous emails, it looks kinda ugly to me, but I'm not sure we could reuse totally the code without a major refactoring or by making many if-s in the common code (even asserts would depend on if we are using RWWEE or not) to keep them united (and therefore less performant). Please give it a look and let me know what do you think! As for "mostly working" what is still puzzling me is that the code seems to have some kind of alignment issue or so (although I take care of using aligned memory structures are required) since if I add/remove some statement it may then just hang or generate a hardfault. It is quite puzzling me since I tried to rule out all possibilities but cannot get it working. But maybe it's just that I'm stubbornly doing this from some time and I need to detach from it mentally for a while ;) But since I have to go out in a while I wanted to commit it so if someone wants to give it a look in the meantime, mostly refering to the structural question of how to implement it, it is there on github. And maybe someone has a general suggestion about this maybe-alignment issue from previous experience! Thanks! Cheers, Federico Il giorno sab 26 gen 2019 alle ore 05:46 Federico Pellegrin ha scritto: Hi Dylan and Oleg, Thanks for the feedback! Sorry I meant kilobyte indeed, but always write it wrong, both the k-s (should be K I see now) and b-s ;) Regarding implementation: To make it interrupt driven I guess it would be quite more a radical change, so I would look at least for now for a blocking one, which basically makes it just an additional flash area no different than the main one. About doing it similar to eeprom what I see, API wise, is that the eeprom one you link (and eeprom in general) is not page based, while the flash one (and also the RWWEE since the interface is the same) is page based. So you need always to work with pages (erase especially). So I would see it more indeed like the flashpage itself indeed. That's why my doubts on having it separate or not, since mostly what changes in the code would be the start offset, various limits now #defines (such as FLASHPAGE_NUMOF) and some flags when accessing the CPU (ie using NVMCTRL_CTRLA_CMD_RWWEEER instead of NVMCTRL_CTRLA_CMD_ER) Cheers, Federico Il giorno ven 25 gen 2019 alle ore 09:21 Dylan Laduranty ha scritto: Hello Federico, IIRC, this flash can be use as a virtual EEPROM. Maybe It would be better to write a eeprom driver (like STM32 [1]) rather than add it to the flashpage driver ? I also think this memory is 8KB for SAML21J18 (not 8Kb), which is a lot :) As a side note: SAML21 also have 8KB of Low Power SRAM in addition to its 32 KB of SRAM I've never played with these additional memories but I'll be happy to help. Cheers, Dylan [1] https://github.com
Re: [riot-devel] SAM Flash Read-While-Write
Hey Federico, Yes, checking for NVMCTRL_RWW_EEPROM_SIZE seems to be a good approach. BTW. Be careful with using the term "revision". Where you mentioned A, B and L, that is what Atmel calls "device variant" to denote functional differences. There is also a die revision, which can be read from DSU.DID.REVISION To quote the datasheet: "Bits 11:8 – REVISION[3:0]: Revision Number Identifies the die revision number. 0x0=rev.A, 0x1=rev.B etc. Note: The device variant (last letter of the ordering number) is independent of the die revision (DSU.DID.REVISION): The device variant denotes functional differences, whereas the die revision marks evolution of the die." On 30-01-19 06:41, Federico Pellegrin wrote: Hi Kees, I gave a better look and I think the fact is that not *all* SAMD21 have the RWWEE, but just revision B and L, while not A. I got the information from this ATMEL's application note: http://ww1.microchip.com/downloads/en/AppNotes/Atmel-32219-Differences-between-SAMD21-Variants-A-B-and-L_ApplicationNote_AT04470.pdf Which revision are you using? As far as I see in RIOT the sodaq ones may indeed be As: sodaq-sara-aff/Makefile.include:export CPU_MODEL = samd21j18a sodaq-explorer/Makefile.include:export CPU_MODEL = samd21j18a samd21-xpro/Makefile.include:export CPU_MODEL = samd21j18a sodaq-autonomo/Makefile.include:export CPU_MODEL = samd21j18a In the include files we have in RIOT the defines I'm using are inside the generic samd so somehow were applying to all of them: vendor/samd21/include/instance/nvmctrl.h:#define NVMCTRL_RWWEE_PAGES 32 // Page size vendor/samd21/include/instance/nvmctrl.h:#define NVMCTRL_RWW_EEPROM_ADDR 0x0040 // Start address of the RWW EEPROM area But I could add for a presence of NVMCTRL_RWW_EEPROM_SIZE which seems to be just in the chips that have it, ie: vendor/samd21/include/samd21j16b.h:#define NVMCTRL_RWW_EEPROM_SIZE 0x800UL /* 2 kB */ vendor/samd21/include/samd21e15bu.h:#define NVMCTRL_RWW_EEPROM_SIZE 0x400UL /* 1 kB */ vendor/samd21/include/samd21g15b.h:#define NVMCTRL_RWW_EEPROM_SIZE 0x400UL /* 1 kB */ vendor/samd21/include/samd21g16b.h:#define NVMCTRL_RWW_EEPROM_SIZE 0x800UL /* 2 kB */ vendor/samd21/include/samd21e15b.h:#define NVMCTRL_RWW_EEPROM_SIZE 0x400UL /* 1 kB */ vendor/samd21/include/samd21j15b.h:#define NVMCTRL_RWW_EEPROM_SIZE 0x400UL /* 1 kB */ vendor/samd21/include/samd21g15l.h:#define NVMCTRL_RWW_EEPROM_SIZE 0x400UL /* 1 kB */ vendor/samd21/include/samd21e16b.h:#define NVMCTRL_RWW_EEPROM_SIZE 0x800UL /* 2 kB */ vendor/samd21/include/samd21e16bu.h:#define NVMCTRL_RWW_EEPROM_SIZE 0x800UL /* 2 kB */ vendor/samd21/include/samd21e15l.h:#define NVMCTRL_RWW_EEPROM_SIZE 0x400UL /* 1 kB */ vendor/samd21/include/samd21g16l.h:#define NVMCTRL_RWW_EEPROM_SIZE 0x800UL /* 2 kB */ vendor/samd21/include/samd21e16l.h:#define NVMCTRL_RWW_EEPROM_SIZE 0x800UL /* 2 kB */ Cheers, Federico Il giorno mer 30 gen 2019 alle ore 04:34 Federico Pellegrin ha scritto: Thanks for testing first of all! That sounds strange, I even see that you just did just the read test, which is basically: void flashpage_rwwee_read(int page, void *data) { assert(page < (int)FLASHPAGE_RWWEE_NUMOF); memcpy(data, flashpage_rwwee_addr(page), FLASHPAGE_SIZE); } Is the RWWEE displayed info correct for the SAMD: RWWEE Flash start addr: 0x0040 RWWEE Number of pages: 8 I will get the datasheet now and check if there is some difference not obvious from the include files. Cheers, Federico Il giorno mar 29 gen 2019 alle ore 22:50 Kees Bakker ha scritto: Hey Federico, Thanks for doing the flashpage stuff. I have some SODAQ boards, basically all SAMD21, that I use to run the flashpage test. Unfortunately, the test program crashes for read_rwwee main(): This is RIOT! (Version: 2019.04-devel-16-gc2c6f-sam_rwee_support) ROM flash read write test Please refer to the README.md for further information Flash start addr: 0x Page size: 256 Number of pages:1024 RWWEE Flash start addr: 0x0040 RWWEE Number of pages: 8 > read_rwwee 0 Context before hardfault: r0: 0x2c24 r1: 0x0040 r2: 0x0100 r3: 0x r12: 0x lr: 0x381b pc: 0x3f78 psr: 0x2100 Misc EXC_RET: 0xfffd Attempting to reconstruct state for debugging... In GDB: set $pc=0x3f78 frame 0 bt ISR stack overflowed by at least 8 bytes. What can that be? -- Kees On 28-01-19 04:32, Federico Pellegrin wrote: Hi Marian, Sure, no problem. I just created a PR at https://github.com/RIOT-OS/RIOT/pull/10884 As it was still very early and uncertain how to structure I've started like this, but indeed maybe easier to keep track directly as a PR. Thanks! Federico Il giorno dom 27 gen 2019 alle ore 13:08 Marian Buschsieweke ha scritto: Hi, do you mind to create a pull request for it? This imho would make discussion of the code easier. Yo
[riot-devel] How to properly use cortexm_sleep
Hey Is there anyone using cortexm_sleep for a real application? And if yes, would you want to share how exactly that's done? Let me say that I've never written a real application with RIOT, but I would like to. One of the important requirements is that the app must be in sleep (deep sleep) and only wake up to do some work. And another requirement is to use the watchdog. That said, I'm familiar with the following Arduino pseudo code. while (forever) { do stuff disable interrupts if !certain condition __WFI(); enable interrupts } That "certain condition" is mostly checking that no WDT or RTC interrupt occurred before disabling the interrupts. These interrupts are handled by ISR's and they set a flag. This is a fairly common thing to do, I think. I don't see (or understand) how this can be achieved with RIOT-OS and cortexm_sleep. It is essential to check the condition AFTER disabling the interrupts. -- Kees Bakker ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] How to properly use cortexm_sleep
Hey Oleg, Are you using the watchdog? On 27-05-19 07:30, Oleg Artamonov wrote: Hi We do. On STM32L0, STM32L1, nRF52, etc. Checking for interrupt flags is absolutely useless here - 1) WFI checks for any relevant interrupt flags, 2) interrupt still can happen between check and WFI. -- /Sincerely yours,/ /Oleg Artamonov/ /+7 (916) 631-34-90/ /www.unwds.com/ <http://www.unwireddevices.com> 26.05.2019, 18:40, "Kees Bakker" : Hey Is there anyone using cortexm_sleep for a real application? And if yes, would you want to share how exactly that's done? Let me say that I've never written a real application with RIOT, but I would like to. One of the important requirements is that the app must be in sleep (deep sleep) and only wake up to do some work. And another requirement is to use the watchdog. That said, I'm familiar with the following Arduino pseudo code. while (forever) { do stuff disable interrupts if !certain condition __WFI(); enable interrupts } That "certain condition" is mostly checking that no WDT or RTC interrupt occurred before disabling the interrupts. These interrupts are handled by ISR's and they set a flag. This is a fairly common thing to do, I think. I don't see (or understand) how this can be achieved with RIOT-OS and cortexm_sleep. It is essential to check the condition AFTER disabling the interrupts. -- Kees Bakker ___ devel mailing list devel@riot-os.org <mailto: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] How to properly use cortexm_sleep
Thanks Juan, That's a lot of information to digest. It will take me a bit of time to go through. -- Kees On 27-05-19 14:17, Juan Ignacio Carrano wrote: Hi Kees, Some observations: 1- WFI will not send you to the deepest sleep states- clocks are gated, but many things remain powered. 2- If you are using the timer module and depending on you clock configuration you may experience more or less frequent wake ups. Whether this is acceptable is up to you. 3- Normally, if no thread is runnable (i.e. all are waiting/blocked) the idle thread is run and that has a loop which sends the MCU to the deepest state possible (considering the currently-enabled peripherals). This means that in many cases the explicit WFI is not needed if in your "while(forever)" loop you put some call that blocks waiting for the events you are interested in. The interaction between (1) and (3) means that by doing a WFI in a thread it is possible that you don't sleep as deep as you could: - The current thread will be blocked on the WFI instruction until an event arrives. - In the meantime, control will not go back to the kernel. - This means the idle thread will not run (from the schedulers point of view, you thread is still running). - The pm_whatever() call in the idle thread will not run. In conclusion, try to use the default mechanism if you can. Regards, Juan. ___ 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] How to properly use cortexm_sleep
Nice, Thanks for sharing On 28-05-19 08:48, Oleg Artamonov wrote: Hi. Yes, but for emergency reboots only. Implementations: https://github.com/unwireddevices/RIOT/blob/loralan-public/cpu/stm32_common/periph/iwdg.c and https://github.com/unwireddevices/RIOT/blob/loralan-public/cpu/nrf5x_common/periph/iwdg.c For task scheduling on sleepy devices we use RTC-based timers with 1 ms resolution and 1 week max period (https://github.com/unwireddevices/RIOT/tree/loralan-public/sys/rtctimers-millis; on STM32L, we use regular HW RTC with SSR register, on nRF52 — "software" RTC implemented on top of HW RTT unit). -- /Sincerely yours,/ /Oleg Artamonov/ /+7 (916) 631-34-90/ /www.unwds.com/ <http://www.unwireddevices.com> 27.05.2019, 21:57, "Kees Bakker" : Hey Oleg, Are you using the watchdog? On 27-05-19 07:30, Oleg Artamonov wrote: Hi We do. On STM32L0, STM32L1, nRF52, etc. Checking for interrupt flags is absolutely useless here - 1) WFI checks for any relevant interrupt flags, 2) interrupt still can happen between check and WFI. -- /Sincerely yours,/ /Oleg Artamonov/ /+7 (916) 631-34-90/ /www.unwds.com/ <http://www.unwireddevices.com/> 26.05.2019, 18:40, "Kees Bakker" <mailto:k...@sodaq.com>: Hey Is there anyone using cortexm_sleep for a real application? And if yes, would you want to share how exactly that's done? Let me say that I've never written a real application with RIOT, but I would like to. One of the important requirements is that the app must be in sleep (deep sleep) and only wake up to do some work. And another requirement is to use the watchdog. That said, I'm familiar with the following Arduino pseudo code. while (forever) { do stuff disable interrupts if !certain condition __WFI(); enable interrupts } That "certain condition" is mostly checking that no WDT or RTC interrupt occurred before disabling the interrupts. These interrupts are handled by ISR's and they set a flag. This is a fairly common thing to do, I think. I don't see (or understand) how this can be achieved with RIOT-OS and cortexm_sleep. It is essential to check the condition AFTER disabling the interrupts. -- Kees Bakker ___ devel mailing list devel@riot-os.org <mailto:devel@riot-os.org> https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org <mailto:devel@riot-os.org> https://lists.riot-os.org/mailman/listinfo/devel , ___ devel mailing list devel@riot-os.org <mailto: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] How to properly use cortexm_sleep
Thanks On 29-05-19 13:02, Robert Hartung wrote: Hey everyone, let me say a few words as Kaspar and I have been driving the implementation of this. In general there is no need to manually go to sleep, as the deepest sleep mode will always be selected from the idle thread depending on the deepest mode possible. Which mode is possible depends on the used periphs. For STM32 sleep was long not possible, as PM_BLOCKER_INITIAL was initialized with 1 for each mode, which resulted in never going to a sleep mode. From what I can see is that it is still initialized with ones? Nevertheless, to make us of it PM_BLOCKER_INITIAL should be initialized with 0. All periph modules should then individually block the sleep modes they can not operate in. For now the biggest problem was the shell/uart, as it would always block any sleep modes. An exception are some platforms, as they have a Uart which can wake them up from sleep modes. I have modified the atmega1284p implementation to make use of it [0] and [1]. Best Regards Robert [0] https://github.com/ibr-cm/RIOT/blob/idealvolting-rc1/cpu/atmega1284p/periph/pm.c [1] https://github.com/ibr-cm/RIOT/blob/idealvolting-rc1/cpu/atmega_common/periph/ On 28.05.19 20:01, Kees Bakker wrote: Nice, Thanks for sharing On 28-05-19 08:48, Oleg Artamonov wrote: Hi. Yes, but for emergency reboots only. Implementations: https://github.com/unwireddevices/RIOT/blob/loralan-public/cpu/stm32_common/periph/iwdg.c and https://github.com/unwireddevices/RIOT/blob/loralan-public/cpu/nrf5x_common/periph/iwdg.c For task scheduling on sleepy devices we use RTC-based timers with 1 ms resolution and 1 week max period (https://github.com/unwireddevices/RIOT/tree/loralan-public/sys/rtctimers-millis; on STM32L, we use regular HW RTC with SSR register, on nRF52 — "software" RTC implemented on top of HW RTT unit). -- /Sincerely yours,/ /Oleg Artamonov/ /+7 (916) 631-34-90/ /www.unwds.com/ <http://www.unwireddevices.com> 27.05.2019, 21:57, "Kees Bakker" : Hey Oleg, Are you using the watchdog? On 27-05-19 07:30, Oleg Artamonov wrote: Hi We do. On STM32L0, STM32L1, nRF52, etc. Checking for interrupt flags is absolutely useless here - 1) WFI checks for any relevant interrupt flags, 2) interrupt still can happen between check and WFI. -- /Sincerely yours,/ /Oleg Artamonov/ /+7 (916) 631-34-90/ /www.unwds.com/ <http://www.unwireddevices.com/> 26.05.2019, 18:40, "Kees Bakker" <mailto:k...@sodaq.com>: Hey Is there anyone using cortexm_sleep for a real application? And if yes, would you want to share how exactly that's done? Let me say that I've never written a real application with RIOT, but I would like to. One of the important requirements is that the app must be in sleep (deep sleep) and only wake up to do some work. And another requirement is to use the watchdog. That said, I'm familiar with the following Arduino pseudo code. while (forever) { do stuff disable interrupts if !certain condition __WFI(); enable interrupts } That "certain condition" is mostly checking that no WDT or RTC interrupt occurred before disabling the interrupts. These interrupts are handled by ISR's and they set a flag. This is a fairly common thing to do, I think. I don't see (or understand) how this can be achieved with RIOT-OS and cortexm_sleep. It is essential to check the condition AFTER disabling the interrupts. -- Kees Bakker ___ devel mailing list devel@riot-os.org <mailto:devel@riot-os.org> https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org <mailto:devel@riot-os.org> https://lists.riot-os.org/mailman/listinfo/devel , ___ devel mailing list devel@riot-os.org <mailto: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] What program do you use to connect to (USB) serial
Hey guys, This is a question for people using Linux to develop for RIOT-OS. What program do you use to connect to the (USB) serial? picocom? minicom? miniterm? grabserial? something else? I'm looking for a program that can automatically reconnect to the USB serial after the RIOT board does a restart. So far I only found that minicom will do that, but not automatically. I like the three others much better because I can more easily log the output. However, when the board resets, it loses the connection. -- Kees ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] What program do you use to connect to (USB) serial
On 17-05-2020 00:42, Michael Richardson wrote: > Kees Bakker wrote: > > This is a question for people using Linux to develop for RIOT-OS. > > > What program do you use to connect to the (USB) serial? picocom? > > minicom? miniterm? grabserial? something else? > > I sometimes use minicom, because it's generally available and can send BREAK, > but I usually wind up using screen, because then I can run it on my serial > console server, and connect to it from multiple places. > > I also use rtty, but it isn't as useable because USB serial devices don't > number consistently. > > > I'm looking for a program that can automatically reconnect to the USB > > serial after the RIOT board does a restart. So far I only found that > > minicom will do that, but not automatically. > > > I like the three others much better because I can more easily log the > > output. However, when the board resets, it loses the connection. > > Which board? > Are you using a board with an FTDI chip attached to a serial console? > Or one with a built-in USB? It's a SODAQ board (basically an Arduino Zero compatible board) with a SAMD21 that has onchip USB. > There is also the interaction with the > flashing process, which sometimes needsd the USB connection. > I'd like to convince the minicom and screen guys to do some kind of back-off > when the flasher asks. > (This is also kinda a call for dual TTY devices that showed up in SunOS > 4,AIX,etc. back in the 1990s that let UUCP run well before we had mgetty.) Well, minicom is kinda old, from the modem era. The thing I don't like about it that it really tries to emulate a terminal. With a curses-style popup when the tty device is gone. You can hit enter and it reconnects. Picocom, miniterm (Python pyserial) and grabserial is what I like. I can pipe (or tee) the output in a file. But like I said, if my program hits a watchdog reset, it reboots, and my USB connection is gone. In my startup I want to print the reset cause to know what was going on. In the past I was using one of the UARTs of the SAMD21. In a sense that was much easier. I hate to say it, but it seems on Windows there is a solution (they tell me). That, by itself, bothers me too :-) -- Kees ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] What program do you use to connect to (USB) serial
On 17-05-2020 22:36, Benjamin Valentin wrote: > On Sat, 16 May 2020 22:49:54 +0200 > Kees Bakker wrote: > >> I'm looking for a program that can automatically reconnect to the >> USB serial after the RIOT board does a restart. So far I only found >> that minicom will do that, but not automatically. > pyterm [1] will do that. It's the default when you run > > make term > > in RIOT's build system. > It will output to the console and keep logs in ~/.pyterm, so it's > pretty handy. > > [1] https://github.com/RIOT-OS/RIOT/tree/master/dist/tools/pyterm > Wow, I never knew it was there. Great. It even has timing. Impressive. Minor twit. It's missing the first 45 characters or so. 2020-05-18 20:41:02,547 # Connect to serial port /dev/ttyACM0 Welcome to pyterm! Type '/exit' to exit. 2020-05-18 20:41:03,550 # -602-g39227-add-sodaq-sff) 2020-05-18 20:41:03,551 # Hello World! 2020-05-18 20:41:03,552 # You are running RIOT on a(n) sodaq-sara-sff board. 2020-05-18 20:41:03,553 # This board features a(n) samd21 MCU. 2020-05-18 20:46:06,269 # Serial port disconnected, waiting to get reconnected... 2020-05-18 20:46:07,276 # Serial port disconnected, waiting to get reconnected... 2020-05-18 20:46:08,277 # Try to reconnect to /dev/ttyACM0 again... 2020-05-18 20:46:08,278 # Reconnected to serial port /dev/ttyACM0 2020-05-18 20:46:08,279 # -602-g39227-add-sodaq-sff) 2020-05-18 20:46:08,280 # Hello World! 2020-05-18 20:46:08,281 # You are running RIOT on a(n) sodaq-sara-sff board. 2020-05-18 20:46:08,281 # This board features a(n) samd21 MCU. Even so, I'm quite happy. -- Kees ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] How to make my boards appear in the info-boards-supported list
Hey, I want to run tests on my SODAQ board(s), but they don't appear in the output of make -C examples/hello-world info-boards-supported What are they missing? -- Kees ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] How to make my boards appear in the info-boards-supported list
OK thanks for looking into this. A quick-and-dirty investigation shows these boards that could potentially be missing. adafruit-clue arduino-mkr1000 arduino-mkrfox1200 arduino-mkrwan1300 arduino-mkrzero arduino-nano-33-ble feather-m0 nrf52840dongle sodaq-autonomo sodaq-explorer sodaq-one sodaq-sara-aff sodaq-sara-sff On 25-05-2020 09:13, Francois-Xavier Molina wrote: > Hi, > > I bisected and found the origin in [1], we are investigating. Cheers, > > Francisco > > [1] > https://github.com/RIOT-OS/RIOT/pull/13738/commits/64552a3b9a05b2dac116008fa61d1842651ffa85 > > - Mail original - >> De: "Alexandre Abadie" >> À: "devel" >> Envoyé: Lundi 25 Mai 2020 08:58:32 >> Objet: Re: [riot-devel] How to make my boards appear in the >> info-boards-supported list >> Hi Kees, >> >> This is not normal, they should appear. This is a bug in the build system. I >> tried locally and could reproduce. >> >> The best would be to open an issue on GitHub that describes the problem. >> >> Alex >> >> - Le 24 Mai 20, à 23:32, Kees Bakker k...@ijzerbout.nl a écrit : >> >>> Hey, >>> >>> I want to run tests on my SODAQ board(s), but they don't >>> appear in the output of >>> make -C examples/hello-world info-boards-supported >>> >>> What are they missing? >>> -- >>> Kees >>> ___ >>> 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 ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] How to make my boards appear in the info-boards-supported list
It's because of bootloader_arduino and the following lines in makefiles/stdio.inc.mk ifeq (,$(filter stdio_cdc_acm,$(USEMODULE))) # The arduino and nrfutil bootloader features cannot be used if the # stdio_cdc_acm module is not used FEATURES_BLACKLIST += bootloader_arduino FEATURES_BLACKLIST += bootloader_nrfutil endif It thinks that stdio_cdc_acm is not included in USEMODULE But the strange this is: USEMODULE **does** contain stdio_cdc_acm $ echo 'print: ; @echo "$(USEMODULE)"' | BOARD=sodaq-autonomo make --no-print-directory -C examples/hello-world -f Makefile -f - print auto_init auto_init_usbus board boards_common_samd21-arduino-bootloader boards_common_sodaq core core_init core_msg core_panic core_thread_flags cortexm_common cortexm_common_periph cpu event isrpipe newlib newlib_nano newlib_syscalls_default periph periph_common periph_gpio periph_init periph_init_gpio periph_init_pm periph_init_usbdev periph_pm periph_usbdev pm_layered sam0_common_periph stdio_cdc_acm sys tsrb usb_board_reset usbus usbus_cdc_acm On 25-05-2020 12:11, Kees Bakker wrote: > OK thanks for looking into this. > > A quick-and-dirty investigation shows these boards that > could potentially be missing. > > adafruit-clue > arduino-mkr1000 > arduino-mkrfox1200 > arduino-mkrwan1300 > arduino-mkrzero > arduino-nano-33-ble > feather-m0 > nrf52840dongle > sodaq-autonomo > sodaq-explorer > sodaq-one > sodaq-sara-aff > sodaq-sara-sff > > > On 25-05-2020 09:13, Francois-Xavier Molina wrote: >> Hi, >> >> I bisected and found the origin in [1], we are investigating. Cheers, >> >> Francisco >> >> [1] >> https://github.com/RIOT-OS/RIOT/pull/13738/commits/64552a3b9a05b2dac116008fa61d1842651ffa85 >> >> - Mail original - >>> De: "Alexandre Abadie" >>> À: "devel" >>> Envoyé: Lundi 25 Mai 2020 08:58:32 >>> Objet: Re: [riot-devel] How to make my boards appear in the >>> info-boards-supported list >>> Hi Kees, >>> >>> This is not normal, they should appear. This is a bug in the build system. I >>> tried locally and could reproduce. >>> >>> The best would be to open an issue on GitHub that describes the problem. >>> >>> Alex >>> >>> - Le 24 Mai 20, à 23:32, Kees Bakker k...@ijzerbout.nl a écrit : >>> >>>> Hey, >>>> >>>> I want to run tests on my SODAQ board(s), but they don't >>>> appear in the output of >>>> make -C examples/hello-world info-boards-supported >>>> >>>> What are they missing? >>>> -- >>>> Kees >>>> ___ >>>> 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 > ___ > 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] How to make my boards appear in the info-boards-supported list
Oh, I see it got fixed in #14129 On 25-05-2020 23:17, Kees Bakker wrote: > It's because of bootloader_arduino and the following lines in > makefiles/stdio.inc.mk > > ifeq (,$(filter stdio_cdc_acm,$(USEMODULE))) > # The arduino and nrfutil bootloader features cannot be used if the > # stdio_cdc_acm module is not used > FEATURES_BLACKLIST += bootloader_arduino > FEATURES_BLACKLIST += bootloader_nrfutil > endif > > It thinks that stdio_cdc_acm is not included in USEMODULE > > But the strange this is: USEMODULE **does** contain stdio_cdc_acm > > $ echo 'print: ; @echo "$(USEMODULE)"' | BOARD=sodaq-autonomo make > --no-print-directory -C examples/hello-world -f Makefile -f - print > auto_init auto_init_usbus board boards_common_samd21-arduino-bootloader > boards_common_sodaq core core_init core_msg core_panic core_thread_flags > cortexm_common cortexm_common_periph cpu event isrpipe newlib > newlib_nano newlib_syscalls_default periph periph_common periph_gpio > periph_init periph_init_gpio periph_init_pm periph_init_usbdev periph_pm > periph_usbdev pm_layered sam0_common_periph stdio_cdc_acm sys tsrb > usb_board_reset usbus usbus_cdc_acm > > > > On 25-05-2020 12:11, Kees Bakker wrote: >> OK thanks for looking into this. >> >> A quick-and-dirty investigation shows these boards that >> could potentially be missing. >> >> adafruit-clue >> arduino-mkr1000 >> arduino-mkrfox1200 >> arduino-mkrwan1300 >> arduino-mkrzero >> arduino-nano-33-ble >> feather-m0 >> nrf52840dongle >> sodaq-autonomo >> sodaq-explorer >> sodaq-one >> sodaq-sara-aff >> sodaq-sara-sff >> >> >> On 25-05-2020 09:13, Francois-Xavier Molina wrote: >>> Hi, >>> >>> I bisected and found the origin in [1], we are investigating. Cheers, >>> >>> Francisco >>> >>> [1] >>> https://github.com/RIOT-OS/RIOT/pull/13738/commits/64552a3b9a05b2dac116008fa61d1842651ffa85 >>> >>> - Mail original - >>>> De: "Alexandre Abadie" >>>> À: "devel" >>>> Envoyé: Lundi 25 Mai 2020 08:58:32 >>>> Objet: Re: [riot-devel] How to make my boards appear in the >>>> info-boards-supported list >>>> Hi Kees, >>>> >>>> This is not normal, they should appear. This is a bug in the build system. >>>> I >>>> tried locally and could reproduce. >>>> >>>> The best would be to open an issue on GitHub that describes the problem. >>>> >>>> Alex >>>> >>>> - Le 24 Mai 20, à 23:32, Kees Bakker k...@ijzerbout.nl a écrit : >>>> >>>>> Hey, >>>>> >>>>> I want to run tests on my SODAQ board(s), but they don't >>>>> appear in the output of >>>>> make -C examples/hello-world info-boards-supported >>>>> >>>>> What are they missing? >>>>> -- >>>>> Kees >>>>> ___ >>>>> 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 >> ___ >> 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
[riot-devel] Problem with test connecting to ttyACM0
Hi, My setup is more or less correct. When I do $ BOARD=sodaq-sara-sff make -C tests/evtimer_msg flash term ... 2020-05-26 21:50:39,186 # Are the reception times of all 4 msgs close to the supposed values? 2020-05-26 21:50:39,187 # At 2361 ms received msg 0: "#2 supposed to be 2361" 2020-05-26 21:50:39,187 # At 2702 ms received msg 1: "#0 supposed to be 2701" 2020-05-26 21:50:39,670 # At 3202 ms received msg 2: "#1 supposed to be 3202" 2020-05-26 21:50:42,116 # At 5656 ms received msg 3: "#3 supposed to be 5656" 2020-05-26 21:50:42,127 # By now all msgs should have been received 2020-05-26 21:50:42,127 # If yes, the tests were successful It connects nicely to the /dev/ttyACM0 with all the expected output. However, when I make the "test" target it fails to find /dev/ttyACM0 $ BOARD=sodaq-sara-sff make RIOT_CI_BUILD=1 CC_NOCOLOR=1 --no-print-directory -C /home/kees/src/RIOT/tests/evtimer_msg test r /home/kees/src/RIOT/dist/tools/pyterm/pyterm -p "/dev/ttyACM0" -b "115200" --no-reconnect --noprefix --no-repeat-command-on-empty-line Connect to serial port /dev/ttyACM0 could not open port /dev/ttyACM0: [Errno 2] No such file or directory: '/dev/ttyACM0' make[1]: *** [/home/kees/src/RIOT/Makefile.include:726: cleanterm] Error 2 Traceback (most recent call last): File "/usr/lib/python3/dist-packages/pexpect/spawnbase.py", line 166, in read_nonblocking s = os.read(self.child_fd, size) OSError: [Errno 5] Input/output error In fact, I'm trying to run compile_and_test_for_board.py, but that fails on the "make test" command. Is there a timeout value somewhere that needs to be increased? -- Kees ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Problem with test connecting to ttyACM0
Alexandre, do you have a suggestion? Anyone? On 26-05-2020 21:59, Kees Bakker wrote: > Hi, > > My setup is more or less correct. When I do > $ BOARD=sodaq-sara-sff make -C tests/evtimer_msg flash term > ... > 2020-05-26 21:50:39,186 # Are the reception times of all 4 msgs close to > the supposed values? > 2020-05-26 21:50:39,187 # At 2361 ms received msg 0: "#2 supposed to > be 2361" > 2020-05-26 21:50:39,187 # At 2702 ms received msg 1: "#0 supposed to > be 2701" > 2020-05-26 21:50:39,670 # At 3202 ms received msg 2: "#1 supposed to > be 3202" > 2020-05-26 21:50:42,116 # At 5656 ms received msg 3: "#3 supposed to > be 5656" > 2020-05-26 21:50:42,127 # By now all msgs should have been received > 2020-05-26 21:50:42,127 # If yes, the tests were successful > > It connects nicely to the /dev/ttyACM0 with all the expected > output. > > However, when I make the "test" target it fails to find /dev/ttyACM0 > > $ BOARD=sodaq-sara-sff make RIOT_CI_BUILD=1 CC_NOCOLOR=1 > --no-print-directory -C /home/kees/src/RIOT/tests/evtimer_msg test > r > /home/kees/src/RIOT/dist/tools/pyterm/pyterm -p "/dev/ttyACM0" -b > "115200" --no-reconnect --noprefix --no-repeat-command-on-empty-line > Connect to serial port /dev/ttyACM0 > could not open port /dev/ttyACM0: [Errno 2] No such file or directory: > '/dev/ttyACM0' > make[1]: *** [/home/kees/src/RIOT/Makefile.include:726: cleanterm] Error 2 > Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/pexpect/spawnbase.py", line 166, > in read_nonblocking > s = os.read(self.child_fd, size) > OSError: [Errno 5] Input/output error > > In fact, I'm trying to run compile_and_test_for_board.py, but that fails > on the "make test" command. > > Is there a timeout value somewhere that needs to be increased? ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Problem with test connecting to ttyACM0
Found it. There is a MAKE_TERM_CONNECT_DELAY that defaults to 0. This is the time between "make reset" and "make cleanterm". In my case (and I'm guessing, all boards with Arduino bootloader) you need a brief delay, for example 2 seconds. The default of MAKE_TERM_CONNECT_DELAY can be overruled by setting envvar TESTRUNNER_CONNECT_DELAY. Hurray, my first successful test $ TESTRUNNER_CONNECT_DELAY=3 ~/src/RIOT/dist/tools/compile_and_test_for_board/compile_and_test_for_board.py ~/src/RIOT sodaq-sara-sff ~/src/RIOT/results --applications tests/evtimer_msg INFO:sodaq-sara-sff:Saving toolchain INFO:sodaq-sara-sff.tests/evtimer_msg:Board supported: True INFO:sodaq-sara-sff.tests/evtimer_msg:Board has enough memory: True INFO:sodaq-sara-sff.tests/evtimer_msg:Application has test: True INFO:sodaq-sara-sff.tests/evtimer_msg:Run compilation INFO:sodaq-sara-sff.tests/evtimer_msg:Run test INFO:sodaq-sara-sff.tests/evtimer_msg:Run test.flash INFO:sodaq-sara-sff.tests/evtimer_msg:Success INFO:sodaq-sara-sff:Tests successful On 27-05-2020 21:31, Kees Bakker wrote: > Alexandre, do you have a suggestion? > Anyone? > > On 26-05-2020 21:59, Kees Bakker wrote: >> Hi, >> >> My setup is more or less correct. When I do >> $ BOARD=sodaq-sara-sff make -C tests/evtimer_msg flash term >> ... >> 2020-05-26 21:50:39,186 # Are the reception times of all 4 msgs close to >> the supposed values? >> 2020-05-26 21:50:39,187 # At 2361 ms received msg 0: "#2 supposed to >> be 2361" >> 2020-05-26 21:50:39,187 # At 2702 ms received msg 1: "#0 supposed to >> be 2701" >> 2020-05-26 21:50:39,670 # At 3202 ms received msg 2: "#1 supposed to >> be 3202" >> 2020-05-26 21:50:42,116 # At 5656 ms received msg 3: "#3 supposed to >> be 5656" >> 2020-05-26 21:50:42,127 # By now all msgs should have been received >> 2020-05-26 21:50:42,127 # If yes, the tests were successful >> >> It connects nicely to the /dev/ttyACM0 with all the expected >> output. >> >> However, when I make the "test" target it fails to find /dev/ttyACM0 >> >> $ BOARD=sodaq-sara-sff make RIOT_CI_BUILD=1 CC_NOCOLOR=1 >> --no-print-directory -C /home/kees/src/RIOT/tests/evtimer_msg test >> r >> /home/kees/src/RIOT/dist/tools/pyterm/pyterm -p "/dev/ttyACM0" -b >> "115200" --no-reconnect --noprefix --no-repeat-command-on-empty-line >> Connect to serial port /dev/ttyACM0 >> could not open port /dev/ttyACM0: [Errno 2] No such file or directory: >> '/dev/ttyACM0' >> make[1]: *** [/home/kees/src/RIOT/Makefile.include:726: cleanterm] Error 2 >> Traceback (most recent call last): >> File "/usr/lib/python3/dist-packages/pexpect/spawnbase.py", line 166, >> in read_nonblocking >> s = os.read(self.child_fd, size) >> OSError: [Errno 5] Input/output error >> >> In fact, I'm trying to run compile_and_test_for_board.py, but that fails >> on the "make test" command. >> >> Is there a timeout value somewhere that needs to be increased? > ___ > 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] Problem with test connecting to ttyACM0
I was wondering why TERM_DELAY is only defined if ifeq ($(PROGRAMMER),bossa) ... ifneq (,$(filter reset flash flash-only, $(MAKECMDGOALS))) ... TERM_DELAY ?= 2 Because now we have to set an envvar to do a "make test" On 27-05-2020 22:06, Alexandre Abadie wrote: > Ok, I replied in the meantime :) > > Good to know that you solved your issue! > > - Le 27 Mai 20, à 22:04, Kees Bakker k...@ijzerbout.nl a écrit : > >> Found it. >> >> There is a MAKE_TERM_CONNECT_DELAY that defaults to 0. This is the time >> between "make reset" and "make cleanterm". >> >> In my case (and I'm guessing, all boards with Arduino bootloader) you >> need a brief delay, for example 2 seconds. >> >> The default of MAKE_TERM_CONNECT_DELAY can be overruled by setting >> envvar TESTRUNNER_CONNECT_DELAY. >> >> Hurray, my first successful test >> >> $ TESTRUNNER_CONNECT_DELAY=3 >> ~/src/RIOT/dist/tools/compile_and_test_for_board/compile_and_test_for_board.py >> ~/src/RIOT sodaq-sara-sff ~/src/RIOT/results --applications >> tests/evtimer_msg >> INFO:sodaq-sara-sff:Saving toolchain >> INFO:sodaq-sara-sff.tests/evtimer_msg:Board supported: True >> INFO:sodaq-sara-sff.tests/evtimer_msg:Board has enough memory: True >> INFO:sodaq-sara-sff.tests/evtimer_msg:Application has test: True >> INFO:sodaq-sara-sff.tests/evtimer_msg:Run compilation >> INFO:sodaq-sara-sff.tests/evtimer_msg:Run test >> INFO:sodaq-sara-sff.tests/evtimer_msg:Run test.flash >> INFO:sodaq-sara-sff.tests/evtimer_msg:Success >> INFO:sodaq-sara-sff:Tests successful >> >> On 27-05-2020 21:31, Kees Bakker wrote: >>> Alexandre, do you have a suggestion? >>> Anyone? >>> >>> On 26-05-2020 21:59, Kees Bakker wrote: >>>> Hi, >>>> >>>> My setup is more or less correct. When I do >>>> $ BOARD=sodaq-sara-sff make -C tests/evtimer_msg flash term >>>> ... >>>> 2020-05-26 21:50:39,186 # Are the reception times of all 4 msgs close to >>>> the supposed values? >>>> 2020-05-26 21:50:39,187 # At 2361 ms received msg 0: "#2 supposed to >>>> be 2361" >>>> 2020-05-26 21:50:39,187 # At 2702 ms received msg 1: "#0 supposed to >>>> be 2701" >>>> 2020-05-26 21:50:39,670 # At 3202 ms received msg 2: "#1 supposed to >>>> be 3202" >>>> 2020-05-26 21:50:42,116 # At 5656 ms received msg 3: "#3 supposed to >>>> be 5656" >>>> 2020-05-26 21:50:42,127 # By now all msgs should have been received >>>> 2020-05-26 21:50:42,127 # If yes, the tests were successful >>>> >>>> It connects nicely to the /dev/ttyACM0 with all the expected >>>> output. >>>> >>>> However, when I make the "test" target it fails to find /dev/ttyACM0 >>>> >>>> $ BOARD=sodaq-sara-sff make RIOT_CI_BUILD=1 CC_NOCOLOR=1 >>>> --no-print-directory -C /home/kees/src/RIOT/tests/evtimer_msg test >>>> r >>>> /home/kees/src/RIOT/dist/tools/pyterm/pyterm -p "/dev/ttyACM0" -b >>>> "115200" --no-reconnect --noprefix --no-repeat-command-on-empty-line >>>> Connect to serial port /dev/ttyACM0 >>>> could not open port /dev/ttyACM0: [Errno 2] No such file or directory: >>>> '/dev/ttyACM0' >>>> make[1]: *** [/home/kees/src/RIOT/Makefile.include:726: cleanterm] Error 2 >>>> Traceback (most recent call last): >>>> File "/usr/lib/python3/dist-packages/pexpect/spawnbase.py", line 166, >>>> in read_nonblocking >>>> s = os.read(self.child_fd, size) >>>> OSError: [Errno 5] Input/output error >>>> >>>> In fact, I'm trying to run compile_and_test_for_board.py, but that fails >>>> on the "make test" command. >>>> >>>> Is there a timeout value somewhere that needs to be increased? >>> ___ >>> 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 ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Which tests are expected to succeed for my board
Hi, Now that I'm happily running automated tests for my SAMD21 board(s) I am wondering which tests should succeed. There are several that fail, but I don't know if that "normal" or not. Some examples of test that fail xtimer_periodic_wakeup: hangs at the end, last couple of printf don't come out tests/thread_flood: [ERROR] expected 30, created 29 Is there maybe a wiki with the status of the tests (per board?). -- Kees ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Which tests are expected to succeed for my board
OK, first one created. I'm afraid there are many more to come. On 30-05-2020 21:27, Alexandre Abadie wrote: > Hi Kees, > > To my knowledge, there is no wiki page for this kind of thing. > The simplest is probably to open an issue and list there the failures with > their output. This way we can easily track the on going work to fix them. > > See [1] as an example. > > Alex > > [1] https://github.com/RIOT-OS/RIOT/issues/12651 > > - Le 29 Mai 20, à 23:14, Kees Bakker k...@ijzerbout.nl a écrit : > >> Hi, >> >> Now that I'm happily running automated tests for my SAMD21 board(s) I am >> wondering which tests should succeed. There are several that fail, but I >> don't know if that "normal" or not. >> >> Some examples of test that fail >> >> xtimer_periodic_wakeup: hangs at the end, last couple of printf don't >> come out >> tests/thread_flood: [ERROR] expected 30, created 29 >> >> Is there maybe a wiki with the status of the tests (per board?). >> -- >> Kees >> ___ >> 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] Which tests are expected to succeed for my board
The reason I ask all these questions is that I'm adding support for another SODAQ board. And I was trying to do it the right way and run some tests. Maybe that was a mistake :-) Anyway, I've created the first issue. On 30-05-2020 21:30, Marian Buschsieweke wrote: > Hi, > > every failing test indicates a bug. (From time to time the bug is found in the > test rather than in the code to test.) Feel free to open an issue for the > failing tests. I personally favor a tracking issue that lists each failing > test > with a checkbox. It is motivating to tick them of one by one; and with the > tiring task of bug hunting some motivation is always welcome :-) > > Kind regards, > Marian > > On Fri, 29 May 2020 23:14:19 +0200 > Kees Bakker wrote: > >> Hi, >> >> Now that I'm happily running automated tests for my SAMD21 board(s) I am >> wondering which tests should succeed. There are several that fail, but I >> don't know if that "normal" or not. >> >> Some examples of test that fail >> >> xtimer_periodic_wakeup: hangs at the end, last couple of printf don't >> come out >> tests/thread_flood: [ERROR] expected 30, created 29 >> >> Is there maybe a wiki with the status of the tests (per board?). > > ___ > 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] Which tests are expected to succeed for my board
Well, not easier for me, I'm afraid. It will delay adding my board even longer (which is already several months in progress). And it's just a hobby for me. Otherwise it begins to look like work :-) Nevertheless, I'll see what I can do. On 30-05-2020 22:14, Alexandre Abadie wrote: > Hi, > > You can just put all of them in the same issue. It will be easier to track. > That is what is done in [1]. > > Alex > > [1] https://github.com/RIOT-OS/RIOT/issues/12651 > > - Le 30 Mai 20, à 21:42, Kees Bakker k...@ijzerbout.nl a écrit : > >> OK, first one created. I'm afraid there are many more to come. >> >> On 30-05-2020 21:27, Alexandre Abadie wrote: >>> Hi Kees, >>> >>> To my knowledge, there is no wiki page for this kind of thing. >>> The simplest is probably to open an issue and list there the failures with >>> their >>> output. This way we can easily track the on going work to fix them. >>> >>> See [1] as an example. >>> >>> Alex >>> >>> [1] https://github.com/RIOT-OS/RIOT/issues/12651 >>> >>> - Le 29 Mai 20, à 23:14, Kees Bakker k...@ijzerbout.nl a écrit : >>> >>>> Hi, >>>> >>>> Now that I'm happily running automated tests for my SAMD21 board(s) I am >>>> wondering which tests should succeed. There are several that fail, but I >>>> don't know if that "normal" or not. >>>> >>>> Some examples of test that fail >>>> >>>> xtimer_periodic_wakeup: hangs at the end, last couple of printf don't >>>> come out >>>> tests/thread_flood: [ERROR] expected 30, created 29 >>>> >>>> Is there maybe a wiki with the status of the tests (per board?). >>>> -- >>>> Kees >>>> ___ >>>> 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 > ___ > 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] Which tests are expected to succeed for my board
On 31-05-2020 12:33, Martine Sophie Lenders wrote: > Hi, > > Am 31.05.20 um 12:25 schrieb Kaspar Schleiser: >> "... FAILED (due to $reason)", and maybe not change return code to >> something that's an error. > While I like this idea I foresee a usage problem since some tests in > that script fail due to missing root permissions (or missing > scapy_unroot). If we say 'FAILED (due to missing root permissions)' I > virtually expect any sane developer to re-run the script then with > `sudo`, leading to people wondering why they are not able to compile > applications anymore, just using `make all`, as the `bin` directory was > created with root permission. Sure this can be easily fixed, I just say > "mind the consequences" ;-). > I don't agree with the "sane" part in that sentence. ;-) -- Kees ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Which tests are expected to succeed for my board
st.flash.failed) - [tests/gnrc_rpl_srh](tests/gnrc_rpl_srh/test.flash.failed) - [tests/gnrc_sixlowpan](tests/gnrc_sixlowpan/test.flash.failed) - [tests/gnrc_sixlowpan_frag](tests/gnrc_sixlowpan_frag/test.flash.failed) - [tests/gnrc_sixlowpan_iphc_w_vrb](tests/gnrc_sixlowpan_iphc_w_vrb/test.flash.failed) - [tests/gnrc_sock_async_event](tests/gnrc_sock_async_event/test.flash.failed) - [tests/gnrc_sock_dns](tests/gnrc_sock_dns/test.flash.failed) - [tests/gnrc_sock_ip](tests/gnrc_sock_ip/test.flash.failed) - [tests/gnrc_sock_neterr](tests/gnrc_sock_neterr/test.flash.failed) - [tests/gnrc_sock_udp](tests/gnrc_sock_udp/test.flash.failed) - [tests/gnrc_tcp](tests/gnrc_tcp/test.flash.failed) - [tests/heap_cmd](tests/heap_cmd/test.flash.failed) - [tests/irq](tests/irq/test.flash.failed) - [tests/irq_disable_restore](tests/irq_disable_restore/test.flash.failed) - [tests/isr_yield_higher](tests/isr_yield_higher/test.flash.failed) - [tests/kconfig](tests/kconfig/test.flash.failed) - [tests/l2util](tests/l2util/test.flash.failed) - [tests/libc_newlib](tests/libc_newlib/test.flash.failed) - [tests/log_color](tests/log_color/test.flash.failed) - [tests/log_printfnoformat](tests/log_printfnoformat/test.flash.failed) - [tests/lwip_sock_ip](tests/lwip_sock_ip/test.flash.failed) - [tests/lwip_sock_tcp](tests/lwip_sock_tcp/test.flash.failed) - [tests/lwip_sock_udp](tests/lwip_sock_udp/test.flash.failed) - [tests/malloc](tests/malloc/test.flash.failed) - [tests/memarray](tests/memarray/test.flash.failed) - [tests/msg_avail](tests/msg_avail/test.flash.failed) - [tests/msg_send_receive](tests/msg_send_receive/test.flash.failed) - [tests/msg_try_receive](tests/msg_try_receive/test.flash.failed) - [tests/mtd_flashpage](tests/mtd_flashpage/test.flash.failed) - [tests/mtd_mapper](tests/mtd_mapper/test.flash.failed) - [tests/pkg_tensorflow-lite](tests/pkg_tensorflow-lite/test.flash.failed) - [tests/stdin](tests/stdin/test.flash.failed) - [tests/vfs_plus_stdio](tests/vfs_plus_stdio/test.flash.failed) - [tests/xtimer_mutex_lock_timeout](tests/xtimer_mutex_lock_timeout/test.flash.failed) - [tests/xtimer_periodic_wakeup](tests/xtimer_periodic_wakeup/test.flash.failed) On 30-05-2020 22:19, Kees Bakker wrote: > Well, not easier for me, I'm afraid. It will delay adding my board > even longer (which is already several months in progress). > And it's just a hobby for me. Otherwise it begins to look like > work :-) > > Nevertheless, I'll see what I can do. > > On 30-05-2020 22:14, Alexandre Abadie wrote: >> Hi, >> >> You can just put all of them in the same issue. It will be easier to track. >> That is what is done in [1]. >> >> Alex >> >> [1] https://github.com/RIOT-OS/RIOT/issues/12651 >> >> - Le 30 Mai 20, à 21:42, Kees Bakker k...@ijzerbout.nl a écrit : >> >>> OK, first one created. I'm afraid there are many more to come. >>> >>> On 30-05-2020 21:27, Alexandre Abadie wrote: >>>> Hi Kees, >>>> >>>> To my knowledge, there is no wiki page for this kind of thing. >>>> The simplest is probably to open an issue and list there the failures with >>>> their >>>> output. This way we can easily track the on going work to fix them. >>>> >>>> See [1] as an example. >>>> >>>> Alex >>>> >>>> [1] https://github.com/RIOT-OS/RIOT/issues/12651 >>>> >>>> - Le 29 Mai 20, à 23:14, Kees Bakker k...@ijzerbout.nl a écrit : >>>> >>>>> Hi, >>>>> >>>>> Now that I'm happily running automated tests for my SAMD21 board(s) I am >>>>> wondering which tests should succeed. There are several that fail, but I >>>>> don't know if that "normal" or not. >>>>> >>>>> Some examples of test that fail >>>>> >>>>> xtimer_periodic_wakeup: hangs at the end, last couple of printf don't >>>>> come out >>>>> tests/thread_flood: [ERROR] expected 30, created 29 >>>>> >>>>> Is there maybe a wiki with the status of the tests (per board?). >>>>> -- >>>>> Kees >>>>> ___ >>>>> 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 >> ___ >> 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] Which tests are expected to succeed for my board
Thanks Alex, The tests that need sudo, I've skipped. For now I don't care about these. I was able to rerun quite a few tests by skipping the ones that caused the the board to hang. I also skip all the tests that need sudo. For now I don't care about these. I'll look at LOW_MEMORY_BOARDS, but if other SAMD21 don't need it, then my board shouldn't need it either. I also need to look at my execution environment. I don't docker (yet), so maybe I'm using incompatible gcc and/or newlib. I've seen strange problems with puts/printf, where part of the output is missing (and thus I get test timeouts). -- Kees On 31-05-2020 21:40, Alexandre Abadie wrote: > Hi Kees, > > Indeed that's a lot of failures! > > Regarding the failures during flash, the flashing over USB workflow is rather > fragile: if something went wrong (a crash) when testing an application, the > board might no recover and cannot be flashed automatically anymore after. > There's also the issue with connecting the terminal application to stdio that > can timeout sometimes. > > The main issues are with the "failures during test" list. I tried some of > them on arduino-mkr1000 and also got failures. So there are bugs. > > Note that you can run each of them individually using "make BOARD= board> -C tests/ flash test". This is what is called by the > "compile_and_test_board.py" script. > > Regarding "tests/bench_xtimer", you can fix the build issue by adding your > board to the LOW_MEMORY_BOARDS list [1]. For the other build failures, I > guess some Python packages are missing. Maybe add BUILD_IN_DOCKER=1 to the > test command. > > Alex > > [1] https://github.com/RIOT-OS/RIOT/blob/master/tests/bench_xtimer/Makefile#L7 > > - Le 31 Mai 20, à 21:06, Kees Bakker k...@ijzerbout.nl a écrit : > >> Let me explain a little bit more why I am struggling right now. >> >> First thing you should know is that I'm creating the support for >> a new SODAQ board (Sara SFF). >> >> Second, I haven't run the automated tests before, so I don't >> know what to expect. >> >> The complete run gives me the result below. No need to comment >> on it. I just wanted to let you know what I have to chew on. I will >> probably get back with more questions. >> >> ERROR:sodaq-sara-sff:Tests failed: 110 >> Failures during compilation: >> - [tests/bench_xtimer](tests/bench_xtimer/compilation.failed) >> - [tests/pkg_nanopb](tests/pkg_nanopb/compilation.failed) >> - [tests/suit_manifest](tests/suit_manifest/compilation.failed) >> >> Failures during test: >> - [examples/micropython](examples/micropython/test.failed) >> - [tests/bench_runtime_coreapis](tests/bench_runtime_coreapis/test.failed) >> - [tests/bench_sizeof_coretypes](tests/bench_sizeof_coretypes/test.failed) >> - [tests/bloom_bytes](tests/bloom_bytes/test.failed) >> - [tests/cond_order](tests/cond_order/test.failed) >> - >> [tests/cpp11_condition_variable](tests/cpp11_condition_variable/test.failed) >> - [tests/cpp11_mutex](tests/cpp11_mutex/test.failed) >> - [tests/cpp11_thread](tests/cpp11_thread/test.failed) >> - [tests/gnrc_ipv6_nib_dns](tests/gnrc_ipv6_nib_dns/test.failed) >> - [tests/mutex_order](tests/mutex_order/test.failed) >> - [tests/periph_gpio](tests/periph_gpio/test.failed) >> - [tests/periph_rtt](tests/periph_rtt/test.failed) >> - [tests/periph_timer](tests/periph_timer/test.failed) >> - [tests/periph_timer_periodic](tests/periph_timer_periodic/test.failed) >> - >> [tests/periph_timer_short_relative_set](tests/periph_timer_short_relative_set/test.failed) >> - [tests/periph_uart_nonblocking](tests/periph_uart_nonblocking/test.failed) >> - [tests/periph_wdt](tests/periph_wdt/test.failed) >> - [tests/pkg_c25519](tests/pkg_c25519/test.failed) >> - [tests/pkg_cifra](tests/pkg_cifra/test.failed) >> - [tests/pkg_cn-cbor](tests/pkg_cn-cbor/test.failed) >> - [tests/pkg_hacl](tests/pkg_hacl/test.failed) >> - [tests/pkg_heatshrink](tests/pkg_heatshrink/test.failed) >> - [tests/pkg_libb2](tests/pkg_libb2/test.failed) >> - [tests/pkg_libbase58](tests/pkg_libbase58/test.failed) >> - [tests/pkg_libcose](tests/pkg_libcose/test.failed) >> - [tests/pkg_libhydrogen](tests/pkg_libhydrogen/test.failed) >> - [tests/pkg_littlefs](tests/pkg_littlefs/test.failed) >> - [tests/pkg_littlefs2](tests/pkg_littlefs2/test.failed) >> - [tests/pkg_monocypher](tests/pkg_monocypher/test.failed) >> - [tests/pkg_nanocbor](tests/pkg_nanocbor/test.failed) >> - [tests/pkg_qcbor](tests/pkg_qcbor/test.failed) >> - [tests/pkg_qdsa](tests/pkg_qd
Re: [riot-devel] Which tests are expected to succeed for my board
On 01-06-2020 11:31, Alexandre Abadie wrote: > I've seen strange problems with >> puts/printf, where >> part of the output is missing (and thus I get test timeouts). > Same here, I think there's an issue stdio over USB. If the string to be > printed starts with a space or a tab, it's not printed over USB. > I've create an issue for it, #14184 -- Kees ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel