Re: [riot-devel] Updates to the build system - modules definition

[Kaspar Schleiser]

Hi,

On 11/30/2017 04:32 PM, Gaëtan Harter wrote:
>   1. Configuration is not documented
>   2. Information is not readable
>   3. Modules definition is scattered but in RIOT global files

> With these issues in mind, I propose to add parseable module meta-data
> definitions in a file in each module directory to first replace the
> existing information and then extend it to add more precise ones.
> How to do in practice it is still to be defined and discussed.

When are you gonna take a look at my ninja-based build system? It solves
1-3 quite nicely, and more. You could save a lot of time.

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

Re: [riot-devel] 6lowpan Host with SLAAC, minimum ram footprint

[Cenk Gündoğan]

Hey Josua!

If you're not using RPL, then you should disable it in the Makefile.
`gnrc_networking` is shipping with RPL enabled. It's sufficient to
remove the `USEMODULE += gnrc_rpl` line in the Makefile.

You can also get some inspiration from the Makefile of the `gnrc_minimal`
example. Especially from the `CFLAGS` line there.

Cheers!
Cenk

On 17-11-30 15:17:59, Arndt, Josua wrote:
> Hello all,
> 
> I have ported Riot OS to the atmega256rfr2 and the gnrc_network example works 
> as expected.
> 
> My setup is following:
> RPI Border Router with an openlabs at86rf233 transceiver and radvd.
> Jiminy Host with gnrc_network.
> 
> Ping6 with link local from Host to BR and from BR to host works.
> Also ping with global Ip works.
> Sending UDP Packets works.
> 
> Now I want to reduce the RAM  footprint to a minimum would need some advice 
> how to proceed.
> 
> And another question would be: is it possible to run all necessary 
> modules/layers needed for slaac with only 16Kbytes sram?
> And how would you proceed/optimize the gnrc_network example to achieve this.
> 
> This question arises as I have ported riot os to an at x mega256 and would 
> like to run it as host, but the sram is only 16kbytes and so
> The gnrc_network example is way too large. Removing shell commands helps but 
> is not enough.
> 
> Following the memory usage of the full gnrc_network example.
> 
> Device: atmega256rfr2
> 
> Program:  114428 bytes (43.7% Full)
> (.text + .data + .bootloader)
> 
> Data:  29195 bytes (89.1% Full)
> (.data + .bss + .noinit)
> 
> 
> Thank you in advance for any advice our suggestion.
> Josua Arndt
> 
> 

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


-- 
Cenk Gündoğan

Hamburg University of Applied Sciences
Dept. of Computer Science / Internet Technologies Group
Berliner Tor 7, 20099 Hamburg, Germany
Fon: +49 40 42875 - 8426
Mail: cenk.guendo...@haw-hamburg.de
Web: https://www.inet.haw-hamburg.de/


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

Re: [riot-devel] 6lowpan Host with SLAAC, minimum ram footprint

[Kaspar Schleiser]

Hi Josua,

On 11/30/2017 04:17 PM, Arndt, Josua wrote:
> I have ported Riot OS to the atmega256rfr2 and the gnrc_network example
> works as expected.
> 
> Now I want to reduce the RAM  footprint to a minimum would need some
> advice how to proceed.

I have a branch in [1] that tries to disable as much as possible in
order to make tests/minimal smaller. Most of it won't be of much use as
you're using gnrc, but maybe you find some inspiration.

Some ideas:

- reduce the number of allowed threads and priority levels to exactly
what you need
- disable all stdio (see also [2])
- compile with LTO=1

Kaspar

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

Re: [riot-devel] Updates to the build system - modules definition

[Gaëtan Harter]

Hi,

On 11/30/2017 11:52 AM, Kaspar Schleiser wrote:

Hi Dan,

On 11/29/2017 02:33 PM, Daniel Petry wrote:

1. The current build system isn't suitable to support the front end for
RAPstore that Hendrik developed for his bachelor thesis, which requires
that certain information can be displayed to the users.

