Re: [riot-devel] Improve Documentation

[Arndt, Josua]

Hi Gaëtan,

Basically the extraction if the information is the part I struggle with. As I 
have seen there is already a lot you can get when calling make BOARD=xxx and …

“ info-objsize info-buildsizes info-build info-boards-supported 
info-features-missing info-modules info-cpu  info-features-provided 
info-features-required
info-buildsizes info-buildsizes-diff info-features-missing 
info-boards-features-missing ”

But this results only in state information and not in what is where. With that 
it is not possible to generate a figure.


  1.  I would like to generate a graph like shown which represent the state of 
the compiled project, and displays which feature is implemented and “where”. To 
be able to compare implementations or to have one “How it should be” 
implementation and generate the Figure automatically when something changes.
  2.  I would be interested in Layer Stackup, and caller Graphs as it is not 
easy to understand where a packet is handled and when. And when a layer is 
removed or added like without “Thread protocol” and with “Thread protocol” …
  3.  A include graph for the Board and application shows the dependency
  4.  And so on …

I have not found out how to realize this, but I had no time to think about it.

Best regards,
Josua

Von: devel <devel-boun...@riot-os.org> Im Auftrag von Gaëtan Harter
Gesendet: Mittwoch, 14. März 2018 12:27
An: devel@riot-os.org
Betreff: Re: [riot-devel] Improve Documentation


Hi Josua,

it is also something I am interested in, not only an image but extracting 
informations on modules.

Could you put descriptive names on the informations you would be interested in?
And if you have some priorities in mind.

Also, if you have an example of something you wanted to know and had a hard 
time finding.

Regards,
Gaëtan
On 05.03.2018 12:06, Arndt, Josua wrote:
Joakim this sounds like you have some idea how to? Could you please elaborate?

Best regards,
Josua

Von: devel [mailto:devel-boun...@riot-os.org] Im Auftrag von Joakim Nohlgård
Gesendet: Donnerstag, 1. März 2018 16:42
An: RIOT OS kernel developers <devel@riot-os.org><mailto:devel@riot-os.org>
Betreff: Re: [riot-devel] Improve Documentation

I think this is certainly an interesting idea! You will probably not even need 
Doxygen for anything, plain graphviz (dot) is probably enough.

Best regards, Joakim

On Mar 1, 2018 16:21, "Arndt, Josua" 
<jar...@ias.rwth-aachen.de<mailto:jar...@ias.rwth-aachen.de>> wrote:
Hello all,

as we are working on the PR to bring the Jiminy board to mainline repo I had 
some problems to find where what is, or should be.
So I had the idea that a graph would help me visualize where which module is 
implemented.

Something like this.

[cid:image001.png@01D3BB99.6E26BFE0]

My idea was to maybe add a feature which uses doxygen to compile dot graphs for 
a test/application and board.

So when executing “make doc board=Bordname” in the folder test_spi then graphs 
for this project and board are created.
Maybe include graphs or such a Module, feature defines graph.

This would make it possible to just generate one graph for a test and add this 
to the depending readme or wiki page.
When implementing you could fastly grasp which feature are necessary and where 
they should be.

Also a comparison of the different cpu and boards could be done.
But for me the most important improvement would be I could build this for a 
board and fastly grasp where which feature is implemented.


This would also help newcomers to get a fast overview  of what is where.

Is there interest for such a feature? Does any one have an idea of how to best 
implement this?






___

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

[riot-devel] RPI border router with openlabs transceiver

[Arndt, Josua]

Hello all,

I just set up an RPI with this
https://github.com/RIOT-Makers/wpan-raspbian/wiki/Setup-native-6LoWPAN-router-using-Raspbian-and-RADVD

I have my devices joining the network and also can ping them.

What do I need to do to be able to ping the lowpan interface or the lowpan 
devices from a third host.
Is this already working, work in progress or abandoned?

Also the 6lowpan branch for radvd is at 2.13 as radvd proceeded to 2.17.
Did the changes made it to the main radvd branch?
Is it still required to use this branch or does it also work with the main 
branch of radvd.

Best regards
Josua


