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

2020-08-31 Thread 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

2020-01-09 Thread 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 the doc and an assert() would be thi

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

2019-09-17 Thread 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

2019-08-26 Thread 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

2019-05-31 Thread 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

2019-05-29 Thread 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

2019-03-01 Thread 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?

2019-02-20 Thread 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

2019-01-17 Thread 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

2018-09-26 Thread 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.



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

2018-09-26 Thread 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

2018-09-26 Thread 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

2018-09-26 Thread 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 
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

2018-02-26 Thread 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

2018-02-26 Thread 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

2018-01-26 Thread 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?

2017-12-12 Thread 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

2017-11-30 Thread 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

2017-11-30 Thread 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 
> 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
>:


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

2017-11-27 Thread 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

2017-10-30 Thread 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

2017-10-27 Thread 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

2017-10-25 Thread 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

2017-10-16 Thread 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

2017-10-16 Thread 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

2017-10-13 Thread 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

2017-10-13 Thread 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


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

2017-08-08 Thread 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

2017-07-13 Thread 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

2017-07-12 Thread 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

2017-07-11 Thread 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

2017-06-19 Thread 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(();

2017-05-02 Thread 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?

2017-03-15 Thread 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] Sensors for RIOT on STM32F4Discovery

2016-12-12 Thread 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

2016-12-08 Thread 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 >:
> 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

2016-10-28 Thread 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" <hauke.peter...@fu-berlin.de 
<mailto:hauke.peter...@fu-berlin.de>> wrote:


Sorry, saw Olegs mail only after I send mine...

Cheers,
Hauke

On 27.10.2016 15:06, Martine Lenders wrote:

Hi,

2016-10-27 15:01 GMT+02:00 Oleg Hahm <oliver.h...@inria.fr
<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

2016-10-27 Thread 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] weird(?) rom section origin in stm32f103cb.ld

2016-10-24 Thread 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

2016-10-12 Thread 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] 2016.04-RC2

2016-04-21 Thread 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] 2016.04-RC1

2016-04-13 Thread 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=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

2016-04-01 Thread 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

2016-03-31 Thread 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

2016-03-29 Thread 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

2016-03-24 Thread 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

2016-03-24 Thread 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] PWM API change

2016-03-19 Thread 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] Biweekly virtual meeting

2016-03-09 Thread 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
<francisco.aco...@inria.fr>:
> 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

2016-03-09 Thread 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

2016-03-03 Thread 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

2016-02-17 Thread 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

2016-02-12 Thread 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] Contribute to RIOT OS

2016-02-08 Thread 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

2016-02-05 Thread 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] Atmel R21

2016-02-04 Thread 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 
>:


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


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

2016-02-04 Thread 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] SamR21 Not using the build in radio

2016-01-26 Thread 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


[riot-devel] Hack'n'ACK tonight

2016-01-26 Thread 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] drivers/SAUL

2016-01-20 Thread 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

2016-01-04 Thread 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

2015-12-14 Thread 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

2015-12-10 Thread 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?

2015-12-09 Thread 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 

Re: [riot-devel] Arduino API merged

2015-11-27 Thread 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)

2015-11-24 Thread 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?

2015-11-23 Thread 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 since the l

Re: [riot-devel] Is RIOT right?

2015-11-19 Thread 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 

Re: [riot-devel] RIOT for Zigduino

2015-11-19 Thread 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] Energy Consumption on samr21_xpro

2015-10-26 Thread 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

2015-09-24 Thread 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!

2015-09-17 Thread 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.

2015-09-09 Thread 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] RIOT examples

2015-08-28 Thread 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 kas...@schleiser.de 
mailto:kas...@schleiser.de:


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

2015-08-27 Thread 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

2015-08-25 Thread 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

2015-07-15 Thread 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] LPC1768 Status, flashing, and uart0

2015-06-29 Thread 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_0hash=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 hauke.peter...@fu-berlin.de 
mailto:hauke.peter...@fu-berlin.de:


Hi Olivier,

I assume you are talking about this mbed-lpc1768 board [1]?
Flashing should work via RIOTs make system: 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] samr21-xpro / watr.li ADC

2015-06-08 Thread Hauke Petersen

Hi,

as we are planning to use the Demo we had @ Embedded World also for 
Lange Nacht der Wissenschaften next Saturday, I have it also on my 
plate, to get a working ADC implementation for the SAMR21 this week.


@wiredsource: Are you planning to do anything on that PR this week? 
Otherwise I would like to take over.


Cheers,
Hauke



On 07.06.2015 21:52, Peter Kietzmann wrote:

Hi Ludwig,

in general I would do so. As part of watrli I already worked with this 
PR and improved some things locally (which I mostly commented inside 
the PR). IIRC @wiredsource stated several times that he wants to 
finish the implementation. @wiredsource are you reading this? What's 
the status from your side?


Best,
Peter

Am 06.06.2015 um 17:31 schrieb Ludwig Ortmann:

Hi,

I just noticed that the samr21-xpro still has no ADC support and was
wondering if maybe someone from the watr.li team could upstream their
implementation..?
Or take over the existing PR https://github.com/RIOT-OS/RIOT/pull/2063 ?

Cheers,
Ludwig
___
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] Biweekly Meeting

2015-06-03 Thread Hauke Petersen

Hi everyone,

here is the link for today biweekly meeting:
http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc-

As usual see the Wiki for instructions on joining in [1]

Cheers,
Hauke

[1] 
https://github.com/RIOT-OS/RIOT/wiki/Instructions-for-remote-participation


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


Re: [riot-devel] Biweekly Meeting

2015-06-03 Thread Hauke Petersen
Somebody else logged in with the RIOT account and killed the ongoing 
Meeting... I just restarted PlaceCam, so please re-join (link should be 
the same).


Cheers,
Hauke


On 03.06.2015 14:00, Hauke Petersen wrote:

Hi everyone,

here is the link for today biweekly meeting:
http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc- 



As usual see the Wiki for instructions on joining in [1]

Cheers,
Hauke

[1] 
https://github.com/RIOT-OS/RIOT/wiki/Instructions-for-remote-participation


___
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] Board Selection for RIOT

2015-05-29 Thread Hauke Petersen

Hi Alexander,

naturally the board of choice would be the iot-lab_M3 (the one used in 
the FIT IoT-lab testbed). But as this board is not freely available on 
the market, I suggest the Atmel samr21-xpro. It uses (almost) the same 
radio as the iot-lab nodes and is freely available at the usual 
electronics suppliers for about 30-40 euros.


Cheers,
Hauke


On 29.05.2015 05:19, Alexander Talavari wrote:

Hello,

As part of my MScThesis i will be devoloping on RIOT and i was 
interest on your suggestion on what board i should buy.


I am already testing it on my Linux Mint image but it would be nice to 
have the board that plays the best with RIOT.


Best regards,
Alexander Talavari


PS I am copy pasting the description of my Thesis as proposed by my 
professor fyi


RIOT [1] is an open source operating system designed for small and 
resource constrained devices. Such devices are expected to be the norm 
in the Internet of Things (IoT). RIOT provides support for 
standardized IoT protocols (e.g., 6LoWPAN and CoAP), as well as, as 
for experimental architectures (e.g., CCN-lite, a lightweight version 
of the CCN Information-Centric Networking [4] architecture [2]). 
FIT-IoT lab [3] is a distributed testbed that enables IoT 
experimentation at a large scale. FIT-IoT provides a variety of 
devices that can be used for experiments, including devices equipped 
with the RIOT OS. The purpose of this thesis is to implement a simple 
application for exchanging content (e.g., sensor measurements) in 
RIOT. The application will be developed in two versions one using CoAP 
and another using CCN-lite. Both versions will be evaluated and 
compared in the FIT-IoT lab.