I hear about this for the first time. Are there any pointers?
Its not specific to the current version of the interface, but to what I 
would like to achieve for the RAPstore project.
Configure a firmware using a graphical interface by selecting modules 
and configuring them.



2. The current build system doesn't allow developers to easily include
modules in their applications

USEMODULE += module_name?

In our context, it could be important to know the consequences of this.
On my computer, when I say 'aptitude install PACKAGE' I am informed of 
the additional dependencies.
Here with interdependencies, and modules affecting the global 
configuration it can be more important than this.


The cbor_ctime pseudomodule, when used with newlib, makes every source 
files compile with -DGNU_SOURCE=1.

I would not know that when simply adding it to USEMODULE.


built can be affected by files/code outside the module directory
2.1 API changes as a result of including other modules aren't
immediately visible in that module
2.2 API changes on other modules as a result of including that module
isn't immediately visible
2.3 The complete build information for a module isn't localised only in
the module directory

If modules are interdependent, they will affect each other. How can a
different module definition help here?
Regarding 'interdependency', I think about module that behave 
differently => are compiled differently if another module is included.

The optional dependencies that affect either your code or your API.

Adding this to a definition would help as documentation. It still allow 
specific requirements, still allows strange architecture for compilation 
optimization, but at least its said somewhere.


It took me some time to understand that `at86rf231` and `at86rf212b` are 
pseudomodules and are both implemented by `at86rf2xx` which is compiled 
differently depending on which one is included. 'git grep at86rf231' 
says nothing about it.


It would of course require tooling to help writing and maintaining these 
modules definition.
And even more for each information that the build system is not using 
and enforcing.



Gaëtan


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] 6lowpan Host with SLAAC, minimum ram footprint

[Martine Lenders]

Hi,

is anyone finding anything in the Wiki? I rather would add it to the
Doxygen. What do you think?

Cheers,
Martine

2017-11-30 16:49 GMT+01:00 Koen Zandberg :

> Hi Martine,
>
> Would you mind if I put these suggestions on a wiki page? Of course it get
> a nice "Here be dragons" warning. :)
>
> Regards,
> Koen
>
> On 11/30/2017 04:33 PM, Martine Lenders wrote:
>
> Hi Josua,
>
> have you had a look at the `gnrc_minimal` example? It gives a nice
> overview about which compile-time parameters you can change to achieve
> exactly that. In summary this is:
>
> * Reduce the size of the packet buffer (GNRC_PKTBUF_SIZE). If you are not
> too verbose with the packets you are sending 512 can be enough (if you have
> problems you can still choose higher numbers; default configuration is
> 6KiB).
> * Reduce the size of the (unicast and multicast) IPv6 addresses you can
> assign to an interface (GNRC_NETIF_IPV6_ADDRS_NUMOF
> and DGNRC_NETIF_IPV6_GROUPS_NUMOF)
> * Reduce the size of the neighbor cache (GNRC_IPV6_NIB_NUMOF; that is
> wrong in gnrc_minimal, will fix that ASAP)
>
> If you want to get even more out of it, run the stack in your scenario for
> a while and check the stack usage of each module, using the `ps` shell
> command. The usage should be much lesser than what is actually allocated.
> You can reduce the stack sizes by modifying the configuration define in the
> respective module's header (or override it with CFLAGS).
>
> Hope this was helpful,
> Martine
>
> 2017-11-30 16:17 GMT+01:00 Arndt, Josua :
>
>> Hello all,
>>
>>
>>
>> I have ported Riot OS to the atmega256rfr2 and the gnrc_network example
>> works as expected.
>>
>>
>>
>> My setup is following:
>>
>> RPI Border Router with an openlabs at86rf233 transceiver and radvd.
>>
>> Jiminy Host with gnrc_network.
>>
>>
>>
>> Ping6 with link local from Host to BR and from BR to host works.
>>
>> Also ping with global Ip works.
>>
>> Sending UDP Packets works.
>>
>>
>>
>> Now I want to reduce the RAM  footprint to a minimum would need some
>> advice how to proceed.
>>
>>
>>
>> And another question would be: is it possible to run all necessary
>> modules/layers needed for slaac with only 16Kbytes sram?
>>
>> And how would you proceed/optimize the gnrc_network example to achieve
>> this.
>>
>>
>>
>> This question arises as I have ported riot os to an at *x* mega256 and
>> would like to run it as host, but the sram is only 16kbytes and so
>>
>> The gnrc_network example is way too large. Removing shell commands helps
>> but is not enough.
>>
>>
>>
>> Following the memory usage of the full gnrc_network example.
>>
>> 
>>
>> Device: atmega256rfr2
>>
>>
>>
>> Program:  114428 bytes (43.7% Full)
>>
>> (.text + .data + .bootloader)
>>
>>
>>
>> Data:  29195 bytes (89.1% Full)
>>
>> (.data + .bss + .noinit)
>>
>> 
>>
>>
>>
>> Thank you in advance for any advice our suggestion.
>>
>> Josua Arndt
>>
>>
>>
>>
>>
>> ___
>> devel mailing list
>> devel@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>>
>>
>
>
> ___
> devel mailing 
> listdevel@riot-os.orghttps://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] Warning on compilation

