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@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
