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 cop

Re: [riot-devel] ADC API resolution

image. 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 ar

Re: [riot-devel] ADC API resolution

would allow for 16-bit ADCs on 16- and 8-bit platforms... Just thinking loud here :-) Cheers (and thanks for tackling this!), Hauke On 1/7/20 10:09 AM, Marian Buschsieweke wrote: Hi, thanks for your reply. On Tue, 7 Jan 2020 09:00:54 +0100 Hauke Petersen wrote: Hi, keep in mind that just b

Re: [riot-devel] ADC API resolution

Hi, keep in mind that just because an enum value is not defined, it does not prevent code like ``` adc_res_t res = 77; adc_init(.., res); ``` Also, calling `adc_init(..., 1234)` is completely fine for the compiler... Hence the two fold approach in the current implementations: each CPU should

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 ok

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 release-2019.07/examp

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

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

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

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

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

wrote: How 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 <mailt

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 c

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" them)

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 tim

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 t

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

Re: [riot-devel] HIL testing

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

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 to

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 to

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

Re: [riot-devel] 2017.10 feature freeze

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

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

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 visualiza

[riot-devel] testmail

this is just a test - we are under the impression that no mails are delivered on the devel list currently... So if you see this mail, its a false alarm... Cheers, Hauke ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinf

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 for

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 that

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

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 func

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 driv

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

Hi Ilias, in general this should be well possible. But of course it depends on some factors, e.g. the network/link layer technology used (e.g. limited throughput of IEEE802.15.4), the camera interface, the image resolution/size, and of course the timing requirements. As of know, RIOT does no

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

Re: [riot-devel] SiLabs Gecko

Hi again, On 08.12.2016 10:49, Akshay Mishra wrote: I have located the track. Now the license question -- Is it ok to use bits of code from the Silicon Labs driver here (https://siliconlabs.github.io/Gecko_SDK_Doc/ezr32lg/html/ezradio__comm_8c_source.html

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 per

Re: [riot-devel] bitfeilds

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

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: > >> As example I was a

Re: [riot-devel] bitfeilds

generated code for accessing the bitfeilds is less size efficient than doing it manually? I would be suprised if that was the case ? On 27 Oct 2016 08:05, "Hauke Petersen" mailto:hauke.peter...@fu-berlin.de>> wrote: Hi Neil, hi Kees, though named bitfi

Re: [riot-devel] bitfeilds

Hi Neil, hi Kees, though named bitfields are kind of nice when it comes to code readability, they behave very poorly when it comes to code size. This is especially true for register maps, as these are typically volatile. For this reason, we don't use them in RIOT and I strongly advice not to u

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] https://github

[riot-devel] RIOT Release 2016.04

Dear RIOT developers and users, we are happy to announce the seventh official release of the RIOT: --- * RIOT 2016.04 * --- This release adds support for two additional network stacks: lwIP and emb6. A bunch of additional protocols are n

[riot-devel] 2016.04-RC3

Hi everyone, by enabling NHC for RC2 we run into problems (e.g. broken UDP), so we decided to disable it again for the release. After reverting it [1], I created another release candidate [2], so please base all your testing efforts on RC3 [3]. Cheers, Hauke [1] https://github.com/RIOT-OS/R

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

[riot-devel] Towards RC2

Hi everyone, seems like we are making great progress towards the release. As of now, we have **0** open issues and **5** open PRs left. Also the release specs [1] have been tested to ~50% (without any issues, yet). Tomorrow morning I will create the RC2, and postpone everything that is not m

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

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