[rwth_ias_bild_rgb_logo]

Josua Arndt, M.Sc.
RWTH Aachen University
Integrated Analog Circuits and RF Systems
Kopernikusstraße 16, ICT Cube North, Room 209, D-52074 Aachen
Email: josua.ar...@ias.rwth-aachen.de
Phone: +49 241 / 80 - 27750



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

Re: [riot-devel] hwrnd how to implement

[Arndt, Josua]

Thanks Martine,

But as the atmegarfr2 is a soc this is the hwrng for this device.

So what would be the best place to put it if not as cpu/periph in this special 
case?

I would then implement it as CPU feature and remove the depency to the 
at86rf2xx driver.

Still the remaining question is it made sure that random32 calls or any calls 
to random are directed to hwrng_read
Is this already done by just enabling the module when building with 
FEATURES_REQUIRED = periph_hwrng ?


Von: devel <devel-boun...@riot-os.org> Im Auftrag von Martine Lenders
Gesendet: Montag, 5. März 2018 15:47
An: RIOT OS kernel developers <devel@riot-os.org>
Betreff: Re: [riot-devel] hwrnd how to implement

Hi Josua,

when the RNG component of the at86rf2xx driver was provided in [1] we decided 
to not implement the `periph/hwnrg` with it.
Main reasons are that it is

1. Not a `periph` (i.e. a CPU feature)
2. Hard to integrate when e.g. the CPU already provides a `hwnrg`.

Hope this helps,
Martine

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

2018-03-05 15:04 GMT+01:00 Arndt, Josua 
<jar...@ias.rwth-aachen.de<mailto:jar...@ias.rwth-aachen.de>>:
Hello all,

While implementing the at86rfr2 transceiver for the jiminy board I thought of 
also implement the hwrng.

What I did is implementing in cpu/atmega256rfr2/periph/hwnrg.c
hwrng_init
hwrng_read

Added feature and module to makefiles.

Now I have some questions:

  1.  How do I best include the depency to 
$(RIOTBASE)/drivers/at86rf2xx/include/at86rf2xx_internal.h, of hwrng.c in cpu 
folder?
  2.  How is it ensured that hardware random is used in all cases? And all 
other are not linked?
  3.  Where to find howto, concept description, implementation guide?

Best Regards
Josua
[rwth_ias_bild_rgb_logo]

Josua Arndt, M.Sc.
RWTH Aachen University
Integrated Analog Circuits and RF Systems
Kopernikusstraße 16, ICT Cube North, Room 209, D-52074 Aachen
Email: josua.ar...@ias.rwth-aachen.de<mailto:josua.ar...@ias.rwth-aachen.de>
Phone: +49 241 / 80 - 27750<tel:+49%20241%208027750>




___
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

[riot-devel] hwrnd how to implement

[Arndt, Josua]

Hello all,

While implementing the at86rfr2 transceiver for the jiminy board I thought of 
also implement the hwrng.

What I did is implementing in cpu/atmega256rfr2/periph/hwnrg.c
hwrng_init
hwrng_read

Added feature and module to makefiles.

Now I have some questions:

  1.  How do I best include the depency to 
$(RIOTBASE)/drivers/at86rf2xx/include/at86rf2xx_internal.h, of hwrng.c in cpu 
folder?
  2.  How is it ensured that hardware random is used in all cases? And all 
other are not linked?
  3.  Where to find howto, concept description, implementation guide?

Best Regards
Josua
[rwth_ias_bild_rgb_logo]

Josua Arndt, M.Sc.
RWTH Aachen University
Integrated Analog Circuits and RF Systems
Kopernikusstraße 16, ICT Cube North, Room 209, D-52074 Aachen
Email: josua.ar...@ias.rwth-aachen.de
Phone: +49 241 / 80 - 27750



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

[riot-devel] Improve Documentation

[Arndt, Josua]

Hello all,

as we are working on the PR to bring the Jiminy board to mainline repo I had 
some problems to find where what is, or should be.
So I had the idea that a graph would help me visualize where which module is 
implemented.

Something like this.