[Gaëtan Harter]

Hi Baptiste,


using '-Wall -Wextra' by default was finally added just two days ago 
https://github.com/RIOT-OS/RIOT/pull/7919/.

But maybe other warnings could be interesting to add you are right.
I like statically checking as many things as possible.

"All the warnings options", depends on the compiler version of each 
target, and gcc or clang, so may not all be available.
Also, some warnings may be problematic for us if they are often just 
false positive.


If you found warnings that could be a good idea to fix, you can propose 
a PR with them, this way its easier to review with the CI build output.


In the list, not all are adding warnings, like '-pipe' or '-std=gnu99', 
-ffunctions-sections (which is already used).

And also -fno-strict-aliasing which removes important check.

Cheers,
Gaëtan


On 11/30/2017 04:20 PM, Baptiste Clenet wrote:

Hi,

I'm using samr21-xpro and I tried to add same warning options than
Atmel Studio for RIOT:

-pipe -fno-strict-aliasing -Wall -Wstrict-prototypes
-Wmissing-prototypes -Werror-implicit-function-declaration
-Wpointer-arith -std=gnu99 -ffunction-sections -fdata-sections
-Wchar-subscripts -Wcomment -Wformat=2 -Wimplicit-int -Wmain
-Wparentheses -Wsequence-point -Wreturn-type -Wswitch -Wtrigraphs
-Wunused -Wuninitialized -Wunknown-pragmas -Wfloat-equal -Wundef
-Wshadow -Wbad-function-cast -Wwrite-strings -Wsign-compare
-Waggregate-return  -Wmissing-declarations -Wformat
-Wmissing-format-attribute -Wno-deprecated-declarations -Wpacked
-Wredundant-decls -Wnested-externs -Wlong-long -Wunreachable-code
-Wcast-align --param max-inline-insns-single=500

I got long list of warnings.
Why RIOT does not used all the warning options?

Cheers,


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

Re: [riot-devel] 6lowpan Host with SLAAC, minimum ram footprint

[Koen Zandberg]

Hi Martine,

Would you mind if I put these suggestions on a wiki page? Of course it
get a nice "Here be dragons" warning. :)

Regards,
Koen


