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

[Hauke Petersen]

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 
copy them into RAM to reduce the ROM overhead. Often a dual approach 
makes sense: keep the static config in ROM and only copy the often used 
fields into the device descriptor, e.g. the SPI/I2C bus and similar...


So as I see it, there is no right or wrong, but it always depends :-)

Cheers,
Hauke


On 8/26/20 3:04 PM, Benjamin Valentin wrote:

Hi,

I've noticed drivers in RIOT will usually keep a copy of their
configuration parameters in RAM:

typedef struct {
 riot_driver_params_t params;
} riot_driver_t;

void riot_driver_setup(riot_driver_t *dev,
const riot_driver_params_t *params)
{
 dev->params = *params;
}

Why is it done this way instead of keeping a pointer to the location in
ROM?

typedef struct {
 const riot_driver_params_t *params;
} riot_driver_t;

void riot_driver_setup(riot_driver_t *dev,
const riot_driver_params_t *params)
{
 dev->params = params;
}

The only reason I can think of is that accessing RAM is faster than
ROM on Flash - or am I missing something?

Best,
Benjamin
___
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

Re: [riot-devel] ADC API resolution

[Hauke Petersen]

Hej,

@Koen I like that idea! However, we must be careful to differentiate 
between the actual bit-width (6,8,10,...) of the ADC and the value 
assigned to the enum members of adc_res_t. While a user might be 
interested in the former for result shaping etc, the latter can have any 
arbitrary values, mostly concerning bit positions in some register. So 
we might need some lookup table or similar to translate from the enum 
members to the actual bit-width values...


Cheers,
Hauke

On 1/8/20 3:51 PM, Marian Buschsieweke wrote:

Hi,


I was thinking of a function such as `adc_res_t adc_res_max(adc_line_t line)`
to be able to support different ADC peripherals on a single image.

good point! This could be provided with no run-time overhead in
drivers/include/periph/adc.h e.g. via:

 #if !defined(HAVE_ADC_RES_MAX)
 static inline adc_res_t adc_res-max(adc_line_t line) {
 (void)line;
 return ADC_RES_NUMOF - 1;
 }
 #endif /* HAVE_ADC_RES_MAX */

And overwritten as needed. This would also make retro-fitting external ADC
drivers to that API easier.

Kind regards,
Marian

On Wed, 8 Jan 2020 14:59:18 +0100
Koen Zandberg  wrote:


Hi all,

A month or so back I added ADC peripherals bindings for the MicroPython
fork. As this had to be generic across boards I also stumbled over a
missing run-time indicator for which resolutions are supported. At that
moment I worked around it by iterating over all possible ADC resolutions
until a supported resolution was tried. Of course this is a bit suboptimal.

I'm very much in favor of some way to determine the available
resolutions and min/max resolutions of an ADC. I was thinking of a
function such as `adc_res_t adc_res_max(adc_line_t line)` to be able to
support different ADC peripherals on a single 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 are produced in cases where values are deducted
programmatically via (potentially broken) code, or from broken
indirect configuration (nested defines...). The main point is simply
that the compiler does not catch this and we need to handle it somehow
-> which we agree upon as it seems :-)

  So +1 in documenting the preconditions correctly, checking the `line`
and `res` values using assertions and not returning any specific code.
How about we change the API doc to something `@return <0 for any
internal error` or similar, to still allow certain peripherals to
signal an error and mark the result invalid.

While touching this API, would it make sense to also change the return
type from `int` to `int32_t`? This 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 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...

To me, this is a text book example of garbage in, garbage out. I personally
don't expect someone to use random numbers out of the head of their mind
instead of the enum constants and expecting things to just somehow
magically work.

How about we add a precondition statement to the API documentation that
only values provided via enum constants are valid input for the resolution?

But if we cannot assume a minimum level of common sense being applied to
the users source code, why not at least use assert()? This way at least
production code doesn't have to pay the overhead of checking for
completely insane bugs.

(Don't get me wrong: I personally very much in favor of doing proper error
handling even at the expense of some overhead. But adding overhead to
check for completely crazy stuff seams not to be a good trade off to me.)
  

Hence the two fold approach in the current implementations: each CPU
should define only the ADC_RES_X values it actually supports and on top
adc_sample() *should* return -1 on unsupported values to catch mishaps
as stated above.

Sadly, neither is it (consistently) implemented like this nor documented
this way. But if there is an agreement that only the enum constants
actually supported should be defined, I can open a PR to document this.
But let's keep the discussion on how to handle it if users call
adc_sample() with a resolution not provided by the enum going for while.

While I'm at it: How should adc_sample() behave if the line parameter is
out of range? This is something that can easily happen, e.g. when
compiling code written for one board for a different board. Again: I would
say a precondition added to t

Re: [riot-devel] ADC API resolution

[Hauke Petersen]

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 in cases where values are deducted programmatically 
via (potentially broken) code, or from broken indirect configuration 
(nested defines...). The main point is simply that the compiler does not 
catch this and we need to handle it somehow -> which we agree upon as it 
seems :-)


 So +1 in documenting the preconditions correctly, checking the `line` 
and `res` values using assertions and not returning any specific code. 
How about we change the API doc to something `@return <0 for any 
internal error` or similar, to still allow certain peripherals to signal 
an error and mark the result invalid.


While touching this API, would it make sense to also change the return 
type from `int` to `int32_t`? This 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 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...

To me, this is a text book example of garbage in, garbage out. I personally
don't expect someone to use random numbers out of the head of their mind
instead of the enum constants and expecting things to just somehow magically
work.

How about we add a precondition statement to the API documentation that only
values provided via enum constants are valid input for the resolution?

But if we cannot assume a minimum level of common sense being applied to the
users source code, why not at least use assert()? This way at least production
code doesn't have to pay the overhead of checking for completely insane bugs.

(Don't get me wrong: I personally very much in favor of doing proper error
handling even at the expense of some overhead. But adding overhead to check for
completely crazy stuff seams not to be a good trade off to me.)


Hence the two fold approach in the current implementations: each CPU
should define only the ADC_RES_X values it actually supports and on top
adc_sample() *should* return -1 on unsupported values to catch mishaps
as stated above.

Sadly, neither is it (consistently) implemented like this nor documented this
way. But if there is an agreement that only the enum constants actually
supported should be defined, I can open a PR to document this. But let's keep
the discussion on how to handle it if users call adc_sample() with a resolution
not provided by the enum going for while.

While I'm at it: How should adc_sample() behave if the line parameter is out of
range? This is something that can easily happen, e.g. when compiling code
written for one board for a different board. Again: I would say a precondition
added to the doc and an assert() would be this best solution here.

I'd also like to add that the API is not safe to be called from IRQ context, as
(at least some) implementations use a mutex to serialize access to the ADC.

(Btw: If we would replace the `ADC_LINE()` macro by a `static inline adc_t
adc_line(unsinged num)` function, we could use `_Static_assert()` to generate
compile time errors there as well. For backward compatibility an macro
ADC_LINE() calling that function could be provided.)


But I do like the idea of adding defines like `HAVE_ADC_RES_X` and
`_MAX` (and `_MIN`).


I'll open a PR for that. (I will also add the minimum resolution in that.)

Kind regards,
Marian


Cheers,
Hauke

On 12/26/19 10:01 AM, Marian Buschsieweke wrote:

Hi,

I just noticed that most of the ADC implementations providing their own
adc_res_t do not cover all values. The API documentation states that
adc_sample() should return -1 on unsupported resolutions. This indicates that
all possible resolutions have to be defined in any case, so that a user could
check at run time which resolutions are provided.

However: Wouldn't it make more sense to only provide the enum values actually
supported? This would have two advantages:

1. Currently all places where adc_res_t is provided need to be updated when new
 resolutions are added, resulting in some maintenance effort
2. Only having the resolutions defined that are actually supported would result
 in compile time errors, which are much easier to spot and debug than run 
time
 errors

Additionally, use cases where users needed to determine available resolutions
could be address by e.g. defining HAVE_ADC_RES_10BIT when ADC_RES_10BIT is
supported. And ADC_RES_MAX could be provided for the highest resolution enum
and ADC_RES_MAX_BITS for the number of bits this has. This would allow to
determine the resolution at compile time, resulting in les

Re: [riot-devel] ADC API resolution

[Hauke Petersen]

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 define only the ADC_RES_X values it actually supports and on top 
adc_sample() *should* return -1 on unsupported values to catch mishaps 
as stated above.


But I do like the idea of adding defines like `HAVE_ADC_RES_X` and 
`_MAX` (and `_MIN`).


Cheers,
Hauke

On 12/26/19 10:01 AM, Marian Buschsieweke wrote:

Hi,

I just noticed that most of the ADC implementations providing their own
adc_res_t do not cover all values. The API documentation states that
adc_sample() should return -1 on unsupported resolutions. This indicates that
all possible resolutions have to be defined in any case, so that a user could
check at run time which resolutions are provided.

However: Wouldn't it make more sense to only provide the enum values actually
supported? This would have two advantages:

1. Currently all places where adc_res_t is provided need to be updated when new
resolutions are added, resulting in some maintenance effort
2. Only having the resolutions defined that are actually supported would result
in compile time errors, which are much easier to spot and debug than run 
time
errors

Additionally, use cases where users needed to determine available resolutions
could be address by e.g. defining HAVE_ADC_RES_10BIT when ADC_RES_10BIT is
supported. And ADC_RES_MAX could be provided for the highest resolution enum
and ADC_RES_MAX_BITS for the number of bits this has. This would allow to
determine the resolution at compile time, resulting in less overhead in terms
of both runtime and memory.

But: As currently the approach to detect available resolutions would result in
compile time errors (when testing for resolutions not covered in the enum),
maybe nobody actually needs this?

Kind regards,
Marian

___
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

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

[Hauke Petersen]

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 to drop 
support for now. If ever someone has the need to use the avsextrem 
again, it is very easy to re-add support as long as we keep the `msba2` 
supported.


Cheers,
Hauke

On 9/16/19 11:13 AM, Marco Ziegert wrote:

Dear Marian,

the avsextrem is a MSB-A2 with acceleration sensor and open for different power 
sources intentionally for mobile/outdoor use.
When I left there have been 100-200 sensors at FU Berlin, but I don’t know if 
they are in use.

I would suggest to look for the differences between MSB-A2 and avsextrem and 
decide if it’s worth the PR. If I remember correctly only the CC1101 was 
internally connected to another SPI, and some more LEDs.

Best regards,
Marco


Am 16.09.2019 um 09:39 schrieb Marian Buschsieweke 
:

Hi,

are there still users of the board avsextrem? I'd like to create a PR to drop
support for it. I believe this is again a board with no users left.

Kind regards,
Marian
___
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


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

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

[Hauke Petersen]

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/examples/default on the Thingy:52.


I'm using a JLink-OB on another DK. The following devices show up on 
Linux:

/dev/ttyACM0
/dev/ttyACM1
/dev/ttyACM2

I've tried them all with no success.

Programming works fine, but the RTT terminal doesn't:

Downloading file 
[release-2019.07/examples/default/bin/thingy52/default.bin]...

Comparing flash   [100%] Done.
Erasing flash     [100%] Done.
Programming flash [100%] Done.
Verifying flash   [100%] Done.
J-Link: Flash download: Bank 0 @ 0x: 1 range affected (16384 
bytes)
J-Link: Flash download: Total time needed: 0.327s (Prepare: 0.032s, 
Compare: 0.004s, Erase: 0.000s, Program: 0.280s, Verify: 0.002s, 
Restore: 0.007s)

O.K.

release-2019.07/dist/tools/jlink/jlink.sh term_rtt
### Starting RTT terminal ###
Twisted not available, please install it if you want to use pyterm's 
JSON capabilities
2019-08-22 22:03:24,215 - WARNING # Host name for TCP connection is 
missing, defaulting to "localhost"

2019-08-22 22:03:24,216 - INFO # Connect to localhost:19021
Welcome to pyterm!
Type '/exit' to exit.
2019-08-22 22:03:25,220 - INFO # SEGGER J-Link V6.48a - Real time 
terminal output
2019-08-22 22:03:25,221 - INFO # J-Link OB-K22-NordicSemi compiled Feb 
14 2019 14:03:18 V1.0, SN=960077373

2019-08-22 22:03:25,221 - INFO # Process: JLinkExe

Any ideas?

Cheers,
Rik

___
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

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

[Hauke Petersen]

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 #11085 (Serial console over USB) & PR #11077 (USB CDC ECM support)

Those two combined with something like the SAM-BA bootloader (Arduino 
SAMD bootloader compatible with BOSSA) would allow us to make 
easy-upgradeable one-chip border-router USB dongles based on the 
ATSAMR21. USB CDC ECM essentially could remove the need for ethos.


Regards,
Mario.

On Fri, May 31, 2019 at 6:51 AM Kevin Weiss 
mailto:kevin.we...@haw-hamburg.de>> wrote:


|Dear RIOTers,


The release dates for the upcoming release cycle are fixed as follows:

- 28.06.2019 - soft feature freeze, for high impact features

- 08.07.2019 - hard feature freeze, for all features

- 31.07.2019 - Release date

Could you please send your suggestions for features which you
would like to see merged during this release cycle.


Best regards, and happy hacking!

Kevin Weiss|
___
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


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

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

[Hauke Petersen]

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. Keeping this in mind, all the needed startup 
code, base linker scripts, ... etc, are implemented and provided by the 
shared `cpu/cortexm_common` code path. All the specific CPU 
implementations have to provide, are their interrupt vector structure 
(see e.g. `cpu/samd21/vectors.c` or `cpu/stm32f4/vectors.c`), their 
memory layout (see e.g. `cpu/sam0_common/Makefile.include`), their clock 
initialization code (see e.g. `cpu/samd21/cpu.c`), and of course there 
peripheral driver implementations (typically in a `periph` subdir).


So with this, all you need is to extract that information above from the 
vendor libraries and you should be good to go!


Cheers,
Hauke


On 5/28/19 5:04 PM, Juan Ignacio Carrano wrote:

Hi Ashim,

I assume you are basing your SmartFusion port on some existing CPU. If 
that's the case, it would be useful to know which one. Even better if 
you can link us to a publicly accessible repo.


I have tried including this file in the new cpu folder I created but 
get the following error when trying to make:
arm-none-eabi-gcc: error: 
/home/user/Desktop/SmartFusion2/testjig/riot/2019.04/examples/hello-world/bin/sf2-starter-kit/cpu/vectors.o: 
No such file or directory




The first question is why the build system is expecting to find 
vectors.o. Not all CPUs generate that file (in your case you would 
compile startup_m2sxxx.S into startup_m2sxxx.o) I believe the answer 
to this question lies in the CPU you started with.


For example: you mention the LPC2387. If you compile any example with
BOARD=msba2 (which uses that cpu) and look inside "bin/msba2/cpu" you 
will not find any vectors.o and that's OK.


How do I use the above file correctly in the RIOT port? Is there some 
configuration that should be changed to use the file properly or 
should I convert it to a vectors.c file? If so, how do I go about 
doing so?




AFAIK you should not need to convert anything, just place the .S file 
in your CPU directory, but without knowing the full contents of the 
dir it is hard to tell what is happening.


Regards,

Juan.
___
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

Re: [riot-devel] USB PID number

[Hauke Petersen]

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 > a écrit :


Hi Juan,

On 2/25/19 3:19 PM, Juan Ignacio Carrano wrote:
> Hi all,
>
> First of all, great work. Now to the VID, PID matter: I don't
think we
> should get any VID. A single PID may be ok.
>
> Product numbers are for products. RIOT is not a product. Rather,
it is
> used to build product (or at least that's wath we hope for). Even if
> we obtained an ID it would be irrelevant for everyone except
> developers: if you develop a device, you should get your OWN
ids, you
> cannot reuse your OS vendor's.
>
> 
>
> I think that having a single PID for "Generic RIOT-powered
device" (or
> something of the sort) is valuable, especially for development, and
> for the CI, and we only really need one, not a whole block.
That, and
> the fact that we have a more or less large project should be enough
> justification to get a PID from pid.codes. Of course, the docs
should
> clearly state that the PID is for use in RIOT development and should
> be changed for actual devices.
>
> A whole VID would not be useful: what would you do with so many
PIDs?