References
[1] http://www.riot-os.org/
[2] CCN-lite, a lightweight implementation of the Content Centric 
Networking protocol CCNx of XEROX PARC, 2014 (http://ccn-lite.net).

[3] https://www.iot-lab.info/
[4] G. Xylomenos, C.N. Ververidis, V.A. Siris, N. Fotiou, C. 
Tsilopoulos, X. Vasilakos, K.V. Katsaros, G.C. Polyzos, “A Survey of 
Information-Centric Networking Research,” IEEE Communications Surveys 
and Tutorials, vol. 16, no. 2, pp. 1024-1049, 2014 
(http://www.mm.aueb.gr/publications/2013-icn-survey.pdf).




___
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] IEEE802.15.4 discovery

2015-05-20 Thread Hauke Petersen

Hi,

@Jonas, is your 802.15.4 MAC layer implementation planned to cope with this?

Cheers,
Hauke


On 19.05.2015 20:18, Kaspar Schleiser wrote:

Hey,

is anybody working on or are there plans for support for discovering
802.15.4 PANs?

Kaspar
___
devel 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-OS on ARM SAM3X8E?

2015-05-19 Thread Hauke Petersen

Hi Zac,

I think you got something wrong: the Arduino-due is indeed based on the 
Atmel SAM3X8E which is based on an ARM Cortex-M3 with *~96kB* RAM and 
*~512kB*  Flash. The RPi on the other hand has nothing at all to do with 
the Atmel SAM3X8E. Instead it is base on some Broadcom Arm-A11 SoC with 
(depending on the version) *~512MB* of RAM and some *Gigabyte* of 
memory... So they have nothing in common.


The nature of RIOT is, that it is focusing on very constrained 
micro-controller platforms, where the Arduino-due is already on the 
upper scale... So basically: If your device runs Linux (like the RPi), 
then run Linux!. For everything that can't, run RIOT :-)


Cheers,
Hauke

On 19.05.2015 18:00, Zac Harvey wrote:
I was surprised to see Arduino Due (an SAM3X8E-based chip) on your 
list of supported platforms, but not Raspberry Pi (any model/version), 
which is also based on SAM3X8E.  On the Future Hardware Platforms 
wiki page 
(https://github.com/RIOT-OS/RIOT/wiki/Future-Hardware-Platforms) I see 
RPi mentioned with a bulleted list of items/todos/notes.


While I like the Due, the sheer power and RAM capacity of the RPi is 
enticing to me.  I would have thought that making RIOT-OS compatible 
for Arduino Due would have crossed RPi off the list as well since they 
are both SAM3X8E-based.


What would I need to do to get RPi supported? What if I am interested 
in supporting other SAM3X8E boards as well?


-Zac
___
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] NSTF - Naming the stack

2015-05-18 Thread Hauke Petersen

Hi,

I also can live very well with gnrc aka generic.

Cheers,
Hauke

P.S. +1 for 'Google never really called' :-)


On 18.05.2015 17:56, Martine Lenders wrote:

Hi,
given that I was asked today what the R means in RIOT (and Thomas W. 
giving the most excellent to my revelutionary or restricted: 
RIOT) I really like gnrc. Let's find some alternative meanings for 
that! :D Generic newly retained code? Great networking! RIOT 
certified? Google never really called [us]?


Cheers,
Martine

2015-05-18 16:17 GMT+02:00 Oleg Hahm oliver.h...@inria.fr 
mailto:oliver.h...@inria.fr:


Hey Kaspar!

 +1 for generic, but do we need the abbrevation?

Aren't you usually the one arguing for short variable names and
the like?

Cheers,
Oleg
--
WHO HAS ANY ARP JOKES?

___
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] NSTF - Naming the stack

2015-05-12 Thread Hauke Petersen

Hi,

Martine and me had the same discussion yesterday. Until we have a name, 
NG_NETOPT would be the natural choice I guess...


Cheers,
Hauke


On 12.05.2015 09:54, Oleg Hahm wrote:

Hi,

I just stumbled across ng_netconf - we should rename this to avoid confusion
with RFC 6241 [1]. If the stack would have a name, we could simply call it
NAME_conf...

Cheers,
Oleg

[1] https://tools.ietf.org/html/rfc6241


___
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-users] MRF24J40 or SAMR21 (or AT86RF2xx) and FCC Certified Module

2015-05-04 Thread Hauke Petersen

Hi,

On 02.05.2015 03:40, Drasko DRASKOVIC wrote:

Hi all,
I tumbled on this thread:
http://comments.gmane.org/gmane.os.riot.devel/1458 while looking for
support for MRF24J40 in RIOT. What is the current state with SPI
driver for this module - does it exits?
some members of the community do actually have access to that chip - 
though to my knowledge nobody started to implement a driver yet...


Actually, this module is quite nice, as it is FCC certified and not expensive.

Other solution would be probably using SAMR21, but I could not find
any existing FCC certified module on the market. Is someone aware of
some SAMR21 FCC CE certified module that can be used with RIOT in
real-world project?

not sure, all we used so far are the samr21-xpro boards...


I am opened to suggestions for some other 6LoWPAN radio modules that
are certified and that I can get on the market to integrate in my
project.
I do not know about certification status of any available modules, maybe 
some else in the community?


Cheers,
Hauke



Best regards,
Drasko
___
users mailing list
us...@riot-os.org
http://lists.riot-os.org/mailman/listinfo/users


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


Re: [riot-devel] NSTF - Naming the stack

2015-05-04 Thread Hauke Petersen

Hi everyone,

giving the ng_stack a name sounds like a very good idea to me (and as 
far as I remembered I already mentioned this last summer...). Though 
finding a name is tough and I don't like the obvious once (flexnet_, 
default_, riotnet_, etc...).


Also 'cutting' out the re-usable parts as headers, header parsing, 
checksum calculation and some others might make sense, though with this 
I think we have to keep in mind, that not every network stack 
implementation has to use those 'generic' building blocks, as these 
implementations might have their own requirements to certain function 
signatures etc...


When it comes to protocol header files, as 'net/udp.h', I would be even 
more careful. I don't think we will have a generic udp header, that each 
network stack will comply to. In my opinion, each network stack should 
just define it's own header files, as these will differ depending on 
their internal implementation...


The only important thing is, that we will have a clearly defined 
interface for applications (e.g. RIOT sockets, CoAP or whatever).


So I would say: let's find a name?!

Cheers,
Hauke


On 04.05.2015 10:22, Kaspar Schleiser wrote:

Hi,

On 05/03/15 14:52, Martine Lenders wrote:

Perfect. Still, what do we refer to when talking about this new tack?
the default stack?

Yes.

The problem here is that the interfaces someone uses will imply the
implementation.

For example, if someone includes net/udp.h, after dropping the ng_
prefix, you get the default stack udp include file.

IMHO that file should include a stack agnostic interface whose
implementation is selected by e.g., USEMODULE.

Same for all other developer-accessible protocols.

I'm happy with having a default network stack. I'm not happy if that
stack's specific interface ends up as de-facto standard interface,
making switching stacks practically impossible.

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


[riot-devel] NSTF Meeting now

2015-04-30 Thread Hauke Petersen
Hello everyone,

here the the link for todays NSTF meeting:

http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc-

See here [1] for more information about how to join remotely.

A preliminary agenda and topics for discussion are listed in the RIOT wiki
[2].

See you!

Cheers,
Hauke

[1]
https://github.com/RIOT-OS/RIOT/wiki/Instructions-for-remote-participation
[2]
https://github.com/RIOT-OS/RIOT/wiki/minutes-network-stack-task-force-april-2015

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


Re: [riot-devel] WDT questions

2015-04-29 Thread Hauke Petersen

Hi,

very simple: A watchdog timer does not at all fit into the context of a 
tickless-system. We want to sleep as long as possible, so waking up just 
to please the WDT is very counter productive...