On 11/30/2017 04:33 PM, Martine Lenders wrote:
> Hi Josua,
>
> have you had a look at the `gnrc_minimal` example? It gives a nice
> overview about which compile-time parameters you can change to achieve
> exactly that. In summary this is:
>
> * Reduce the size of the packet buffer (GNRC_PKTBUF_SIZE). If you are
> not too verbose with the packets you are sending 512 can be enough (if
> you have problems you can still choose higher numbers; default
> configuration is 6KiB).
> * Reduce the size of the (unicast and multicast) IPv6 addresses you
> can assign to an interface (GNRC_NETIF_IPV6_ADDRS_NUMOF
> and DGNRC_NETIF_IPV6_GROUPS_NUMOF)
> * Reduce the size of the neighbor cache (GNRC_IPV6_NIB_NUMOF; that is
> wrong in gnrc_minimal, will fix that ASAP)
>
> If you want to get even more out of it, run the stack in your scenario
> for a while and check the stack usage of each module, using the `ps`
> shell command. The usage should be much lesser than what is actually
> allocated. You can reduce the stack sizes by modifying the
> configuration define in the respective module's header (or override it
> with CFLAGS).
>
> Hope this was helpful,
> Martine
>
> 2017-11-30 16:17 GMT+01:00 Arndt, Josua  >:
>
> Hello all,
>
>  
>
> I have ported Riot OS to the atmega256rfr2 and the gnrc_network
> example works as expected.
>
>  
>
> My setup is following:
>
> RPI Border Router with an openlabs at86rf233 transceiver and radvd.
>
> Jiminy Host with gnrc_network.
>
>  
>
> Ping6 with link local from Host to BR and from BR to host works.
>
> Also ping with global Ip works.
>
> Sending UDP Packets works.
>
>  
>
> Now I want to reduce the RAM  footprint to a minimum would need
> some advice how to proceed.
>
>  
>
> And another question would be: is it possible to run all necessary
> modules/layers needed for slaac with only 16Kbytes sram?
>
> And how would you proceed/optimize the gnrc_network example to
> achieve this.
>
>  
>
> This question arises as I have ported riot os to an at *_x_*
> mega256 and would like to run it as host, but the sram is only
> 16kbytes and so
>
> The gnrc_network example is way too large. Removing shell commands
> helps but is not enough.
>
>  
>
> Following the memory usage of the full gnrc_network example.
>
> 
>
> Device: atmega256rfr2
>
>  
>
> Program:  114428 bytes (43.7% Full)
>
> (.text + .data + .bootloader)
>
>  
>
> Data:  29195 bytes (89.1% Full)
>
> (.data + .bss + .noinit)
>
> 
>
>  
>
> Thank you in advance for any advice our suggestion.
>
> Josua Arndt
>
>  
>
>  
>
>
> ___
> 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



signature.asc
Description: OpenPGP digital signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] 6lowpan Host with SLAAC, minimum ram footprint

[Martine Lenders]

Hi,

2017-11-30 16:33 GMT+01:00 Martine Lenders :

> * Reduce the size of the neighbor cache (GNRC_IPV6_NIB_NUMOF; that is
> wrong in gnrc_minimal, will fix that ASAP)
>

See https://github.com/RIOT-OS/RIOT/pull/8185 for the fix.

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

Re: [riot-devel] 6lowpan Host with SLAAC, minimum ram footprint

[Martine Lenders]

Hi Josua,

have you had a look at the `gnrc_minimal` example? It gives a nice overview
about which compile-time parameters you can change to achieve exactly that.
In summary this is:

* Reduce the size of the packet buffer (GNRC_PKTBUF_SIZE). If you are not
too verbose with the packets you are sending 512 can be enough (if you have
problems you can still choose higher numbers; default configuration is
6KiB).
* Reduce the size of the (unicast and multicast) IPv6 addresses you can
assign to an interface (GNRC_NETIF_IPV6_ADDRS_NUMOF
and DGNRC_NETIF_IPV6_GROUPS_NUMOF)
* Reduce the size of the neighbor cache (GNRC_IPV6_NIB_NUMOF; that is wrong
in gnrc_minimal, will fix that ASAP)

If you want to get even more out of it, run the stack in your scenario for
a while and check the stack usage of each module, using the `ps` shell
command. The usage should be much lesser than what is actually allocated.
You can reduce the stack sizes by modifying the configuration define in the
respective module's header (or override it with CFLAGS).

Hope this was helpful,
Martine

2017-11-30 16:17 GMT+01:00 Arndt, Josua :