I agree with you here. First of all, I also don't see any use for
a VID
for RIOT-os, but hey maybe somebody else has a use case for a full
VID.

For me, a hypothetical RIOT-os PID would be used only for development
and testing. CI jobs, people wanting to test USB or develop USB
devices.
As soon as the USB device leaves the building it must have a different
VID/PID owned by the developer/company. Having a PID for this is
mostly
for ease of development, so we don't have to use a random VID/PID with
all the consequences. A lot of USB functionality doesn't require a
specific VID/PID, but is purely recognized based on the descriptor
information.

A second PID could be required if we have our own DFU enabled RIOT
bootloader. For this I wouldn't mind if it was used for actual
products
as long as the RIOT bootloader is unmodified. This as in if it
claims to
be the RIOT-os DFU bootloader, it should behave like the RIOT-os
bootloader and be able to flash RIOT-os on the mcu with the
RIOT-os DFU
tooling.

I think Koen perfectly sums up the situation and I agree with him.
VID is pointless for RIOT, but having two PIDs (one for development, 
one for DFU) would be great. Of course, it should be clearly state 
that the devel PID must not be used outside of its original scope.


BTW, If people want to be involve. We must port the lowlevel driver  
and test the stack against several MCUs (EFM32, STM32, 
Kinetis,etc...). Any help is welcome !


Cheers,

Cheers,
Koen


___
devel mailing list
devel@riot-os.org 
https://lists.riot-os.org/mailman/listinfo/devel



--
Dylan Laduranty

___
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

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

[Hauke Petersen]

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 $PATH. Testing
will be as simple as running

 make BOARD=thingy52 PROGRAMMER=openocd flash
 make BOARD=thingy52 term

in `examples/hello_world`.

It would be nice to have this PR tested on the last two remaining boards before
merging it into master.

Thank you very much!

Kind regards,
Marian

[1]: https://github.com/RIOT-OS/RIOT/pull/9407

___
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

Re: [riot-devel] Usage of DMA

[Hauke Petersen]

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 highly appreciated 
if you would add DMA support to the sam3's SPI driver :-)


Cheers,
Hauke


On 1/9/19 4:16 PM, Maksim Dmitrichenko wrote:

Hi everyone!

I'm new to RIOT OS, and I'm trying to use it instead of Arduino on 
Arduino Due board. I briefly examined sources and found that it's SPI 
implementation doesn't use DMA for transfers though MCU supports it. 
Also I found that it is not the issue of the board or the platform, 
though a general lack of paradigm in RIOT OS. Is there any good reason 
for it?


--
With best regards
  Maksim Dmitrichenko

___
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

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

[Hauke Petersen]

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, or should it be kept simple to produce small code? One option
would be to use the pseudomodule approach to enable additional features.


Part of keeping it small is omitting conversion code (see answer below).

How often does it happen that one runs out of flash space? I'm asking 
because I honestly don't know. I do know that it's probably easier for 
the user to remove stuff if he runs out of flash than to read the 
device manual and add the missing functions if the driver is incomplete.

We have to differentiate two dimensions here:
1. code size, as in "How often does it happen that one runs out of flash 
space?" -> IMHO we should not even be asking this question, but always 
expect that people do. Having a low ROM fingerprint is one of the most 
important differentiators of RIOT!
2. feature richness (or poorness): in an ideal world, all drivers would 
support everything. But as manpower is limited, there is a good reason 
for having only basic implementations for many drivers, as we can not 
force contributors to only provide drivers that are feature-complete... 
So I think the current approach: merged 'baseline' drivers and 
'complete' them by demand works fine.



On some platforms unused code is not linked into the binary.



Unused functions, where the linker can determine the function is not 
used. If you have a big function for configuring device modes, but you 
never call it with certain parameters and a bit chunk goes unused, it 
may not be optimized away (I'm not sure if LTO changes this).
yes, thats why my preferred method would be to use submodules for 
certain things. But as always, use common sense: having e.g. a 
read_raw() and a read_converted() function that uses the former, than 
there is no need to 'sub-module' the read_converted(), as it will only 
be compiled in in case it is used. But for other features, there are 
often blocks of code in functions that are used in any case (e.g. 
initialization), which are easily made configurable using submodules.



- Should a driver support at least data-ready interrupts (if possible at
all) to realize event-driven data retrieval?



Yes. Totally yes. Polling is dumb:
I'd say 'dumb' depends very much on the use case. In general I agree 
that IRQ based approaches definitely are to be preferred, but there are 
also very valid use cases where polling is be desirable... So not having 
interrupts in an initial driver is no blocker!


* Goes against low power goals.
* The data is not polled with a clock that is synchronized with the 
sensor clock (if the sensor has an ADC), meaning unpredictable jitter.



- Should a driver always return normalized/converted data, or rather
return the raw data and the application needs to convert them? The
conversion is sometimes quite complex. I saw both approaches of them for
similar sensors.



RAW data.

* Conversion usually results in loss of precision, especially if one 
limits the word length to something like 16 bits (see answer below).
* Doing conversion "right" (in an unbiased way) is non trivial. You 
cannot just go around truncating digits.
* Is is beyond the scope of the driver, which should handle device 
communication/configurations only.

* If the converted value is not needed, the conversion cannot be undone.
* In SAUL, conversion to and from the base-10 floating point format 
used is really painful.


I think the measurement should be raw, and there should be a way to 
query the conversion constant. This way the user can choose, and there 
are not unnecessary computations done.


In control applications, for example, the conversion is totally not 
necessary, as the conversion constants can be folded into the control 
system constants.


Again, not black and white, but very much depending on the use case. If 
the conversion is short and its overhead is negligible, I see no need 
for additional _raw() functions. For all other cases we already provide 
differentiated APIs (or at least we should).



The design rules that are clear to me are:

- Drivers have to provide an interface for polling with init and read
that is compatible with SAUL.



Yes. It makes all interfaces consistent. That being said, it is sad 
that there is no unified way for configuring and for interrupt driven 
measurements.
I think our 'dual' approach (driver specific interface and SAUL on top 
of that) is the way to go. We know, how hard it is to map all the tiny 
device specific modes into a generic interface (see e.g. periph_), so 
having something device specific as base is very powerful. SAUL was 
never meant to map all these specific modes etc, but rather provide 
something slim but generic, for the most obvious device functions.


Fu

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

[Hauke Petersen]

Hi Pekka,

that would indeed be something very desirable. Would you mind maybe just 
dumping this as TODO at the end of the wiki page? Then this is 
'documented' and is not forgotten in the depth of the devel list :-)


Thanks and cheers,
Hauke


On 09/26/2018 01:34 PM, Nikander Pekka 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 <mailto:hauke.peter...@fu-berlin.de>> wrote:


Hi,

long done :-)

Seehttps://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 concept of RDM [1] ?)

Best

Emmanuel





___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

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

[Hauke Petersen]

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 concept of RDM [1] ?)

Best

Emmanuel

[1] https://github.com/RIOT-OS/RIOT/pull/6191


On Wed, Sep 26, 2018 at 11:38 AM Gunar Schorcht > wrote:


Hi Hauke,

many thanks for your comprehensive and clearifying answers. Most
of them
met my thoughts about driver design.

>> - Should a driver support at least data-ready interrupts (if
possible at
>> all) to realize event-driven data retrieval?
> If the driver comes with a 'full/extra' configuration, this is
part of
> it anyway, right? In the simples 'basic' configuration I don't think
> this needs to be part of I would say.

Agreed.

>> - Should a driver always return normalized/converted data, or
rather
>> return the raw data and the application needs to convert them? The
>> conversion is sometimes quite complex. I saw both approaches of
them for
>> similar sensors.
> My opinion is quite clear: I am always in favor of returning
> normalized/converted data. In 90% of the cases the conversion is not
> expensive, so just do it. In those rare cases, where the
conversions is
> actually relatively expensive, we can always fall back by providing
> additional `xx_read_raw()` or similar functions, that allow to
access
> the data before conversion.

Agreed. All the drivers I wrote til now, either return
normalized/converted and raw data with same read function or offer an
additional read_raw function.

>> The design rules that are clear to me are:
>>
>> - Drivers have to provide an interface for polling with init
and read
>> that is compatible with SAUL.
> that is a nice to have, but not a MUST.

Ok.

>> - Output are always 16 bit integers.
> Not quite true. The SAUL interface is build around 16-bit
integers, and
> at least when reading/writing data via SAUL the data needs to be
> converted. But the driver specific interface can always use
other data
> types/lengths. If it is however easily possible to use int16,
one should
> use it.

Ok.

>> What else?
> All this information should go into the 'device driver guide'
>

(https://github.com/RIOT-OS/RIOT/wiki/Guide:-Writing-a-device-driver-in-RIOT).
> This guide needs however still work - and I will not have the
time to do
> it. So it would be nice if other people can help here :-)

Agreed.

Regards
Gunar

-- 
Wenn du laufen willst, lauf eine Meile. Wenn du ein neues Leben

kennenlernen willst, dann lauf Marathon. (Emil Zatopek)

___
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


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

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

[Hauke Petersen]

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). With 
this I mean thinks like e.g. event detection, interrupt mode vs. polling 
etc.). I know choosing those features is definitely not a black&white 
kind of task, but when keeping this on a coarse level I think it should 
be rather straight forward. The goal with this would be to allow people 
to use a simple (e.g. polling) driver configuration (-> low ROM/RAM 
usage), but also allow developers to chose the full fledged feature 
version of the driver, trading ROM/RAM usage against features.


As said, don't aim for a fine grained configuration (e.g. submodules for 
every small feature), but rather go with something like `USEMODULE += 
l3gd20h` for the simple polling configuration, and something like 
`USEMODULE += l3gd20h_full` for all the additional features.

```

To map this reply to the actual questions see inline comments below.

On 09/26/2018 09:27 AM, Gunar Schorcht wrote:

Hi,

I wrote a series of sensor drivers for esp-open-rtos/ESP-IDF, for
example for different ST sensors, the BME680, the CCS811 or the SHT3x. I
would like to port some of these drivers to RIOT OS. All the drivers are
quite complex as they try to cover all the features of the sensors.

I have seen that most drivers in RIOT for similar sensors usually only
implement an interface to with init, read, power-up and power-down. So
I'm wondering now, what the design rules for sensor drivers in RIOT are?

- Should a driver be as complete as possible, which of cource produces
more code, or should it be kept simple to produce small code? One option
would be to use the pseudomodule approach to enable additional features.
On some platforms unused code is not linked into the binary.
As always, the usage of a driver depends heavily on the application use 
case and can differ in many ways. Sometimes a simple but small driver is 
preferable (get me any simple temperature sensor, but I don't have 
RAM/ROM to spare), in other cases some specialized features of a device 
are even the key driver for selecting that specific device. In the 2nd 
case, it is surely of the essence to have a driver that supports all 
those little specials.


So as stated above: IMO having a coarse modularity inside the driver 
should be the way to go, this way we can cover both sides.


- Should a driver support at least data-ready interrupts (if possible at
all) to realize event-driven data retrieval?
If the driver comes with a 'full/extra' configuration, this is part of 
it anyway, right? In the simples 'basic' configuration I don't think 
this needs to be part of I would say.


- Should a driver always return normalized/converted data, or rather
return the raw data and the application needs to convert them? The
conversion is sometimes quite complex. I saw both approaches of them for
similar sensors.
My opinion is quite clear: I am always in favor of returning 
normalized/converted data. In 90% of the cases the conversion is not 
expensive, so just do it. In those rare cases, where the conversions is 
actually relatively expensive, we can always fall back by providing 
additional `xx_read_raw()` or similar functions, that allow to access 
the data before conversion.


The design rules that are clear to me are:

- Drivers have to provide an interface for polling with init and read
that is compatible with SAUL.

that is a nice to have, but not a MUST.


- Output are always 16 bit integers.
Not quite true. The SAUL interface is build around 16-bit integers, and 
at least when reading/writing data via SAUL the data needs to be 
converted. But the driver specific interface can always use other data 
types/lengths. If it is however easily possible to use int16, one should 
use it.


What else?
All this information should go into the 'device driver guide' 
(https://github.com/RIOT-OS/RIOT/wiki/Guide:-Writing-a-device-driver-in-RIOT). 
This guide needs however still work - and I will not have the time to do 
it. So it would be nice if other people can help here :-)


Cheers,
Hauke




Regards
Gunar



___
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

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

[Hauke Petersen]

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 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 time on this. It would be 
great, if anyone else could step up and take the lead. @Dylon: is this 
maybe a job for you?!


The current state:
- tracking issue: #6577 [1]
- new interface proposal: #4926 [2]
- first thoughts on automated, HIL-style test setup: [3]  (see mostly 
tests/softi2ccli/main.c)


The former idea was, to rename the 'legacy' i2c functions (as proposed 
in #6575 [4]), merge the new API and then rework all the 
implementations and device drivers in a step-by-step manner. But with 
more thoughts and recent experiences, the way to proceed is probably 
using the feature-branch approach as recently done for for the new 
ietif remodeling.


So the steps that I see are:
1. finish the work on the testing setup [3], as in-depth testing is 
the key for the remodeling (lessons learned from the SPI remodeling...)
2. implement the proposed interface [2] on some more (restricted) 
target platforms (e.g. nrf52 TWIM) to verify, that the API details do 
actually work on all the CPUs that we support...
3. rewrite existing periph drivers, adapt device drivers, and test 
everything thoroughly. This will take significant time and effort!


Best,
Hauke

[1] https://github.com/RIOT-OS/RIOT/issues/6577
[2] https://github.com/RIOT-OS/RIOT/pull/4926
[3] 
https://github.com/RIOT-OS/RIOT/compare/master...haukepetersen:add_softi2cli

[4] https://github.com/RIOT-OS/RIOT/pull/6575



On 02/07/2018 01:15 PM, Dylan Laduranty wrote:

Dear RIOTers and maintainers,

I would like to know the current status of the new I2C master API. 
It's been a long time since we heard about it. I'm willing to work on 
it and maybe others are also interested.


I'm fully aware that such a big rework will take some times and a lot 
of efforts but this task has to be done.


Would it be useful to create a task force ?

What do you think ?

Cheers

--
Dylan Laduranty


___
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


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

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

[Hauke Petersen]

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 time on this. It would be 
great, if anyone else could step up and take the lead. @Dylon: is this 
maybe a job for you?!


The current state:
- tracking issue: #6577 [1]
- new interface proposal: #4926 [2]
- first thoughts on automated, HIL-style test setup: [3]  (see mostly 
tests/softi2ccli/main.c)


The former idea was, to rename the 'legacy' i2c functions (as proposed 
in #6575 [4]), merge the new API and then rework all the implementations 
and device drivers in a step-by-step manner. But with more thoughts and 
recent experiences, the way to proceed is probably using the 
feature-branch approach as recently done for for the new ietif remodeling.


So the steps that I see are:
1. finish the work on the testing setup [3], as in-depth testing is the 
key for the remodeling (lessons learned from the SPI remodeling...)
2. implement the proposed interface [2] on some more (restricted) target 
platforms (e.g. nrf52 TWIM) to verify, that the API details do actually 
work on all the CPUs that we support...
3. rewrite existing periph drivers, adapt device drivers, and test 
everything thoroughly. This will take significant time and effort!


Best,
Hauke

[1] https://github.com/RIOT-OS/RIOT/issues/6577
[2] https://github.com/RIOT-OS/RIOT/pull/4926
[3] 
https://github.com/RIOT-OS/RIOT/compare/master...haukepetersen:add_softi2cli

[4] https://github.com/RIOT-OS/RIOT/pull/6575



On 02/07/2018 01:15 PM, Dylan Laduranty wrote:

Dear RIOTers and maintainers,

I would like to know the current status of the new I2C master API. 
It's been a long time since we heard about it. I'm willing to work on 
it and maybe others are also interested.


I'm fully aware that such a big rework will take some times and a lot 
of efforts but this task has to be done.


Would it be useful to create a task force ?

What do you think ?

Cheers

--
Dylan Laduranty


___
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

Re: [riot-devel] Timers

[Hauke Petersen]

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 to
bitbang the protocol of WS2812 LEDs very elegantly)

This is probably impossible to get right cross-platform.
Yepp :-) Thats why we separated their interfaces... But there is no 
restriction in reusing code internally when implementing both 
periph/timer and periph/pwm interfaces...


Cheers,
Hauke



Sorry,
PyroPeter


___
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

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

[Hauke Petersen]

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 (targeting the atxmega128). The Atxmega is feature rich when 
contrasted against the Atmega counterpart which I am using as a 
porting guideline.


1) Since I would like to contribute my port to the git repository, how 
should I go about implementing new CPU features not found in the core 
RIOT OS functionality (enhanced TWI, USART, etc.)?
I don't quite get the question. TWI (i2c) and UART are interfaces 
provided by RIOT, which are simply implemented by the specific CPU 
implementations, hence their implementation code should reside in the 
corresponding cpu folder (as in /cpu/atxmega_common/periph/uart.c, etc.).


2) How should I implement the addition of both Master and Slave 
functionality to my peripheral interfaces?
For the master mode of SPI and I2C (TWI) there are interfaces designed 
by RIOT (-> drivers/include/periph/[spi|i2c].h). So simply implement 
them for the ATxmega and you should be good to go.


Currently there are no interfaces for the slave mode of these buses, so 
my proposal would be that you include slave interfaces together with the 
CPU code (so to make the slave implementations CPU specific for now), 
and adapt the code at a later point in time once we introduce slave 
interfaces to RIOT.


3) How should I go about adding interrupt functionality for these 
peripherals?
Not sure what you mean: peripheral specific interrupts should be handled 
inside the corresponding periph drivers. The global interrupt handling 
is abstracted by the core/include/irq.h interface, which needs to be 
implemented for the CPU family.


Hope this information helps, let me know where clarification is needed!

Cheers,
Hauke




Currently I am just smashing these extra features right into the 
driver's .C files as I am trying to preserve the OS-Core files.


Any suggestions would be appreciated!

Madison McCarthy


___
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

Re: [riot-devel] HIL testing

[Hauke Petersen]

Hi Peter,

I think definition/implementation of a I2C slave interface/drivers is 
still wanted. But I found, that for the presented HIL use-case, a custom 
pin-banging i2c slave mock-up implementation is better suited, as it 
further allows us to intentionally trigger faulty bus behavior (not 
releasing the clock line, etc), which gives us even better control than 
using a hardware I2C slave unit for the test peer. When getting to 
testing the actual I2C slave implementations at some point, we would 
IMHO then also need a pin-banging version of a I2C master for testing...


But before jumping into the I2C slave discussion (and same goes of 
course for the SPI slave), I think it makes sense to lead all our 
efforts into the I2C master API remodeling first.


Cheers,
Hauke

On 28.11.2017 09:21, Peter Kietzmann wrote:

Hi Hauke,

thanks for you efforts! This is great and really useful work. IMO it is
the right direction, even though I always hoped to find a way around
implementing our own I2C slave device. That's why I wanted to take this
opportunity to ask around for other experiences with I2C (slave) test
devices. Anyone, anything?

Best
Peter

Am 27.11.2017 um 18:33 schrieb 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 promised to
share it (although it is in very very early state). So here it is.

So the basic idea is to connect the I2C pins of the 'board-under-test'
(i2c master for now) to a 2nd board (lets call it 'test peer'), running
a fully controllable software i2c slave implementation. On the
device-under-test we simply run the 'tests/periph_i2c' app, that lets us
control the I2C master using shell commands (init/read/write incl
parameters). On the 'test peer' we run a programmable soft i2c client,
that offers shell commands expressing expectations, e.g. "expect 4 byter
[abcd] written to addr 0x23".

Now for creating an automated I2C test-suite, I imagine something
similar to our existing pyexpect scripts (testrunner), just with the
added capability of handling two clients. So the test script could look
something like this (mostly pseudocode...):

`PORT=/dev/ttyACM0 TESTPEER=/dev/ttyACM1 make hil-test`

triggers:

```python
...
def testfunc(testie, peer):
     ...
    # tell the 'test peer' to expect something to be written to addr 0x23
