Re: [riot-devel] Why do drivers copy their params to RAM?

Hej Benjamin, you got it right, it is about additional overhead. At least in the drivers that I designed, I always look at the specific parameters and judge them on their importance. If used only during initialization, I tend to leave them in ROM. But if used constantly during run-time, I

Re: [riot-devel] ADC API resolution

. Just my 2 cents on this issue. I'm already glad that this is tackled. Cheers, Koen On 08/01/2020 14.30, Hauke Petersen wrote: Hi Marian, I agree that users are unlikely to produce that garbage when passing value to the `adc_sample` function directly. More likely those kind of values are produced

Re: [riot-devel] Are there users of avsextrem?

Hej, we still do have some of these boards at FU, but I have not touched some for some years now. With the `f4vi1` there was also a successor developed at FU, so I think the avsextrem is rarely being used anywhere around here?! If no one else from FU is raising a hand, I would think it is

Re: [riot-devel] Thingy52: Real time terminal output

Hi Rik, it has been a while since I last used that board. I have one here, so I will give this a test sometime today. I'll let you know what I can find out. Cheers, Hauke On 8/22/19 10:49 PM, Rik Gene wrote: Dear All, I'm not getting through to the shell when running

Re: [riot-devel] Release 2019.07 - dates and feature requests

Hej, big +1! Getting the USB+Ethernet slave mode to work would be a major milestone towards simple to deploy border routers and such. So ~4 more weeks seems doable, right?! Cheers, Hauke On 5/31/19 10:11 PM, Mario Gómez wrote: Hi all! My grain of salt: For high impact features: PR

Re: [riot-devel] RIOT vectors for Smartfusion2 port

Hi Ashim, the LPC2387 is unfortunately a very bad example, as this CPU is not very well maintained and does not comply with the best practices of structure and style that newer CPUs in RIOT use. The general approach for porting CPUs in RIOT is to rely as much as possible on shared code.

Re: [riot-devel] USB PID number

Hi, fully agree. +1 to go with the two PID solution. And I'd say we can always revisit the VID situation if someone comes up with a good justification why we would need one... Cheers, Hauk On 2/26/19 10:21 AM, Dylan Laduranty wrote: Hi all, Le mar. 26 févr. 2019 à 09:51, Koen Zandberg

Re: [riot-devel] Someone having access to a Thingy:52 or a RuuviTag?

Hej, I have both boards in question available to me and will give this a try. Cheers, Hauke On 2/15/19 12:46 PM, Marian Buschsieweke wrote: Hi everyone, this PR #9407 [1] is waiting for someone to test it on a Thingy:52 or a RuuviTag. You'll need a current development version of OpenOCD in

Re: [riot-devel] Usage of DMA

Hi Maksim, DMA is simply not implemented for the sam3, mostly to the lack of manpower. This is simply an implementation issue - the periph_spi interface is actually designed in a way, to be agnostic to an implementation using DMA or not... So if this is something you care about, it would be

Re: [riot-devel] Driver design rules in RIOT

Hej, On 09/26/2018 12:16 PM, Juan Ignacio Carrano wrote: Hi Gunar, I'm not very experienced on the driver development side, but enough as a user to see some issues. On 9/26/18 9:27 AM, Gunar Schorcht wrote: - Should a driver be as complete as possible, which of cource produces more code,

Re: [riot-devel] Driver design rules in RIOT

about adding some information about how to handle multiple threads, when to use mutexes, and how to deal with interrupts?  :-)  And especially patterns for being nice from other threads and power consumption point of view... --Pekka On 26.9.2018, at 14:31, Hauke Petersen <mailto:hauke.pe

Re: [riot-devel] Driver design rules in RIOT

Hi, long done :-) See https://github.com/RIOT-OS/RIOT/wiki/Guide:-Writing-a-device-driver-in-RIOT Cheers, Hauke On 09/26/2018 11:11 AM, Emmanuel Baccelli wrote: Hi there, based on this exchange, is there matter for a wiki page on this? (Or for alternative documentation, e.g. reviving the