> Hello all,
>
>
>
> I have ported Riot OS to the atmega256rfr2 and the gnrc_network example
> works as expected.
>
>
>
> My setup is following:
>
> RPI Border Router with an openlabs at86rf233 transceiver and radvd.
>
> Jiminy Host with gnrc_network.
>
>
>
> Ping6 with link local from Host to BR and from BR to host works.
>
> Also ping with global Ip works.
>
> Sending UDP Packets works.
>
>
>
> Now I want to reduce the RAM  footprint to a minimum would need some
> advice how to proceed.
>
>
>
> And another question would be: is it possible to run all necessary
> modules/layers needed for slaac with only 16Kbytes sram?
>
> And how would you proceed/optimize the gnrc_network example to achieve
> this.
>
>
>
> This question arises as I have ported riot os to an at *x* mega256 and
> would like to run it as host, but the sram is only 16kbytes and so
>
> The gnrc_network example is way too large. Removing shell commands helps
> but is not enough.
>
>
>
> Following the memory usage of the full gnrc_network example.
>
> 
>
> Device: atmega256rfr2
>
>
>
> Program:  114428 bytes (43.7% Full)
>
> (.text + .data + .bootloader)
>
>
>
> Data:  29195 bytes (89.1% Full)
>
> (.data + .bss + .noinit)
>
> 
>
>
>
> Thank you in advance for any advice our suggestion.
>
> Josua Arndt
>
>
>
>
>
> ___
> 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] Updates to the build system - modules definition

[Gaëtan Harter]

Hi Thomas, Francisco, all,

I will try to summarize with three aspects formatted as problems.

Just for clarity, in the following text, use the words 'description', 
'informations', 'configuration', 'dependencies' to describe all the 
meta-information that can be attached to a module in addition to its 
source code.



I also am in demand of other issues that you have and that should be 
taken into account if the current system is refactored.
So I invite you to talk about your case too, I want to start discussions 
before working on it.


Also I welcome all remarks regarding my problems and the way I want to 
address them.



 1. Configuration is not documented

As Francisco is saying, about configuring an application and so its modules.
The problem, for me, is that its hard to know the possible 
configurations of a module and the impact of the configuration/dependencies.



   Details:

When building an application, I need to:

 * describe what I want to use in my application, which usually means
   saying which module/package I want
 * configure the application and the modules, by using either specific
   variables `DEVELHELP`, `OUTPUT` or manually setting CFLAGS
 * Specify requirements to work only on boards with this hardware support.

 * But it also means understanding the impact of adding a specific
   module / setting one configuration

Right now the impact is tedious to find. A dependency pulled by one 
module can have an impact on another module code, on its API, on all 
modules.
And modules configuration, is often only described into the doxygen or 
the source code: what CFLAGS should I put to configure the radio channel ?


I would like to clearly write down these public configurations and 
dependencies relations.



 2. Information is not readable

The module information cannot be presented and re-interpreted to show on 
a graphical interface.
It is not machine readable, and the same way of defining things has 
multiple meaning.



   Details:

I would need to have parseable files usable by an automated system, 
which is currently not the case.


For my needs, it would be necessary to refine the current information to 
make it more precise.
The 'dependencies' and configurations now used in the build system can 
be ambiguous to present because they have different meaning.


 * Some optional dependencies have different impact, they:
 o can change the source code behavior
 o can change the module API
 o can affect every modules
 * The same goes for configuration, is the configuration affecting the
   module API ?



 3. Modules definition is scattered but in RIOT global files

The meta-information on a module is not grouped together with the module 
but written in 3-4 files global to the RIOT repository.
This means reading different files to get a complete view on a module 
but also that it is not possible to use external modules trees without 
modifying the RIOT repository.



   Details:

I would like to make modules self contained. I think it would help 
developers as it improves readability and documentation by having only 
one place to understand a module.
Also, external modules would be defined in the same way as internal ones 
by just adding a tree of modules to load.



   Bonus. Unnecessary globally visible configuration

A bonus aspect that I would like to tackle in the long term when the 
updates would be in place.


Right now all CFLAGS/INCLUDES are global to all modules.
This means a different version of the `core` module is build if another 
high level module is included or has its configuration changed.


Having more informations on modules dependencies and configuration scope 
could help refine this.



 Details:

Having a determined context would makes tests more reliable, because we 
could know which configuration has been tested and which not.
It would require explicit build system configuration to make a 
configuration affect another module.
Solving this could allow doing build caching at a the build system level 
when build with common local context.
I am also interested in reproducible builds and so being able to 
describe what has been build with the minimal information required and 
verifying the produced output.



With these issues in mind, I propose to add parseable module meta-data 
definitions in a file in each module directory to first replace the 
existing information and then extend it to add more precise ones.

How to do in practice it is still to be defined and discussed.


Cheers,
Gaëtan - cladmi


On 11/27/2017 04:39 PM, Francisco Javier Acosta Padilla wrote:

Hi,

I think the problem to solve is that RIOT is very difficult to configure.

While working with other IoT operating systems, one can notice that 
RIOT is very hardly configurable, unless we are very familiar with the 
build system and specific RIOT CFLAGS and special key-words 
(USEMODULE, USEPKG, etc…).


Besides, I have no knowledge of a tool that can p

[riot-devel] Warning on compilation

[Baptiste Clenet]

Hi,

I'm using samr21-xpro and I tried to add same warning options than
Atmel Studio for RIOT:

-pipe -fno-strict-aliasing -Wall -Wstrict-prototypes
-Wmissing-prototypes -Werror-implicit-function-declaration
-Wpointer-arith -std=gnu99 -ffunction-sections -fdata-sections
-Wchar-subscripts -Wcomment -Wformat=2 -Wimplicit-int -Wmain
-Wparentheses -Wsequence-point -Wreturn-type -Wswitch -Wtrigraphs
-Wunused -Wuninitialized -Wunknown-pragmas -Wfloat-equal -Wundef
-Wshadow -Wbad-function-cast -Wwrite-strings -Wsign-compare
-Waggregate-return  -Wmissing-declarations -Wformat
-Wmissing-format-attribute -Wno-deprecated-declarations -Wpacked
-Wredundant-decls -Wnested-externs -Wlong-long -Wunreachable-code
-Wcast-align --param max-inline-insns-single=500

I got long list of warnings.
Why RIOT does not used all the warning options?

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

[riot-devel] 6lowpan Host with SLAAC, minimum ram footprint

[Arndt, Josua]

Hello all,

I have ported Riot OS to the atmega256rfr2 and the gnrc_network example works 
as expected.

My setup is following:
RPI Border Router with an openlabs at86rf233 transceiver and radvd.
Jiminy Host with gnrc_network.

Ping6 with link local from Host to BR and from BR to host works.
Also ping with global Ip works.
Sending UDP Packets works.

Now I want to reduce the RAM  footprint to a minimum would need some advice how 
to proceed.

And another question would be: is it possible to run all necessary 
modules/layers needed for slaac with only 16Kbytes sram?
And how would you proceed/optimize the gnrc_network example to achieve this.

This question arises as I have ported riot os to an at x mega256 and would like 
to run it as host, but the sram is only 16kbytes and so
The gnrc_network example is way too large. Removing shell commands helps but is 
not enough.

Following the memory usage of the full gnrc_network example.

Device: atmega256rfr2

Program:  114428 bytes (43.7% Full)
(.text + .data + .bootloader)

Data:  29195 bytes (89.1% Full)
(.data + .bss + .noinit)


Thank you in advance for any advice our suggestion.
Josua Arndt


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

Re: [riot-devel] HIL testing

[Daniel Petry]

Hi all

I've raised an issue for my initial concept for the HIL testing of the
UART driver: https://github.com/RIOT-OS/RIOT/issues/8184.

I'm going to start on it immediately in order to go ahead with issue
https://github.com/RIOT-OS/RIOT/issues/7941. All comments and input
would be gratefully received while I'm doing so! Once the tests have
been developed and used and any feedback discussed/integrated I'll open
a separate PR for the UART HIL tests.

Perhaps we could aim for the discussion on this and the I2C HIL setup to
feed into a standard implementation, to allow it to be more easily
implemented in Murdock, if that would be useful?

Dan

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

Re: [riot-devel] Updates to the build system - modules definition

[Matthias Waehlisch]

Hi Kaspar,

On Thu, 30 Nov 2017, Kaspar Schleiser wrote:

> > 1. The current build system isn't suitable to support the front end for
> > RAPstore that Hendrik developed for his bachelor thesis, which requires
> > that certain information can be displayed to the users.
> 
> I hear about this for the first time. Are there any pointers?
> 
  it was briefly presented during the RIOT Summit this year. As soon as 
we have a public demo ready, we will post on the list.


Cheers
  matthias

-- 
Matthias Waehlisch
.  Freie Universitaet Berlin, Computer Science
.. http://www.cs.fu-berlin.de/~waehl
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Updates to the build system - modules definition

[Kaspar Schleiser]

Hi Dan,

On 11/29/2017 02:33 PM, Daniel Petry wrote:
> 1. The current build system isn't suitable to support the front end for
> RAPstore that Hendrik developed for his bachelor thesis, which requires
> that certain information can be displayed to the users.

I hear about this for the first time. Are there any pointers?

> 2. The current build system doesn't allow developers to easily include
> modules in their applications

USEMODULE += module_name?

> built can be affected by files/code outside the module directory
>   2.1 API changes as a result of including other modules aren't
> immediately visible in that module
>   2.2 API changes on other modules as a result of including that module
> isn't immediately visible
>   2.3 The complete build information for a module isn't localised only in
> the module directory

If modules are interdependent, they will affect each other. How can a
different module definition help here?

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

Re: [riot-devel] Open source best practices - Presentation

[Peter Kietzmann]

Hi Dan,

looking forward to that talk! It's been a while I read it but this
contribution might be interesting:"Experiences from a Decade of TinyOS
Development".

We'd like to join (remotely) from Hamburg. Usually we use PlaCam as
explained in [1] and -as you may know- recently we tried with
zoom [2].

Cheers
Peter


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


Am 29.11.2017 um 14:42 schrieb Daniel Petry:
> Hi all
> 
> I'm doing a presentation next Friday on open source best practices. As a
> newcomer in open source development, it was something I was interested
> in, and I thought it would help by informing future discussions on the
> way we do things as well.
> 
> I was wondering if anyone had any input to make the presentation more
> useful?
> 
> Specifically:
> 
> - Can you think of any case studies of prominent open source projects
> that are like RIOT, and have either succeeded or failed in a
> particularly notable manner?
> - Do you know of any particularly prominent studies or other literature
> on the subject, maybe which have analysed successes/failures and the
> reason for them over a large number of projects?
> - Do you have any suggestions for topics/areas of focus that would be
> particularly relevant to RIOT, and for what reason would the area of
> focus be relevant?
> - Is there anyone on other sites who would be interested in this
> presentation, and what tech do we usually use for live cross-site
> presentations if so?
> 
> Many thanks,
> 
> Dan.
> 
> ___
> 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

Re: [riot-devel] Open source best practices - Presentation

[Daniel Petry]

Just to clarify, the date of the presentation is 8 December.

Cheers

Dan.

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

[riot-devel] Test

[Martine Lenders]

Dan Petry was reporting, that none of his mails got through to devel, so
this is a test if there is a problem with this mailing list.

Please ignore this message, if it comes through ;-)

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

Re: [riot-devel] HIL testing

[Hauke Petersen]

Hi Peter,

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


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


Cheers,
Hauke

On 28.11.2017 09:21, Peter Kietzmann wrote:

Hi Hauke,

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

Best
Peter

Am 27.11.2017 um 18:33 schrieb Hauke Petersen:

Hi everyone,

in today's developer meeting the discussion passed by the topic of HIL
testing once again, this time in the context of the upcoming re-modeling
of the I2C interface. Some weeks ago I had an idea for a simple HIL
setup for automatically testing perihp/i2c drivers, and I promised to
share it (although it is in very very early state). So here it is.

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

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

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

triggers:

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

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

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

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

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

Cheers,
Hauke

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


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

Re: [riot-devel] RIOT developers monthly meeting

[Hauke Petersen]

HI Thomas,

I think the general idea here was to have the meeting on the day before 
Hack'n'Ack, which is as of now on a Tuesday.


Cheers,
Hauke