and respond with a NACK
     peer.sendline("expect_addr 0x23")
    # write a random byte the addr 0x23
     testie.sendline("w 0x23 a")
     # the 'test peer' will tell if it sees the expected address
     peer.expect("[SUCCESS]")
     # the 'device-under-test' should recognize the NACK
     testie.expect("error: no device with that address found on bus")

     # test writing (expect 4 bytes [affe] written to address 0x42)
     peer.sendline("expect_write 0x42 a f f e")
     testie.sendline("w 0x42 a f f e")
     peer.expect("[SUCCESS]")
     testie.expect("I2C_DEV(0): successfully wrote 4 bytes to the bus\n")

    ...
     # many many more test cases here, including simulation of badly
behaving slaves and bus recovery...
```

I have sketched a I2C slave implementation to run on the 'test peer' in
[1] (under `tests/softi2ccli`). It is in no means production code, but a
quick prove of concept. But IMHO this would be a very easy and straight
forward way to have an automatic test-suite that would work on someones
desk for now.

Integration into the bigger picture would hopefully be easy doable, but
this not in the scope of this particular proposal here...
For now my goal would simply be to build a test suite for assisting with
the upcoming I2C remodeling to get some hands-on experience and speed up
the testing efforts for that task.

Cheers,
Hauke

[1] https://github.com/haukepetersen/RIOT/tree/add_softi2cli
___
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

Re: [riot-devel] RIOT developers monthly meeting

[Hauke Petersen]

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 easier to tune in any other day of the 
week. I’m just generally asking since my actual RIOT development 
availability is very limited anyways.


Best, Thomas

On Nov 28, 2017, at 4:59 AM, Francisco Javier Acosta Padilla 
mailto:francisco.aco...@inria.fr>> wrote:



+1 on my side too.

--
Francisco Javier Acosta Padilla
Research Engineer at INRIA Saclay
INFINE Team

On 28 November 2017 at 12:24:00, Alexandre Abadie 
(alexandre.aba...@inria.fr ) wrote:



Hi,



Hi,

as hinted yesterday, I usually need to go around 5:30pm. So I
was wondering if we can move the meeting to 4pm.


+1


Cheers,
Martine

2017-11-27 16:33 GMT+01:00 Francisco Javier Acosta Padilla
mailto:francisco.aco...@inria.fr>>:


RIOT developers monthly meeting
Scheduled: 27 Nov 2017 17:00 to 18:00
Location: https://zoom.us/j/235153205
Invitees: devel@riot-os.org ,
Francisco Javier Acosta Padilla
Hi there,

Francisco Acosta is inviting you to a scheduled Zoom meeting.

Join from PC, Mac, Linux, iOS or Android:
https://zoom.us/j/235153205

Or iPhone one-tap :
    US: +16699006833 ,,235153205#
 or +16465588656 ,,235153205#
Or Telephone:
    Dial(for higher quality, dial a number based on your
current location)：
        US: +1 669 900 6833   or
+1 646 558 8656 
    Meeting ID: 235 153 205
    International numbers available:
https://zoom.us/zoomconference?m=3QuTkS0wteDtL_3pyOjFM0KBPZ_220mB


-- 
Francisco Javier Acosta Padilla

Research Engineer at INRIA Saclay
INFINE Team

___
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


___
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



___
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

[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 promised to 
share it (although it is in very very early state). So here it is.


So the basic idea is to connect the I2C pins of the 'board-under-test' 
(i2c master for now) to a 2nd board (lets call it 'test peer'), running 
a fully controllable software i2c slave implementation. On the 
device-under-test we simply run the 'tests/periph_i2c' app, that lets us 
control the I2C master using shell commands (init/read/write incl 
parameters). On the 'test peer' we run a programmable soft i2c client, 
that offers shell commands expressing expectations, e.g. "expect 4 byter 
[abcd] written to addr 0x23".


Now for creating an automated I2C test-suite, I imagine something 
similar to our existing pyexpect scripts (testrunner), just with the 
added capability of handling two clients. So the test script could look 
something like this (mostly pseudocode...):


`PORT=/dev/ttyACM0 TESTPEER=/dev/ttyACM1 make hil-test`

triggers:

```python
...
def testfunc(testie, peer):
    ...
   # tell the 'test peer' to expect something to be written to addr 
0x23 and respond with a NACK

    peer.sendline("expect_addr 0x23")
   # write a random byte the addr 0x23
    testie.sendline("w 0x23 a")
    # the 'test peer' will tell if it sees the expected address
    peer.expect("[SUCCESS]")
    # the 'device-under-test' should recognize the NACK
    testie.expect("error: no device with that address found on bus")

    # test writing (expect 4 bytes [affe] written to address 0x42)
    peer.sendline("expect_write 0x42 a f f e")
    testie.sendline("w 0x42 a f f e")
    peer.expect("[SUCCESS]")
    testie.expect("I2C_DEV(0): successfully wrote 4 bytes to the bus\n")

   ...
    # many many more test cases here, including simulation of badly 
behaving slaves and bus recovery...

