Re: [riot-devel] Hardfault when linking OpenThread library

What platform are you running this on? Could you post your .map file? (preferably as a link to gist or pastebin or similar, since they tend to be very large) Best regards, Joakim On Fri, Jun 17, 2016 at 1:51 PM, Jose Alamos wrote: > Hi community, > > I'm having a weird

Re: [riot-devel] Odd problems with xtimer

Also, you can use the .map file to find out if there are any buffers or other things nearby which may have overflowed and messed up your state. Are you using any IPC messages other than the xtimer functions? (I wonder if there might be a race between the timer ISR callbacks and the message

Re: [riot-devel] Implementation of a real low power timer for sleep/stop mode (idle thread)

Hi Bernhard, ​It should be possible with some modifications to use a slow clock as the xtimer source. There are a few developers working on improving the low power operation in RIOT. As you discovered, the periph/timer API currently needs to be updated to support non-MHz timer frequencies. I have

[riot-devel] Populating neighbor cache without ND

(Continuing from a thread on Github: https://github.com/RIOT-OS/RIOT/issues/5025) tldr; It should be possible to use RPL standalone without 6lowpan-ND. Currently the only way to add neighbor cache entries is through neighbor solicitations+neighbor advertisements (ND) or through the shell. My

Re: [riot-devel] Updating micro-ecc

Hey Mathias, On Mon, Mar 7, 2016 at 12:14 PM, Tausig Mathias wrote: > > Hy! > > I'd like to update the micro-ecc package included with RIOT-OS, since the > current version is pretty outdated. > Currently, the package uses a patch which removes all the random

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

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

Re: [riot-devel] Compatibility matrix

Good idea! Maybe it could be linked to Murdock to have it automatically generate the matrix based on what current master can compile? /Joakim Den 15 jul 2016 16:53 skrev "Ludwig Knüpfer" : Hi, One idea for improving understanding of the meaning of "supported

Re: [riot-devel] I have question about scheduler when all thread in sleep

Dear Teemu, What you are describing sounds like the xtimer subsystem in RIOT. It uses a hardware timer to schedule tasks in the future. See examples/xtimer_periodic_wakeup in the RIOT sources for an example on how to achieve periodic scheduling for your task. Also note that the function

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

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

Re: [riot-devel] qemu-i386 port

I agree with dropping qemu-i386 On the same subject, would it make sense to clean up some other boards with less than ideal support? chronos is one board which I frequently run into trouble with because it is never up to date with the other platform implementations, especially the stdio is very

Re: [riot-devel] RIOT and avr-libc

Yes, it is using avr-libc for AVR targets. On Aug 25, 2016 10:16 AM, "Loïc Dauphin" wrote: > Hello, > > I think I know the answer, but just to be sure : Do RIOT use avr-libc or > newlib for AVR targets ? > > I think it is avr-libc by the way. > > Cheers ! > > Loïc > >

Re: [riot-devel] Unlocking mutex in RTC ISR and thread switching causes HardFault

Do you have some example code that you can share which triggers this fault? Best regards, Joakim On Sep 14, 2016 7:50 PM, "Anon Anonymous" wrote: > Hello, > > I trying to unlock mutex in RTC Alarm ISR and after alarm shoots and mutex > is unlocked, the thread switch

Re: [riot-devel] BIN FILES

If you want a binary file which is an exact byte-for-byte copy of the microcontroller ROM you can use objcopy to convert from ELF to raw binary. The RIOT build system also produces a HEX file for flashing, which is a plain-text variant of the raw binary. arm-none-eabi-objcopy -O binary myprog.elf

Re: [riot-devel] About RIOT support filesystem

Hello, Work is being done to add file system capabilities to RIOT. Currently there is a proposed change which adds SPIFFS (https://github.com/pellepl/spiffs) support to RIOT. The changes are not yet merged with the master branch, but the goal is to get them into master soon. I have unfortunately

Re: [riot-devel] MIPS Port

I don't have anything to comment on the PR, but I thought it should be mentioned that only maintainers can set labels and assign people to an issue/PR, you'll probably get some labels added on it by the maintainers soon. Best regards, Joakim On Sep 28, 2016 13:52, "Neil Jones"

Re: [riot-devel] Cortex M0 HardFault

On a related note, I had some trouble with unexplained hard faults when I built newlib using gcc-6.2, but I didn't have time to investigate further at that time and I simply reinstalled newlib built with gcc-5.4 instead. Best regards, Joakim On Dec 15, 2016 5:51 PM, "Kaspar Schleiser"

[riot-devel] periph/rtt intent

, or the RTT API will be useless as an abstraction layer, since its interpretation will be platform dependent. What are your opinions on the RTT API, or the timer APIs in general? Best regards, Joakim Nohlgård RIOT developer ___ devel mailing list devel

Re: [riot-devel] CPU clock on kinetis boards

a Padilla > Research Engineer at INRIA Saclay > INFINE Team > > On 12 June 2017 at 19:36:46, Joakim Nohlgård (joakim.nohlg...@eistec.se) > wrote: > > Hi, > I think the wisest choice is probably to switch to FEI mode first to use the > internal oscillator before booting a new

Re: [riot-devel] usb-serial support on RIOT for radino32

Dear Shengrong, There is currently no USB stack in RIOT. There was an attempt to add one a while ago, but it was never finished. See https://github.com/RIOT-OS/RIOT/pull/3890 for the last work in progress. Adding USB support would be a welcome feature, and I guess a vendor library can be a useful

Re: [riot-devel] usb-serial support on RIOT for radino32

On Jul 21, 2017 23:07, "Shengrong Yin" wrote: > Hello, > > We are porting RIOT to radino32 uwb board. > > However, unlike existing supported board in RIOT, this radino32 board does > not > have a USB to serial converter. > > board info: >

Re: [riot-devel] Reorganization of Cortex-M build test MCU groups

On Mon, Apr 24, 2017 at 9:27 AM, Kaspar Schleiser <kas...@schleiser.de> wrote: > Hey Joakim, > > On 04/21/2017 06:46 PM, Joakim Nohlgård wrote: >> I would like to change this split to create groups of boards which are >> likely to fail together to be in the same gro

[riot-devel] 6lowpan fragmentation sending too fast

/sixlowpan/frag/gnrc_sixlowpan_frag.c#L211 Best regards, Joakim Nohlgård Eistec AB ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Help testing Kinetis dev boards

have opened a tracker issue [3] on GitHub for viewing the progress of this effort. [1]: https://github.com/RIOT-OS/RIOT/pull/6994 [2]: https://github.com/RIOT-OS/RIOT/pull/6995 [3]: https://github.com/RIOT-OS/RIOT/issues/7154 Best regards, Joakim Nohlgård Eistec AB

Re: [riot-devel] Help testing Kinetis dev boards

PM, Emmanuel Baccelli < > emmanuel.bacce...@inria.fr> wrote: > >> Hi Joakim >> >> just the other day, we ordered a couple frdm-kw41z at Inria, so we >> should be able to test here soon. >> >> Cheers, >> >> Emmanuel >> >> On

Re: [riot-devel] CPU clock on kinetis boards

Hi, I think the wisest choice is probably to switch to FEI mode first to use the internal oscillator before booting a new image. That is the same mode that the mcu comes up in after a hardware reset. There are some relevant PRs open on GitHub for the Kinetis clocking:

Re: [riot-devel] Dynamic radio power scaling in RIOT

devices start becoming ubiquitous. Best regards, Joakim Nohlgård Eistec AB On Jun 22, 2017 10:00 PM, "Koen Zandberg" <k...@bergzand.net> wrote: Hello, For a small research project as a part of my study, I did some research on the effectiveness of dynamic radio output scaling.

[riot-devel] Netdev events questions

Dear developers, I'm working on a radio driver for the Kinetis KW41Z 802.15.4 radio and I have run into some questions regarding when to send the different netdev events from my device driver. Should NETDEV_EVENT_RX_COMPLETE be sent before, or after TX of ACK packet is finished? Should

Re: [riot-devel] At86rf2xx ACK frame

Why do you need the actual ACK frame? It's only like 3 bytes + FCS and doesn't really contain anything interesting. The only interesting information is that the frame with the given sequence id was received properly, which is exactly the same information you get from the transceiver hardware.

[riot-devel] gnrc: MAC layer selection

. Best regards, Joakim Nohlgård Eistec AB ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] On the State of RIOT's IEEE 802.15.4 Support

On Wed, Sep 20, 2017 at 11:32 AM, Kaspar Schleiser <kas...@schleiser.de> wrote: > Hi Joakim, > > On 09/20/2017 10:11 AM, Joakim Nohlgård wrote: >> I have recently been digging around the gnrc_netdev code as well. I >> think that adding support for other frame

Re: [riot-devel] Graphing build sizes

On Oct 13, 2017 09:53, "Hauke Petersen" wrote: Hej, very nice effort, I love it! Thinking out loud: would it make sense to do some data aggregation for more generic views? On first thought I would imagine something like average ROM/RAM size over all

Re: [riot-devel] rtc alarm running with threads

Hi Paula, It is likely that the debug print in the sale_test function overflows the ISR stack. You can increase that stack size by adding CFLAGS += -DISR_STACKSIZE=1024 to your Makefile. The interrupt service routines on cortex m have a separate stack which is set to 512 bytes by default. Usually

Re: [riot-devel] PIC programmer with Linux support?

Is this for pic32 HIL tests? Do the pic32 boards support jtag like the cortex boards? In that case you could maybe use one of the ftdi ft2232 based jtag programmers out there. /Joakim On Fri, May 18, 2018, 10:30 Kaspar Schleiser wrote: > Hey fellow RIOTers, > > I'm looking

[riot-devel] Clarification request: periph_timer behaviour

Hi developers, I have some questions about the details of the expected behaviour of the periph_timer interface with regards to stopped timers: timer_init: Should an already initialized and started timer be reset to zero and timer targets cleared when this is called? timer_set,

Re: [riot-devel] Porting RIOT to 8051 Architecture

Hi Madison, I haven't used any 8051 architecture devices myself, but I think the biggest difficulties will probably be getting everything to compile with a new toolchain which is not gcc based (we have support for clang as well, but the clang developers work hard to be gcc compatible). Like you

Re: [riot-devel] [riot-users] End of I2C embargo

Good job, everyone involved! /Joakim Den tor 2 aug. 2018 12:49Dylan Laduranty skrev: > 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

Re: [riot-devel] Activation of modules by make command line

It should be possible in the current state if you give the modules as an environment variable instead of on the command line. So: USEMODULE='module_a module_b' make BOARD=asdf /Joakim Den tor 6 sep. 2018 10:33Gunar Schorcht skrev: > Hi, > > It is often necessary to enable or disable various

Re: [riot-devel] Improve Documentation

I think this is certainly an interesting idea! You will probably not even need Doxygen for anything, plain graphviz (dot) is probably enough. Best regards, Joakim On Mar 1, 2018 16:21, "Arndt, Josua" wrote: Hello all, as we are working on the PR to bring the

Re: [riot-devel] RIOT policy on hardware support without example board

ished RTT > support for the ATMegas, but none of the Arduinos breaks out the pins > that would allow you to add a 32kHz crystal. > > Sincerely, > Matthew > > > On Thu, 15 Mar 2018 09:20:37 +0100 > Joakim Nohlgård <joakim.nohlg...@eistec.se> wrote: > >> Hi Matthew

Re: [riot-devel] RIOT policy on hardware support without example board

Hi Matthew, Generally, everything in the main repository should be covered by the automatic compilation tests performed by the CI system, which is why all CPUs must have at least one board using them. Perhaps you have some development board which uses the same CPU that you can add a basic

Re: [riot-devel] Dropping FEATURES_MCU_GROUP?

ml), don't know if > anybody > uses that? > > Best, > Sebastian > > > On 25. Apr 2018, at 09:28, Bas Stottelaar <basstottel...@gmail.com> > wrote: > > > > +1 if it's not used. > > > > Kind regards, > > > > Bas Stottelaar >

[riot-devel] Dropping FEATURES_MCU_GROUP?

Hi developers, Is the old FEATURES_MCU_GROUP variable used by tools anymore? AFAIK Murdock tracks build status per board/app tuple, without grouping by families or anything. It might be time to drop it from the board configurations to avoid confusing newcomers. Best regards, Joakim

Re: [riot-devel] xtimer race condition

Hi Matthew, My guess is that you are running that function with interrupts disabled, which blocks the xtimer timeouts. The reason that short sleeps work in xtimer is that internally that is handled as a spin, while longer timeouts are handled by setting a hardware timer target. You can try using

Re: [riot-devel] Compute the time elapsed when switching between two threads

Would you be able to get the measurements you are looking for using this approach instead? The low priority thread is toggling a gpio pin in a tight loop. The other thread toggles a different pin as soon as it is resumed. You would need external equipment to get the time between the two, but it

Re: [riot-devel] EFM32 timers, PWM and xtimer

Hi Christian, If you want some inspiration for a timer driver you could take a look at the Kinetis periph/timer driver which wraps two different timer hardware modules underneath, one for high frequency and precise control (PIT, always clocked by the CPU bus clock), and the other for low power

Re: [riot-devel] Lifting the 50 characters commit first line limit?

+1 what Martine wrote. (I was composing a similar message when you beat me to it) /Joakim Den ons 10 okt. 2018 08:51Martine Lenders skrev: > Hi Pekka, > > the 50 chars is just the warning bound. You can go up to 70 until the > commit message check fails on you. Longer will make GitHub break

Re: [riot-devel] Where to put board pictures?

Hi all, Ideally, the pictures and figures should be part of the pull request to add the board configuration, to make reviewing easier for maintainers. Having the maintainers to upload the pictures manually of a proposed board is too much extra administration and will steal maintainer focus from

Re: [riot-devel] Eliminating casts

A controversial idea is to change the implementation to C++ and make the driver a proper class with inheritance and utilize polymorphism with dynamic casts. /Joakim Den tor 27 dec. 2018 21:51 skrev Kees Bakker : > On 27-12-18 13:54, Kaspar Schleiser wrote: > > Hi, > > > > On 12/26/18 11:16 PM,

Re: [riot-devel] Compile-time peripheral configuration in board definitions

Hi Gunar, I have experimented with something similar, moving the configurations to a .c file instead of periph_conf.h, but I came to the conclusion that there are a number of drawbacks to the various alternatives. First, let's clear up one thing regarding the current implementation: The static

[riot-devel] Neighbor solicitations (NS) from border router (6lo ND)

Hi developers, When using the shell on the gnrc_border_router application trying to send to an unknown address with its designated prefix, the application does not send any neighbor solicitations on the wireless network. When I type ping6 2001:db8::1234 I expected that a neighbor solicitation

Re: [riot-devel] Neighbor solicitations (NS) from border router (6lo ND)

.3/11, 15.4 ...) and the MAC address is acquired via ND. In your > case, you mention SLIP. A serial line interface does not use L2 > addresses and does not need ND. > > Best, > Thomas > > On 17/12/2018 08:59, Joakim Nohlgård wrote: > > Hi developers, > > When usi