A WDT interface we could actually introduce, I guess just nobody did it 
so far...


Cheers,
Hauke


On 29.04.2015 14:43, Baptiste Clenet wrote:

Hi,

I've got two questions concerning WDT:
 - Why do we disable it on the samr21 at launch time?
 - Why doesn't RIOT provide a wdt.h in drivers/include/periph?

Cheers,

--
/Clenet 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] Hack'n'ACK tonight

2015-04-28 Thread Hauke Petersen
Hi everyone,

here is the Link for remote participation in tonight's Hack'n'ACK:

http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc-

As always, see here [1] for more information on how to join.

Cheers,
Hauke

[1]
https://github.com/RIOT-OS/RIOT/wiki/Instructions-for-remote-participation

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


Re: [riot-devel] Board maintainers

2015-04-27 Thread Hauke Petersen

done.

Cheers,
Hauke


On 26.04.2015 10:48, Kaspar Schleiser wrote:

Hey guys,

I've added a Maintainer field to our supported platforms list [1]. 
Feel free to add yourself to the board ports you feel responsible for.


Kaspar
[1] https://github.com/RIOT-OS/RIOT/wiki/RIOT-Platforms
___
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] Biweekly Dev Meeting

2015-04-22 Thread Hauke Petersen

Hi everyone,

here is the Placecam link for todays developer meeting:

http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc-

See you there,
Hauke



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


Re: [riot-devel] LWM2M client on RIOT

2015-04-22 Thread Hauke Petersen

Hi Roberto,

we will be porting LWM2M to RIOT as a GSOC project this summer.

Cheers,
Hauke

On 22.04.2015 09:44, Roberto P wrote:

Hi,
I'm interested in making work a LWM2M client on RIOT, I have a project in my 
mind.
For the moment the only solution I found to make it work on RIOT was to 
translate the client of leshan from java to c but that seems like a very 
complicated things, do you have any other ideas?
In a comment of15. July 2014 you wrote thatyou didn't yet have any LWM2M 
implementation running in RIOT, but that was on your TODO list, is there some 
updates about that?
Thank you, regards,
Robert


___
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] [ ST32L152RE ] [periph_conf.h]

2015-04-01 Thread Hauke Petersen

Hi Tara,

the alternate function definition (PWM_x_PIN_x_AF) is meant for defining 
which alternate function the referneced pin is using. You can find the 
correct values for your configuration in the devices data sheet [1] on 
page 43ff, Table 9.


If you for example want to use PWM_0 with timer TIM2 and you want to map 
the PWM channel 0 to pin PA3, the value of AF is 1.


Let me know if anything is unclear!

Cheers,
Hauke


[1] 
http://www.st.com/web/en/resource/technical/document/datasheet/CD00277537.pdf


On 01.04.2015 02:19, Tararaina Klipffel wrote:

Hi everybody,

I have few questions about the PWM configuration pin on the 
periph_config.h [1] on STM32L152RE. The pwm.c file is already done, we 
were based on pwm.c stm32f3 discovery file. We also used this two 
manuals [2] [3].


What is the link between PWM_0_PIN_CH0  and  PWM_0_PIN_AF  ? Does 
PWM_0_PIN_AF refer to the GPIO_AFRL_AFRLX (X € [0..7] ) or the 
GPIO_AFRH_AFRHX (X € [8..15] ) in stm32l1xx.h ?



[1] : http://pastebin.com/bthJXJFP
[2] : 
http://www.st.com/web/en/resource/technical/document/reference_manual/CD00240193.pdf
[3] : 
http://www.st.com/web/en/resource/technical/document/datasheet/CD00277537.pdf


Kind regards
Tara.


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


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


Re: [riot-devel] API proficiency levels

2015-03-25 Thread Hauke Petersen

Hi Kaspar,