```

I have sketched a I2C slave implementation to run on the 'test peer' in 
[1] (under `tests/softi2ccli`). It is in no means production code, but a 
quick prove of concept. But IMHO this would be a very easy and straight 
forward way to have an automatic test-suite that would work on someones 
desk for now.


Integration into the bigger picture would hopefully be easy doable, but 
this not in the scope of this particular proposal here...
For now my goal would simply be to build a test suite for assisting with 
the upcoming I2C remodeling to get some hands-on experience and speed up 
the testing efforts for that task.


Cheers,
Hauke

[1] https://github.com/haukepetersen/RIOT/tree/add_softi2cli
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

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

[Hauke Petersen]

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 be definately worth a thought to consider adding the vendor 
libraries as packages. This way there would be no need for keeping all 
these files in the RIOT source tree directly, and code duplication would 
not be an issue. Further, it would be simple to update the libraries. 
Drawback here is, that we/someone would need to provide a public 
available repository containing these libraries - I guess TI is not 
doing this, right?


Cheers,
Hauke


On 28.10.2017 13:47, Cristiano Gavião wrote:

Hello Riot Devs,

As I have written before, I would like to use Riot in my 6lowPan 
project that is using CC1310 and CC1350 MCU.


No long ago, Texas Instruments have separated its common provided SDK 
into CC13XXWARE and CC26XXWARE. Currently there are many code that are 
still equals, but I did a file to file compare using Meld and found 
significant differences between some of them (9 files).


What I heard was that in the next MCUs versions (CC1312 and CC1352) 
more differences will come...


Besides that, those MCU have written in they ROM the most used SDK's 
driverlib binaries. So using the binaries instead flash them can give 
us more space for the applications.


So I would like to use headers and driverlib from CC13XXWARE in a best 
way that would fit in Riot and also facilitate maintenance when new 
updated come.


Would like to hear suggestion about what would be the best approach to 
work on this.


thanks for any comment,

Cristiano

___
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

[riot-devel] Release 2017.10

[Hauke Petersen]

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 supporting
over-the-air-updates by containing initial support for MCUBoot.
Furthermore, it adds support for some new platforms (e.g. arduino-mkzero,
nucleos, and frdm-k22f), drivers (e.g. my9221, apa102, ds1307), and of course
a large number of bug fixes (e.g. `make buildtest` now working properly,
various fixes to `xtimer`).

About 230 pull requests with about 442 commits have been merged since
the last release and about 13 issues have been solved. 45 people
contributed with code in 56 days. 1395 files have been touched with
211720 insertions and 65729 deletions.

You can download the RIOT release from Github by cloning the repository
[1] or by downloading the tarball [2], and look up the release notes for
further details [3].

Again, a big thank you to all the people who helped getting this release
on its way and who constantly work on making RIOT a better OS.

Keep on RIOTing and cheers,
Hauke

[1] https://github.com/RIOT-OS/RIOT/releases/tag/2017.10
[2] https://github.com/RIOT-OS/RIOT/archive/2017.10.tar.gz
[3] https://github.com/RIOT-OS/RIOT/blob/2017.10-branch/release-notes.txt

___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Release 2017.07 - RC2

[Hauke Petersen]

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 
towards RIOT 2017.10! [1]


As always, testing of RC2 is coordinated in the dedicated issue [2] and 
any help is much appreciated!


If everything goes well, the final release should be out by this Friday. 
So as a reminder: please take a look at the preliminary release notes 
[3] and add everything you see fit.


Cheers,
Hauke

[1] https://github.com/RIOT-OS/RIOT/releases/tag/2017.10-RC2
[2] https://github.com/RIOT-OS/Release-Specs/issues/49
[3] http://piratepad.net/49RLasqxGS
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] 2017.10 feature freeze

[Hauke Petersen]

Hi again,

one more clarification (thanks Martine for just pointing this out 
offline): Feature freeze does not mean that we don't merge any feature 
until the release. It just means, that anything merged from now on will 
not be backported into the release branch and hence will not be part 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 release date for 2017.10 is Okt 25th (next Wednesday).

As usual, we use an issue in the "RIOT-OS/Release-Specs" repository 
for tracking and synchronizing on the final release testing efforts 
[3]. Any help here is highly appreciated! If unclear, please feel free 
to contact me (or the mailing list or post in the issue directly).


Also, I created the template for the release notes [4]. Same here: 
please feel free to fill the list.


Happy testing and thanks for all the work that has already been put 
into this release!


Cheers,
Hauke

[1] https://github.com/RIOT-OS/RIOT/releases/tag/2018.01-devel
[2] https://github.com/RIOT-OS/RIOT/releases/tag/2017.10-RC1
[3] https://github.com/RIOT-OS/Release-Specs/issues/47
[4] http://piratepad.net/49RLasqxGS

___
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

[riot-devel] 2017.10 feature freeze

[Hauke Petersen]

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 use an issue in the "RIOT-OS/Release-Specs" repository for 
tracking and synchronizing on the final release testing efforts [3]. Any 
help here is highly appreciated! If unclear, please feel free to contact 
me (or the mailing list or post in the issue directly).


Also, I created the template for the release notes [4]. Same here: 
please feel free to fill the list.


Happy testing and thanks for all the work that has already been put into 
this release!


Cheers,
Hauke

[1] https://github.com/RIOT-OS/RIOT/releases/tag/2018.01-devel
[2] https://github.com/RIOT-OS/RIOT/releases/tag/2017.10-RC1
[3] https://github.com/RIOT-OS/Release-Specs/issues/47
[4] http://piratepad.net/49RLasqxGS

___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Graphing build sizes

[Hauke Petersen]

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 over all platforms.

Yes! The data should already be there (in the parsed sizes.json). Maybe
an "all" selector for both application and board would do it?


I also have an idea for code size diff visualization, that I have in my
mind for quite a while: how about we draw a (huge) table, using all
available platforms as columns and all available applications as rows.
Each cell would then be colored: [...]

What do you think about this idea, and how would you assess the doability?

Well, that table would be *huge* (~100 * 150 cells). We could make a
bitmap with mouse-over.
This is what I head in mind, talking about something like 5x5 pixes per 
cell (or similar) - the term table was more coined as a HTML table would 
be the natural construct to build this...


Cheers,
Hauke




Kaspar


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Graphing build sizes

[Hauke Petersen]

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 visualization, that I have in my 
mind for quite a while: how about we draw a (huge) table, using all 
available platforms as columns and all available applications as rows. 
Each cell would then be colored: different green saturation for code 
size decreases and different red saturation for code size increases, 
while something neutral for no change. Then we could draw this table 
once for ROM and once for RAM usage . This would allow us to see on 
first sight in which aspects a certain PR influences the overall code 
size and also if there are unexpected side effects in that regard.


What do you think about this idea, and how would you assess the doability?

Cheers,
Hauke

On 11.10.2017 16:59, Koen Zandberg wrote:

Hello,

One of the issues from the CI discussion at the RIOT summit was the
tracking and graphing of the nightly build sizes. After some
instructions from Kaspar for getting the JSON files I got something
working here:

https://riot-graphs.snt.utwente.nl/dashboard/db/demonstrator?orgId=1

For now I want to keep it up to date by running my script as a cron
every night approximately after the nightly build. The source code of
the script that parses and pushes the values to the database can be
found at my github [1].

The dashboard is now a simple Grafana templated dashboard where a test
and a board can be selected. I'd like to expand this by creating a
dashboard for every test or for every board. The most difficult thing
for now is to present the huge amount of data in a clear and concise
way. Input on this and the overview in general is most welcome.

Koen

[1]: https://github.com/bergzand/RIOT-graphs




___
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

[riot-devel] testmail

[Hauke Petersen]

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/listinfo/devel

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

[Hauke Petersen]

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 coding. Personally 
I use sublime-text for most editing...


[1] https://github.com/RIOT-OS/RIOT/pull/7451


On 06.08.2017 19:00, Kees Bakker wrote:

Hey,

Since commit 2811adc0 we get colorized gcc output.
Hmm. That's unfortunate for Emacs users (I'm probably one of
the very few).
Emacs parses the compiler output and now it cannot match the error
messages anymore.

Would it be possible to add some variable to disable the coloring? 
(There's

more than just this GCC diagnostics-color.) Something like DONOT_COLOR.
This would be in the same category as QUIET, I guess.

But really, I'm curious what people use to develop RIOT-OS. VIM?, 
Eclipse? Atom?

Emacs?


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] periph/rtt intent

[Hauke Petersen]

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 to exactly one API. So it was never intended for the periph 
interfaces to care of multiplexing between different hardware units of 
the same/simliar type, but this was always intended to be done by higher 
layer modules (as e.g. the xtimer, stdio, etc).


So the original reason for creating the RTT interface was actually 
historically driven by the stm32's and the sam3, where especially the 
stm32 have three different hardware units (timer, rtt, rtc), all with 
some different characteristics. So we decided back then, to create 
different periph APIs for each of these units.


Now from todays point of view (and we have learned a lot in the last 3 
years...), I think what is nagging is most conceptionally is that the 
periph API and the way its used does not allow us to concurrently map 
different devices into the same API (e.g. timer vs lptimer, uart vs. 
lpuart, rtt vs tim, etc). The only way this is currently possible is to 
use (very) ugly if-else constructs in the periph drivers imlementation, 
that switch between two (or more?) completely different code paths. This 
is not only ugly, hard to maintain, and imposes run-time penalties, but 
this also breaks with the original intention of the periph API to 
provide slim and direct access to a single selected type of peripheral.


So back to the RTT topic: considering what one would expect from the 
API, there is indeed no good reason for having a separation between 
periph/timer and periph/rtt. Both provide the same type of functionality 
and the periph/timer interface could simply also be implemented for rtt 
hardware units. But to do this cleanly, we would need to solve the 
(internal) multiplexing issue for using different typed peripherals 
under the same API. There was some prior work done by some people in the 
community (kaspar, johann, ...) to play around with function pointer 
based approaches which would solve this issue natively, but so far no 
solution yielded satisfying results and could compete in terms of 
efficiency.


So bottom line: functional the RTT interface does only make limited 
sense, but structurally given by the motivation of the periph interfaces 
there is a reason for having it. I guess the problem we need to solve is 
more about internally multiplexing peripheral types to the same API...


Cheers and thanks for bringing this up,
Hauke


On 13.07.2017 21:32, Joakim Nohlgård wrote:

Dear developers,
The intent of the RTT API seem to be rather unclear. My interpretation 
was that the RTT API is used for long time, low precision timers that 
can be used to sleep the system for minutes, hours or days. The 
precision is expected to be 1 second, the same as for the RTC API, but 
without the calendar struct representation. The reason for using the 
RTT API is to let it represent the current wall clock time, for 
tagging collected data etc, while the xtimer (and periph timer) is 
used for delays and internal precision timing of events. The RTT alarm 
is used to schedule wake ups or events which should happen at a 
specific time of day, for example taking a measurement every day at 2:00.
There seem to be a different interpretation as well: the RTT API is 
used for any hardware timers which keep running in low power modes.
This split is seen in the board configurations, where some boards list 
the RTT as a 32768 Hz timer, others list it as a 1 Hz timer. This has 
already begun causing problems among the API users, see the lwmac 
implementation for example, which only works if the RTT is 32768 Hz.
My interpretation was initially based on a limitation in the RTT 
(called RTC in NXP documents) on Kinetis hardware which only allow 
integer seconds for the alarm, while a different hardware module can 
be used for 1/32768 second precision, but that timer wraps around 
after 2 seconds (2**16 ticks).
We need to clarify the documentation and align the implementations to 
match each other, or the RTT API will be useless as an abstraction 
layer, since its interpretation will be platform dependent.


What are your opinions on the RTT API, or the timer APIs in general?

Best regards,
Joakim Nohlgård
RIOT developer


___
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

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

[Hauke Petersen]

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 can be directly (say without overhead) controlled.
The actual pins used should still be configured by the board, but we can put
default pins in place and we don't need all this redundant pin wobble
clutter in a board's configuration.

I don't fully get this point. How would this header differ from the current
LED control?

See https://github.com/RIOT-OS/RIOT/pull/7352


Besides, I would still vote for keeping the LED macros, because they are so
simple that you can always rely on them

But they are problematic in some contexts:
- currently, they increase power consumption even if not used (LED pins 
are always initialized, independent of their use)
- some boards have pin usage clashes (e.g. LED pin also used for 
SPI/UART/I2C etc)


So making the LEDs optional in some way is IMHO needed in any case...


- even in case you have fucked
something completely up. Splitting them into a different header and maybe even
make them optional, however, is fine with me.

Actually, I think this is pretty much what we did with #7350 and #7352.

What do you think about this approach?

Cheers,
Hauke


Cheers,
Oleg


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Re-visiting the LED macros

[Hauke Petersen]

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 would 
be less redundant code and a simplified board configuration.


To recap the original motivation for the 'direct-control-LED-macros': 
the idea was to make the LED pins controllable with the least possible 
overhead (-> 1 instruction on most platforms), so they can be used for 
debugging and profiling without adding any/much overhead themselves.


Now as I see it, the situation today is the following: on most 
platforms, we have some sort of pretty nice debugging possibilities 
(e.g. gdb) so we don't really need the LEDs for debugging anymore? Or 
has anyone using the LED macros for time-critical debugging lately?


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 can be directly (say without 
overhead) controlled. The actual pins used should still be configured by 
the board, but we can put default pins in place and we don't need all 
this redundant pin wobble clutter in a board's configuration.


So the main question here is: is anyone o.k. with refactoring the LED 
code or their opinions against proceeding with this? As said, one 
proposed solution is in #7350 [2], but this can be further improved (as 
in not taking any ROM if no LEDs are actually used...).


Cheers,
Hauke

[1] https://github.com/RIOT-OS/RIOT/pull/7321
[2] https://github.com/RIOT-OS/RIOT/pull/7350
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

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

[Hauke Petersen]

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 functions. So using the 'raw' i2c_read/write functions, 
it is very easy to interact also with devices that use 16-bit data 
registers.


As further optimization step I was already thinking, of inlining the 
read/write_reg functions anyway, so it would we might as well add 
something like i2c_read_reg16/i2c_write_reg16. But for this step some 
further analysis on the impacts of code size and some more 
implementation experience on all the platforms is needed...


Cheers,
Hauke



On 18.06.2017 13:41, Neo wrote:

Hello to all RIOT developers,

I have seen that there are plans to create a new API for I2C.

I have just one hint about that API:

There are I2C devices out there with an 8-bit ADDRESSING model and 
also with a 16-bit addressing model.


BUT there are also I2C devices which have a 16-bit DATA register set 
(e.g. sensors from TI, for example LDC1614)


http://www.ti.com/product/ldc1614/description


For my opinion it would be nice to have an API which could also handle 
16-bit register transfers.


Regards,

Neo

___
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

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

[Hauke Petersen]

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 
driver will re-initialize the same peripheral, potentially with 
contradicting settings...


For your specific problem: if you only use one specific SPI and use pins 
configured to another SPI dev for other purposes, then the other SPI 
should not be configured, so you should use an application specific 
`periph_conf.h` file. This should fix your issues.


Cheers,
Hauke


On 29.04.2017 14:56, Neo wrote:

Dear RIOT developers,

I think it is not a good idea to initilialize the SPI interface 
automatically via the periph_init() function because it is not as 
static as mentioned.


In my application I have 2 SPI interfaces defined in the periph_conf.h 
file - but I wanted only to configure the second one of these interfaces.


I the older days everything went well, but when I pulled in the new 
sources I was wondering why now the spi_init() function was invoked 3 
times2 times automatically by the periph_init() function 
(initializing all defined interfaces) and one time by my own 
(initializing only the second interface).and it took some time to 
find out what was going wrong.


For my opinion interface initialization should be under control of the 
application which interface is set up.


Best regards,

Neo

___
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

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

[Hauke Petersen]

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 
is feasible to create a new group, we can always refactor later...


Cheers,
Hauke


On 04.03.2017 10:37, Neo wrote:

Hello RIOT developers,

actually there are 3 categories for device drivers in the RIOT source 
tree: network device drivers, sensor device drivers and memory device 
drivers.


How about adding for example an SPI-Uart? It doesn't belong to one of 
these 3 driver categories.


Should it stay stand-alone - especially in the auto_init section?

Best regards,

Neo

___
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

Re: [riot-devel] Images

[Hauke Petersen]

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 not support any camera module. So you would need 
to implement some device driver(s) for the module of choice. Also there 
is no USB support in RIOT (yet), so this would also need to be addressed 
when you want to use USB cameras.


However, on first sight it seems to me, that there are quite some simple 
i2C and SPI camera modules on the market, for which it should be easy to 
write/port a driver to RIOT.


Cheers,
Hauke



On 11.03.2017 11:34, Ilias Seitanidis wrote:

Hi,
I apologise  my question was really too abstract.  Could it be 
possible to use a riot device(more or less the most common devices are 
m3, m0) connected to a camera( a raspi cam,  or even a usb camera) 
 take a picture and forward the picture to a more powerful computer 
for further processing? For example there is a windows iot with 
raspberry face recognition project.  Of course I am not comparing rasp 
with an m3 or m0 device and thats the reason that the processing will 
take place in a more powerful machine,  but just taking a picture and 
forward  it.

Thank you in advance!
Best,
Ilias

On Mar 10, 2017 15:10, "Emmanuel Baccelli" > wrote:


Hi Ilias,
what do you mean by "image"?
what do you mean by "external module"?
If you gave a concrete example, it would help.
Best,
Emmanuel

On Fri, Mar 10, 2017 at 9:44 AM, Ilias Seitanidis
mailto:iliasseitani...@gmail.com>> wrote:

Dear all,
Is Riot capable of handling images taken by an external module
and transmitting them?  Of course this also depends on the
hardware but I would like to know thats possible at the os
level.  Thank you in advance!

Best,  Ilias

___
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




___
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

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

[Hauke Petersen]

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,

I would like to try out some sensors on the STM32F4Discovery platform. 
Has anyone used any sensors with this platform? Any recommendations?


/Adeel



___
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

Re: [riot-devel] SiLabs Gecko

[Hauke Petersen]

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 
) 
as per RIOT-OS licensing norms ?
In general yes, but it depends which license SiLabs has put on the code, 
so as long as it is compatible to LGPL you could use it. But if that is 
the most elegant solution is something of personal taste... :-)


Cheers,
Hauke




On 8 December 2016 at 14:58, Akshay Mishra > wrote:


Thanks Martine,
It is possible that there is no RF support (I thought so but was
not sure.). I can look at porting it if there can be pointers.

The example used was gnrc_networking on the latest git clone.

One confession, :-|, is that the EZR32WG is supported and I worked
on the basic examples only modifying the WG to LG which changes it
from Cortex-M4 to Cortex-M3.

*Akshay Mishra*

On 8 December 2016 at 14:31, Martine Lenders
mailto:m...@martine-lenders.eu>> wrote:

Hi Akshay,
I fear you have to be a bit more specific than that. What
application
are you using e.g., which network stack? Also, I might be
mistaking
but it seems like there is no RF support for the EZR32LG in master
yet. Maybe that is the problem?

Cheers,
Martine

2016-12-08 8:34 GMT+01:00 Akshay Mishra mailto:aks...@dspworks.in>>:
> Hello,
> I tried it on the SLWSTK6220a with the EZR32LG.
While I was able to
> get riot-os working on it, the ipv6 address does not get
assigned.
>
> How does the interface get enabled ? I did not enable any
tap on the host.
>
> Thanks,
> Akshay
>
>
> ___
> 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






___
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

Re: [riot-devel] SiLabs Gecko

[Hauke Petersen]

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 periph drivers + most of the 
arch code)


Next than you can implement the radio driver, as a rough guideline have 
a look at the (early) device driver implementation guideline [1].


Cheers,
Hauke

[1] 
https://github.com/RIOT-OS/RIOT/wiki/Guide:-Writing-a-device-driver-in-RIOT



On 08.12.2016 10:28, Akshay Mishra wrote:

Thanks Martine,
It is possible that there is no RF support (I thought so but was not 
sure.). I can look at porting it if there can be pointers.


The example used was gnrc_networking on the latest git clone.

One confession, :-|, is that the EZR32WG is supported and I worked on 
the basic examples only modifying the WG to LG which changes it from 
Cortex-M4 to Cortex-M3.


*Akshay Mishra*

On 8 December 2016 at 14:31, Martine Lenders > wrote:


Hi Akshay,
I fear you have to be a bit more specific than that. What application
are you using e.g., which network stack? Also, I might be mistaking
but it seems like there is no RF support for the EZR32LG in master
yet. Maybe that is the problem?

Cheers,
Martine

2016-12-08 8:34 GMT+01:00 Akshay Mishra mailto:aks...@dspworks.in>>:
> Hello,
> I tried it on the SLWSTK6220a with the EZR32LG. While I
was able to
> get riot-os working on it, the ipv6 address does not get assigned.
>
> How does the interface get enabled ? I did not enable any tap on
the host.
>
> Thanks,
> Akshay
>
>
> ___
> 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





___
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

Re: [riot-devel] bitfeilds

[Hauke Petersen]

Hi Neil,

On 27.10.2016 21:22, Neil Jones wrote:


Ok so they are not outright banned but not recommended unless you can 
prove there are not any code size penalties?


I would say yes. If the code size is the same, I would not mind using 
named bitfields.


I'm now very interested in testing this on MIPS and will be querying 
our compiler engineers if there is a difference. I wonder if the fact 
that volatile acts as a compiler memory barrier that the compiled code 
is larger?



Please share what you find out, I would be very interested in their view!

About the volatile: I think Jü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:

Hi,

2016-10-27 15:01 GMT+02:00 Oleg Hahm mailto:oliver.h...@inria.fr> <mailto:oliver.h...@inria.fr
<mailto:oliver.h...@inria.fr>>>:

Hi Martine!

On Thu, Oct 27, 2016 at 01:35:21PM +0200, Martine Lenders
wrote:
> >> As example I was able to save several 100 bytes of
ROM when
removing the
> >> named bitfield use from the samr21s peripheral drivers.
> >
> >
> I don't know about your specific code, but I was able to
show,
that a
> bitfield actually *saves* ROM [1].

In your example the variables were not volatile.


Right. That might be a factor ^^".

Cheers,
Martine


___
devel mailing list
devel@riot-os.org <mailto:devel@riot-os.org>
https://lists.riot-os.org/mailman/listinfo/devel
<https://lists.riot-os.org/mailman/listinfo/devel>


___
devel mailing list
devel@riot-os.org <mailto:devel@riot-os.org>
https://lists.riot-os.org/mailman/listinfo/devel
<https://lists.riot-os.org/mailman/listinfo/devel>



___
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

Re: [riot-devel] bitfeilds

[Hauke Petersen]

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 able to save several 100 bytes of ROM when
removing the
> >> named bitfield use from the samr21s peripheral drivers.
> >
> >
> I don't know about your specific code, but I was able to show,
that a
> bitfield actually *saves* ROM [1].

In your example the variables were not volatile.


Right. That might be a factor ^^".

Cheers,
Martine


___
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

Re: [riot-devel] bitfeilds

[Hauke Petersen]

Hi,

Marinte's example does not use `volatile` fields, this makes it in my 
experience even worse...


Anyhow, it still shows, that on Cortex based platforms, the manual 
approach is superior in terms of ROM usage (which fits with my 
experiences). So especially for register maps (which are completely tied 
not only to a platform but to a specific CPU) I see a negative effect 
from using named bitfields.


 @Neil: yes, I am suggesting (also backed by Martine's example) that 
compiler generated code for accessing the bitfeilds is less size 
efficient on Cortex-Mx based platforms. But please feel free to prove me 
wrong!


Cheers,
Hauke


On 27.10.2016 13:35, Martine Lenders wrote:

Hi,
because this discussion came up in one of my (higher level) PRs, too.

2016-10-27 12:33 GMT+02:00 Neil Jones <mailto:neil...@gmail.com>>:


are you suggesting the compiler 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 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 use those.

As example I was able to save several 100 bytes of ROM when
removing the named bitfield use from the samr21s peripheral
drivers.


I don't know about your specific code, but I was able to show, that a 
bitfield actually *saves* ROM [1].


Cheers,
Martine

[1] https://github.com/RIOT-OS/RIOT/pull/5866#issuecomment-249801576


___
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

Re: [riot-devel] bitfeilds

[Hauke Petersen]

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 use 
those.


As example I was able to save several 100 bytes of ROM when removing the 
named bitfield use from the samr21s peripheral drivers.


Cheers,
Hauke



On 26.10.2016 21:24, Kees Bakker wrote:

On 26-10-16 16:52, Neil Jones wrote:

Hi,

What is RIOT's position on using named bitfields for register
definitions ? I know they are frown upon as there are no endian
guarantees in the C standard, personally I don't use them, but the PIC32
device files supplied by Microchip do include bitfield structures for
most registers so could make life easier ? (thankfully there are #define
for most register fields too, if the answer is not to use them).


I can't speak for RIOT, but personally I don't have a problem with them
when they are used for register definitions.

And I know that SAMD21 uses them too in Atmel's CMSIS include files.

In many cases it makes the code much nicer. That doesn't mean the
SAMD21 already uses them a lot. For example, we currently have code
like

dev(bus)->CTRLA.reg |= SERCOM_SPI_CTRLA_SWRST;
while ((dev(bus)->CTRLA.reg & SERCOM_SPI_CTRLA_SWRST) ||
   (dev(bus)->SYNCBUSY.reg & SERCOM_SPI_SYNCBUSY_SWRST));
...
while (!(dev(bus)->INTFLAG.reg & SERCOM_SPI_INTFLAG_DRE)) {}
...
dev(bus)->CTRLA.reg &= ~(SERCOM_SPI_CTRLA_ENABLE);


which could use bitfields and be written like this

dev(bus)->CTRLA.bit.SWRST = 1;
while ((dev(bus)->CTRLA.bit.SWRST) ||
   (dev(bus)->SYNCBUSY.bit.SWRST)) {}
...
while (!(dev(bus)->INTFLAG.bit.DRE)) {}
...
dev(bus)->CTRLA.bit.ENABLE = 0;



___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

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

[Hauke Petersen]

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 of course not be reflected in the default linkerscript for 
the stm32f103rb... Here is a fix [1].


Cheers,
Hauke

[1] https://github.com/RIOT-OS/RIOT/pull/5989


On 24.10.2016 17:05, Carsten Bormann wrote:
On 24 October 2016 at 17:01:35, Olaf Bergmann (bergm...@tzi.org 
) wrote:

Is there a specific reason why the ISR vector table is placed at address
0x08005000 instead of 0x0800 as usual?


“As usual” = as in the other related cpu specs, say, stm32f103c8.ld 
or stm32f103rb.ld.

Has anyone ever actually tried the cb variant?
I don’t even understand how it could work; those vectors need to be at 
0x0800.


Grüße, Carsten



___
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

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

[Hauke Petersen]

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.com/RIOT-OS/RIOT/pull/4926


On 11.10.2016 21:29, Kees Bakker wrote:

Hi,

The SHT2x I2C device has a register with a 16 bits address. If I'm 
correct

we don't have a function in the I2C driver to do that. Right?

Assuming we need to extend the driver API, what would be a good name
for such a function?

All I can come up with is i2c_read_regs2:

/**
 * @brief   Read multiple bytes from a register at the I2C slave with 
the given

 *  address
 *
 * @param[in]  dev  I2C peripheral device
 * @param[in]  address  bus address of the target device
 * @param[in]  reg  the 16 bits register address on the 
targeted I2C device

 * @param[out] data array holding the received bytes
 * @param[in]  length   the number of bytes to read into `data`
 *
 * @return  the number of bytes that were read
 * @return  -1 on undefined device given
 */
int i2c_read_regs2(i2c_t dev, uint8_t address, uint16_t reg,
  char *data, int length);



___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] RIOT Release 2016.04

[Hauke Petersen]

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 now available, P2P-RPL in the GNRC
network stack, Ethernet-over-Serial (ethos). Murdock, the new, blazing fast
RIOT CI is now available to significantly speed up code merging procedures.

This release also adds support for a number of new boards and sensors 
and a new
tool for automated border router setup is now provided which greatly 
simplifies

that setup for newbies as well as for old-timers. Last but not least: this
release includes a number of bug fixes, mostly about stabilizing and 
enhancing

the networking capabilities of RIOT.

About 470 pull requests with about 1196 commits have been merged since 
the last
release and 127 additional issues have been solved. 55 people 
contributed code

in 124 days. 1521 files have been touched with ~91700 insertions and ~42200
deletions.

You can download the RIOT release from Github by cloning the repository 
[1] or by
downloading the tarball [2], and look up the release notes for further 
details [3].


Thanks everyone for your contributions, discussions, testing efforts, 
and keep RIOTing!


Cheers,
Hauke

[1] https://github.com/RIOT-OS/RIOT/releases/tag/2016.04
[2] https://github.com/RIOT-OS/RIOT/archive/2016.04.tar.gz
[3] https://github.com/RIOT-OS/RIOT/blob/master/release-notes.txt
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] 2016.04-RC3

[Hauke Petersen]

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/RIOT/pull/5385
[2] https://github.com/RIOT-OS/RIOT/releases/tag/2016.04-RC3
[3] https://github.com/RIOT-OS/Release-Specs/issues/20
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] 2016.04-RC2

[Hauke Petersen]

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 release 
specs [2].


If you have not already done so, please check also the release note 
draft [3] and fill in any gaps that you see.


Thanks everyone for the great effort so far and let's get this release out!

Cheers,
Hauke

[1] https://github.com/RIOT-OS/RIOT/releases/tag/2016.04-RC2
[2] https://github.com/RIOT-OS/Release-Specs/issues/19
[3] http://www.yourpart.eu/p/oCGClz07sh



___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Towards RC2

[Hauke Petersen]

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 merged by then. Based on this RC I challenge everyone to participate 
in running the complete release specs again, plus testing the RC on your 
own setups and scenarios.


Target for the final release is then Friday afternoon!

Keep on testing,
Hauke

[1] https://github.com/RIOT-OS/Release-Specs/issues/18
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] 2016.04-RC1

[Hauke Petersen]

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 pressing 
tasks are:

- running all the tests as specified in the release-spec repository [2]
- run your favorite setups and make sure they (still) work
- review, test, and merge the open fix PRs [3] (27 to go)
- fix the open issues (or at least the critical ones) [4] (31 to go)

Out of these issues, the NDP bug [5] showing in conjunction with the 
newly merged, ethos based border router [6] seems to be the most 
critical one! IMHO here we need at least some king of work-around for 
the release, as nodes that can be addressed for more than ~15min should 
not be something optional...


So keep it up everyone!
Hauke

[1] https://github.com/RIOT-OS/RIOT/releases/tag/2016.04-RC1
[2] https://github.com/RIOT-OS/Release-Specs/issues/18
[3] 
https://github.com/RIOT-OS/RIOT/pulls?q=is%3Aopen+is%3Apr+milestone%3A%22Release+2016.04%22
[4] 
https://github.com/RIOT-OS/RIOT/issues?page=1&q=is%3Aopen+is%3Aissue+milestone%3A%22Release+2016.04%22

[5] https://github.com/RIOT-OS/RIOT/issues/5122
[6] https://github.com/RIOT-OS/RIOT/pull/4725

___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RIOT-ESP8622

[Hauke Petersen]

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 core. I have only found part of the information needed (ISA, stack 
handling, peripheral register descriptions) that is needed to port RIOT, 
but I have not looked very good for it...


Cheers,
Hauke


On 31.03.2016 13:19, Roger wrote:

Hi,

I'm wondering if RIOT can be used in combination with the ESP8622.

Thank you for considering my request

Best regards

- Roger Zink -


___
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

[riot-devel] Feature Freeze

[Hauke Petersen]

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 feature freeze:

- we should put a lot of effort into testing to make the release as 
solid as possible

- this includes running the tests specified in the release specs [1]
- new features should not be merged until the release is out
- bug fixes should of course be merged...

For everyone opening PRs with new features during this time, please be 
patient, as code review will most likely be postponed during the time of 
feature freeze...


As of now, we still have 47 issues [2] to solve until release - so every 
help in testing, fixing, and testing again is highly appreciated! Also 
feel free to put anything you think might be of interest into the 
release notes [3].


Keep up the good work and let's make this release great! :-)

Cheers,
Hauke


[1] https://github.com/RIOT-OS/Release-Specs
[2] 
https://github.com/RIOT-OS/RIOT/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Release+2016.04%22

[3] http://www.yourpart.eu/p/oCGClz07sh
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Hack'n'ACK tonight

[Hauke Petersen]

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-os.org/mailman/listinfo/devel

[riot-devel] Upcoming Release

[Hauke Petersen]

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 everyone, to take some 
time and look through his/her own PRs and issues and bring them up to 
speed or let them re-marked for the next release.


So I encourage everyone again to focus on testing and reviewing for the 
next days, so we can merge as many open PRs as possible before the 
feature freeeze!


I have also created an empty release notes document [1]. Please feel 
free to edit/add to it!


Nice job everyone and keep it up!

Cheers,
Hauke

[1] http://www.yourpart.eu/p/oCGClz07sh
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

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

[Hauke Petersen]

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 & Regards,
Harsha


___
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

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

[Hauke Petersen]

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 have any network interfaces
as far as I see. Because of this there are no network drivers
implemented and ifconfig doesn't have anything to show. Do you use it
with any kind of extension board?

Hi Thomas,

  Thanks for answering.

I wanted to run the example using the mbed-lpc1768 ethernet device. It already 
has an integrated phy, so we just connected an rj-45 jack.

Do you have support for ethernet devices in your stack?

Regards,


___
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

Re: [riot-devel] PWM API change

[Hauke Petersen]

Hej,

I think my datasheet was from the TM4C123GH6PZ, I thought this is just 
the re-branded lm4f120xl...


While the base timer clock speed is not configurable, the timer does 
have a pre-scale register, right? Can't we use that to change the timers 
freq? If not, I would say just adapt the freq to the wanted value and 
basically ignore the resolution parameter. This should suffice when 
implementing the PWM interface...


Best,
Hauke


On 17.03.2016 18:02, Marc wrote:

Hey,

Thank you for taking the time to try to help me solve my problem :)

The thing is that on the ek-lm4f120xl board, it's a lm4f120... The DS 
you are referring to seems to be lm4f232 (or similar). I'm using the 
lm4f120h5qr-124014.pdf as a reference.
The main reason I can see this is that there is no PWM generator on my 
board. I guess it was broken so they simply "removed" it from the 
datasheet. There is only the timers that can be used in PWM mode: 
that's what I was describing previously. I could not find how to 
change their clock speed (and by reading the docs and all the examples 
I could find, it seems that's not only me).
You can easily configure a PWN by setting 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 is to map the values given via
the RIOT PWM interface to internal values that make the PWM behave as
expected. See section 20.4 how they configure a 25KHz PWM on top of a
20MHz CPU clock. The only thing that probably won't be as exact is the
resolution (number of steps), as this must be rounded for this
implementation. But just put a comment in the implementation about
this.

Or as an alternative: implement the PWM interface by using a GPT
timer, those can be adjusted to the desired clock speed...

Cheers,
Hauke

On 17.03.2016 12:59, Marc wrote:

Hi,

Maybe you're right... PWM on lm4f120 is done by configuring a timer 
for which there's no real prescaler and a match value that gives the 
duty cycle. The timer is 16bits, but can be extended to 20bits if 
needed. The timer is clocked by the system, so there's no way to fix 
a resolution and then pick a frequency (even within a given range): 
the resolution is the value loaded in the timer, and that 
corresponds to a frequency.
Getting a 50Hz PWM with a 16Mhz clock requires the loading of 
0x4E200 in the timer. As the API states that the PWM must preserve 
the resolution given in the _init(), I need to be able to pass this 
value.


Of course, I could tweak the implementation and do some scaling on 
the values asked by the user (ie. compute the timer value needed for 
the required freq and scale all input from other function to match 
the real resolution), but that would not be ok with "In this case 
the PWM driver will always keep the resolution and decrease the 
frequency if needed.". In my case, this 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? 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, and not in changing the API...

 'int' was actually not a very smart idea -> when moving an
application that uses PWM from a 32-bit platform to a 16-bit platform
it will break, without giving any hints to why. When using fixed
values for low-level APIs, you always now exactly what you can work
with, independent of the hardware you are using.

 Cheers,
 Hauke

On 07.03.2016 13:33, dkm_riotos wrote:


Hi!

I'm cleaning a local port for lm4f120 and making new PR. I see
that a recent commit changed/cleaned the PWM API. One of the
changes includes limiting the resolution to 16bits (it was an int
before, so 32bits in my case). Is there a motivation for limiting
the value to 16bits ? In my case, the underlying timer can't be
scaled but simply extended by a 8 bits . When I need some low
frequency (eg. something suitable for driving a servo), I need to
set the timer to something > 16bits.

I see at least 2 possible fixes :
- increase resolution to 32bits in the PWM API so that I can expose
the real resolution. Having an 'int' here was not really bad in my
opinion, as it was not forcing a size. Forcing 16bits param on a
32bits hw or 32bits param on a 16bits may cost more than simply
using 'int'...
- do some scaling on the resolution to be able to use the full
range of the pwm while limiting the resolution to 16bits

What should I do ?

Thanks,
Marc

_

Re: [riot-devel] PWM API change

[Hauke Petersen]

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 is to map the values given via the 
RIOT PWM interface to internal values that make the PWM behave as 
expected. See section 20.4 how they configure a 25KHz PWM on top of a 
20MHz CPU clock. The only thing that probably won't be as exact is the 
resolution (number of steps), as this must be rounded for this 
implementation. But just put a comment in the implementation about this.


Or as an alternative: implement the PWM interface by using a GPT timer, 
those can be adjusted to the desired clock speed...


Cheers,
Hauke

On 17.03.2016 12:59, Marc wrote:

Hi,

Maybe you're right... PWM on lm4f120 is done by configuring a timer 
for which there's no real prescaler and a match value that gives the 
duty cycle. The timer is 16bits, but can be extended to 20bits if 
needed. The timer is clocked by the system, so there's no way to fix a 
resolution and then pick a frequency (even within a given range): the 
resolution is the value loaded in the timer, and that corresponds to a 
frequency.
Getting a 50Hz PWM with a 16Mhz clock requires the loading of 0x4E200 
in the timer. As the API states that the PWM must preserve the 
resolution given in the _init(), I need to be able to pass this value.


Of course, I could tweak the implementation and do some scaling on the 
values asked by the user (ie. compute the timer value needed for the 
required freq and scale all input from other function to match the 
real resolution), but that would not be ok with "In this case the PWM 
driver will always keep the resolution and decrease the frequency if 
needed.". In my case, this 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? 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, and not in changing the API...

 'int' was actually not a very smart idea -> when moving an
application that uses PWM from a 32-bit platform to a 16-bit platform
it will break, without giving any hints to why. When using fixed
values for low-level APIs, you always now exactly what you can work
with, independent of the hardware you are using.

 Cheers,
 Hauke

On 07.03.2016 13:33, dkm_riotos wrote:


Hi!

I'm cleaning a local port for lm4f120 and making new PR. I see
that a recent commit changed/cleaned the PWM API. One of the
changes includes limiting the resolution to 16bits (it was an int
before, so 32bits in my case). Is there a motivation for limiting
the value to 16bits ? In my case, the underlying timer can't be
scaled but simply extended by a 8 bits . When I need some low
frequency (eg. something suitable for driving a servo), I need to
set the timer to something > 16bits.

I see at least 2 possible fixes :
- increase resolution to 32bits in the PWM API so that I can expose
the real resolution. Having an 'int' here was not really bad in my
opinion, as it was not forcing a size. Forcing 16bits param on a
32bits hw or 32bits param on a 16bits may cost more than simply
using 'int'...
- do some scaling on the resolution to be able to use the full
range of the pwm while limiting the resolution to 16bits

What should I do ?

Thanks,
Marc

___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel [1]




Links:
--
[1] https://lists.riot-os.org/mailman/listinfo/devel

___
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


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] PWM API change

[Hauke Petersen]

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, and not in changing the API...


'int' was actually not a very smart idea -> when moving an application 
that uses PWM from a 32-bit platform to a 16-bit platform it will break, 
without giving any hints to why. When using fixed values for low-level 
APIs, you always now exactly what you can work with, independent of the 
hardware you are using.


Cheers,
Hauke


On 07.03.2016 13:33, dkm_riotos wrote:

Hi!

I'm cleaning a local port for lm4f120 and making new PR. I see
that a recent commit changed/cleaned the PWM API. One of the
changes includes limiting the resolution to 16bits (it was an int
before, so 32bits in my case). Is there a motivation for limiting
the value to 16bits ? In my case, the underlying timer can't be
scaled but simply extended by a 8 bits . When I need some low
frequency (eg. something suitable for driving a servo), I need to
set the timer to something > 16bits.

I see at least 2 possible fixes :
  - increase resolution to 32bits in the PWM API so that I can expose the real 
resolution. Having an 'int' here was not really bad in my opinion, as it was 
not forcing a size. Forcing 16bits param on a 32bits hw or 32bits param on a 
16bits  may cost more than simply using 'int'...
  - do some scaling on the resolution to be able to use the full range of the 
pwm while limiting the resolution to 16bits

What should I do ?

Thanks,
Marc


___
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

Re: [riot-devel] Biweekly virtual meeting

[Hauke Petersen]

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, Francisco Javier Acosta Padilla wrote:

Hi!

OK, a PlaceCam session should available for the meeting.

Cheers!

Paco.


On 9 March 2016 at 12:35:52, Martine Lenders (authmille...@gmail.com 
<mailto:authmille...@gmail.com>) wrote:



Hi,
I'm not sure I'll make it in time, since I have an appointment at 1pm,
but I'll join as soon as I'm home.

Cheers,
Martine

2016-03-07 16:17 GMT+01:00 Francisco Javier Acosta Padilla
:
> Hi RIOTers!
>
> As we agreed in a local meeting at FU I was proposed as “the biweekly
> virtual guy” in order to retake this habit of biweekly virtual 
meetings.

>
> Therefore, I have proposed an agenda for the next meeting that is 
accessible

> here: http://www.yourpart.eu/p/riot-2016-03-09-virtual-meeting
>
> Feel free to add the subjects of your interest.
>
> Sincerely yours,
>
> Paco.
>
>
>
> ___
> 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



___
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


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Biweekly virtual meeting

[Hauke Petersen]

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!

Paco.


On 9 March 2016 at 12:35:52, Martine Lenders (authmille...@gmail.com 
) wrote:



Hi,
I'm not sure I'll make it in time, since I have an appointment at 1pm,
but I'll join as soon as I'm home.

Cheers,
Martine

2016-03-07 16:17 GMT+01:00 Francisco Javier Acosta Padilla
:
> Hi RIOTers!
>
> As we agreed in a local meeting at FU I was proposed as “the biweekly
> virtual guy” in order to retake this habit of biweekly virtual 
meetings.

>
> Therefore, I have proposed an agenda for the next meeting that is 
accessible

> here: http://www.yourpart.eu/p/riot-2016-03-09-virtual-meeting
>
> Feel free to add the subjects of your interest.
>
> Sincerely yours,
>
> Paco.
>
>
>
> ___
> 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



___
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

Re: [riot-devel] Port to STM32F7

[Hauke Petersen]

Hej,

any contributions are welcome! Doing the acutal port should not take too 
long, as the code should be largely similar to the stm32f4 
implementation. When you look at my branch, you probably notices that I 
basically only copied the f4... So it is basically a matter of adapting 
the code, step by step to the F7. I don't think this should take more 
than a week, considering never having used RIOT.


let me know where you need help!

Cheers,
Hauke


On 04.03.2016 09:58, Antoine Faure wrote:

Hi,

I would be interested in contributing to the port, but it will not be 
entirely up to me as this would be part of a project at work, and we 
are going to decide very soon which board to use. How long do you 
think it would take to do such a port, considering I have never used 
RIOT before ?


@Nick : Good to know !

Cheers,
Antoine.


On 03/04/2016 08:52 AM, Emmanuel Baccelli 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 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

On 03.03.2016 18:31, Emmanuel Baccelli wrote:


Hi Antoine,

As far as I know, no one has started porting to this board, or
to any other Cortex M7-based board yet.

However, it would be great to have support for this Discovery
board (and initial M7 support).

Are you interested/willing to start porting?

The community usually turns out to be supportive of that type of
efforts in various ways via exchanges on GitHub or discussions
on this list or private exchanges spun out from such discussions.

Cheers

Emmanuel

On Mar 3, 2016 17:52, "Antoine Faure"
mailto:antoine.faure.1...@gmail.com>> wrote:

Hi everyone,

I am interested in using RTOS with an STM32F746NG Discovery
(a board with an ARM Cortex M7), but it doesn't seem to be
supported yet. Does anyone know if someone started working
on this ?

Here is a link to the board I'm talking about :

http://www.st.com/web/en/catalog/tools/FM116/SC959/SS1532/LN1848/PF261641?sc=stm32f7-discovery

Thanks,
Antoine.
___
devel mailing list
devel@riot-os.org <mailto:devel@riot-os.org>
https://lists.riot-os.org/mailman/listinfo/devel



___
devel mailing list
devel@riot-os.org <mailto:devel@riot-os.org>
https://lists.riot-os.org/mailman/listinfo/devel



___
devel mailing list
devel@riot-os.org <mailto: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




___
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

Re: [riot-devel] Port to STM32F7

[Hauke Petersen]

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

On 03.03.2016 18:31, Emmanuel Baccelli wrote:


Hi Antoine,

As far as I know, no one has started porting to this board, or to any 
other Cortex M7-based board yet.


However, it would be great to have support for this Discovery board 
(and initial M7 support).


Are you interested/willing to start porting?

The community usually turns out to be supportive of that type of 
efforts in various ways via exchanges on GitHub or discussions on this 
list or private exchanges spun out from such discussions.


Cheers

Emmanuel

On Mar 3, 2016 17:52, "Antoine Faure" > wrote:


Hi everyone,

I am interested in using RTOS with an STM32F746NG Discovery (a
board with an ARM Cortex M7), but it doesn't seem to be supported
yet. Does anyone know if someone started working on this ?

Here is a link to the board I'm talking about :

http://www.st.com/web/en/catalog/tools/FM116/SC959/SS1532/LN1848/PF261641?sc=stm32f7-discovery

Thanks,
Antoine.
___
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


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Implementing rng

[Hauke Petersen]

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.2016 17:14, Tausig Mathias wrote:

Hy!

I would like to use the hardware RNG from my samr1-xpro board. It should be 
available by reading out a certain register, according to the AT86RF233 
documentation.
My problem is, that I don't how to do that (I am pretty new to this stuff). Is 
there some documentation available for this kind of task, or could you point me 
in the right
direction?

cheers
Mathias


___
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

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

[Hauke Petersen]

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-USB converters under Linux...


To your second question: the `lpc_arch.c` is exactly the place to 
implement switchting to low-power modes.


Cheers,
Hauke


On 11.02.2016 23:24, Bernhard Nägele wrote:
Hello, I am trying to port RIOT-OS to the STM32L053 MCU and I get 
stuck at the moment.
The base system seems to work - every time I stop the system with the 
emulation probe I
can see that the system is in the idle-thread and I can single-step 
until I reach the next idle-thread.
The misterious thing is that the main task is never executed. No 
"Hello World" on the serial
interface. One character is seen by a terminal software after each 
restart, but not more.
Have you any idea what could going wrong at that step. The UART is 
set-up correctly, because

I got the dummy handler message before I worked at the vectors.c file.

Question 2: I want to use the Low Power Timer of the STM32L053 during 
the idle thread (stop-mode).
Can you give me a hint, where to place the change-over from the normal 
clock to the LPTimer?

lpm_arch.c ?

Best regards,
Bernhard
___
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

Re: [riot-devel] USB BLE HCI protocol

[Hauke Petersen]

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.nordicsemi.com

On 08.02.2016 11:03, PHANINDRA SURA wrote:

Hello,

I would like to work on the above issue, related to Bluetooth low 
Energy,a topic of my interest.
Please tell me the pre-requisites to be learnt for contributing to 
this task.
Where can I find relevant material to build my knowledge on these 
protocols.


Thanks

Regards,
Phanindra


___
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

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

[Hauke Petersen]

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 the above issue, related to *B*luetooth low 
Energy, a topic of my interest.
Please tell me the pre-requisites to be learnt for contributing to 
this task.


Thanks

Regards,
Phanindra


___
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

Re: [riot-devel] Contribute to RIOT OS

[Hauke Petersen]

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 for GSOC2016 again, so stay 
tuned for our proposed topics, or propose your own!


Cheers,
Hauke

[1] https://github.com/RIOT-OS/RIOT/wiki/Contributing-to-RIOT
[2] https://github.com/RIOT-OS/RIOT/issues

On 06.02.2016 07:15, Parthiv Parikh wrote:

Sir,

 This is Parthiv Parikh from Dwarkadas J Sanghvi College of 
Engineering, India.


I'm interested in contributing for RIOT OS. How should I proceed?
I have seen RIOT OS's projects in Google Summer of Code 2015, and I 
found some of them to be really interesting. (BLE project). I am 
personally interested in contributing towards embedded projects.
I was wondering if there similar projects in Google Summer of Code 
2016 which I could contribute to.


Thank you.


___
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

Re: [riot-devel] Event Driven Button

[Hauke Petersen]

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,

I notice that button function has been added to the latest version of 
RIOT.   Basically, it gives 0 on pressing and 1 on releasing. Is there 
an event driven implementation for this button such onClick() or 
onPress()?


Thanks,

Sugang

--

*/WINLAB, Department of Electrical and Computer Engineering/*
*/Rutgers,the State University of New Jersey
/*


___
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

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

[Hauke Petersen]

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 01.02.2016 12:56, Bernhard Nägele wrote:

Hello,
I want to port the RIOT-OS to the STM32L0 microcontroller series for 
using the 6LoWPAN protocol.
Do you think that 8MHz core clock is sufficient for utilizing the 
6LoWPAN stack of RIOT-OS?


Best regards,
Bernhard
___
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

Re: [riot-devel] Atmel R21

[Hauke Petersen]

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 ping the serial interface(I used the 
first one).
My problem now is that I cannot ping the other(wireless 
interface[interface 5]).



2016-02-02 10:25 GMT+01:00 Francisco Javier Acosta Padilla 
mailto:francisco.aco...@inria.fr>>:


Hi Ilias!

There are work in progress on the BR right now.

You can look at [1] in order to get a version of a BR using only one
serial connection.

Otherwise you can try the "classical" way which is to use another
serial
interface on the R21 and a SLIP connection. You can find more details
here [2].

Best,

Francisco.

[1] https://github.com/RIOT-OS/RIOT/pull/4725
[2]
https://github.com/RIOT-OS/RIOT/tree/master/examples/gnrc_border_router


On Tue, 2016-02-02 at 10:13 +0100, Ilias Seitanidis wrote:
> Dear all!
> After following all the tutorials on the net for Atmel R21 as BR
in Riot
> ,with serial connection , I cannot ping the Inteface 6 of the
BR, which is
> the interface from both linux and R21.Any suggestions?
> Thank you in advance!
> ___
> 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




___
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

[riot-devel] Hack'n'ACK tonight

[Hauke Petersen]

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

[Hauke Petersen]

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 you need to do is not use the `USEMODULE=netif_default` in 
your applications Makefile... Instead you then simply tell the make 
system to use your GPRS device (something like 
`USEMODULE=your_driver_name`) and add auto-initialization code for your 
device to sys/auto-init/netif/.


Cheers,
Hauke



On 25.01.2016 14:50, Ilias Seitanidis wrote:

Dear all,
I want to use the sam R21 Xpro with a GPRS plugin (Some friends from 
the electronics department will take care of the hardware 
connectivity). What  changes should I perform to the Riot code?

Thank you in advance!


___
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

Re: [riot-devel] drivers/SAUL

[Hauke Petersen]

Hej,

I see your point. Actually SAUL is (so far) not really intended for 
hot-plugging. But what you can easily do, is define the pin(s) you 
connect to your actuator at compile time and make them available via the 
SAUL registry. To do this in the simplest way, you can just edit the 
`boards/samr21-xpro/include/gpio_params.h` file and add the pins that 
you need control over, maybe like this (if your actuator is connected to 
pin PB02):


static const  saul_gpio_params_t saul_gpio_params[] =
{
{
.name = "LED(orange)",
.pin = LED_GPIO,
.dir = GPIO_DIR_OUT,
},
{
.name = "My Actuator",
.pin = GPIO_PIN(PB, 2),
.dir = GPIO_DIR_OUT
}
};

And thats it, now your actuator pin should be listed when using the 
`saul` shell command.


Cheers,
Hauke


On 20.01.2016 16:07, Ilias Seitanidis wrote:

Dear Hauke,
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:hauke.peter...@fu-berlin.de>>:


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 drivers as we speak, expect some PRs to this
topic end of this week...

Hope that gives you some direction, otherwise let us know if you
have more specific questions on SAUL!

Cheers,
Hauke



On 19.01.2016 15:01, Ilias Seitanidis wrote:

Dear all ,
I would like to ask you if there is any example of the drivers/saul .
Thank you in advance!


___
devel mailing list
devel@riot-os.org <mailto:devel@riot-os.org>
https://lists.riot-os.org/mailman/listinfo/devel



___
devel mailing list
devel@riot-os.org <mailto: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


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] drivers/SAUL

[Hauke Petersen]

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 drivers as we speak, expect some PRs to this topic end of this 
week...


Hope that gives you some direction, otherwise let us know if you have 
more specific questions on SAUL!


Cheers,
Hauke


On 19.01.2016 15:01, Ilias Seitanidis wrote:

Dear all ,
I would like to ask you if there is any example of the drivers/saul .
Thank you in advance!


___
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

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

[Hauke Petersen]

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 
previous mail...). Thanks!


Cheers,
Hauke


On 04.01.2016 01:46, Mateusz Kubaszek wrote:

Hi everyone!

A few days ago I ran a sniffer application using CC1101 transceiver. 
Sniffing device is connected via UART<->USB adapter to PC. A python 
sniffer application redirects the frames to Wireshark (v. 2.0.0).
Sniffer was gathering frames from one node programmed with 
gnrc-networking example application. This node was sending a frame in 
every 10 seconds. The problem is that Wireshark did not recognize any 
803.15.4 frames. Digging deeper into a 803.15.4 frame, controll part 
(first octet) look like:


bitsdescription
0-2 frame type (000 Beacon, 001 Data, 010 Ack, 011 MAC 
command, 100-111 Reserved)

3security
4frame pending
5AR
6PAN ID Compression
7-9Reserved
10-11Dest. Addressing Mode (00 PAN and addr. not present, 01 
Reserved, 10 Short address, 11 Ext. Address)
12-13Frame Version (00 IEEE802.15.4-2003 compatible, 01 
IEEE802.15.4 compatible)
14-15Source Addressing Mode (00 PAN and addr. not present, 01 
Reserved, 10 Short address, 11 Ext. Address)


The received data has wrong source address mode (picture in 
attachment). Why is there no compatibility with IEEE802.15.4 standard?
Is there anyone with knowledge concerning sniffing radio packets in 
RIOT powered mesh using Wireshark? Is there a possibility to recognize 
802.15.4 packet types using standard Wireshark dissector?


Best regards,
Kubaszek Mateusz


___
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

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

[Hauke Petersen]

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 most pressing item
for me currently is RF support, but I would also like to see support
for the ROM API and a few other things (including the sensors on the
OpenBattery board, eventually).

I'm new to RIOT and thought I'd try to clear up a few things before
getting my hands dirty, so you'll have to excuse me if some of these
questions seem obvious/stupid/irrelevant:

1) TI provide open-source firmware for the cc2538, but I can't find
any trace of it in the RIOT tree. It seems like there are a few
cherry-picked bits and pieces but not in the same format/layout as the
original firmware. Is there a reason for not including TI's firmware
in the tree verbatim (I'm thinking licensing/re-distribution issues,
architectural or coding-style differences, etc)? It seems like this
would make fully supporting the MCU a lot easier.
You can't find it because we are not using it... The main reason for 
this is manifold: TI's firmware is bloated, in-efficient and I am not 
sure about the licensing (though this might not be an issue). Personally 
I also doubt, that it makes porting so much easier - in the end you have 
to read the ref manual in any case to understand the MCU, so why not 
program the registers directly without overhead through some vendor 
library...


2) To avoid duplication of effort, is there anyone else already
working on RF support for this chip?
Not sure, did you search the mailing list archive? There might have been 
something on this in the past...


3) Where should a hypothetical RF driver for the cc2538 live in the
tree? Since it's on-chip should it live in the cpu subdir? Or
programmed as a "module" the same way as for peripherals?
If I see it right, the radio is register mapped on this SoC, right? In 
that case the radio driver should reside in the cpu subdir.


4) Are there any guidelines or example code for this kind of work? The
only other on-chip RF driver I could find to use as a reference is for
the nrf51. Perhaps this will do to get me on the right track, but just
thought I'd check if there's something I missed.
Not yet. You saw it right, that the NRF51 is the only SoC with register 
mapped radio at the moment in RIOT. But you should not 100% trust that 
implementation, as it is not quite up to the current 'state-of-the-art' 
in RIOT, ergo it does not implement the netdev2 interface.


Let us know if you need more information!

Cheers,
Hauke



Thanks!
/Aaron
___
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

Re: [riot-devel] cpuid for atmega2560

[Hauke Petersen]

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


Cheers,
Hauke


On 10.12.2015 05:18, Nguyễn Quốc Đính wrote:

Hello RIOT developers,

I am new to the group, then please forgive me for the innocence.

I am doing the cpuid for atmega2560, to finish some part of 
https://github.com/RIOT-OS/RIOT/issues/1511.
Some cpus have unique id/or usb id, some don't. Atmega2560 belongs to 
the later (please correct me if I am wrong).


Then what is your suggestion to provide the device an ID? I am 
thinking about write to its eeprom a 16Bytes number. Any though on this?


Thank for making this great project.

Dinh.


___
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

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

[Hauke Petersen]

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 specific to 
RIOT OS, and how they have evolved. More precisely, I have questions 
to ask:


1] Is RIOT OS kernel still *tickless*?

YES
The now gone 'hwtimer' that was in RIOT kernel only fired when an 
time-related event was actually happening---meaning there was no 
'useless' wake-up (i.e.: simply related to the underlying timer 
frequency) where MCU was activated only to find that there was nothing 
to do and get back to low-power mode. That's why RIOT OS kernel could 
be qualified as tickless (no regular and potentially useless 
interrupt/wake-up).
I see that xtimer, according to its documentation (Doxygen comments) 
is based on an unique hardware timer supposed to have a fixed 1 MHz 
frequency.
Does it mean that there will be an interrupt every microsecond when 
'xtimer' is used, or will we still have only an interrupt when a 
time-related event actually happens (which means RIOT still qualifies 
as a tickless OS) ?
The answer has two aspects: the system does not wake up on a certain 
type of system tick, so no wakeup every ms or so. But to be able to work 
for (very) long spans of time, the xtimer is currently programmed in a 
way, so that it wakes up every time the underlying peripheral timer 
overflows. For 32-bit periph timers, this is every ~1h 20m, for 16-bit 
timers this is every ~65ms. But this behavior is only 'temporary', is it 
is planned for the future to make use of peripheral RTT (real-time 
timers) or RTC (real time clocks) for the long term ticks, so that this 
periodic wakeup can be omitted.


2] Unless I'm mistaken, the 'hwtimer' feature that allowed to use as 
much 'hwtimer' instances (as the underlying hardware timers could 
offer counters/comparators is now gone, 'xtimer' being based on an 
unique (high-resolution) hardware timer onto which every 'xtimer' 
instance is multiplexed.
Can someone confirm me that the previous statement---based on what I 
understand---is correct?
yes, this is correct: the xtimer multiplexes all active timers on a 
single peripheral timer channel, so in practice using exactly one 
capture-compare channel on a single periph timer instance.


This significantly lowers the complexity of the timer infrastructure 
(one level less of multiplexing) and leads to more deterministic 
behavior in terms that you can't run into the situation of 'no hardware 
timer channel left'.



3] 'xtimer' is said to be based on a 1-MHz hardware timer, but does it 
mean we *really* have a granularity/jitter of the order of the 
microsecond?
Dianel Krebs warned me (during the discussion on PR #4178) that 
xtimer_usleep() was dependent on the scheduler and the delay for its 
next context switch, and that consequently, the delay passed as a 
parameter could suffer for an undetermined and potentially *big* jitter.
Is this problem specific to the sleep-related functions and their 
implementation, or does the whole 'xtimer' mechanism suffer from the 
same problem (i.e.: the xtimer_set[*,_msg,_wakeup]() functions)?
In that case, what kind of jitter can we expect relative to the delays 
we pass as parameters to the xtimer functions? If this jitter is too 
high or too hard to predict, the status of RIOT OS as a real-time OS 
could be put in jeopardy?
Since be able to have fine-grained real-time features is necessary to 
my work, can someone reassure me about the 'xtimer' module and its 
abilities?
Again, the answer is two fold: I am actually not sure about the jitters 
you can expect - @kaspar: can you add some details here? But AFAIK no 
*big* jitter would be expected, as the timer uses a backoff mechanism, 
to prevent task switches (scheduler runs) for small wait intervals and 
falls back to active blocking in these cases.


I don't see the status of RIOT as real-time OS in jeopardy in any case: 
it is true that you can construct/configure RIOT in a way, that it is 
not real-time capable (very stupid ISR implementations, badly configured 
priorities, etc). But you can always build it in a way, that it will 
comply to any real-time requirements.


If you need very precise and fine grained timing abilities, you have 
always the possibility to use a second peripheral timer directly 
(instead of the xtimer). This allows you (i) to run with other timer 
speed than 1MHz and to trigger your sensible events directly from the 
timer callback, withtout any xtimer overheads...


Thanks in advance to enlighten me: my job during this year didn't 
allow me to follow correctly the evolution of RIOT's timer mechanisms, 
and I quite need some technical details about the new low-level 
timers' inner workings.
Let us know, where you need more details, and we will be happy to help 
(and hopefully also try to enhance ou

Re: [riot-devel] Arduino API merged

[Hauke Petersen]

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


___
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

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

[Hauke Petersen]

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 » 




  Hack'n'ACK

/When/
Tue Nov 24, 2015 5pm – 10pm Berlin
/Where/
	c-base Berlin; HAW Hamburg(map 
)

/Calendar/
RIOT Events
/Who/

•   
Martine Lenders - creator

Invitation from Google Calendar 

You are receiving this email at the account peterschme...@gmail.com 
because you are subscribed for notifications on calendar RIOT Events.


To stop receiving these emails, please log in to 
https://www.google.com/calendar/ and change your notification settings 
for this calendar.


Forwarding this invitation could allow any recipient to modify your 
RSVP response. Learn More 
.




___
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

Re: [riot-devel] Is RIOT right?

[Hauke Petersen]

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 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 application and we got impressed with RIOT. 
It sports some really nice features and it looks like there is a 
great community over here.
On the paper RIOT seems to be perfect for our application, but we 
need to go deeper before we start investing our resources into this 
project. We have some questions that are not easy to answer just by 
looking at the documentation, so your experience is much appreciated.


Let me first introduce our platform.
As in many WSN we have multiple wireless nodes and one (or more) 
router / coordinator / gateway.


++ Nodes ++
Nodes are based on Atmel SAM R21 that, as you know, is basically an 
Atmel SAM D21 plus an Atmel RF233 in the same package. We already 
designed the modules and they work well with Atmel code examples.

We want to use the following stack:
RF233 <-> 6LowPAN <-> TCP <-> MQTT client <-> Application

++ Router / coordinator / gateway ++
Another device acts as PAN coordinator and as router/gateway to the 
local LAN.
This device is based on a Olimex A13-SOM-512 
(https://www.olimex.com/Products/SOM/A13/A13-SOM-512/) running Linux 
with a wired Ethernet interface and the same SAM R21 radio module 
(with a different firmware). The two boards are connected trough a 
serial connection (USART).

Here the communication stack is a little more complex:

[Olimex A13] Application <-> MQTT broker <-> (???) <-> Kernel Serial 
driver <-> USART

  |
[serial from A13 to SAMR21]
  |
[SAMR21] USART <-> (???) <-> 6LowPAN <-> RF233

As you can see, we are not sure about the stack composition, see 
"(???)". We would like to integrate the coordinator and routing 
functions in the A13 side (since we have more resources there) and 
basically just use the SAMR21 as a transceiver.



I hope I gave enough details to understand the platform. If not, I 
will be happy to answer your questions.

Now, our questions:

1) Architecture: is RIOT viable for this architecture?#

YES indeed! These kind of setups are exactly what RIOT is intended for!


Perfect! We are almost convinced. Today we cloned from the repository 
and started playing with the native example and we are even more 
impressed. It worked flawlessly out of the box. In the next days we 
will try to implement something on the SAM R21 platform.
Good to hear! Again, let us know (or even better: open issues on github) 
if you stumble upon faulty/unclear/non-RFC complient behavior.




2) Gateway: which stack layers do you advise to include for the 
"(???)" parts? Is it a good idea to include the coordinator on the 
A13 side? Or is better to put it into the SAMR21 side?
On first sight I would use SLIP here, which is already supported by 
RIOT. Only drawback is that SLIP does as far as I know not support 
any 802.15.4 link layer specific functionalities, so the PAN 
coordinator part would need to be handled by the SAMR21. Resource 
wise this is not problem at all (as the samr21 provides plenty of 
ressources in terms of memory and processing power to this). Only 
thing is some missing parts on the implementation side in RIOT, 
though I am not quite sure about the latest state on this.




If I understand well, are you suggesting the following?

  [Olimex A13] Application <-> MQTT broker <-> Linux TCP/IP stack <-> 
SLIP <-> Kernel Serial driver <-> USART

|
   [serial from A13 to SAMR21]
|
   [SAMR21] USART <-> SLIP <-> 6LowPAN+Coordinator <-> RF233

I'm not really familiar with SLIP, so I don't know if I got it right. 
At which level does SLIP operate? It will send IP packets over serial?

Yes. It is basically a link layer over UART.


SAMR21 is pretty capable, but with 32kB RAM would it be able to 
coordinate hundreds of nodes? Somebody ever tried with a large number 
of nodes? The original reasoning behind putting the coordinator on the 
A13 side was for managing a large number of notes.

You might have a point here, but I am probably the wrong person to ask.

@Cenk, @Oleg, @Martine: can you give some estimates if the above is 
doable on the SAM nodes?




@Martine, @Oleg: do you know the latest about this?


3) Robustness: please be honest, is RIOT robust and mature enough 
for a large scale use? Do you know of commercial products that 
integrates it?

A mean thing to ask developers about the maturity of their code :-)

No, seriously: IMHO RIOT is ready and mature enough for large scale 
use s

Re: [riot-devel] RIOT for Zigduino

[Hauke Petersen]

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 simple 
approach: copy the `arduino-mega2560` board and the `atmega2560` cpu and 
adapt them to the specifics of the new board. Start simple by just 
trying to get the UART to work and than add to it. Don't worry about 
duplicating code while you just want to get the board working somehow - 
I would suggest that you than PR your code once you have basic 
functionality working (e.g. UART, GPIO, timers) and we can work out 
together a concept of introducing some shared board/cpu folders for 
ATMega based platforms (as done in cpu/cortexm_common for coretx-m based 
platforms).


Just let us know where we can help!

Cheers,
Hauke


On 17.11.2015 09:42, Behailu S. Negash wrote:

Greetings,

I have been trying to port RIOT for Zigduino board for about a week 
(On and Off), but I am confused. Has anybody done porting for zigduio? 
or is there any specific steps I need to follow, besides the general 
guideline given in documentation?


Thank you

--
Behailu Shiferaw Negash
Turku, Finland


___
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

Re: [riot-devel] Is RIOT right?

[Hauke Petersen]

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 application and we got impressed with RIOT. 
It sports some really nice features and it looks like there is a great 
community over here.
On the paper RIOT seems to be perfect for our application, but we need 
to go deeper before we start investing our resources into this 
project. We have some questions that are not easy to answer just by 
looking at the documentation, so your experience is much appreciated.


Let me first introduce our platform.
As in many WSN we have multiple wireless nodes and one (or more) 
router / coordinator / gateway.


++ Nodes ++
Nodes are based on Atmel SAM R21 that, as you know, is basically an 
Atmel SAM D21 plus an Atmel RF233 in the same package. We already 
designed the modules and they work well with Atmel code examples.

We want to use the following stack:
RF233 <-> 6LowPAN <-> TCP <-> MQTT client <-> Application

++ Router / coordinator / gateway ++
Another device acts as PAN coordinator and as router/gateway to the 
local LAN.
This device is based on a Olimex A13-SOM-512 
(https://www.olimex.com/Products/SOM/A13/A13-SOM-512/) running Linux 
with a wired Ethernet interface and the same SAM R21 radio module 
(with a different firmware). The two boards are connected trough a 
serial connection (USART).

Here the communication stack is a little more complex:

[Olimex A13] Application <-> MQTT broker <-> (???) <-> Kernel Serial 
driver <-> USART

  |
[serial from A13 to SAMR21]
  |
[SAMR21] USART <-> (???) <-> 6LowPAN <-> RF233

As you can see, we are not sure about the stack composition, see 
"(???)". We would like to integrate the coordinator and routing 
functions in the A13 side (since we have more resources there) and 
basically just use the SAMR21 as a transceiver.



I hope I gave enough details to understand the platform. If not, I 
will be happy to answer your questions.

Now, our questions:

1) Architecture: is RIOT viable for this architecture?#

YES indeed! These kind of setups are exactly what RIOT is intended for!


2) Gateway: which stack layers do you advise to include for the 
"(???)" parts? Is it a good idea to include the coordinator on the A13 
side? Or is better to put it into the SAMR21 side?
On first sight I would use SLIP here, which is already supported by 
RIOT. Only drawback is that SLIP does as far as I know not support any 
802.15.4 link layer specific functionalities, so the PAN coordinator 
part would need to be handled by the SAMR21. Resource wise this is not 
problem at all (as the samr21 provides plenty of ressources in terms of 
memory and processing power to this). Only thing is some missing parts 
on the implementation side in RIOT, though I am not quite sure about the 
latest state on this.


@Martine, @Oleg: do you know the latest about this?


3) Robustness: please be honest, is RIOT robust and mature enough for 
a large scale use? Do you know of commercial products that integrates it?

A mean thing to ask developers about the maturity of their code :-)

No, seriously: IMHO RIOT is ready and mature enough for large scale use 
since the latest 2015.09 release. We have just recently tested some 
long-term setups using the samr21 nodes with raspberry pi + at86rf233 
based modules as boarder router that were running for weeks without any 
trouble. As young as RIOT is (and especially the GNRC network stack), I 
wouldn't expect it to bug free, but I with little effort one can build 
very reliable products with it.


4) License: RIOT is published with a LGPLv2 license and if we 
understand well, we can then use it in our product without any 
limitation. Is this right?
'Without limitations' might give the wrong impression. In general the 
situation is quite easy: if you change any of the existing code (e.g. 
you fix bugs), you have to make those changes available to the community 
(e.g. commit them into RIOT's master branch). But you are perfectly fine 
in linking RIOT together with your disclosed, proprietary application code.


5) TCP: we have seen that some TCP support has been temporarily 
removed and being refactored. What is the plan for reintroducing it? 
(MQTT is based on TCP)
There is current work going on to re-implement TCP, and last I heard is 
that it is already partly working, so I expect TCP support to be back in 
RIOT rather soonisch, though we can't give a hard time-frame on this. 
Further I can't really tell, which TCP features will be supported. But 
this process can probably speed up if more people decide to help...


6) MQTT: is there any plan to develop a MQTT client for RIOT? Is 
anybody already developing it?
In general: Yes. But the current effort is focussing on MQTT-SN (the 
MQTT variant that works over UDP). But using MQ

Re: [riot-devel] Task Forces

[Hauke Petersen]

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 the nasty 
task force?

yes


- would Martine & Hauke agree they are the shepherds of the 
documentation task force?

and yes

Cheers,
Hauke



- who would take on the shepherding for the OTA task force? If no-one 
speaks up, we could classify this TF as dormant the time being.




On Thu, Nov 19, 2015 at 4:04 PM, Oleg Hahm > wrote:


Hi!

Sounds like a sensible proposal to me.

Cheers,
Oleg

Am Thu, Nov 19, 2015 at 03:51:36PM +0100 schrieb Emmanuel Baccelli:
> +1 here too.
> I think it is also important to describe to malloc and free :)
> I mean how to:
>
> 1 - create a new task force (hopefully we have a lot more to come!)
> 2 - join/ping/revive an existing task force (e.g. OTA is
somewhat dormant)
> 3 - dissolve an existing task force
>
> For creating: how about, simply stating something like:
> "If you wish to launch a new task force, go ahead, create your
wikipage,
> and report your progress or summarize the latest stand of your
discussions
> on devel@riot-os.org "
> There's the slight possibility that duplicate work may happen
down the
> line, if a lot of task forces are active at the same time.
> But this is not dangerous right now. If we want to cover this
case, maybe
> we can add: "RIOT maintainers will contact you if duplicate or very
> closely-related work has been detected elsewhere, and if joining
forces
> might make sense."
>
> For ping/join/revive how about naming one or two shepherds per
task force,
> that could be pinged?
>
> For dissolving: how about "either (i) the shepherd(s) declares
the TF is
> done, or gives up, or (ii) the shepherds are unreachable, the TF
has been
> dormant for a long time and RIOT maintainers declare the TF
dissolved"
>
>
>
>
> On Thu, Nov 19, 2015 at 3:34 PM, Kaspar Schleiser
mailto:kas...@schleiser.de>>
> wrote:
>
> > Hey,
> > On 11/19/15 14:48, Oleg Hahm wrote:
> > > As an effort to "formalize" this idea of task forces a
little bit more,
> > I just
> > > created a small page in the Wiki:
> > >
> > > What do you think?
> >
> > +1
> >
> > I've updated the xtimer page.
> >
> > Kaspar
> > ___
> > 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


--
/* Thanks to Rob `CmdrTaco' Malda for not influencing this code in any
 * way.
 */
