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

Hi, On 5/30/20 10:14 PM, Alexandre Abadie wrote: > You can just put all of them in the same issue. It will be easier to track. > That is what is done in [1]. I think we should add this information to compile_and_test.py. Some way to expect failure for specific tests or board/test combinations,

Re: [riot-devel] Release 2020.04

Hey, On 4/30/20 1:25 PM, Leandro Lanzieri wrote: > --- * RIOT 2020.04 * --- Gratulations everyone! And special thanks to Leandro! ;) Kaspar ___ devel mailing list devel@riot-os.org

Re: [riot-devel] RIOT sprint day

Hey Martine, On 3/19/20 11:39 AM, Martine Sophie Lenders wrote: > So you judge this as a hen and egg then? There is no interest, since not > many people know about it, so there is no advertisement for it since not > enough interest was generated. Well, I had pitched the idea on maintainers@,

Re: [riot-devel] RIOT sprint day

Hi, On 3/19/20 10:29 AM, Martine Sophie Lenders wrote: > then why not advertise it more? E.g. by posting the relevant links a day > ahead to devel? The interest when first announced was quite limited (basically zero interest). After the announcement that this is really happening and feels

Re: [riot-devel] RIOT sprint day

Hi Martine, On 3/18/20 3:43 PM, Martine Sophie Lenders wrote: > apparently the RIOT sprint days proposed a while back are already > happening. I'd like to have some transparency: when are they happening > and how are they organized (incl. how can one join / can anybody join)? They are currently

[riot-devel] anyone using the eZ430 chronos?

Hey fellow RIOTers, is anyone using TI's chronos with RIOT? We're in the process of updating the msp430 toolchain. The chronos has quite some special cases, and I'd like to avoid having to deal with them. I suspect that noone is actually using the chronos port anyways... If you do, please shout

Re: [riot-devel] Release 2020.01

Hi, On 2/3/20 10:02 PM, Francois-Xavier Molina wrote: > We are happy to announce the 22nd official release of RIOT: Congrats everyone! Awesome job managing the release, Francisco! Kaspar ___ devel mailing list devel@riot-os.org

Re: [riot-devel] ztimer - a new high-level timer for RIOT

Hi Ralf, On 12/13/19 6:41 PM, Ralf Schlatterbeck wrote: > As far as I understand, the new timer implementation would not use 64 > bit for the timer and the user is responsible for not overrunning the > timer? Note that I haven't looked a the implementation yet, so forgive > my ignorance. I think

Re: [riot-devel] ztimer - a new high-level timer for RIOT

Hi Michel, On 12/11/19 4:50 PM, Michel Rottleuthner wrote: > Hi Kaspa >> Would it make sense to make a micro conference? Get everyone interested >> in improving timers in a room and lock it until solutions are presented? > Not convinced about the "lock in a room" ;) - but otherwise: absolutely >

Re: [riot-devel] ztimer - a new high-level timer for RIOT

Hi Michel, thanks for all that input. It is *a lot*. I guess it is a complex subject.. Would it make sense to make a micro conference? Get everyone interested in improving timers in a room and lock it until solutions are presented? On 12/10/19 6:23 PM, Michel Rottleuthner wrote: >> RIOT needs

Re: [riot-devel] ztimer - a new high-level timer for RIOT

Hey, On 12/9/19 10:32 PM, Oleg Hahm wrote: > Hm, to be honest, I'm not so sure of what kind of efficiency we're speaking > here. CPU time or memory? Probably both, right? Regarding the CPU efficiency, > I would assume that this also dictates the maximum precision, right? I don't think so. The

Re: [riot-devel] ztimer - a new high-level timer for RIOT

Hi Oleg et all, On 12/9/19 9:25 PM, Oleg Hahm wrote: > I think the problem statement and the requirements could indeed be more > precise - while I must admit that a lack of precise requirements is a failure > of the RIOT community. Yes, that could be. I intentionally did not add requirements. I

Re: [riot-devel] ztimer - a new high-level timer for RIOT