On 28.11.2017 19:01, Thomas Eichinger wrote:

Hi,

I forgot, but was there a particular reason having these on Mondays?

For me personally it would be easier to tune in any other day of the 
week. I’m just generally asking since my actual RIOT development 
availability is very limited anyways.


Best, Thomas

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



+1 on my side too.

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

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



Hi,



Hi,

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


+1


Cheers,
Martine

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


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

Francisco Acosta is inviting you to a scheduled Zoom meeting.

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

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


-- 
Francisco Javier Acosta Padilla

Research Engineer at INRIA Saclay
INFINE Team

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



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


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

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



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


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

Re: [riot-devel] HIL Testing

[Daniel Petry]

Hi

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

I have done it the other way around from what Hauke's doing it: I used a
master as the tester device, to develop the driver for a slave. The
driver was already implemented on the master, which was an Arduino, so I
just wrote a bunch of test cases (correct and incorrect message formats)
and then ran them on a loop on the Master with serial output onto my
computer. (No test logic on the computer, just text output.)

So I guess you could maybe use an Arduino as the slave and write some
basic tests using their "Wire" (basically, I2C) library?

I'm also doing something similar to this with uart testing. Will update
re thoughts on that once I've had more of a play around.

Cheers

Dan.

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

Re: [riot-devel] Updates to the build system - modules definition

[Daniel Petry]

Hi

> I wonder, what problems are we trying to solve?

The problems as I understand it are the following - Gaetan, please
correct me if I haven't got this quite right, or if there are additions!


1. The current build system isn't suitable to support the front end for
RAPstore that Hendrik developed for his bachelor thesis, which requires
that certain information can be displayed to the users. Information for
each module is not readily available in one place and in a format which
is parseable to human-readable text.
1.1 Information on other required modules is not readily available in a
common format
1.2 How the inclusion of modules changes functionality of other modules
is not readily available in a common format
1.3 Type of module is not readily available in a common format
1.4 Include path for applications that use the module is not readily
available in a common format


2. The current build system doesn't allow developers to easily include
modules in their applications, and they need to investigate
cross-dependencies etc. They have to look in a range of different places
rather than just one place to see what effects the inclusion of a module
has.
2.1 Any module API/functionality changes to modules as a result of
including other modules are difficult to find
2.2 Any other modules they need to include are difficult to find
2.3 The order in which they need to include the modules is difficult to
figure out
2.4 The CFLAGS that are added and whether they're global or local to a
module is difficult to figure out


3. The current build system doesn't allow developers to easily work on
modules. This includes creating new modules, or changing current
modules, either just to make them work or without introducing regression
bugs in related modules. This is because module code and the way they're
built can be affected by files/code outside the module directory
2.1 API changes as a result of including other modules aren't
immediately visible in that module
2.2 API changes on other modules as a result of including that module
isn't immediately visible
2.3 The complete build information for a module isn't localised only in
the module directory


@Gaetan, would you say this is the case or do you have any comments?

Maybe we could decide on the problems - i.e., refine/change this list -
before moving on to discuss solutions? A good target might be to decide
on the problems that need to be solved - i.e. the requirements - by a
week on Friday then go on to a design/development phase?


Dan.


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

[riot-devel] Open source best practices - Presentation

[Daniel Petry]

Hi all

I'm doing a presentation next Friday on open source best practices. As a
newcomer in open source development, it was something I was interested
in, and I thought it would help by informing future discussions on the
way we do things as well.

I was wondering if anyone had any input to make the presentation more
useful?

Specifically:

- Can you think of any case studies of prominent open source projects
that are like RIOT, and have either succeeded or failed in a
particularly notable manner?
- Do you know of any particularly prominent studies or other literature
on the subject, maybe which have analysed successes/failures and the
reason for them over a large number of projects?
- Do you have any suggestions for topics/areas of focus that would be
particularly relevant to RIOT, and for what reason would the area of
focus be relevant?
- Is there anyone on other sites who would be interested in this
presentation, and what tech do we usually use for live cross-site
presentations if so?

Many thanks,

Dan.

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