in general I like the idea, one problem I see is however, that is not 
always clear, to which level an API belongs (e.g. the GPIO API is 
definitely used also by high-level application programmers, while still 
belonging to the low-level peripheral drivers...).


Cheers,
Hauke

On 25.03.2015 10:39, Kaspar Schleiser wrote:

Hey guys,

I've been thinking about how to find generally usable principles for 
certain API aspects, like when to check a function's parameters for 
validity.


An idea came to mind:

We could define some (two, three) levels of how low an API goes and 
define (and document) consistent behaviour around those levels.


For example, a high-level timer or socket API that is being used by 
any simple application has probably more need for parameter checking 
than a low-level interface that no normal user will ever see.
On the other hand, low-level functions for accessing the flash will 
probably abstracted with a sane user API.


The idea is to document that some API's do need a deep understanding 
of what's going on, thus will be used by developers that don't need a 
high level of safeguards. We could omit a lot of extra sanity checks.


Other API's will be used by high-level programmers which might not 
know how to debug parameter mistakes, so checking function arguments 
is more important.


What do you think?

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


Re: [riot-devel] Updated Invitation: Biweekly virtual meeting @ Wed Mar 25, 2015 2pm - 3pm (RIOT Events)

2015-03-25 Thread Hauke Petersen

Hi everyone,

we will start with the bi-weekly developer meeting now. The PlaceCam 
link for joining is the following:


http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc-

Please refer to the RIOT wiki [1] for information on how to join.

Cheers,
Hauke

[1] 
https://github.com/RIOT-OS/RIOT/wiki/Instructions-for-remote-participation




On 24.03.2015 16:44, Martine Lenders wrote:


Event Invitation

Title:



Biweekly virtual meeting

Location:



When:



Wed 25 Mar 2015 14:00 – 15:00




Organizer:



Description:



Developer discussions. Remote participation will be provided. View 
your event at 
https://www.google.com/calendar/event?action=VIEWeid=anBwMXUyaXZsdWVkOHFkdHA1MGpzYjFzZ2tfMjAxNTAzMjVUMDkwMDAwWiBrM3FsOHNldHY3bDQ4b2Zub2wwdGZ1dTZ0c0Bn.


Comment:



Attendees:






___
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] NSTF radio driver

2015-03-23 Thread Hauke Petersen

Hi Joakim,

as of today, I PRed a new version of the Xbee S1 radio driver[1], which 
is build 100% on the new netdev interface. I think it makes a good 
reference implementation for radio drivers, even if it is through it's 
UART interface a little different from others drivers we are supporting...


So to my opinion, the netdev interface can be considere as stable (I 
expect only very minor changes). So if you want to go ahead implementing 
your new driver, now is a good time as any!


Cheers,
Hauke

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


On 20.02.2015 07:25, Joakim Gebart wrote:

Dear RIOT developers,
  - Which radio driver is the most up to date with regards to the
network stack restructuring work being done in #2278?
  - How stable is the radio device API currently? Are there any more
API changes coming?
  - Would it be wise to wait until the restructuring todo list is
mostly checked off until starting work on implementing a new radio
device driver?
  - Which driver would be best to use as an example of a fully
compliant radio driver?

I am looking at implementing a driver for a new radio chip, but I do
not want to have to redo the work again in a couple of weeks because
of the network refactoring...

https://github.com/RIOT-OS/RIOT/issues/2278

Best regards,
Joakim Gebart
Managing Director
Eistec AB

Aurorum 1C
977 75 Luleå
Tel: +46(0)730-65 13 83
joakim.geb...@eistec.se
www.eistec.se
___
devel mailing list
devel@riot-os.org
http://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] N2 Project

2015-03-23 Thread Hauke Petersen

Hi David,

when using Wakaama (which is certainly an option), the way would be to 
include it in RIOT as a package and include some Makefiles that are able 
to download/checkout the library and build it into RIOT. When choosing 
this path, one important thing is to think of a concept for continuous 
integration, so that the Makefiles and patches can be adjusted to 
changes of the Wakaama implementation in an easy way.


