Re: [riot-devel] SAMR21: SPI, at86rf233, I2C

Hi Baptiste, On 13.11.2014 17:22, Baptiste Clenet wrote: Hi, I have seen the pull request from Troels51 concerning the SAMR21. Is that normal that it uses the transceiver at86rf231 instead of the at86rf233? The SAMR21 Explained pro board uses the *at86rf233 *transceiver so something should

Re: [riot-devel] Basing my cpu/board port off existing ports

for more * details. */ /** * @ingroup cpu_stm32f1 * @{ * * @file lpm_arch.c * @brief Implementation of the kernel's lpm interface * * @author Alaeddine Weslati alaeddine.wesl...@inria.fr * @author Hauke Petersen hauke.peter...@fu-berlin.de * * @} */ All the functions in this file contain a single line

Re: [riot-devel] hwtimer implementation for Freescale MKW2xDxxx

Hi Johann, hi Gebart, first I have to say that I have not worked with any Kinetis MCU so far, so don't nail me down on details... As far as I see it, we have a short- and a longterm solution: For now I think the using the LPTMR seems reasonable, although it only offers a single channels if

Re: [riot-devel] Persistent configuration interface

it's possible for me. Regards, Frank Am 29.12.2014 um 15:04 schrieb Hauke Petersen: Hi Frank, shuch a solution is at least partly already in place in RIOT, however implemented only for the MSBA2/LPC23xx platform to my knowledge. It is however a more generic interface/approach missing

Re: [riot-devel] readline / writeline interface based on periph/uart

Hi Christian, as far as I know it's not in riot directly, but you coult implement it in a couple of lines (simplified - no error handling...): char buf[100]; int num_of_bytes = readline_stdin(buf, sizeof(buf)); OR int num_of_bytes = readline(UART_x, buf, sizeof(buf); int readline_stdin(char

Re: [riot-devel] readline / writeline interface based on periph/uart

Oh, forgot - have a look at the system call _read and _write implementations (e.g. for the stm32f0), for the case UART0 is not defined, there you got a pretty good template how to implement some read/writeline features without using the uart_x_blocking functions Cheers, Hauke On

Re: [riot-devel] Network Stack Task Force

tomorrow morning. See you tomorrow, Hauke On 16.01.2015 19:08, Hauke Petersen wrote: Dear RIOTers, we recently came up with the idea to create task forces around special topics in RIOT to concentrate and speed up the development of key parts. The idea is to bring all people that are interested

Re: [riot-devel] Network Stack Task Force

Good Morning again, we will continue with the network stack soon. If you want to join remotely, here is the PlaceCam link: http://placecam.de/call.php?c=0~dA5j0OrfTdsesyQKlqIZvQi7bo1YKYGdMORGFmqL8- http://placecam.de/call.php?c=0%7EdA5j0OrfTdsesyQKlqIZvQi7bo1YKYGdMORGFmqL8- How-To use it?

Re: [riot-devel] thread is not working

)__bss_start__; i (uint32_t)__bss_end__; i++) { addr = (int*)i; *addr = (int)NULL; } I am not sure this is the /correct/ way to do it, but the .bss definitely needs to be initialised to zeros. Hope that helps, Ryan On 14 January 2015 at 07:56, Hauke Petersen hauke.peter...@fu

[riot-devel] Network Stack Task Force

Dear RIOTers, we recently came up with the idea to create task forces around special topics in RIOT to concentrate and speed up the development of key parts. The idea is to bring all people that are interested in this topic and are prepared to spend some on it together in a (virtual) room and

Re: [riot-devel] Network Stack Task Force

Hi, On 16.01.2015 19:46, Oleg Hahm wrote: Hey Hauke! For the workshop I propose January 27-28, but its just a proposal... Keep in mind, that the next HA is scheduled for January 27. Of course I did not. :-) But I think thats a perfect fit! Cheers, Hauke Cheers, Oleg

Re: [riot-devel] NRF51 unable to poweron RNG (is it a bug or is it me?)

Hi guys, I would propose you take a good look at the NRFs errata sheet: it's (i) quite long and (ii) tells you lot's of things that work on one stepping but do not work on another... I took my for example quite some time to find out, that my NRF bords have their timers fixed to 24-bit width

Re: [riot-devel] thread is not working

Hi Shishir, when RIOT initially starts up, the CPU is normally running in interrupt mode (using the interrupt mode stack). After creating the stacks for the main and the idle threads, the CPU must be put into thread-mode. This means the main threads initial context needs to put into the CPUs

Re: [riot-devel] RFDuino Board - add to Wiki please (and more)

Hi Frank, good to hear that somebody is following up on the work on the Nordic SoCs! To give you a quick overview on the current state of the RIOT support: - the basic support for the NRFs peripherals is quite good (timers, UART, GPIO, rtt, rng), for SPI there is a open PR [1], for PWM [2],

Re: [riot-devel] RFDuino Board - add to Wiki please (and more)

Hi Jan, On 13.01.2015 11:13, Jan Wagner wrote: Hi christian, i will create the gfx soon. I also wanted to do some testing about the PIN nunberig. https://github.com/RIOT-OS/RIOT/blob/master/boards/yunjia-nrf51822/include/periph_conf.h #define GPIO_0_PIN 7 #define GPIO_1_PIN 8 #define

