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

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

Re: [riot-devel] cpu/samd21 is currently filled with SAMR21 files, not SAMD21

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] cpu/samd21 is currently filled with SAMR21 files, not SAMD21

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

Re: [riot-devel] Is samr21-xpro SPI working

g, 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 s

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

Re: [riot-devel] Is samr21-xpro SPI working

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 "

[riot-devel] LITTLE_ENDIAN conflicts

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] Byte array should be uint8_t, not char

. Cheers, Ludwig Am 3. Juli 2016 22:50:10 MESZ, schrieb Kees Bakker <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 b

Re: [riot-devel] Is samr21-xpro SPI working

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 <k...@sodaq.com>: Ah, _now_ it makes sense. :-) Thanks for letting me know. T

Re: [riot-devel] Is samr21-xpro SPI working

works so SPI works, I used SPI1 also with no problem 2016-07-05 21:50 GMT+02:00 Kees Bakker <k...@sodaq.com>: 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 c

[riot-devel] Progress of port to SODAQ Autonomo

pherals, 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

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

[riot-devel] Support for SODAQ Autonomo was added

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

Re: [riot-devel] Byte array should be uint8_t, not char

buildtest` for the respective test application (tests/periph_spi). Cheers, Ludwig Am 5. Juli 2016 21:31:49 MESZ, schrieb Kees Bakker <k...@sodaq.com <mailto:k...@sodaq.com>>: >Hi Ludwig, > >Well, it will be a challenge to smootly correct this.

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

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

Re: [riot-devel] BIN FILES

iot-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

) 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" <k...@sodaq.co

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

[riot-devel] I2C driver function to read a register with 16 bits address

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 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

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

[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

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

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

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

Re: [riot-devel] Eliminating casts

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 n

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

[riot-devel] RN2xx3, MAC status stuck at 4

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

Re: [riot-devel] Hello world stopped working

://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

[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

Re: [riot-devel] Hello world stopped working

://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

Re: [riot-devel] Hello world stopped working

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

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

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

[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

[riot-devel] What's the password of the user in RIOT-LORA-VM

;user" in the VM? -- Kees Bakker ___ 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

Re: [riot-devel] SAM Flash Read-While-Write

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:

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

Re: [riot-devel] How to properly use cortexm_sleep

. -- /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

[riot-devel] How to properly use cortexm_sleep

texm_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

/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

Re: [riot-devel] How to properly use cortexm_sleep

mplemented 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

[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

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 e

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

Re: [riot-devel] Problem with test connecting to ttyACM0

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 wrot

Re: [riot-devel] Problem with test connecting to ttyACM0

e: > 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

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

Re: [riot-devel] How to make my boards appear in the info-boards-supported list

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...@ij

Re: [riot-devel] How to make my boards appear in the info-boards-supported list

_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

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

[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

Re: [riot-devel] Which tests are expected to succeed for my board

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

Re: [riot-devel] Which tests are expected to succeed for my board

> 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

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

Re: [riot-devel] Which tests are expected to succeed for my board

/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

Re: [riot-devel] Which tests are expected to succeed for my board

ck 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)

Re: [riot-devel] Which tests are expected to succeed for my board

er", 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/

[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

[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