Re: [riot-devel] Driver design rules in RIOT

Hi everyone, for documentation purposes a quote from a private mail that I wrote Gunar earlier today (at that point I was not aware of this email...): ``` Maybe one think that could (or even should?!) be considered: try to make very specialized features optional (e.g. via "sub-moduling"

Re: [riot-devel] Status of new I2C API

Hi again, fixup to my previous mail: the new proposed API is better presented in #6576 [1]... Cheers, Hauke [1] https://github.com/RIOT-OS/RIOT/pull/6576 On 02/26/2018 10:07 AM, Hauke Petersen wrote: Hi everyone, sorry for the late reply. The remodeling of the I2C (master) API should

Re: [riot-devel] Status of new I2C API

Hi everyone, sorry for the late reply. The remodeling of the I2C (master) API should indeed be tackled ASAP (as every newly merged implementation just adds to the work)... But this is not new and I/we have been talking about this for ages now... I won't be able to drive this nor to spend

Re: [riot-devel] Timers

Hej, On 01/25/2018 01:29 AM, PyroPeter wrote: Hi, to make matters even more complicated: Timers and PWM are the same thing on most platforms. It would be nice if one could choose whether to use interrupts or PWM pins or both per timer. (e.g. using both the interrupt and a PWM pin enables one

Re: [riot-devel] Atxmega Port with RIOT OS - Where to put abundance of new driver features?

Hi Madison, awesome to hear about your port, it will be very nice to have ATxmega support in RIOT. I will try to answer your questions inline below. On 11.12.2017 22:04, Madison McCarthy wrote: Hi Everyone, I'm nearing completion of a port for RIOT OS to the ATxmega family of devices

Re: [riot-devel] HIL testing

Hauke Petersen: Hi everyone, in today's developer meeting the discussion passed by the topic of HIL testing once again, this time in the context of the upcoming re-modeling of the I2C interface. Some weeks ago I had an idea for a simple HIL setup for automatically testing perihp/i2c drivers, and I

Re: [riot-devel] RIOT developers monthly meeting

HI Thomas, I think the general idea here was to have the meeting on the day before Hack'n'Ack, which is as of now on a Tuesday. Cheers, Hauke On 28.11.2017 19:01, Thomas Eichinger wrote: Hi, I forgot, but was there a particular reason having these on Mondays? For me personally it would be

[riot-devel] HIL testing

Hi everyone, in today's developer meeting the discussion passed by the topic of HIL testing once again, this time in the context of the upcoming re-modeling of the I2C interface. Some weeks ago I had an idea for a simple HIL setup for automatically testing perihp/i2c drivers, and I promised

Re: [riot-devel] Need some orientation about using vendor SDK when porting MCU

Hi Cristiano, I think in general, the inclusion of at least the vendor/firmware headers for those CPUs should probably be done in a similar fashion than the inclusion of the stellaris ware (cpu/stellaris_common). But dependent on the amount of headers (or even library source files), it would

[riot-devel] Release 2017.10

Dear RIOTers, we are happy to announce the 13th official release of RIOT: --- * RIOT 2017.10 * --- This release provides fixes, code cleanup and improved documentation, as well as enhancements. Most notable, this release is bringing RIOT a step closer

[riot-devel] Release 2017.07 - RC2

Dear RIOTers, thanks to all the hard work, we were able to successfully run all the tests specified by the release specs and fix all errors we encountered (almost all of them connected to test applications). So I am happy to announce the 2nd (and supposedly/hopefully last) release candidate

Re: [riot-devel] 2017.10 feature freeze

of the release. Best, Hauke On 16.10.2017 17:35, Hauke Petersen wrote: Dear community, as time flies by, we are closing in on the 2017.10 release. I just created the release branch [1] and with it the first release candidate [2], and from this moment on we are in feature freeze. The targeted

[riot-devel] 2017.10 feature freeze

Dear community, as time flies by, we are closing in on the 2017.10 release. I just created the release branch [1] and with it the first release candidate [2], and from this moment on we are in feature freeze. The targeted release date for 2017.10 is Okt 25th (next Wednesday). As usual, we

Re: [riot-devel] Graphing build sizes

Hej, On 13.10.2017 13:19, Kaspar Schleiser wrote: 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

Re: [riot-devel] Graphing build sizes

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 also have an idea for code size diff

Re: [riot-devel] Colorized compiler output not for Emacs users

Hi Kees, I was not aware of the compatibility issues for Emacs users when enabling the colored gcc output. So yes, I'd say a conditional flag preventing this on demand is indeed needed. I just opened a PR with that fix [1]. Cheers, Hauke P.S. AFAIK many in the community actually use VIM

Re: [riot-devel] periph/rtt intent

Hej! For the motivation of creating the RTT interface it is needed to once more recap the main motivation of the peripheral drivers: the idea is/was to introduce unified APIs that give direct access to selected MCU peripherals with the least possible overhead, mapping each type of peripheral

Re: [riot-devel] Re-visiting the LED macros

Hej! On 12.07.2017 09:00, Oleg Hahm wrote: Hi Hauke! On Tue, Jul 11, 2017 at 06:04:29PM +0200, Hauke Petersen wrote: For the purpose of profiling using GPIO pins, I think it makes more sense to think about something like a CPU specific `pin_debug` header for a small number (say 2?) pins

[riot-devel] Re-visiting the LED macros

Dear community, in #7321 [1] an old friend of discussion popped up again: should we get rid of the special handling for on-board LEDs and move over to use the `periph/gpio` driver for controlling them? This could be done in a global module (as for example proposed in #7350 [2]). The benefit

Re: [riot-devel] periph/i2c: remodeling part 1 and 2: deprecate existing API

Hi Neo, thanks for your input! When talking about addressing, you talk about addressing registers and not about I2C bus addresses, right? The read/write reg functions of the proposed new interface can simply be seen as convenience functions, mapping to actual calls to the i2c_read/write

Re: [riot-devel] SPI automatic interface configuration inside of cpu.c/periph_init(();

Hi Neo, the global/automatic SPI initialization might not be ideal, but the benefits are greater than the drawbacks. One of the major design issues this is solving is the handling of shared peripherals (as in SPI/I2C): when doing the initialization somewhere in the driver code, different

Re: [riot-devel] Another category for communication device drivers?

Hi Neo, actually the grouping evolved around the obvious, and are mainly driven by the high-level interfaces that these groups implement (netdev, SAUL, ...). For everything that doesn't fit one of these groups, I'd say we just put them 'ungrouped' into the drivers folder. Once we find that it

Re: [riot-devel] Sensors for RIOT on STM32F4Discovery

Hi Adeel, pretty much any sensor supported by RIOT (just have a look into the /drivers/ folder) should do. Most simple are for example the DHTx temperature sensors -> very easy to connect, inexpensive and widely available. Cheers, Hauke On 09.12.2016 18:15, Adeel Mohammad Malik wrote:

Re: [riot-devel] SiLabs Gecko

Hi Akshay, if I understand it correctly, you use the ezr32lg? So I would suggest you start by porting that CPU first: - create the `ezr32lg` cpu - create a `ezr32_common` folder - move everything from the `ezr32wg` to the common folder that can be re-used (I would suppose this includes all

Re: [riot-devel] bitfeilds

put it very nicely in his description. Cheers, Hauke Neil On 27 Oct 2016 14:11, "Hauke Petersen" <hauke.peter...@fu-berlin.de <mailto:hauke.peter...@fu-berlin.de>> wrote: Sorry, saw Olegs mail only after I send mine... Cheers, Hauke On 27.10.2016

Re: [riot-devel] bitfeilds

Sorry, saw Olegs mail only after I send mine... Cheers, Hauke On 27.10.2016 15:06, Martine Lenders wrote: Hi, 2016-10-27 15:01 GMT+02:00 Oleg Hahm >: Hi Martine! On Thu, Oct 27, 2016 at 01:35:21PM +0200, Martine Lenders wrote:

Re: [riot-devel] weird(?) rom section origin in stm32f103cb.ld

Hi, took me some minutes to remember, but the reason is quite simple, though stupid: the stm32f103rb was imported while porting the spark-core board. Now the spark-core is does some hacky things (i.e. some custom bootloader stuff), so it expects the ISR table at addr 0x08005000. This should

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

Hi Kees, you are right, the current interface does not support 16-bit registers. We are however overhauling the I2C interface as we speak, and the re-worked interface does have support for them (see [1]). Feel free to take a look and comment on the proposal! Cheers, Hauke [1]

[riot-devel] 2016.04-RC2

Dear RIOTers, I am happy to pronounce the 2nd (and hopefully last) release candidate towards the 2016.04 release [1]. All that is left todo is to go through another round of heavy testing. So please make sure that your setups behave as expected and if possible pitch in with completing the

[riot-devel] 2016.04-RC1

Dear community, we are making progress on our way to get RIOT ready for the upcoming release: I proudly present the first release candidate 2016.04-RC1 [1]. For taking the next steps, I encourage (and challenge) everyone, to put an extra effort into getting this release out of the door. Most

Re: [riot-devel] RIOT-ESP8622

Hi Roger, RIOT can certainly be ported to the ESP8622, and it would make for a very interesting platform. I think some people (including myself) have briefly looked into this, but there has been created no countable output, yet. The main problem I have encountered so far is their custom CPU

[riot-devel] Feature Freeze

Dear RIOTers, the new 2016.04 release is closing in fast as ever (April 15th). Last night we reached we moved to feature freeze. We will create a release candidate branch shortly (2016.04-RC1), that should be used as a base for running tests, like we did for the last releases. So while in

[riot-devel] Hack'n'ACK tonight

Hi everyone, tonights Hack'n'ACK is starting now. Here the link for remote participation: http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc- See you around! Cheers, Hauke ___ devel mailing list devel@riot-os.org

[riot-devel] Upcoming Release

Dear Community, we are closing in fast on the next RIOT release. Feature freeze is next week Tuesday (March 30st) and the plan is to get the 2016.04 release out by April 15th. As of now, we still have 79 PRs and 57 open issues marked for the release - this will hardly be doable. So I ask

Re: [riot-devel] PWM API change

resolution is the real freq, which is not expected by the user. Cheers, Marc On 2016-03-17 12:33, Hauke Petersen wrote: Hi, I have to say that I don't quite understand the problem with the 16-bit max here. Is the timer on the lm4f120 limited to it's prescalers? For applications like contro

Re: [riot-devel] Biweekly virtual meeting

Hej everyone, please re-join, link is the same. Cheers, Hauke On 09.03.2016 13:55, Hauke Petersen wrote: Hej everyone, here is the PlaceCam link for joining the meeting: http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc- See you there, Hauke On 09.03.2016 13:22

Re: [riot-devel] Biweekly virtual meeting

Hej everyone, here is the PlaceCam link for joining the meeting: http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc- See you there, Hauke On 09.03.2016 13:22, Francisco Javier Acosta Padilla wrote: Hi! OK, a PlaceCam session should available for the meeting. Cheers!

Re: [riot-devel] Port to STM32F7

Hi, this is not quite true, I have started to work on this some time ago [1], but don't quite remember were I left of. But maybe this branch might give you a head start? Feel free to copy what you need! Cheers, Hauke [1] https://github.com/haukepetersen/RIOT/tree/add_board_stm32f7discovery

Re: [riot-devel] Implementing rng

Hi Mathias, I think the way to go here is to implement the `drivers/include/periph/hwrng.h` interface. For this I think it makes sense to add a function that reads the random data from the radio to the at86rf2xx driver and call this function from the hwrng driver. Cheers, Hauke On

Re: [riot-devel] Problems during porting RIOT-OS

Hi Bernhard, I can't really tell what's causing this behavior, seems to me though that there is something wrong in the UART configuration. But it's hard to tell without seeing your code. Which board are you using? Some STM nucleo one? The boards are notorious for weird behavior of their

Re: [riot-devel] Contribute to RIOT OS

Hi Parthiv, contributing to RIOT is easy: just write code and PR it via github :-) Refer to [1] for more details. If you are looking for topics, you could start to browse the open issue list [2] and try to fix something that is appealing to you. We will also apply as mentoring organization

Re: [riot-devel] Event Driven Button

Hi, I am not quite sure which button function you are referring to. If you mean the buttons mapped via SAUL, then there is no event drive API, yet. Though this is being worked on and will hopefully be introduced to RIOT soon... Cheers, Hauke On 05.02.2016 17:37, Sugang Li wrote: Dear

Re: [riot-devel] Atmel R21

Hej Ilias, you could have a look at this wiki page [1] and adapt it accordingly. Hope that helps! Cheers, Hauke [1] https://github.com/RIOT-OS/RIOT/wiki/Howto:-Slip-border-router-with-Raspberry-Pi-and-samr21-xpro On 02.02.2016 15:55, Ilias Seitanidis wrote: Thank you very much now I can

Re: [riot-devel] Minimal MCU-Core Frequency for using 6LoWPAN Protocol

Hi Bernhard, I can't tell for sure (as I have not tested it), but depending on your link utilization 8MHz should be sufficient to run RIOT with 6LoWPAN enabled GNRC stack. But this of course also depends on which other tasks your node has to perform besides networking... Cheers, Hauke On

Re: [riot-devel] SamR21 Not using the build in radio

Hi Ilias, for you GPRS device you need to implement a device driver (which should implement the netdev2 interface to be able to integrate with out network stack(s). Roughly you then need to do the following: For not using the build in radio, you don't have to change anything in the code,

[riot-devel] Hack'n'ACK tonight

Hello everyone, Here's the link for the PlaceCam session tonight: http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc- Cheers, Hauke ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] drivers/SAUL

Hi, depends on what you are looking for. Have a look at the `default` example for the `iotlab-m3` or the `samr21-xpro`. These are so far the only boards that have bindings to some sensors/gpios via SAUL. But as coincidence I am working on some SAUL optimizations and on SAULifying many more

Re: [riot-devel] RIOT Wireshark Sniffer - unidentified frame format

Hi Mateusz, could you please tell us, which board (and radio) you were using to send out the 802.15.4 frames? Seems to me that you discovered a bug in RIOT, which leads to a faulty address mode configuration somehow... Also would you mind to attach your wireshark dump (as you forgot it in

Re: [riot-devel] Improving support for OpenMote-cc2538

Hi Aaron, good to hear you want to put some work into the OpenMote! Let me try to answer your questions best to my knowledge: On 13.12.2015 04:06, Aaron Sowry wrote: Hi, I'd like to try and improve RIOT OS support for the OpenMote platform in general, and the TI cc2538 MCU specifically. The

Re: [riot-devel] cpuid for atmega2560

Hej Dinh, in this case I would just not implement the CPUID interface for that cpu. The idea of the interface is to abstract mcu peripherals - so if a peripheral does not exist, we should not try to emulate it on this level. So let higher levels (e.g. UUID generation) worry about this...

Re: [riot-devel] From hwtimer to xtimer: What Changes for RIOT Features?

Hi Kevin, let me try to answer your questions (see inline). On 09.12.2015 12:57, ROUSSEL Kévin wrote: Hello everyone, As (I suppose) everybody here knows, the 'hwtimer' kernel feature has been replaced by the 'xtimer' module. Consequently, I'm wondering about some features that were

Re: [riot-devel] Arduino API merged

You just did :-) Cheers, Hauke On 27.11.2015 14:03, Martine Lenders wrote: Hi, the Arduino API wrapper [1] was finally merged. Do we want to advertise that on devel and users? Cheers, Martine [1] https://github.com/RIOT-OS/RIOT/pull/3900 ___

Re: [riot-devel] Notification: Hack'n'ACK @ Tue Nov 24, 2015 5pm - 10pm (RIOT Events)

Hi everyone, here is the link for joining tonights Hack'n'ACK: http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc- Cheers, Hauke On 23.11.2015 16:59, Google Calendar wrote: more details »

Re: [riot-devel] Is RIOT right?

Hi Patrick, On 20.11.2015 20:48, Patrick Rota - Swissponic Sagl wrote: Dear Hauke, thank you for your answers. Please see my comments inline. On 11/20/2015 01:13 AM, Hauke Petersen wrote: Hi, thanks for sharing your architecture with us, it is always interesting to see what people

Re: [riot-devel] Is RIOT right?

Hi, thanks for sharing your architecture with us, it is always interesting to see what people are planning! I will try to answer your questions as good as I can, see answers inline below. On 19.11.2015 20:09, Patrick Rota - Swissponic Sagl wrote: Hello everyone, we are developing an IOT

Re: [riot-devel] RIOT for Zigduino

Hi, I think so far nobody has attempted to port that board. Please don't take the available porting guide word-by-word, it might be outdated in places - we are currently putting heavy effort in rewriting/updating our documentation! So for porting the Zigduino I think you can just follow a

Re: [riot-devel] Energy Consumption on samr21_xpro

Hi, if you decide to measure the energy consumption through those external pins, keep in mind, that you are measuring the consumption of the complete board - not only the MCU+radio. Last time I tried, I always got something around 100mA. This is fairly high for this kind of board (the

Re: [riot-devel] RIOT preview for TI cc3200

Hej, On 03.09.2015 23:22, Attilio Dona wrote: Ciao Kaspar, I agree with RIOT philosophy, so a rewrite could be a nice thing, but I also think that this is not a top priority now, at least for me ... If someone else wants to contribute it would be great! One more thing to consider is that

Re: [riot-devel] The border router wi^H^H is ready!

Very cool! Awesome job! Cheers, Hauke On 17.09.2015 18:31, Oleg Hahm wrote: Ladies and gentlemen! I'm more than proud to announce that just a couple of minutes ago I sent the first successful ping from an iotlab-m3 node over a RIOT powered border router (running on a samr21-xpro) to my

Re: [riot-devel] Introduction, some technical questions.

Hi Mateusz, welcome to RIOT! Let me try to answer your questions (see inlined comments). On 09.09.2015 10:14, Mateusz Kubaszek wrote: Hello everyone, Let me introduce myself, my name is Mateusz and it is my first message here, in this community I am a student of AGH academy in Cracow. New

Re: [riot-devel] RIOT examples

+1 for flat hierarchy with a good naming scheme. this makes it IMHO much more efficient when working on the command line... On 20.08.2015 08:34, Martine Lenders wrote: Hey, 2015-08-19 14:47 GMT+02:00 Kaspar Schleiser kas...@schleiser.de mailto:kas...@schleiser.de: Hey, On

Re: [riot-devel] Save data in ROM

Hi Baptiste, that is actually something being planned (although with low prio). Some of the older boards have this already implemented (look at the config module for the msba2 and msb-430). For streamlining this all across RIOT, I thing what we should to is to create a generic architecture

[riot-devel] Tonight's Hack'n'Ack

Hej everyone, here is the link for joining tonights hack'n'ack: http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc- Cheers, Hauke ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Biweekly Meeting Now

Hi everyone, our biweekly developer meeting starts at 2PM, here is the link for remote participation: http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc- See you there, Hauke ___ devel mailing list devel@riot-os.org

Re: [riot-devel] LPC1768 Status, flashing, and uart0

... maybe the virtual consoles are not supported in Linux ... 2015-06-26 14:58 GMT+02:00 Hauke Petersen hauke.peter...@fu-berlin.de mailto:hauke.peter...@fu-berlin.de: Hi Olivier, I assume you are talking about this mbed-lpc1768 board [1]? Flashing should work via RIOTs make system

Re: [riot-devel] samr21-xpro / watr.li ADC

Hi, as we are planning to use the Demo we had @ Embedded World also for Lange Nacht der Wissenschaften next Saturday, I have it also on my plate, to get a working ADC implementation for the SAMR21 this week. @wiredsource: Are you planning to do anything on that PR this week? Otherwise I

[riot-devel] Biweekly Meeting

Hi everyone, here is the link for today biweekly meeting: http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc- As usual see the Wiki for instructions on joining in [1] Cheers, Hauke [1] https://github.com/RIOT-OS/RIOT/wiki/Instructions-for-remote-participation

Re: [riot-devel] Biweekly Meeting

Somebody else logged in with the RIOT account and killed the ongoing Meeting... I just restarted PlaceCam, so please re-join (link should be the same). Cheers, Hauke On 03.06.2015 14:00, Hauke Petersen wrote: Hi everyone, here is the link for today biweekly meeting: http://placecam.de

Re: [riot-devel] Board Selection for RIOT

Hi Alexander, naturally the board of choice would be the iot-lab_M3 (the one used in the FIT IoT-lab testbed). But as this board is not freely available on the market, I suggest the Atmel samr21-xpro. It uses (almost) the same radio as the iot-lab nodes and is freely available at the usual

Re: [riot-devel] IEEE802.15.4 discovery

Hi, @Jonas, is your 802.15.4 MAC layer implementation planned to cope with this? Cheers, Hauke On 19.05.2015 20:18, Kaspar Schleiser wrote: Hey, is anybody working on or are there plans for support for discovering 802.15.4 PANs? Kaspar ___ devel

Re: [riot-devel] RIOT-OS on ARM SAM3X8E?

Hi Zac, I think you got something wrong: the Arduino-due is indeed based on the Atmel SAM3X8E which is based on an ARM Cortex-M3 with *~96kB* RAM and *~512kB* Flash. The RPi on the other hand has nothing at all to do with the Atmel SAM3X8E. Instead it is base on some Broadcom Arm-A11 SoC

Re: [riot-devel] NSTF - Naming the stack

Hi, I also can live very well with gnrc aka generic. Cheers, Hauke P.S. +1 for 'Google never really called' :-) On 18.05.2015 17:56, Martine Lenders wrote: Hi, given that I was asked today what the R means in RIOT (and Thomas W. giving the most excellent to my revelutionary or restricted:

Re: [riot-devel] NSTF - Naming the stack

Hi, Martine and me had the same discussion yesterday. Until we have a name, NG_NETOPT would be the natural choice I guess... Cheers, Hauke On 12.05.2015 09:54, Oleg Hahm wrote: Hi, I just stumbled across ng_netconf - we should rename this to avoid confusion with RFC 6241 [1]. If the stack

Re: [riot-devel] [riot-users] MRF24J40 or SAMR21 (or AT86RF2xx) and FCC Certified Module

Hi, On 02.05.2015 03:40, Drasko DRASKOVIC wrote: Hi all, I tumbled on this thread: http://comments.gmane.org/gmane.os.riot.devel/1458 while looking for support for MRF24J40 in RIOT. What is the current state with SPI driver for this module - does it exits? some members of the community do

Re: [riot-devel] NSTF - Naming the stack

Hi everyone, giving the ng_stack a name sounds like a very good idea to me (and as far as I remembered I already mentioned this last summer...). Though finding a name is tough and I don't like the obvious once (flexnet_, default_, riotnet_, etc...). Also 'cutting' out the re-usable parts as

[riot-devel] NSTF Meeting now

Hello everyone, here the the link for todays NSTF meeting: http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc- See here [1] for more information about how to join remotely. A preliminary agenda and topics for discussion are listed in the RIOT wiki [2]. See you! Cheers,

Re: [riot-devel] WDT questions

Hi, very simple: A watchdog timer does not at all fit into the context of a tickless-system. We want to sleep as long as possible, so waking up just to please the WDT is very counter productive... A WDT interface we could actually introduce, I guess just nobody did it so far... Cheers,

[riot-devel] Hack'n'ACK tonight

Hi everyone, here is the Link for remote participation in tonight's Hack'n'ACK: http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc- As always, see here [1] for more information on how to join. Cheers, Hauke [1]

Re: [riot-devel] Board maintainers

done. Cheers, Hauke On 26.04.2015 10:48, Kaspar Schleiser wrote: Hey guys, I've added a Maintainer field to our supported platforms list [1]. Feel free to add yourself to the board ports you feel responsible for. Kaspar [1] https://github.com/RIOT-OS/RIOT/wiki/RIOT-Platforms

[riot-devel] Biweekly Dev Meeting

Hi everyone, here is the Placecam link for todays developer meeting: http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc- See you there, Hauke ___ devel mailing list devel@riot-os.org

Re: [riot-devel] LWM2M client on RIOT

Hi Roberto, we will be porting LWM2M to RIOT as a GSOC project this summer. Cheers, Hauke On 22.04.2015 09:44, Roberto P wrote: Hi, I'm interested in making work a LWM2M client on RIOT, I have a project in my mind. For the moment the only solution I found to make it work on RIOT was to

Re: [riot-devel] [ ST32L152RE ] [periph_conf.h]

Hi Tara, the alternate function definition (PWM_x_PIN_x_AF) is meant for defining which alternate function the referneced pin is using. You can find the correct values for your configuration in the devices data sheet [1] on page 43ff, Table 9. If you for example want to use PWM_0 with timer

Re: [riot-devel] API proficiency levels

Hi Kaspar, in general I like the idea, one problem I see is however, that is not always clear, to which level an API belongs (e.g. the GPIO API is definitely used also by high-level application programmers, while still belonging to the low-level peripheral drivers...). Cheers, Hauke On

Re: [riot-devel] Updated Invitation: Biweekly virtual meeting @ Wed Mar 25, 2015 2pm - 3pm (RIOT Events)

Hi everyone, we will start with the bi-weekly developer meeting now. The PlaceCam link for joining is the following: http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc- Please refer to the RIOT wiki [1] for information on how to join. Cheers, Hauke [1]

Re: [riot-devel] NSTF radio driver

Hi Joakim, as of today, I PRed a new version of the Xbee S1 radio driver[1], which is build 100% on the new netdev interface. I think it makes a good reference implementation for radio drivers, even if it is through it's UART interface a little different from others drivers we are

Re: [riot-devel] N2 Project

Hi David, when using Wakaama (which is certainly an option), the way would be to include it in RIOT as a package and include some Makefiles that are able to download/checkout the library and build it into RIOT. When choosing this path, one important thing is to think of a concept for

Re: [riot-devel] CSMA MAC-layer, Open Issues

Hi Jonas, On 20.03.2015 18:02, Jonas Remmert wrote: 1. Both, the upper layer and the current implementations of the ng_netdev radio drivers use task messages to signalize an event (Packet to be sent or Packet to receive waiting). Both message mechanisms send their messages to the mac_pid

Re: [riot-devel] BLE project N2

Hi Kausthub, with a clean hardware abstraction the BLE implementation should be mostly independent of hardware. For the small hardware dependent part we propose the NRF51822 SoC (as it is broadly available and cheap), that is correct. But as a basic driver for the SoC's radio is already

  1   2   >