linux-2.4.3/net/core/netfilter.c

___
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


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Energy Consumption on samr21_xpro

[Hauke Petersen]

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 
STM32F4discovery was around ~15mA for the full board). Not sure where 
this high consumption comes from - but maybe you can measure your board 
and share your results with us?


Cheers,
Hauke


On 26.10.2015 10:59, Baptiste Clenet wrote:

@Illias, the current monitor header pins are the only way I know to
measure the current consumption. If you see a better way to do that,
It would be great to try it, let us know.

Baptiste

2015-10-23 11:37 GMT+02:00 Peter Kietzmann :

Hi Ilias,

I'd love to have such possibility, but from my knowledge there is no coulomb
counter (or similar) on that board or on any common hardware. If you find a
way, please let me know :-) !

Cheers,
Peter

Am 23.10.2015 um 11:31 schrieb Ilias Seitanidis:

Hi Peter,
First of all I want to thank you for your fast reply.I want to measure the
energy consumption from the board using software without external tools as
an ammeter.
Thank you.
Best ,
Ilias

2015-10-23 11:22 GMT+02:00 Peter Kietzmann :

Hi Ilias,

and welcome to RIOT! This board has a jumper on it's current monitor
header pins (next to the user programmable button). You can replace the
jumper by an ammeter and measure the current. Compare the boards user guide
http://www.atmel.com/Images/Atmel-42243-SAMR21-Xplained-Pro_User-Guide.pdf