[cid:image002.png@01D3B177.3D74DD90]

My idea was to maybe add a feature which uses doxygen to compile dot graphs for 
a test/application and board.

So when executing "make doc board=Bordname" in the folder test_spi then graphs 
for this project and board are created.
Maybe include graphs or such a Module, feature defines graph.

This would make it possible to just generate one graph for a test and add this 
to the depending readme or wiki page.
When implementing you could fastly grasp which feature are necessary and where 
they should be.

Also a comparison of the different cpu and boards could be done.
But for me the most important improvement would be I could build this for a 
board and fastly grasp where which feature is implemented.


This would also help newcomers to get a fast overview  of what is where.

Is there interest for such a feature? Does any one have an idea of how to best 
implement this?

Best regards
Josua

[rwth_ias_bild_rgb_logo]

Josua Arndt, M.Sc.
RWTH Aachen University
Integrated Analog Circuits and RF Systems
Kopernikusstraße 16, ICT Cube North, Room 209, D-52074 Aachen
Email: josua.ar...@ias.rwth-aachen.de
Phone: +49 241 / 80 - 27750



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

[riot-devel] GCOAP Error from gnrc_sock_udp

[Arndt, Josua]

Hello I got an strange behavior when compiling the gcoap example. Maye someone 
has an idea.

I run Riot on an atxmega256a3u with an at86rf233.

When I compile with ENABLE_DEBUG (1) tin gcoap.c then everything works as 
expected and I am able to get .well-known/core information from the node.
But when I disable debug I always get the error -EPROTO  from gnrc_sock_udp.
Which checks

