[riot-devel] Introduction, some technical questions.

Hauke Petersen hauke.petersen at fu-berlin.de
Wed Sep 9 11:54:18 CEST 2015


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 hardware and software 
> platform design for 6LoWPAN is my subject of Masterthesis. In the 
> following year I am supposed to run a small 6LoWPAN mesh and 
> performwide tests showing the potential of 6LoWPAN. Its usage is seen 
> in industrial sensor meshes.
> The debate about IoT operational systems revolved around Contiki, 
> RIOT, Thread and ARM EmbedOS. Despite some work has been done around 
> Contiki by previous student, we chose RIOT as it is the fastest 
> developing system.
>
> Up till now, I have done:
> - EFM32WG port to RIOT system - libraries, startup, vectors have been 
> included to the project (locally);
>
I have acutally also ported the EFM32WG to RIOT some weeks ago, though 
it is not merged yet. But have a look at the PR [1]. It containts periph 
drivers for timers, uart, and GPIO.
>
> - usart and timer implementation (console is working, hwtimer too);
> Generally speaking system is functional but it’s still in the 
> beginning stage.
>
> Couple of topics and some technical questions I have:
> 1) UART communication - searching through the libraries, I didn't find 
> any solution based on interrupt handling or DMA.
>
Actually, all our UART implementations are interrupt driven, at least 
for receiving. We are further trying to enhance the existing drivers 
towards also using interrupt driven sending. Also there is some work in 
progress to optimize our UART driver interface -> [2].
>
> Is it necessary to implement DMA or Interrupt writing?
>
DMA could be added on a per CPU basis, but it has not yet been done for 
any platform -> classical issue of missing man-power :-)
>
> 2) What is the difference between thread and posix thread. Which is 
> desired in IoT software?
>
The difference is quite simple. Both use the same code for threading in 
RIOT, and what you mention are just different interface to the same 
functionality. The (RIOT) thread API (core/inclide/thread.h) is very 
light weight and stripped down to the most essential -> use this for 
when writing SW from scratch or if you want to be efficient. Posix 
threads (pthreads) implement a wrapper on top of this API to be 
consistent with the Posix API -> use this when you want to port existing 
libraries to RIOT.
>
> 3) I was a little confused while exploring the timers libraries.
>
Understandable - this is why we currently switch to a new timer system: 
the xtimer. For a better understanding a short overview: we have two 
timer layers that work together: the peripheral timer abstracts the CPUs 
timers - it basically gives a unified access to the timers your MCU 
provides, without any multiplexing, chaining and so on. The xtimer is 
put on top of this and takes care of multiplexing, overflows and all 
this stuff. The xtimer is also build in a way, so that it can cope with 
low-level timers of different width, e.g. 16-bit, 24-bit, 32-bit 
peripheral timers.

Previously we had a 3-layer architecture, with periph timer -> hwtimer 
-> vtimer. But this is deprecated now and is in the process of being 
removed...
>
>     a) hwtimer is essential to Kernel. It is responsible for delays 
> and so on. Hardware timer speed is initialized to 1MHz, tell me what 
> is the longest period needed by it? For example 16 bit timers maximum 
> delay will be around 64ms - it seems to be insufficient. May this 
> timer be clocked much slower, f.e. 36kHz?
>
hwtimer is deprecated and will be removed this week :-). This is taken 
care of by the xtimer...
>
>     b) Why we have double wrapper to hwtimer? Some processors have 
> directly implemented hwtimer functions and the rest is done through 
> RIOT/sys/compat/hwtimer_arch.c.
>
all deprecated code, is being cleaned up as we speek. As mentioned 
above: all you need is the xtimer and the periph timer.
>
>     c) What is going on in situation where we have 1 hw timer with 3 
> compare registers but it will be insufficient for networking algorithm 
> to work properly?
>
xtimer takes care of this.
>
>     d) Is there any possibility to initialize not one, but f.e. 4 
> hwtimers on 4 peripheral timers? I have 4 timers in EFM32WG990, so why 
> use a cpu consuming vtimer wrapper working on one hwtimer while we 
> could make use of MCU peripherals?
>
ne need for this, the multiplexing of xtimer on 1 periph timer is more 
power efficient then letting run 4 periph timers in parallel
>
>     e) Does RIOT support absolute time? I could make use of RTC 
> peripheral clock for this, in EFM32 MCU, it is not power consuming.
>
yes. At the moment you can use the RTT and RTC interfaces directly, and 
these will also be integrated in the xtimer. The idea is, to use a slow 
timer (e.g. RTT or RTC) for long running timers, and enable and use the 
periph timer only for the last part of those intervals. This allows the 
CPU to go to lower sleep modes while timers are active...
>
> 4) Could anyone explain me the power stages used in RIOT:
>     - ON
>     - IDLE
>     - ACTIVE
>     - POWERDOWN
>     - OFF
>
Not sure, there were some issues and PRs that discussed these in more 
detail -> @Oleg, @Kaspar do you remember these discussions?
>
>     EFM32 has 5 energy modes and a couple of peripherals functioning 
> well in low power modes. How can I make use of them in RIOT? Here is a 
> short description:
> https://www.silabs.com/Support%20Documents/TechnicalDocs/AN0007.pdf
>
The really important question here is: do you really need them all? 
Before you focus on them in detail, it is really important, that when 
using an OS like RIOT, you have to make always compromises between 
portability to other X platforms (as RIOT does), and the specialized 
features of your 1 platform. We will of course never find a hardware 
abstraction for different MCU families and even architectures, that is 
portable and can cope with all the small details of one platform!

So back to your question: Try to find which of the 5 energy modes are 
actually useful and map RIOTs power modes to these in a sensible matter 
for now. Once the release is done, we will have a more extensive 
discussion and might be updating the lpm module slightly - feel free to 
join that discussion and share your experiences!
>
>
>
> It’smy first letter here. I am not used to mailing list, so in case I 
> misunderstood the form or chose the wrong place to post my questions 
> write me about it.
>
This is the perfect for this kind of questions - welcome agian to the list!

Cheers,
Hauke

[1] https://github.com/RIOT-OS/RIOT/pull/3571
[2] https://github.com/RIOT-OS/RIOT/pull/3265

>
> _______________________________________________
> devel mailing list
> devel at riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/devel/attachments/20150909/f6347415/attachment.html>


More information about the devel mailing list