Best,
Peter




Am 23.10.2015 um 11:07 schrieb Ilias Seitanidis:

Hi , I am new to wsn and I am wondering if there is a way to measure the
energy consumption of the atmel samr21_xpro .Thank you in advance!


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


--
Peter Kietzmann

Hamburg University of Applied Sciences
Dept. Informatik, Internet Technologies Group
Berliner Tor 7, 20099 Hamburg, Germany
Fon: +49-40-42875-8426
Web: http://www.haw-hamburg.de/inet


___
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


--
Peter Kietzmann

Hamburg University of Applied Sciences
Dept. Informatik, Internet Technologies Group
Berliner Tor 7, 20099 Hamburg, Germany
Fon: +49-40-42875-8426
Web: http://www.haw-hamburg.de/inet


___
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

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

[Hauke Petersen]

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 cc3200 has:

  * 256 Kb of RAM
  * an external SD serial flash card memory where to flash the image
  * an internal ROM memory burned into the chip that hosts the
bootloader and the driverlib "ROM version" (directly from factory)

So from version ES1.33 it seems possible to link to the ROM version of 
driverlib for resource optimizations (so could be a waste to throw 
away the driverlib API?)

IMHO that is exactly what we do!

@kaspar: in this particular case (as for the LM4F120 launchpad board) it 
makes very much sense to use the provided hardware abstraction to 
implement RIOTs periph interfaces, as the code used by this HAL layer is 
burned into read-only ROM directly on the CPU and thus does not use any 
additional memory...