if (
(sock->remote.family != AF_UNSPEC) &&  /* check remote end-point if set 
*/
((sock->remote.port != byteorder_ntohs(hdr->src_port)) ||
/* We only have IPv6 for now, so just comparing the whole end point
 * should suffice */
((memcmp(>remote.addr, _addr_unspecified,
 sizeof(ipv6_addr_t)) != 0) &&
 (memcmp(>remote.addr, , sizeof(ipv6_addr_t)) != 0 {

With debug:
_recv_ieee802154: received packet from 18:c0:ff:ee:1a:c0:ff:ee of length 65
  6F  00  08  E0  8B  21  A5  00  00  00  00  00  00  00  00  00
0010  00  00  00  00  01  21  A5  00  00  00  00  00  00  20  28  3C
0020  DC  25  BB  61  3E  F0  81  3D  16  33  F2  6F  50  01  73  6A
0030  BB  2E  77  65  6C  6C  2D  6B  6E  6F  77  6E  04  63  6F  72
0040  65
_recv_ieee802154: reallocating.
Address Format specified unspecified 0, Format 0
Port 0 != 33085
IP good ipv6_addr_unspecified: 0
IP good tmp.addr: 1

Without Debug:
_recv_ieee802154: received packet from 18:c0:ff:ee:1a:c0:ff:ee of length 65
  6F  00  05  01  10  21  A5  00  00  00  00  00  00  00  00  00
0010  00  00  00  00  01  21  A5  00  00  00  00  00  00  20  28  3C
0020  DC  25  BB  61  3E  F0  83  5E  16  33  F0  4E  50  01  73  6A
0030  BB  2E  77  65  6C  6C  2D  6B  6E  6F  77  6E  04  63  6F  72
0040  65
_recv_ieee802154: reallocating.
Address Format specified unspecified 1, Format -29115
Port 41 != 33630
IP good ipv6_addr_unspecified: 1
IP good tmp.addr: 1

So the question is where are these values assigned to the sock, so I can 
investigate this further.
And what could cause this strange behavior.

Thanks in advance
Josua Arndt

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

[Arndt, Josua]

I just pushed it to my repo as it is, so you can have a look.

https://github.com/Josar/RIOT_XMEGA

I would suggest to implement the common functionality in the atxmega_common 
folder.
I have done the gpio, timer anf the uart but spi is still hard coded to my 
platform.

Von: devel [mailto:devel-boun...@riot-os.org] Im Auftrag von Arndt, Josua
Gesendet: Dienstag, 12. Dezember 2017 11:00
An: RIOT OS kernel developers <devel@riot-os.org>
Betreff: Re: [riot-devel] Atxmega Port with RIOT OS - Where to put abundance of 
new driver features?

I have a working port of an atxmega256a3u

I started to port it to a common folder maybe we could work something out
Von: devel [mailto:devel-boun...@riot-os.org] Im Auftrag von Madison McCarthy
Gesendet: Montag, 11. Dezember 2017 22:04
An: devel@riot-os.org<mailto:devel@riot-os.org>
Betreff: [riot-devel] Atxmega Port with RIOT OS - Where to put abundance of new 
driver features?

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

2) How should I implement the addition of both Master and Slave functionality 
to my peripheral interfaces?

3) How should I go about adding interrupt functionality for these peripherals?


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

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

[Arndt, Josua]

I have a working port of an atxmega256a3u

I started to port it to a common folder maybe we could work something out
Von: devel [mailto:devel-boun...@riot-os.org] Im Auftrag von Madison McCarthy
Gesendet: Montag, 11. Dezember 2017 22:04
An: devel@riot-os.org
Betreff: [riot-devel] Atxmega Port with RIOT OS - Where to put abundance of new 
driver features?

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

2) How should I implement the addition of both Master and Slave functionality 
to my peripheral interfaces?

3) How should I go about adding interrupt functionality for these peripherals?


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

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

[Arndt, Josua]

Yes it is but then all shells are disabled, not only that which I don’t need.

Von: devel [mailto:devel-boun...@riot-os.org] Im Auftrag von Martine Lenders
Gesendet: Montag, 4. Dezember 2017 15:10
An: RIOT OS kernel developers <devel@riot-os.org>
Betreff: Re: [riot-devel] 6lowpan Host with SLAAC, minimum ram

Hi,

This sounds awesome!

2017-12-04 15:05 GMT+01:00 Arndt, Josua 
<jar...@ias.rwth-aachen.de<mailto:jar...@ias.rwth-aachen.de>>:
> If there is demand for separately enabled shells I could do a PR, but this 
> needs to be also well  documented and I’m not quite sure which is the best 
> way.

Maybe I've missed something, but this is already possible by just deactivating 
the `shell_commands` module.

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

[Arndt, Josua]

Thanks all for your suggestions.



I used following configuration



CFLAGS += -DGNRC_PKTBUF_SIZE=512

CFLAGS += -DGNRC_IPV6_NETIF_ADDR_NUMOF=8

CFLAGS += - DGNRC_IPV6_NIB_NUMOF =1



CFLAGS += -DTHREAD_STACKSIZE_DEFAULT=512

CFLAGS += -DTHREAD_STACKSIZE_IDLE=129

CFLAGS += -DTHREAD_EXTRA_STACKSIZE_PRINTF=128



CFLAGS += -DAT86RF2XX_MAC_STACKSIZE=256

CFLAGS += -DGNRC_SIXLOWPAN_STACK_SIZE=512

CFLAGS += -DGNRC_IPV6_STACK_SIZE=512

CFLAGS += -DGNRC_RPL_STACK_SIZE=512



Yes basically the default values, as I try to touch as less as possible.



Compiling gnrc_network

AVR Memory Usage

Device: atmega256rfr2

Program:  113986 bytes (43.5% Full)

(.text + .data + .bootloader)

Data:  22334 bytes (68.2% Full)

(.data + .bss + .noinit)



I removed rpl as suggested and got a good step forward



Device: atmega256rfr2

Program:   88418 bytes (33.7% Full)

(.text + .data + .bootloader)

Data:  16047 bytes (49.0% Full)

(.data + .bss + .noinit)



I used some reges magic to change the shell_commands.c to seperatly enable 
schells for every module

And only used this shells:

CFLAGS += -DMODULE_GNRC_NETIF_SHELL_ENABLE

CFLAGS += -DMODULE_PS_SHELL_ENABLE

CFLAGS += -DMODULE_GNRC_ICMPV6_ECHO_SHELL_ENABLE



Device: atmega256rfr2

Program:   85956 bytes (32.8% Full)

(.text + .data + .bootloader)

Data:  15039 bytes (45.9% Full)

(.data + .bss + .noinit)



This is at least a good starting point  to be used with 16kbyte instead of 
32kbyte ram, and leaves some space for further optimization.



Running in on the xmega gives with all shell

AVR Memory Usage

Device: atxmega256a3u

Program:   97324 bytes (36.0% Full)

(.text + .data + .bootloader)

Data:  16154 bytes (98.6% Full)

(.data + .bss + .noinit)



And with only the above mentioned shells, reboot and udp
> help
Command  Description
---
udp  send data over UDP and listen on UDP ports
reboot Reboot the node
ps Prints information about running threads.
ping6   Ping via ICMPv6
ifconfigConfigure network interfaces

Device: atxmega256a3u
Program:   94906 bytes (35.1% Full)
(.text + .data + .bootloader)
Data:  15148 bytes (92.5% Full)
(.data + .bss + .noinit)

If there is demand for separately enabled shells I could do a PR, but this 
needs to be also well  documented and I'm not quite sure which is the best way.

As I tried several suggestions I would give a short result here

GNRC_PKTBUF_SIZE from 6KiB to 512

CFLAGS += -DGNRC_IPV6_NETIF_ADDR_NUMOF=5,  when reduced below 5 no global 
address is not accepted.

CFLAGS += -DGNRC_IPV6_NC_SIZE=1



Removed modules
#USEMODULE += gnrc_rpl
#USEMODULE += auto_init_gnrc_rpl
#USEMODULE += netstats_rpl

Thank you again.

[rwth_ias_bild_rgb_logo]

Josua Arndt, M.Sc.
RWTH Aachen University
Integrated Analog Circuits and RF Systems
Kopernikusstraße 16, ICT Cube North, Room 209, D-52074 Aachen
Email: josua.ar...@ias.rwth-aachen.de
Phone: +49 241 / 80 - 27750



___
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

[riot-devel] Jimini Board support announcement

[Arndt, Josua]

Hello All,

I'm happy to announce the support of a new board develop at the IAS of the RWTH 
Aachen. The initial PR is ongoing, it will be followed by driver and module PRs 
soon. Have a closer look at the wiki page to get an overview and insight of our 
development state.

A quick status: we have a working link to an RPI3 which has a Atmel transceiver 
board from Openlabs connected. It works as boarder router running radvd. As we 
are facing the problem of global IP drop as described in issue #5790 we decided 
to start pushing what we got, to also avoid parallel implementation.

While I was at it I did some changes to the wiki which a want to announce as it 
is proposed in the howto's.

  *   The addition of support for the Jimini board. Wiki page is added, PR is 
ongoing .

https://github.com/RIOT-OS/RIOT/wiki/Board%3A-Jiminy-atmega256rfr2

  *   Minor changes to the wiki page  eclipse added  7. Code convention  
configuration also provided an eclipse code style convention to import. 
(checks, amendment or improvement welcome)

https://github.com/RIOT-OS/RIOT/wiki/Using-the-Eclipse-IDE-for-C-and-CPP-Developers%2C-Howto

  *   sidebar changed to level structured Family/ Board layout to increase 
overview. (comments welcome) and added Jimini Board to ATmega family

https://github.com/RIOT-OS/RIOT/wiki

  *   Tabular for supported platforms, Minor changes to line break in tabular 
and consistency of Family Name

https://github.com/RIOT-OS/RIOT/wiki/RIOT-Platforms

  *   Added link to development procedure as tip under the porting guide

https://github.com/RIOT-OS/RIOT/wiki/Porting-Guide

Thank you all for working on Riot.
Especially all who help working through the PRs.

Best regards,
Josua Arndt
[rwth_ias_bild_rgb_logo]

Josua Arndt, M.Sc.
RWTH Aachen University
Integrated Analog Circuits and RF Systems
Kopernikusstraße 16, ICT Cube North, Room 209, D-52074 Aachen
Email: josua.ar...@ias.rwth-aachen.de
Phone: +49 241 / 80 - 27750



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