Re: [riot-devel] Event driven drivers

Hi, we do indeed have a number of places in the driver code, where busy waiting is used. The reason for this is mostly missing man power to implement better versions of the same driver. The most important fact here is, that you can re-implement a driver in a more efficient way completely

Re: [riot-devel] Event driven drivers

Hi again, On 09.02.2015 14:33, Kaspar Schleiser wrote: Hi Joakim, On 02/09/15 14:20, Joakim Gebart wrote: Has anyone measured the cost of the thread context switching on the different platforms? I'm mainly interested in Cortex-M4 (Kinetis). This would be a good indication of how slow an I/O

Re: [riot-devel] Virtual GSOC Meeting

Hi everyone, we had a synchronization issue. Please connect to this link: http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc- Cheers, Hauke On 16.03.2015 21:03, Hauke Petersen wrote: Dear RIOTers, there is a lot of interest in our GSOC projects (which is great

Re: [riot-devel] Virtual GSOC Meeting

with the RIOT PlaceCam account! Cheers, Hauke [1] https://github.com/RIOT-OS/RIOT/wiki/Instructions-for-remote-participation On 16.03.2015 21:03, Hauke Petersen wrote: Dear RIOTers, there is a lot of interest in our GSOC projects (which is great!). As the next developer meeting is still

Re: [riot-devel] GSoC 2015 - Porject S2: RIOT as an RPython module

Hi Damián, welcome to RIOT (and sorry for the late reply...). If you are still interested, the next step for you would be to prepare a short application [1][2]. The main part of the application consists of your proposed (high-level) project plan. Maybe have also a look at our last

Re: [riot-devel] Help need

Hi and welcome to RIOT! To get started I would recommend looking around in the RIOT wiki [1] for starters. Especially the wiki pages on development procedures [2] and contribution guidelines [3] might be most interesting. As next step we encourage everyone to start out with small pull

Re: [riot-devel] GSOC-2015 Application

Hi Shrenik, welcome to the RIOT community! The best way to get started with RIOT is to cruise around our wiki pages [1]. Here you find information on how to contribute [2] and our general development procedures [3]. The best way to start contributing is to look at the list of open issues in

Re: [riot-devel] GSOC 2015 Project N2: Implementation of LwM2M

Hi Vaneet, welcome to RIOT! To get familiar with RIOT, I would recommend to prepare one or two small pull requests and try to get them merged. Have a look at the contributing and development guidelines in our wiki [1][2]. The easiest to get started is to look at the list of issues labeled

Re: [riot-devel] [GSOC] Introduction

a rough idea about an architecture and a high-level project plan on how you would like to structure this as a GSOC project? I encourage you to share this with us, so we can help you to improve it! Cheers, Hauke 2015-03-16 19:21 GMT+01:00 Hauke Petersen hauke.peter...@fu-berlin.de

Re: [riot-devel] [GSoC 2015] Question about project idea

Hi Dimitrii, welcome to RIOT! I think generally support for HTTP/2 is something that could be very interesting to RIOT. Although I think that HTTP/2 is probably only an option for the upper scale of devices in terms of memory and processing power, there might be quite some use cases where

Re: [riot-devel] GSoC: Application for participation

Hi Batov, welcome to RIOT! To get started on the project, I would suggest that you spend some initial thoughts on a high-level architecture for your BLE implementation and share this with the community. This architecture should help you to plan your project and will get you some feedback

Re: [riot-devel] CC430 compile

Hi İlkay, to my knowledge anyone has started to port RIOT to the EW430 board, yet. So go ahead! For first steps have a look at the development procedures [1] and our porting guide [2]. Have fun coding! Cheers, Hauke [1] https://github.com/RIOT-OS/RIOT/wiki/Development-procedures [2]

Re: [riot-devel] RIOT/tests/vtimer_msg/main.c Failure after 1 hour 5 minutes an 32 seconds

Hi Baptiste, hi Karel, the vtimer problems are (infamously) well known at the moment. We are currently putting a timer task-force in place that will focus on re-designing the timer infrastructure. So expect some further information on this soon! Cheers, Hauke On 10.03.2015 09:32, Baptiste

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] Hack'n'ACK 2015-03-04

Hi again, just killed our PlaceCam here... Same link, sorry! Cheers, Hauke On 03.03.2015 17:36, Hauke Petersen wrote: Hi everyone, the PlaceCAM link for the HnA is set: http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc- Sorry for not sharing it earlier... Cheers

Re: [riot-devel] Repository for Docker builds

Hi Joakim, +1 from my side! Cheers, Hauke On 23.02.2015 09:35, Oleg Hahm wrote: Hi Joakim! I'm completely fine with that. Thanks for the effort! Cheers, Oleg Am Mon, Feb 23, 2015 at 09:18:42AM +0100 schrieb Joakim Gebart: I'd like to hear if anyone is strongly opposed to this, otherwise I

Re: [riot-devel] replace printf, puts issue

Hi Attilio, personally I think Macros might not be the best idea - one of the design principles of RIOT so far is to limit the use of Macros to the minimum. You can actually get the same results for the code below by using a plain API based approach: log_api.h: void log_info(...);

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

[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

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

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

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

[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

[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

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

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

[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

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

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

[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

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

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

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

[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

  1   2   >