Cheers,
Hauke




I have not tested this setup yet, but I think could be a trail to do.

Attilio



On Wed, Sep 2, 2015 at 9:36 AM, Kaspar Schleiser > wrote:


Hey Attilio,

Thanks a lot for your effort on getting this board supported!

On 09/01/15 21:32, Attilio Dona wrote:
> I need just some confirmation, the most important is
> that driverlib from TI is license compatible with RIOT
> (cpu/cc32000/driverlib and cpu/cc3200/inc files used as HAL for the
> drivers).

I just took a quick look, but it seems like "driverlib" is TI's own
hardware abstraction C code.

Our philosphy here was always to not use vendor-supplied HAL code and
instead rewrite hardware support from scratch.

While that requires a little more effort for a new port in the
beginning, we usually end up with a lot cleaner, smaller, more-to-the
point code that can more easily be shared between platforms.

(The license used by driverlib looks fine actually.)

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


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

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

[Hauke Petersen]

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 PC and received its response!

Let's celebrate this tonight!

Cheers,
Oleg

P.S. Everything you need is included in my pre-release branch:
https://github.com/OlegHahm/RIOT/tree/2015.09-RC0


___
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

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

[Hauke Petersen]

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 

Re: [riot-devel] msp430 thoughts

[Hauke Petersen]

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 
inconsistencies in the msp430 family you describe below...