Cheers,
Hauke


On 23.03.2015 19:45, David Reinert wrote:
I am almost certainly planning on using the Wakaama project(formerly 
liblwM2M) for this project. A possibly silly question but, would a 
final port of this implementation look similar to the various ports 
under RIOT/pkg/ or is it more involved than that? I am just trying to 
get a picture of what the final project would look like so I can 
better form a clear timeline. Thanks!


-David


___
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] CSMA MAC-layer, Open Issues

2015-03-23 Thread Hauke Petersen

Hi Jonas,

On 20.03.2015 18:02, Jonas Remmert wrote:


1. Both, the upper layer and the current implementations of the 
ng_netdev radio drivers use task messages to signalize an event 
(Packet to be sent or Packet to receive waiting). Both message 
mechanisms send their messages to the mac_pid and therefore use the 
same message queue. If the mac-layer and the transceiver is busy with 
sending a message out or waiting for an ACK it might wait for a signal 
from the driver (RX-ready, ACK-received...). In the same time there 
might also be messages from the upper layers that can not be handled 
until the previous packet is sent out.


- I handled this problem in using the drivers call-back function in 
combination with different task lock mechanisms for upper layer 
(msg_receive) and for driver events 2x(mutex_lock), which causes in 
TASK_BLOCKED state. That method worked very well, even if I fired the 
mac-layer continously with upper layer messages.
Though this probably works fine, this is not quite how the concept was 
meant. The problem is of course there: when the MAC layer is getting 
spammed by upper layer messages, the reaction time for device driver 
messages might be not as fast... Though the messages should not be los 
(as they are queued...). The concept is based on the assumption, that 
the time needed for handling incoming messages in the MAC layer is very 
short. Also so far we basically assumed, that the MAC layer has a higher 
priority then the upper layers. This way, the MAC layer will always 
finish processing all it's queued messages before the upper layers get 
scheduled again.


2. The drivers send function builds the IEEE 802.15.4 MAC header on 
its own. The alternative would be to let the MAC layer do this job. 
This would avoid code duplication and make it easier to implement new 
radio drivers. Is there any reason to do this in the driver 
implementation?
I don't really understand the code duplication issue here... The MAC 
layer should actually not know anything about the radio frame format or 
the like, as the idea behing the MAC layer in the current form is to 
make them interchangable and usable with different network devices (not 
only 802.15.4 devices)... So to answer your question: yes!


3. Introduction of PHY dependant constants: The constants (e.g. 
SYMBOL_LENGTH used in backoff intervall, MAX_BE, MIN_BE, 
TURNAROUND_TIME, MAC_ACK_WAIT_DURATION, MAX_RETRIES..). As these 
constants are different for each type of PHY (2,5 Ghz, subGhz and also 
Modulation specific) we could put them in a struct that would be 
linked to the device descriptor.
Actually, these constants should not be constants :-) The way I would 
implement them is by naming these defines something like 
xx_DEFAULT_MAX_BE, xx_DEFAULT_TURNAROUND_TIME, etc. The you include 
fields in your device descriptor for these values and initialize them 
with these values. This way you can change them during runtime and 
define different values if you run more then 1 device concurrently...


4. Generally, a successfull TX of a packet is not signalized to upper 
layers. But how do we handle a packet that could not be sent to the 
channel (e.g. channel busy)? Should upper layer be informed about the 
failure?
So far the packets are just silently dropped. The plain netapi_send() 
does not support feedback to upper layers on the success of the send 
process - this we did to avoid deadlock scenarios and synchronization 
issues...


Cheers,
Hauke




A WIP state of the ng_kw2xrf-driver that I used for testing can be 
found in my repo [2].


a nice Weekend,
Jonas


[1] - https://github.com/RIOT-OS/RIOT/pull/2467
[2] - https://github.com/jremmert-phytec-iot/RIOT/tree/wip%40kw2xrf_ng


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


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


  1   2   >