[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 https://lists.

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

Re: [riot-devel] RIOT OS support for RISCV -ISA

Hi, so far RIOT does not have any support for this architecture. But I am sure that would be people from the community interested in this and happy to help if you want to work on this! Best, Hauke On 23.03.2016 21:35, Harsha Kondajji wrote: Hello, Does RIOT OS support RISCV-ISA. Thanks

Re: [riot-devel] Question regarding MBED-LPC1768 network drivers support.

Hi, we do have support for ethernet, but we don't have a device driver for the lpc1768 phy, yet. Feel free to write one :-) Cheers, Hauke On 18.03.2016 20:50, Fernando Alberione wrote: On 2016-03-18 13:05, Thomas Eichinger wrote: Hi Fernando, the mbed-lpc1768 according to [1] doesn't h

Re: [riot-devel] PWM API change

a freq and duty cycle, but not by settings a freq and resolution. Marc On 2016-03-17 17:48, Hauke Petersen wrote: Hej Marc, this seems like a pretty broken design to me, who knows what TI was thinking... Anyway, by looking at the datasheet, I think that the solution to this problem in this case

Re: [riot-devel] PWM API change

s would mean the 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

Re: [riot-devel] PWM API change

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 controller servo motors 16-bit is normally still more than sufficient... So I think the key here lies in the PWM implementation,

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

wrote: Oops, did not remember that one. Thanks Hauke! Emmanuel On Mar 4, 2016 08:49, "Hauke Petersen" <mailto:hauke.peter...@fu-berlin.de>> wrote: 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

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 16.02

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

Re: [riot-devel] USB BLE HCI protocol

Hi, there are multiple places. How about you start with the pages of the Bluetooth SIG [1]? Further the Nordic developer pages are usually having much information on BLE on them [2]. Otherwise just start with google :-) Cheers, Hauke [1] https://www.bluetooth.com/ [2] https://devzone.nordics

Re: [riot-devel] USB BLE HCI protocol #4684

HI Phanindra, there are no pre-requisites. If you want to look into BLE, just start to write code or even better describe your technical plan in detail to this list and discuss it with the community! Cheers, Hauke On 06.02.2016 23:08, PHANINDRA SURA wrote: Hello, I would like to work on t

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

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 0

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 pi

[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] 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, all

Re: [riot-devel] drivers/SAUL

, Thank you for your answer. I executed the default example in my samr21 but unfortunately only the led is supported. I hoped that there was an abstraction on the rest of the gpios so I would be able to connect an actuator easily. Best, Ilias 2016-01-20 11:45 GMT+01:00 Hauke Petersen <mailto:hauk

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 dr

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 your

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

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 specifi

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

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 are

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 si

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 app

Re: [riot-devel] Task Forces

On 19.11.2015 16:50, Emmanuel Baccelli wrote: OK, I could go ahead and modify the wiki with some tentative text for that, which we could refine later on. In practice: - would Kaspar agree he was the shepherd of the timers task force? - would Martine & Hauke agree they were the shepherds of t

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 STM32F4

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 cc

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 desktop

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 har

Re: [riot-devel] msp430 thoughts

Hi, currently it seems like we do not have any 'main' msp430 developers, though there are some who have spend some time on these boards. I have just last week implemented our low-level peripheral interfaces for UART, timers, SPI, and GPIO for the msp430 - stumbling on exactly the painful inco

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 >: Hey, On 08/14/15 14:54, Oleg Hahm

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 lik

[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 https://li

Re: [riot-devel] Using C++ in device drivers

Hi, On 09.07.2015 21:20, Kaspar Schleiser wrote: So I'd be reluctant to change any of the core interfaces to use C++. Kaspar +1 (same for device drivers, platform, etc). Cheers, Hauke ___ devel mailing list devel@riot-os.org https://lists.riot-os.o

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

1-port1: unable to enumerate USB device ... maybe the virtual consoles are not supported in Linux ... 2015-06-26 14:58 GMT+02:00 Hauke Petersen <mailto:hauke.peter...@fu-berlin.de>>: Hi Olivier, I assume you are talking about this mbed-lpc1768 board [1]? Flashing sho

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

Hi Olivier, I assume you are talking about this mbed-lpc1768 board [1]? Flashing should work via RIOTs make system: just connect the board, switch into your RIOT application folder (e.g. default) and call 'make flash' after building: connect the board via USB #cd ../RIOT/examples/default #BO

Re: [riot-devel] Device ID feature in RIOT

Hi Kevin, I think we had that discussion before, have a look at the CPUID peripheral driver as well as this PR [1]. I also commented this into the your PR.. Cheers, Hauke [1] https://github.com/RIOT-OS/RIOT/pull/2963 On 19.06.2015 14:15, ROUSSEL Kévin wrote: There: PR #3223. Le 19/06/20

  1   2   >