To cope with some of them, I actually re-wrote parts of the msp430 
header files in a more modern, ARM CMSIS style. This makes it much 
easier, to implement register based code in a configurable fashion.


Although we do now have first periph driver implementation, there is a 
lot of cleanup of the msp code to be done. Some steps include (i) moving 
and generalization of the clock initialization code from the boards into 
the cpu (as done for cortex based CPUs), (ii) implementation of missing 
periph drivers (e.g. I2C, cpuid, adc, pwm), and switching to the CORE_NG 
interface (implementing the interfaces in `core/include/arch/..`).


So your help would be much appreciated!

Cheers,
Hauke


On 07.09.2015 02:46, Eric Decker wrote:as430 chips on TinyOS. It was a 
pain.  The TI architecture across different models of the cpu is let us 
just say not very consistent.


I've looked quickly at the approach taken in the RIOT code and there 
are some issues which run into the TI issues.


I'd liked to possibly help you folks to avoid the same crap I ran into.

who are the main msp430 developers?

also take a look at my documentation (I actually documented the issues 
as I ran into them) at


https://github.com/tp-freeforall/prod/blob/tp-master/tos/chips/msp430/00_Chip_Notes



--
Eric B. Decker
Senior (over 50 :-) Researcher



___
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

Re: [riot-devel] RIOT examples

[Hauke Petersen]

+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 wrote:
>> > But maybe we can even live with one examples directory holding all 
examples,
>> > as that makes finding them very easy.
> I think I would also prefer a flat hierarchy and keep it simple.

Does anyone have an opinion on this?


 I also prefer flat hierarchies.


___
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

Re: [riot-devel] Save data in ROM

[Hauke Petersen]

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 like 
this:



| light-weight persistent storage API  |

| some kind of (static) multiplexing   |

| low-level  | low-level  | low-level | I2C| . |
| SPI flash  | EEPROM | on-chip   | EEPROM | . |
| driver | driver | flash dri | driver | . |


Through the API on top it should subsequently then also be possible to 
implement a real file system on top of this. In the end it think the 
most important part is the separation of API and the actual drivers for 
different storage 'devices'!


Again, this is just a rough draft, feel free to advance this discussion!

Cheers,
Hauke


On 27.08.2015 09:34, Baptiste Clenet wrote:

Hi,

I know that Riot hasn't got a file system but I'm wondering if we 
could still save some raw data in the ROM which would be available 
after reset? Could we allow some space in the ROM and write some data?


By the way, have you planned to design a file system for Riot?

--
Baptiste


___
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

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

[Hauke Petersen]

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

[Hauke Petersen]

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://lists.riot-os.org/mailman/listinfo/devel

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

[Hauke Petersen]

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.org/mailman/listinfo/devel

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

[Hauke Petersen]

Hi Olivier,

actually I have never used/looked at that board, so I can sadly not 
really help you setting it up. If it is similar to the mbed-lpc1768 
board, it should actually register with Linux as flash storage device 
and also as virtual UART device.


I can't really tell from your dump what the problem with your device is, 
looks like your computer is unable to read from the USB device. Maybe 
google can help you further?


Sorry I can't give you much better help!

Cheers,
Hauke


On 27.06.2015 08:49, Olivier Fauchon wrote:

Hi Hauke,

I'm working with  'NXP LPC1768 minimum System Board Core Board' from 
ebay:


http://www.ebay.fr/itm/NXP-LPC1768-minimum-System-Board-Core-Board-/170896978026?pt=LH_DefaultDomain_0&hash=item27ca40f06a

When I press KEY1 Button and plug USB at the same time, the USB drive 
"CRP DISABLE" shows up.

Then I copy my firmware.bin file.

Is that correct ?



What are the next step ?

- Should I power cycle the chip after firmware copy ?
- What time the virtual serial port should appear ?

... because I have usb errors when I power cycle the chipset:

  977.740706] usb 1-1: new full-speed USB device number 9 using xhci_hcd
[  977.900894] usb 1-1: device descriptor read/64, error -71
[  978.164385] usb 1-1: device descriptor read/64, error -71
[  978.427916] usb 1-1: new full-speed USB device number 10 using xhci_hcd
[  978.587998] usb 1-1: device descriptor read/64, error -71
[  978.851545] usb 1-1: device descriptor read/64, error -71
[  979.114947] usb 1-1: new full-speed USB device number 11 using xhci_hcd
[  979.115136] usb 1-1: Device not responding to setup address.
[  979.318659] usb 1-1: Device not responding to setup address.
[  979.521874] usb 1-1: device not accepting address 11, error -71
[  979.681964] usb 1-1: new full-speed USB device number 12 using xhci_hcd
[  979.682184] usb 1-1: Device not responding to setup address.
[  979.885623] usb 1-1: Device not responding to setup address.
[  980.088860] usb 1-1: device not accepting address 12, error -71
[  980.088894] usb usb1-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 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
#BOARD=mbed_lpc1768 make clean all flash

afterwards just call 'make term', this will open a serial. The
uart0 is normally mapped to the onboard virtual UART port, so that
there is no need to connect an external UART adapter.

If the flash script does not work for (which happens on some Linux
or Mac systems), you can alternatively just copy over the binary
manually. Copy the RIOT/examples/default/bin/default.bin to the
drive, that is automatically created when plugging in the mbed board.

Please note: the support for the mbed board is very rudimentary at
the moment, so don't expect too much :-)

Cheers,
Hauke

[1] https://developer.mbed.org/platforms/mbed-LPC1768/



On 26.06.2015 14:44, Olivier Fauchon wrote:

Hi.

I could compile my application (a couple of printf within two
threads).
I'd like to test it on a ebay simple LPC1768 board.

What is the correct way to flash this chip, and what are the
correct pins for
the serial uart0.

Thanks.

--
Olivier Fauchon



___
devel mailing list
devel@riot-os.org  <mailto:devel@riot-os.org>
https://lists.riot-os.org/mailman/listinfo/devel



___
devel mailing list
devel@riot-os.org <mailto: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


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

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

[Hauke Petersen]

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
#BOARD=mbed_lpc1768 make clean all flash

afterwards just call 'make term', this will open a serial. The uart0 is 
normally mapped to the onboard virtual UART port, so that there is no 
need to connect an external UART adapter.


If the flash script does not work for (which happens on some Linux or 
Mac systems), you can alternatively just copy over the binary manually. 
Copy the RIOT/examples/default/bin/default.bin to the drive, that is 
automatically created when plugging in the mbed board.


Please note: the support for the mbed board is very rudimentary at the 
moment, so don't expect too much :-)


Cheers,
Hauke

[1] https://developer.mbed.org/platforms/mbed-LPC1768/


On 26.06.2015 14:44, Olivier Fauchon wrote:

Hi.

I could compile my application (a couple of printf within two threads).
I'd like to test it on a ebay simple LPC1768 board.

What is the correct way to flash this chip, and what are the correct 
pins for

the serial uart0.

Thanks.

--
Olivier Fauchon



___
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

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

[Hauke Petersen]

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/2015 14:09, ROUSSEL Kévin a écrit :

Hello,

I've just made a branch with this.

I'll PR it, so everyone can see what I mean.

And indeed, I think it's related to #3221, since it would be way to have
a seed (hopefully) unique for every mote/device.

Regards,



___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel