Many legacy applications are built on Contiki, and many papers on IoT
are written around tests done on Contiki. Contiki also has a quite
large community who work with applications on the platform.
Because of this it would be useful to have a way of running Contiki
applications and projects under R
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 recepti
I think it is better to make a revert commit and push that as well, that
avoids the problem of rewritten history.
git revert 30ab6883331e29ce8453ebc1057f939575e6
git push
To prevent mistakes like this in the future, change the upstream repo URL
to use the https:// or git:// links instead of s
See if you have g++multilib installed (32 bit versions of GCC libraries for
64 bit systems), otherwise install it:
sudo apt-get install g++-multilib
Best regards,
Joakim
On Fri, Feb 12, 2016 at 9:00 AM, tobaccopipeyoyo . <
tobaccopipey...@gmail.com> wrote:
> Hi everyone,
> Sorry to disturb y'al
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 a
Hi Bernhard,
There has been some previous discussion on this theme.
I believe that if you want to use low power modes in a WSN you will
need to implement a duty cycling MAC layer with synchronization, such
as IEEE802.15.4e. Running the power duty cycling from a single thread
like you propose will l
Thank you for your bug report, I think your analysis is correct. Do
you mind creating a pull request on Github to get your change merged
into our master branch?
Best regards,
Joakim
On Tue, Feb 23, 2016 at 9:10 PM, malo wrote:
> Hello riots,
>
> just joined the list, have been playing with riot
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 number
> generation code from micro-ec
(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 init
> next-hop by a routing-protocol.
> I think there's no need to extend RPL to fill the neighbor-cache.
>
> Best regards,
> Martin
> ------
> *Von:* devel [devel-boun...@riot-os.org]" im Auftrag von "Joakim Nohlgård
> [joakim.nohlg...@
I noticed that you wrote %.2 for the format of the number. The period (".")
doesn't make sense in a format string for integer variables. Does it crash
if you change the format string to only "%" or "%2" PRIu32?
On Apr 7, 2016 4:29 PM, "Theodore Kotsonis" wrote:
> Hi everyone
>
> I am trying to us
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 hardfault when I'm linkin
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
documen
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 xtimer_usl
I would also like to hear the presentations, but I will not be able to
attend. Will the presentations be recorded and available online after the
event?
Best regards,
Joakim
Den 14 jul 2016 19:13 skrev "Ken Bannister" :
> I read that Ari Keränen and Carsten Bormann plan to lead a discussion on
>
Thank you!
/Joakim
On Fri, Jul 15, 2016 at 10:44 AM, Oleg Hahm wrote:
> +1
>
> On Fri, Jul 15, 2016 at 09:35:06AM +0200, Emmanuel Baccelli wrote:
> > Thanks Carsten!
> >
> > On Jul 15, 2016 9:30 AM, "Carsten Bormann" wrote:
> >
> > >
> > > https://hangouts.google.com/hangouts/_/bomthsflordmhfhp
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 platform":
We could provide a matrix
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 chan
Dear Anon,
To expand on Ludwig's reply:
Does the eeprom support overwriting single bytes or
does it require an erase command
before memory can be overwritten?
If you can freely access random bytes and overwrite random bytes then NVRAM
is the correct interface.
If you need erase I su
Dear Anon,
First of all, good to hear that someone is working on LPM!
Does your program work correctly if you remove the lpm_set() line from your
main or does it still crash when the RTC alarm occurs?
Normally, the idle thread will call lpm_set to go to a low power mode when
the system is idle, I
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 ha
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
>
> ___
I can join late (after 21) if anyone is still there
On Aug 30, 2016 4:42 PM, "Peter Kietzmann"
wrote:
> Hi all,
>
> is anyone else planning to join remotely? If not I would abstain from
> setting up a PlaceCam session for the plenum. Otherwise we can proceed as
> usual.
>
> Best
> Peter
>
>
> Am
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 request is pending. RTC ISR
Not yet implemented. Currently there's a PR open for arbitrary constant
frequency hardware timers with xtimer, but that PR is only one step on the
way and does not take into account multiple timers or timers with varying
frequency.
The PR can be found at https://github.com/RIOT-OS/RIOT/pull/5608
B
,
Joakim
On Fri, Sep 16, 2016 at 4:31 PM, Anon Anonymous
wrote:
> Hi,
>
> Any ideas on this?
>
> 2016-09-14 22:13 GMT+03:00 Anon Anonymous :
>
>> Sure. Here it is: http://pastebin.com/ZGwtZKDd
>>
>> 2016-09-14 21:03 GMT+03:00 Joakim Nohlgård :
>>
>>&g
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 be
Dear developers,
Even though the official CI system is the Murdock server maintained by
Kaspar, it is not entirely clear what scripts are being run and in
what order. With the Travis and Drone scripts it is still possible to
run the same tests directly on your own PC without creating a PR. This
is
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" wrote:
Hi all,
I
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
I agree with the general idea of this thread.
In my opinion, integer widths should only be specified in cases where the
developer needs to know the exact width, for example in network protocols
or when interfacing with hardware. In normal program logic the variables
should be using the general typ
Thank you Juergen, this was a very comprehensive answer, in my opinion. I
have been watching this thread to understand bitfields better :)
Best regards,
Joakim
On Oct 28, 2016 10:04 AM, "Juergen Stuber" wrote:
> Hi Neil, hi everybody,
>
> On Thu, 27 Oct 2016 11:33:57 +0100
> Neil Jones wrote:
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" wrote:
>
Dear developers,
The build test MCU groups were added as a measure to split the compile test
during CI runs into several smaller runs and to easier get an overview of
what is failing. The initial groups were based on what architectures were
supported in the code base, but when the Cortex-M groups b
On Mon, Apr 24, 2017 at 9:27 AM, Kaspar Schleiser 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 group. For example, the Nucleo
>
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 NETDEV_EVEN
s.
I 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
Eist
t;
> 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 Thu, Jun 8, 2017 at 11:32 AM, J
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:
https://github.com/RIOT-OS/RI
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.
Rega
devices
start becoming ubiquitous.
Best regards,
Joakim Nohlgård
Eistec AB
On Jun 22, 2017 10:00 PM, "Koen Zandberg" 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. The general idea
is th
, 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
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 image. That is the same mode tha
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:
> https://shop.in-circuit.de/product_info.php?products_id=18
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 s
layer/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
model.
Best regards,
Joakim Nohlgård
Eistec AB
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
Hi,
I have recently been digging around the gnrc_netdev code as well. I
think that adding support for other frame types and logic for sending
these frames will definitely become a mess if the 802.15.4 code is not
decoupled from the netdev code. Especially if someone would like to
add advanced featu
On Wed, Sep 20, 2017 at 11:32 AM, Kaspar Schleiser 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 types and logic for sending
>> t
s I think as the interface
> wouldn't have to change.
>
> In the end I'm fine with whatever works and covers our requirements.
>
> Best, Thomas
>
>
> On 20 Sep 2017, at 1:11 PDT(-0700), Joakim Nohlgård wrote:
>
>> Hi,
>> I have recently been digging ar
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 application/examples over all platforms.
I a
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 w
Hi,
On Tue, Nov 21, 2017 at 5:26 PM, Daniel Evans wrote:
> First, I should add that I currently have a working samd21 low power
> implementation but to accomplish that I use rtt.c for my always running
> clock and then standby sleep the module whenever it gets to the idle task.
> This is a hack a
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, timer_set_absolute,
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 wro
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 Jiminy board to mainline repo I
h
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 configura
TMegas, 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 wrote:
>
>> Hi Matthew,
>> Generally, everything in the main repository should
My guess is that your files are missing a final newline at the end of file.
Best regards,
Joakim
On Mar 21, 2018 16:03, "Baptiste CARTIER"
wrote:
> Hello all,
>
> I am trying to do a Pull Request (#8811) but I can't pass the Travis CI
> checks and I do not understand why.
>
> I have the followin
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 xt
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
___
t; anybody
> uses that?
>
> Best,
> Sebastian
>
> > On 25. Apr 2018, at 09:28, Bas Stottelaar
> wrote:
> >
> > +1 if it's not used.
> >
> > Kind regards,
> >
> > Bas Stottelaar
> >
> >
> > 2018-04-24 7:02 GMT
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 for a readily availab
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 em
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 oth
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 fu
In case anyone stumbles across this thread in the future:
The difference is that giving a variable on the command line to make will
cause that variable to become immutable by the makefiles, which means that
it will not be updated by the USEMODULE += module commands in the makefiles
(unless the spec
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 skrev
de?
>
> --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.
&g
various CPUs,
> allowing e.g. the Cortex-M support to get rid of cortexm_isr_end().
Getting rid of cortexm_isr_end would help reducing hard to spot
mistakes in the periph drivers, but this is a very important piece of
code and any changes must be made carefully and with confidence. I am
not sure
+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 the
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 sho
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 cons
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.
/Joa
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 query
02.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 usin
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 con
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. Stu
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, K
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++).
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 [1
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. 20
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
83 matches
Mail list logo