Hi, On 12/9/19 4:52 PM, Kaspar Schleiser wrote: > Hi Robert, > > On 12/9/19 4:25 PM, Robert Hartung wrote: >> Do we need to put any thoughts in power management / low_power / >> integration with pm_layered? Or are the possible issues addreses / >> already tal

Re: [riot-devel] How to deal with lost interrupts?

Hi, On 12/9/19 5:02 PM, José Ignacio Alamos wrote: > No, I wouldn't consider those lost interrupts (because messages are > lost, not IRQs). Ok, thanks for clarifying! Kaspar ___ devel mailing list devel@riot-os.org

Re: [riot-devel] ztimer - a new high-level timer for RIOT

Hi Robert, On 12/9/19 4:25 PM, Robert Hartung wrote: > Do we need to put any thoughts in power management / low_power / > integration with pm_layered? Or are the possible issues addreses / > already talked about? Yes and yes. ;) I'll my thoughts so far. Thanks! Kaspar

Re: [riot-devel] ztimer - a new high-level timer for RIOT

Hi Robert, On 12/9/19 4:19 PM, Robert Hartung wrote: > why are 8-bit timers not listed? Intentional or unintentional? Unintentional! Kaspar ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] How to deal with lost interrupts?

Hey Jose, On 12/9/19 3:46 PM, José Ignacio Alamos wrote: > The main question here is, how should we handle lost interrupts in > general? Let's say: What do you mean by "lost interrupt"? GNRC uses messages to pass an ISR from the interrupt handler to "userspace". Those can be lost. Are you

[riot-devel] ztimer - a new high-level timer for RIOT

Hey everyone, since the RIOT Summit in Helsinki, I've put quite some work into ztimer, a possible successor to xtimer. If you're interested, please see an updated design document here: [1] Cheers, Kaspar [1] https://github.com/RIOT-OS/RIOT/wiki/ztimer-problem-statement-and-design-document

[riot-devel] Question about expected timer semantics

Hi everyone, I think everyone agrees that if a relative timer is set, it is expected to run *at least* the amount of time that is specified as interval to timer_set(). That means if now() is e.g., 0 ticks and the timer is set to wait 1 tick, the timer must trigger at 2 ticks, as even if

Re: [riot-devel] [riot-users] Release 2019.10

Congrats everyone!! And special thanks to Ken! Kaspar On 10/31/19 2:38 PM, Martine Lenders wrote: > Woohoo! Congratulations to everyone and thanks Ken for the great work! > > Best regards, > Martine > > Am Do., 31. Okt. 2019 um 14:29 Uhr schrieb Emmanuel Baccelli >

Re: [riot-devel] Notification: Hack'n'ACK @ Tue Oct 29, 2019 5pm - 10pm (CET) (RIOT Events)

Hi, we're all set in Berlin. Join us at https://meet.jit.si/riot-hacknack! Kaspar On 10/28/19 5:00 PM, Google Calendar wrote: > more details » >

Re: [riot-devel] Notification: Hack'n'ACK @ Tue Oct 29, 2019 5pm - 10pm (CET) (RIOT Events)

Hey, On 10/28/19 5:00 PM, Google Calendar wrote: > Hack'n'ACK > > /When/ > Tue Oct 29, 2019 5pm – 10pm Central European Time - Berlin Don't they start at 3pm now? Kaspar ___ devel mailing list devel@riot-os.org

Re: [riot-devel] RIOT OS and Raspberry Pi 3

Hi Milica, On 10/21/19 11:14 AM, Milica Lekic wrote: > Does RIOT OS support installation on Raspberry Pi3? In a way like I > installed RIOT OS on Linux PC. As I found out it does not but I am not > sure.  Running RIOT directly on the Pi3 SoC is currently not possible. You can, however, run the

Re: [riot-devel] SmartFusion2 Port: Timer

Hi Gideon, On 6/5/19 12:46 PM, wrote: > Dear List, > > In an effort to port RIOT to SmartFusion2 (goto BACKGROUND at the bottom > for interest), we've hit a small stumbling block. The dedicated hardware > timer is extremely basic and does not have any CCP (capture/compare) > channels. It's is a

Re: [riot-devel] Lightweight Syslog Implementation

Hi, On 5/29/19 11:57 AM, Juan Ignacio Carrano wrote: > IPC/message queue backend. RIOT's message queues are a poor choice for this, as they can only send pointers around. That means the calling thread needs to allocate memory for the log message and keep that valid until the message has been

Re: [riot-devel] Lightweight Syslog Implementation

Hi Robin, On 5/23/19 2:09 PM, Robin wrote: > First and most important is the > question if this feature is still of interest for the RIOT community? It > was originally mentioned in a feature request back in 2015[2] and may be > obsolete by this time. IMO the syslog API itself should not be

Re: [riot-devel] Ethos global wired address

Hi Ashim, On 5/21/19 12:44 PM, Ashim Asharaph wrote: > I am using ethos for a project I have. The computer needs to communicate > with a samr21-xpro. The board needs to have a global address so that I > can reach it. I have tried to adapt the gnrc_border_router example but I > see only the

Re: [riot-devel] Release 2019.04

Hey everyone, On 4/29/19 4:01 PM, Daniel Petry wrote: > we are happy to announce the 19th official release of RIOT: congratulations and big thanks to everyone involved! Special thanks to Dan. Good job managing the release and I'm sorry to see you leave! Kaspar

Re: [riot-devel] RIOT Support for STM32WB with Nucleo Board

Hi Warren, On 3/26/19 10:22 AM, Warren Bilgeri wrote: > Are there any plans to support the STM32WB with RIOT? > I have used RIOT on other STM32 devices and would like to use RIOT on > the STM32WB - the STM32WB is targeted at IOT applications. I started adding STM32WB support in [1]. The cpu

Re: [riot-devel] just got my Vega

Hi, On 2/12/19 2:01 PM, Joakim Nohlgård wrote: > There is a tracking issue for porting > at https://github.com/RIOT-OS/RIOT/issues/10575 I feel two months late. Thanks! Kaspar ___ devel mailing list devel@riot-os.org

[riot-devel] just got my Vega

Hey fellow RIOT'ers, I've just received a VEGAboard (rv32m1-vega). It's feature list is very promising. On-board BLE/802.15.4, plenty of RAM and flash, (apparently) specs & reference manuals for everything. I'm curious how it's power consumption will be. I think it'll be a challenge integrating

Re: [riot-devel] Location for module specific compile configurations

Hi, On 1/31/19 3:31 PM, Gaëtan Harter wrote: > One solution, which does not match the current way of doing in RIOT. > Is to use Make declarative syntax and  define your configurations using > deferred evaluation > > CFLAGS += $(if $(filter something,$(USEMODULE)), -DIF_NUM=3) > > This would

Re: [riot-devel] PhyNode connecting to Raspberry Pi

Hi Anna, it is quite cumbersome at the moment, especially considering that the current Raspbian kernel is broken. May I suggest @smlng's Wiki pages [1]? AFAIK They contain up-to-date information on how to set up the RasPi side. Once that is set up, compiling and flashing e.g.,

Re: [riot-devel] sched_active_thread is a volatile pointer, but volatile is ignored

Hi Kees, 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

Re: [riot-devel] Eliminating casts

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. > void at86rf2xx_tx_exec(const at86rf2xx_t *dev) > { >     netdev_t *netdev = (netdev_t *)dev; What would be the

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

Hi Julien, On 11/21/18 11:31 AM, Julien Gomez wrote: > Indeed, using external equipment like an oscillograph was the first > thing I did.  > > But I am looking to compute the context switching time only with software.  > > > I am pretty sure I will have to tweak the kernel to get such >

[riot-devel] 20000 commits!

Hey fellow RIOTers, master has just grown past 2 commits! And in other news, RIOT is about to cross the 200 contributors mark. Keep up the good work everyone, Kaspar ___ devel mailing list devel@riot-os.org

Re: [riot-devel] Unit test code coverage using gcov

Hey Toon, On 10/9/18 4:16 PM, STEGEN Toon wrote: > Has anybody succeeded in getting gcov to work to check code coverage of > the unit tests? I managed to get gprof working at some point. AFAIR they're using the same infrastructure (PC sampling, saving it somewhere, then dumping the file) as

Re: [riot-devel] Benchmarking of Real-Time Operating Systems for Internet of Things Devices

Hi Julien, On 9/25/18 6:13 PM, Julien Gomez wrote: > We'd love to hear your recommandations or any help you can provide us with. For RIOT, compile with "LTO=1" and "DEVELHELP=0" set in the Makefile. ;) Kaspar ___ devel mailing list devel@riot-os.org

[riot-devel] CI news

Hey everyone, thanks to Martine we now have a nice new view for our nightly builds: https://ci.riot-os.org/nightlies.html There are many more improvements to Murdock and the accompanying scripts, but they're under the hood and thus more or less invisible. But they'll allow for more nice

Re: [riot-devel] Proposal for sys folder

Hi, On 8/29/18 11:13 AM, Jose wrote: > 1. Move the `net` folder to the RIOTBASE folder (`sys/net` -> `sys`): >    This is consistent with our documentation, generates less folder >    depth, makes refactoring easier. The Linux kernel does exactly the >    same [2]. > 2. Add a `lib` folder in the

Re: [riot-devel] What definitions/configuration belong into to what file

Hi Robert, On 8/27/18 3:37 PM, Robert Hartung wrote: > While the peripherals belong to the MCU > hardware-wise, the actual board might limit the available > configurations, as pins might be used as GPIOs, and the peripherals > might not be available. Therefore it would also belong to the board.h.

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

He, On 8/21/18 11:28 AM, Jose wrote: > I personally think 2. (put them in the RIOT wiki) is the fastest way to > go and doesn't bloat the RIOT repository. But I would like to hear some > comments about this topic. +1. Don't forget, the Wiki is a git repo, too. Kaspar

Re: [riot-devel] Driver AT, what is the concept of process_urc

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

Re: [riot-devel] size_t vs int usage

Hi Neil, On 06/27/2018 03:03 PM, Neil Jones wrote: > IIRC size_t is unsigned so the error is correct, how did this code get > upstream, and how come no one else is getting this error ? I suppose the toolchain is compiled with different default warning flags. > I presume the fact that this PR

Re: [riot-devel] Scheduler: Supporting Cooperative Threading

Hi Juan, On 06/13/2018 10:27 AM, Juan Ignacio Carrano wrote: >>> Coroutines make it possible to program asynchronous code in a >>> blocking style - see "await". This is more natural and easier that >>> using callbacks. >> How does it compare to sending / receiving messages? >> > > Using messages

[riot-devel] PIC programmer with Linux support?

Hey fellow RIOTers, I'm looking for a readily available PIC programmer with Linux support. Main requirements are: - can flash the boards that RIOT supports - has a CLI application that runs on Linux (both x86 and ARM/RasPi) (- not too expensive) Any suggestions? Kaspar

[riot-devel] Release 2018.04

Dear RIOTers, we are happy to announce the 15th official release of RIOT: --- * RIOT 2018.0 * --- The 2018.04 release includes major progress in support for current crypto libraries. A lot of work has gone into updating drivers to RIOT's unified

[riot-devel] Release 2018.04 feature freeze

Dear fellow RIOTers, I've branched off the 2018.04 release branch, and we're now officially in feature freeze. That means from now on only bug fixes will be merged into 2018.04-branch. There are 12 open issues tagged for the release [1]. I hope we'll be able to resolve most of them in the next

Re: [riot-devel] License check for vendor specific MIT license

Hi Gunar, On 04/12/2018 01:09 PM, Gunar Schorcht wrote: > What is the right way to add a new license test pattern in > dist/tools/licenses/patterns? As usual PR or is there any other > procedure for that? Yes, a PR is the prefered procedure. Regards, Kaspar

Re: [riot-devel] Porting RIOT to ESP8266

Hi, On 04/16/2018 01:56 PM, Emmanuel Baccelli wrote: > FYI at FOSDEM this year, one of the most frequent question we got was > "when will RIOT be ported to ESP32"? It actually was the second most asked question, only bested by "does RIOT work on ESP8266?". Kaspar

Re: [riot-devel] Release 2018.04 planning

Hey all, On 03/06/2018 11:35 AM, Kaspar Schleiser wrote: > - final feature freeze will be two weeks later, on the 16.04.2018 just a quick reminder: the last week before feature freeze just started! Keep on hacking, Kaspar ___ devel mailing list de

Re: [riot-devel] ESP8266 Port and Networking

Hi, On 03/24/2018 07:33 PM, Gunar Schorcht wrote: > Therefore, my question is, what is the best way to realize networking on > a new platform that doesn't have 802.15.4 radio but full TCP/IP stack > and WiFi on board? I suggest implementing netdev on top of the WiFi layer 2 of the ESP, treating

[riot-devel] Release 2018.04 planning

Hey fellow RIOTers, here are the dates for release 2018.04: - feature freeze for high impact features will be on the 02.04.2018 - final feature freeze will be two weeks later, on the 16.04.2018 - final release date will be once all tests run through successfully Happy hacking! Kaspar

[riot-devel] Timers

Hi all, I guess it is time to coordinate improving RIOT's timers - again. IMO xtimer is a dead end. It was designed with good intentions, but unfortunately with not much real-world experience. It has also (d)evolved into a complex and inflexible #ifdef-mess... Here's what I think is bad about

Re: [riot-devel] Pull request for RISCV

Hi JP, On 01/13/2018 01:12 AM, JP wrote: > So I've asked some questions in the PR but receive few answers and it > usually takes weeks for an answer. Should I be asking in the PR or > here? In any case here's some questions. I'll answer in the PR. Kaspar

Re: [riot-devel] Updates to the build system - modules definition

Hi, On 11/30/2017 04:32 PM, Gaëtan Harter wrote: > 1. Configuration is not documented > 2. Information is not readable > 3. Modules definition is scattered but in RIOT global files > With these issues in mind, I propose to add parseable module meta-data > definitions in a file

Re: [riot-devel] 6lowpan Host with SLAAC, minimum ram footprint

Hi Josua, On 11/30/2017 04:17 PM, Arndt, Josua wrote: > I have ported Riot OS to the atmega256rfr2 and the gnrc_network example > works as expected. > > Now I want to reduce the RAM  footprint to a minimum would need some > advice how to proceed. I have a branch in [1] that tries to disable as

Re: [riot-devel] Updates to the build system - modules definition

Hi Dan, On 11/29/2017 02:33 PM, Daniel Petry wrote: > 1. The current build system isn't suitable to support the front end for > RAPstore that Hendrik developed for his bachelor thesis, which requires > that certain information can be displayed to the users. I hear about this for the first time.

Re: [riot-devel] Release 2017.10

Hey all, On 10/27/2017 12:37 PM, Hauke Petersen wrote: > we are happy to announce the 13th official release of RIOT: Congratulations and many thanks to everyone involved! Kaspar ___ devel mailing list devel@riot-os.org

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

Hi Paula, on which platform are you running your application? Kaspar On 10/20/2017 09:45 PM, Paula Ortega Cancino wrote: > Hi Oleg, > > Thanks for your help. I should mention that i'm working on the 2017.07 > release. This is the main functions of the code, the behavor i'm > expecting is to

Re: [riot-devel] Ethernet communication initialization.

Hi Subhasis, On 10/16/2017 01:04 PM, SUBHASIS MAITY cs16m055 wrote: > By the way how the flag is used. I mean to ask where the flag will be used?  > I can't find the use of the value of DGNRC_NETIF_NUMOF in any file. Look for GNRC_NETIF_NUMOF (without D). Kaspar

Re: [riot-devel] Ethernet communication initialization.

Hi Subhasis, On 10/16/2017 11:32 AM, SUBHASIS MAITY cs16m055 wrote: > When I try to run with module enc28j60 driever and cc2538_rf drivers, > only wired interface is detected on ifconfig. Can you specify why is > that happening. Might be that gnrc is configured to only use one network interface.

Re: [riot-devel] Graphing build sizes

Hi, On 10/13/2017 09:53 AM, Hauke Petersen wrote: > 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. Yes! The data should already

Re: [riot-devel] Graphing build sizes

Hi Koen, (your mail's quoting arrived a little garbled, I'll try my best to fix) On 10/12/2017 03:02 PM, Koen wrote: > At that point it might be easier to integrate > this work into the CI to trigger it after such a build. Probably! There's already infrastructure to run arbitrary scripts after

Re: [riot-devel] Graphing build sizes

Hey Koen, On 10/11/2017 04:59 PM, Koen Zandberg wrote: > For now I want to keep it up to date by running my script as a cron > every night approximately after the nightly build. If we'd build the in-between HEAD commits, would your script pick them up? > The dashboard is now a simple Grafana

Re: [riot-devel] Commercial products based of RIOT

Hi Samir, one product that's in development is the Sleeping Beauty [1], a GPS tracking device with an integrated GSM modem. Kaspar [1] https://sleeping-beauty.kontrollfeld.com On 10/11/2017 10:05 AM, SKS wrote: > Dear All > > > I am doing a literature survey on the commercial applicability

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

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 > these frames will definitely become a mess if the 802.15.4 code is not > decoupled from the

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

Hi Thomas, On 09/17/2017 11:37 PM, Thomas Eichinger wrote: > tl;dr: Do we see the need to be IEEE 802.15.4 compliant? Thanks for bringing this up. The answer is pretty simple: Yes, of course! Kaspar ___ devel mailing list devel@riot-os.org

Re: [riot-devel] pm_reboot

Hi, On 09/13/2017 03:06 PM, Robert Hartung wrote: > Make all pm_* implementations submodules, so the final CPU *always* has > to select the according pm implementation. You mean all functions, like pm_reboot()? Kaspar ___ devel mailing list

Re: [riot-devel] pm_reboot

Hi, On 09/08/2017 11:28 AM, Robert Hartung wrote: > Looks like it's not that easy. Many platforms define pm_reboot in the > board's file(s). Only mips-malta has it's own "pm_reboot()" implementation. The other two define stubs. > Additionally pm_layered does not define pm_reboot, the same

Re: [riot-devel] Discussion of Power Management

Hi, On 08/31/2017 05:13 PM, Robert Hartung wrote: >> SRC := $(pm_fallback.c,$(wildcard *.c)) >> to drivers/periph_common/Makefile >> >> - add "PSEUDOMODULES += periph_common_%" to makefiles/pseudomodules.mk >> >> That would compile pm_fallback *only* if periph_common_pm_fallback is >>

Re: [riot-devel] Discussion of Power Management

Hi Robert, On 08/31/2017 04:37 PM, Robert Hartung wrote: >> - if not, possibly e.g., kinetis_common has pm_set(), then that should >> depend on pm_layered > > This means that kinetis_common should provide a module > **kinetis_common_pm** that provides pm_set. The CPU should then depend > on this

Re: [riot-devel] Discussion of Power Management

Hi Robert, (I'll CC the list, this may be interesting to others) On 08/31/2017 03:52 PM, Robert Hartung wrote: > The main problem is that it is NOT sufficient to provide pm_layered and > periph_pm. As the various CPUs provide different implementations. Actually, that is sufficient. > The

Re: [riot-devel] Mailserver issues

Hi Michael, On 08/14/2017 06:36 PM, Michael Andersen wrote: > Lambda is actually pretty flexible. > [...] > So yeah, totally agree that you need caching, but actually it does that, > they just don't advertise it much. Ok, that makes it a lot more attractive. How would we deal with the needed

Re: [riot-devel] Mailserver issues

Hi Michael, On 08/11/2017 08:26 PM, Michael Andersen wrote: > Having just done something similar for something else, you should really > look at doing CI in AWS lambda. It is remarkably cheap and (more > importantly for my case) requires nearly zero devops once set up. If you > suddenly have 10x

Re: [riot-devel] Mailserver issues

Hi Adam, On 08/11/2017 07:14 PM, Adam Hunt wrote: > What sort of hardware would RIOT need for CI? Would a machine with, > for example, a pair of E5-2670 (eight cores @ 2.60 GHz), Xeons between > 64 and 128 GB of DDR3 ECC RAM, an SSD or two, and maybe some spinning > storage suffice or are we

Re: [riot-devel] edbg build failure in Vagrant VM due to missing libudev-devpackage + problems flashing Atmel samr21-xpro board

Hey all, On 05/29/2017 10:21 AM, Adrian Herrmann wrote: > Attempting to flash with the edbg driver instead of OpenOCD results in > an error when using the Vagrant VM as building edbg requires the > libudev-dev package, which is not included in the image and cannot be > found in the configured

[riot-devel] heads up: new header guard rules

Hey fellow RIOTers, we've just merged [1], which will enforce certain rules about the C header guards. See [2] for more details. In order to adapt your git tree, $ dist/tools/headerguards/check.sh ... will show which files might need a header guard fix. The checker outputs unified diff,

Re: [riot-devel] Support for cc3200

Hi, On 05/19/2017 09:10 AM, Martine Lenders wrote: > __- __Is it correct that it is only necessary to wirte the > cc3200_netdev.c-File. > > The CC3200 delivers a full embedded network stack right? If so, I would > rather suggest to either implement against GNRC's NETAPI [1] or

[riot-devel] Release 2017.04

Dear RIOTers, we are happy to announce the 11th official release of RIOT: --- * RIOT 2017.04 * --- This release provides a lot of new features, fixes and enhancements. Among these has been a huge cleanup regarding cppcheck and documentation, and we're

Re: [riot-devel] coccinelle

Hi Julia, On 05/05/2017 08:41 AM, Julia Lawall wrote: > The following rule finds local variables that are static, but where the > static property is not used, because the variable is initialized before > any use. Thanks! I've added the patch to my coccinelle branch [1]. > There are only two

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

Hey, On 04/24/2017 10:00 AM, smlng wrote: >>> It might be that this is equivalent to what we now call "features". ;) >> >> A good idea, we could introduce just introduce more features and wire >> the features_required checks to be available from the command line. >> `make buildtest TAGS=kinetis`

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

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 > boards could be in one or more groups cortexm_nucleo, the SAM boards, > nrf, and kinetis

[riot-devel] 2017.04 feature freeze

Dear fellow RIOT'ers, I've just created the 2017.04 branch and tagged the first release candidate [1], which means we're now in feature freeze. Theres an issue for tracking the testing progress at [2]. Any help is highly appreciated! Best regards, Kaspar [1]

Re: [riot-devel] flash command without compiling

Hey, On 04/18/2017 10:15 AM, Oleg Hahm wrote: I remember that (years ago) I thought that this would be a bad idea, but got overruled. Probably the newbie friendlyness is to be blamed... Anyhow, I have a branch for on-hardware CI testing, where I've added another flash target that doesn't

Re: [riot-devel] flash command without compiling

Hey, On 04/17/2017 04:47 PM, Jose Alamos wrote: I noticed the 'make flash' recompiles everything before flashing. What's the reason behind this? Does it actually recompile? The flash target in Makefile.include depends on the "all" target, ensuring that the build is up-to-date. I guess at

[riot-devel] 2017.04 feature freeze delayed

Hey RIOT'ers, due to the easter holidays, the feature freeze will be delayed until Tuesday. That means there are three more days for polishing your PR's! ;) Kaspar ___ devel mailing list devel@riot-os.org

Re: [riot-devel] Question about priority inversion mechanism in Riot OS

Hi Felix, On 04/11/2017 05:54 PM, Felix Levitre wrote: > I would like to know if there is a mechanism to avoid priority inversion in > Riot OS. Nope, there's no technical mechanism in place. Kaspar ___ devel mailing list devel@riot-os.org

[riot-devel] Release 2017.4 release planning

Hey fellow RIOT'ers, short reminder: The upcoming release's feature freeze is on April 14th. That means there are ten days left to polish your work in progress. Happy hacking, Kaspar ___ devel mailing list devel@riot-os.org

Re: [riot-devel] [RIOT][xTimer] Question about xtimer implementation.

Hi Phuong, On 04/01/2017 04:40 PM, Minh Phuong Dang wrote: > The CPU has 32bit timers/counters and it has countdown mode only. When > the timer reaches zero it generates timer interrupt request to the CPU. > I reference to another platforms porting which are implemented count up > timer mode

Re: [riot-devel] questions about riot os

Hi, On 03/22/2017 12:13 AM, Arjun Hary wrote: > Is there a plan or a timeline for it? Nordic seems to have released its BLE stack for Mynewt under a compatible license. AFAIK someone is already looking into porting that to RIOT, but I don't know what's the state there. Help is very

Re: [riot-devel] questions about riot os

Hi Arjun, On 03/20/2017 05:03 PM, Arjun Hary wrote: > 1) After adding the softdevice the code size jumped to 46K bytes which > includes compilation of 6lowpan, ipv6. Is there a way to compile the > nordic ble linbrary without adding these modules. I tried the > DISABLE_MODULE macro and though the

Re: [riot-devel] To global seed or not to global seed

Hey, On 03/08/2017 10:06 AM, Cenk Gündoğan wrote: > >> How about an interface a la >> > Looks good at first sight. We also would need some sort of > synchronization for concurrent access, e.g. a mutex in the `rnd_t` > struct, if two threads should use the same local state. Do we need that kind

Re: [riot-devel] To global seed or not to global seed

Hey, On 03/08/2017 12:18 AM, Cenk Gündoğan wrote: > we rather > should opt to allow local states for each thread (not excluding a global > state). Interesting. Up to now our trouble with RNGs was mostly on how to make them more random. Now we're trying to make them predictable. What's your use

[riot-devel] Code Quality Task Force

Hey fellow RIOTers, our CI currently fails on added files having either doxygen or cppcheck warnings. Unfortunately if changed files contain either warning, it cannot determine whether the warnings are new or have been there. So I hereby launch the Code Quality Task Force, and declare it's

Re: [riot-devel] Radio Driver Recommendations

Hi Anthony, On 02/22/2017 05:17 PM, Anthony Merlino wrote: > I'm trying to understand a few things. In the _setup command, > how should I copy the default value struct into the overall params if > the radio_params pointer member is const. Should I use memcpy? Or > should I create a new struct

[riot-devel] planning for release 2017.04

Dear RIOTers, for the next release, we've decided to shorten the merge window for "high impact"-changes. Previously, we've tried hard to finish up even complex changes (like the just released SPI rework) in time for a release. That lead to code touching many configurations but getting only two

Re: [riot-devel] Radio Driver Recommendations

Hi Anthony, On 02/14/2017 03:56 PM, Anthony Merlino wrote: > I am in the process of writing a radio driver for a device I'm working > with. The device is highly configurable and I am trying to identify the > best strategy for exposing some of the configuration to the user. For > example, the

Re: [riot-devel] Removed Driver

Hi Ilias, On 02/20/2017 02:07 PM, Ilias Seitanidis wrote: > I want to ask why the ltc4150 driver was removed( I will need to use it > and I would like to know if I should do any modifications on the > existing code for the ltc4150). Or is there any other new driver > supported by RIOT for

  1   2   3   >