Re: [riot-devel] Hello world stopped working

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.

Re: [riot-devel] Current best practice for sleeping in a device driver?

Hi Pekka, What we have done in several other places is to use a mutex. The device driver blocking code will attempt to lock the mutex twice, and the ISR will unlock it to let the thread continue. Does that work in your use case? Best regards, Joakim Den tis 11 sep. 2018 16:40Nikander Pekka

Re: [riot-devel] Current best practice for sleeping in a device driver?

-Pekka > > On 11.9.2018, at 20:48, Joakim Nohlgård wrote: > > Hi Pekka, > What we have done in several other places is to use a mutex. The device > driver blocking code will attempt to lock the mutex twice, and the ISR will > unlock it to let the thread continue. > Does that wo

Re: [riot-devel] Function declaration isn't a prototype

The obvious workaround is to turn off the warning via -Wno-strict-prototypes The alternative is to fix the function declarations in the headers. IIRC this is what shows up when you forget to put void inside the argument list of a function which takes no arguments in C (it is not a warning in C++).

Re: [riot-devel] just got my Vega

There is a tracking issue for porting at https://github.com/RIOT-OS/RIOT/issues/10575 /Joakim Den tis 12 feb. 2019 13:35 skrev Alexandre Abadie : > > > - Le 12 Fév 19, à 13:15, Robert Hartung hart...@ibr.cs.tu-bs.de a > écrit : > > > Sounds great - where did you order yours from? > > From

Re: [riot-devel] IEEEE 802.15.4 FCF Format in "RIOT/sys/net/link_layer/ieee802154/ieee802154.c"

I think you must have made a mistake in your calculations. buf[1] contains bits 8-15 of the fcf, bits 12-13 are the version bits. 12 - 8 = 4, 1 << 4 = 0x10, so the frame version is set to version 1, all other bits are zero at the beginning of that function. Best regards, Joakim Den tis 26 nov.

Re: [riot-devel] IEEEE 802.15.4 FCF Format in "RIOT/sys/net/link_layer/ieee802154/ieee802154.c"

I think you are confusing byte ordering with bit ordering, the IEEE 802.15.4 frame format uses little-endian _byte_ ordering, so the least significant byte comes first. But inside each byte, the least significant bit has number 0, the most significant bit has number 7. Therefore, a byte where only