Re: [riot-devel] Working on port to SODAQ Autonomo (SAMD21)

[Kees Bakker]

On 13-06-16 09:56, Peter Kietzmann wrote:

Hi Kees,


Hi Peter,



nice to see your interest in RIOT! Find some comments inline.

Am 12.06.2016 um 21:14 schrieb Kees Bakker:

Hi,

This is a heads up to let you know I'm working on a port of
RIOT to SODAQ Autonomo, which has an Atmel samd21 (like
Arduino Zero).

First I moved the existing cpu/samd21 tree to cpu/samr21. Then


Why? Well *if* there is a need to change the current RIOT code base, 
you should open a separate PR for that.


That seems like a good aproach, but I asked  a related question before 
and I was
stuck with the answer. The answer was something like: the samr21 
processor is the same

as the samd21, so for RIOT that's good enough.



This is a question to all: How comes the Atmel samr21-xplained pro 
board has "samd21" CPU in RIOT?


I don't know the history of how it was added. I like to understand what 
happened
when cpu/samd21 was added. Where did the files come from? I'm guessing 
they're

from ASF 3.18 or 3.19. ASF => Atmel Software Framework




I added the samd21 CMSIS files from Arduino and the board files
for the SODAQ Autonomo. For that, I copied several files from
samr21-xpro.


What was wrong with current CMSIS headers?

https://github.com/RIOT-OS/RIOT/tree/master/cpu/samd21/include


Well, these files are from the samr21 tree in ASF, yes samr21, not samd21

SAMR21 and SAMD21 have the same cpu. But there are tens of derivatives. The
differences are in memory size (RAM, ROM), peripherals, etc. So if you 
select a

board, you also want to select the particular flavor of the SAMx21.

Another issue here is maintenance. How do we want to follow upgrades 
from Atmel?
New cpu variants, bug fixes, etc. The best would be to have the files in 
RIOT as close as

possible to the original. And a description somewhere how to do an upgrade.

To answer the question why I wanted to move cpu/samd21 to cpu/samr21, it is
basically driven by the need for SAMD21J18A.





In the process I learned how to use the Atmel-ICE and how to
debug via openocd. Nice :-)


Yepp :-)



At the moment I can step through the hello world example. But
I have no idea where the output is going. That's my next challenge.


By default the STDIO is mapped to UART_DEV(0) which will generally be 
the first device defined in the periph_conf.h file of the board. E.g.:


https://github.com/RIOT-OS/RIOT/blob/master/boards/samr21-xpro/include/periph_conf.h#L108 



The driver used should be common for samX21 MCUs but is currently not.

https://github.com/RIOT-OS/RIOT/blob/master/cpu/samd21/periph/uart.c

For Kinetis there already is a great code reusability:

https://github.com/RIOT-OS/RIOT/tree/master/cpu/kinetis_common/periph

However, you could try to set up a different STDIO UART device and 
connect an external UART/USB converter to see if it's about 
conflicting pins.


That is more or less already what I did. I filled in uart_config[] with 
two devices
and I have a serial line connect to my PC. This configuration works with 
the Arduino

setup. But not yet with RIOT.





Meanwhile the changes and additions are available in my fork at

 g...@github.com:keestux/RIOT-OS

Branch sodaq-autonomo.



Best
Peter




--
Kees Bakker
Founder
SODAQ
M. 0031617737165
www.sodaq.com

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

Re: [riot-devel] Working on port to SODAQ Autonomo (SAMD21)

[Kees Bakker]

On 15-06-16 09:32, Peter Kietzmann wrote:

Hi Kees,

if you volunteer you could start with moving code to samd21_common and 
open PR(s) for that :-).


Well, OK. I'll give it a try.

Seems like a step in the right direction. I personally won't find time 
for that unfortunately. On our side we could test your PR(s) with the 
samr21-xpro board and AFAIK Kaspar has a saml21-xpro board.


Do you have a "build farm" of some sorts? Or do you run tests manually?



Regarding the UART issue, could you give some more insights about the 
pad you want to add to uart_conf_t? I just gave it a quick look into 
the reference manual


http://www.atmel.com/images/atmel-42181-sam-d21_datasheet.pdf

but on the first sight I didn't see a difference to

http://www.atmel.com/Images/Atmel-42223%E2%80%93SAM-R21_Datasheet.pdf


My UART changes have nothing to do with samd21 versus samr21. It's about 
selecting a

pin for RX, TX.
For example, on Autonomo use pin PA10 for TX. PA10 is PAD2 of SERCOM0, 
with MUX C.

The samr21_xpro has PA4 as TX, PA4 is PAD0 of SERCOM0 (ALT) with MUX D.
--
Kees
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] cpu/samd21 is currently filled with SAMR21 files, not SAMD21

[Kees Bakker]

Well, then why does Atmel supply different trees for SAMR21 and SAMD21?
And why are the include files different? Not a whole lot, but still.

The CPU may be the same but there is (much) more than that.

Furthermore, the SAMD21 has several variants and so does the SAMR21. Each
have small difference in their specific include files. It feels very 
uncomfortable

to have just one "samd21" in RIOT.

So, if it was up to me, I would like to see that
* all files in cpu/samd21 are moved to cpu/samr21 (to make room for the 
real samd21 tree)
* some document is written explaining where these files came from 
(version, URL, etc)
* write up some procedure that describes what to do when the CMSIS 
source is updated (bug fixes, new release, etc)

* preferably no CMSIS files are changed, unless properly documented

BTW. Where are these CMSIS files coming from anyway? I see them in the 
Arduino Zero distribution too, but I
couldn't find them anywhere else on the web. They are from Atmel, but 
nothing on Atmel's website gives a clue.


On 24-04-16 18:59, Andrew Ruder wrote:

The SAMR21 is just a SAMD21 with several of the GPIOs and one of the SPI
buses internally connected to the at86rf233.  The CPU support would be
exactly the same.



--
Kees Bakker

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

[riot-devel] cpu/samd21 is currently filled with SAMR21 files, not SAMD21

[Kees Bakker]

Hi,

The files in cpu/samd21 are not really for SAMD21 but for SAMR21.
The two cpu variants are very similar but not quite the same.

The files in cpu/samd21 have been added because of the addition of
the samr21-xpro board.

I'm trying to figure out if I can add my board in RIOT. It is the SODAQ 
Autonomo

which is derived from Arduino Zero. It has an Atmel SAMD21J18A (Cortex M0).
Plus we have a new board, the LoRaONE which is a SAMD21G18A.

As said, the files currently in cpu/samd21 tree are meant for the SAMR21.
Now, if I wanted to add my SAMD21 boards, how should I proceed?

--
Kees Bakker

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

Re: [riot-devel] Is samr21-xpro SPI working

[Kees Bakker]

:-) I made a local change to the format of that message, using %lx 
because that way I can look
up the address in the data sheet. The last two hex digits are good 
enough for me to see that 17 is 23.


But yeah, the GPIO_PIN() is perhaps a better idea.

I am using an Atmel ICE that connects via openocd. I can single step 
through the code with gdb (from

Emacs). That way I can confirm that the CS line is indeed the expected PA23.


On 11-07-16 09:17, Peter Kietzmann wrote:

Hi Kees,

stupid question: How do you know SPI is not working? "GPIO_1090536471" 
was a formatting bug, compare:


https://github.com/RIOT-OS/RIOT/pull/5619

Would you try to initialize an other pin as CS line? If I see it 
correctly you decided for PA23. Maybe just try it with PB2 (in case 
you don't use it for other things).


Best
Peter


Am 08.07.2016 um 20:16 schrieb Kees Bakker:

This very same setup works perfectly with Arduino.
It is a SAMD21 on a Autonomo (very much like Arduine Zero).
It has a 16Mb "serial flash" chip on it.

I started with the code from cpu/samd21 that was developed for
the samr21-xpro board.

The "only" thing I had to change is the pins for the SPI. And with the
pins I also had to change the SERCOM, the PADs and the pin MUX.
And yes, I checked the SS pin (and all other pins) over and over.

So far I was able to get UART and I2C working. But for more than a
week now I am stuck at SPI. I use the tests/periph_spi test program.

�main(): This is RIOT! (Version:
2016.07-devel-336-g38dc1-rapper-add-sodaq-autonomo)

RIOT low-level SPI driver test
This application enables you to test a platforms SPI driver 
implementation.

Enter 'help' to get started

 > �main(): This is RIOT! (Version:
2016.07-devel-336-g38dc1-rapper-add-sodaq-autonomo)

RIOT low-level SPI driver test
This application enables you to test a platforms SPI driver 
implementation.

Enter 'help' to get started

 > help
Command  Description
---
init_master  Initialize node as SPI master
init_slave   Initialize node as SPI slave
send Transfer string to slave (only in master mode)
print_rx Print the received string (only in slave mode)
reboot   Reboot the node
 >
 > init_master 0 0 23
SPI_0 successfully initialized as master, cs: GPIO_1090536471, mode: 0,
speed: 2
 >
 > send
Transfered 5 bytes:
MOSI   01234
  0x9f 0x00 0x00 0x00 0x00
   ??   ??   ??   ??   ??

MISO   01234
  0xff 0xff 0xff 0xff 0xff
   ??   ??   ??   ??   ??

It drives me nuts. Any hint is greatly appreciated.
-- Kees

On 08-07-16 19:03, Baptiste Clenet wrote:

Autonomo  uses samd21 CPU? You use same driver as samr21?
What's your problem?
Are you sure your SPI Slave chip is working correctly?

2016-07-07 21:01 GMT+02:00 Kees Bakker <k...@sodaq.com>:

Ah, _now_ it makes sense. :-) Thanks for letting me know.

That leaves me with my own SPI problem. On my Autonomo I can't get
it to work. It is working with Arduino, but with RIOT (under
construction)
it's
not :-(



On 06-07-16 22:53, Baptiste Clenet wrote:

Yes I know, I changed it to make it work :)  (SPI1)

2016-07-06 22:48 GMT+02:00 Kees Bakker <k...@sodaq.com>:

OK thanks. However, your remark about SPI1 puzzles me a bit,
because it
was
using
an incorrect PAD setting. PR #5609 fixed today.


On 05-07-16 23:21, Baptiste Clenet wrote:

I can confirm that it works properly.
SPI is used to communicate with the transceiver on samr21-xpro and
communication works so SPI works, I used SPI1 also with no problem

2016-07-05 21:50 GMT+02:00 Kees Bakker <k...@sodaq.com>:

Hey,

Can someone confirm that SPI is working on the samr21-xpro board?

I'm trying to make SPI work on my Autonomo board, but I haven't
succeeded yet. FYI, I'm also reorganizing the code so there are a
lot
of parameters that can be of influence. I can't use the current 
code

because the pins and the SERCOMs are different.

It would help me to know that it works on samr21-xpro.

--
Kees Bakker
Founder
SODAQ
M. 0031617737165
www.sodaq.com

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




--
Kees Bakker
Founder
SODAQ
M. 0031617737165
www.sodaq.com

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





--
Kees Bakker
Founder
SODAQ
M. 0031617737165
www.sodaq.com

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











--
Kees Bakker
Founder
SODAQ
M. 0031617737165
www.sodaq.com

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

Re: [riot-devel] Is samr21-xpro SPI working

[Kees Bakker]

On 10-07-16 19:43, Kaspar Schleiser wrote:

Hey,

On 07/10/2016 01:13 PM, Kees Bakker wrote:

It drives me nuts. Any hint is greatly appreciated.

Do you have a logic analyzer?

No, I don't have one.
At some point I shall buy one, I guess. But that introduces new
challenges. The SPI signals are not easily accessible.

I've made good experiences with the cheap Saleae ones (I've been using
cheap remakes from ebay like [1]).

It's easy to hook them up between MCU and SPI-device, and they come with
simple but usable Linux software that can decode SPI signals.
Tremendously useful for spotting timing errors ...


Ah, thanks for the pointer. I'll have a look.


Kaspar

[1]
http://www.ebay.de/itm/24MHz-8-Channel-USB-Logic-Analyzer-8-CH-Logic-Analyzer-for-Arduino-MCU-/131840997125?hash=item1eb255f705:g:FEUAAOSwQupXVjOq
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel



--
Kees Bakker
Founder
SODAQ
M. 0031617737165
www.sodaq.com

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

Re: [riot-devel] Is samr21-xpro SPI working

[Kees Bakker]

It was staring me in the face but I didn't see it.
It was a wrong mux for the MOSI pin. I finally found by single stepping
through the Arduino code. Stupid mistake that took me almost a week :-)

Here's proof.

> init_master 0 0 23
SPI_0 successfully initialized as master, cs: GPIO_0x41004417, mode: 0, 
speed: 2

>
> send
Transfered 5 bytes:
MOSI   01234
 0x9f 0x00 0x00 0x00 0x00
  ??   ??   ??   ??   ??

MISO   01234
 0xff 0x1f 0x26 0x00 0x01
  ??   ??&   ??   ??


Anyway, I have to tidy up the code and then I consider the Autonomo ready
for RIOT.


On 11-07-16 09:17, Peter Kietzmann wrote:

Hi Kees,

stupid question: How do you know SPI is not working? "GPIO_1090536471" 
was a formatting bug, compare:


https://github.com/RIOT-OS/RIOT/pull/5619

Would you try to initialize an other pin as CS line? If I see it 
correctly you decided for PA23. Maybe just try it with PB2 (in case 
you don't use it for other things).


Best
Peter


Am 08.07.2016 um 20:16 schrieb Kees Bakker:

This very same setup works perfectly with Arduino.
It is a SAMD21 on a Autonomo (very much like Arduine Zero).
It has a 16Mb "serial flash" chip on it.

I started with the code from cpu/samd21 that was developed for
the samr21-xpro board.

The "only" thing I had to change is the pins for the SPI. And with the
pins I also had to change the SERCOM, the PADs and the pin MUX.
And yes, I checked the SS pin (and all other pins) over and over.

So far I was able to get UART and I2C working. But for more than a
week now I am stuck at SPI. I use the tests/periph_spi test program.

�main(): This is RIOT! (Version:
2016.07-devel-336-g38dc1-rapper-add-sodaq-autonomo)

RIOT low-level SPI driver test
This application enables you to test a platforms SPI driver 
implementation.

Enter 'help' to get started

 > �main(): This is RIOT! (Version:
2016.07-devel-336-g38dc1-rapper-add-sodaq-autonomo)

RIOT low-level SPI driver test
This application enables you to test a platforms SPI driver 
implementation.

Enter 'help' to get started

 > help
Command  Description
---
init_master  Initialize node as SPI master
init_slave   Initialize node as SPI slave
send Transfer string to slave (only in master mode)
print_rx Print the received string (only in slave mode)
reboot   Reboot the node
 >
 > init_master 0 0 23
SPI_0 successfully initialized as master, cs: GPIO_1090536471, mode: 0,
speed: 2
 >
 > send
Transfered 5 bytes:
MOSI   01234
  0x9f 0x00 0x00 0x00 0x00
   ??   ??   ??   ??   ??

MISO   01234
  0xff 0xff 0xff 0xff 0xff
   ??   ??   ??   ??   ??

It drives me nuts. Any hint is greatly appreciated.
-- Kees

On 08-07-16 19:03, Baptiste Clenet wrote:

Autonomo  uses samd21 CPU? You use same driver as samr21?
What's your problem?
Are you sure your SPI Slave chip is working correctly?

2016-07-07 21:01 GMT+02:00 Kees Bakker <k...@sodaq.com>:

Ah, _now_ it makes sense. :-) Thanks for letting me know.

That leaves me with my own SPI problem. On my Autonomo I can't get
it to work. It is working with Arduino, but with RIOT (under
construction)
it's
not :-(



On 06-07-16 22:53, Baptiste Clenet wrote:

Yes I know, I changed it to make it work :)  (SPI1)

2016-07-06 22:48 GMT+02:00 Kees Bakker <k...@sodaq.com>:

OK thanks. However, your remark about SPI1 puzzles me a bit,
because it
was
using
an incorrect PAD setting. PR #5609 fixed today.


On 05-07-16 23:21, Baptiste Clenet wrote:

I can confirm that it works properly.
SPI is used to communicate with the transceiver on samr21-xpro and
communication works so SPI works, I used SPI1 also with no problem

2016-07-05 21:50 GMT+02:00 Kees Bakker <k...@sodaq.com>:

Hey,

Can someone confirm that SPI is working on the samr21-xpro board?

I'm trying to make SPI work on my Autonomo board, but I haven't
succeeded yet. FYI, I'm also reorganizing the code so there are a
lot
of parameters that can be of influence. I can't use the current 
code

because the pins and the SERCOMs are different.

It would help me to know that it works on samr21-xpro.

--
Kees Bakker
Founder
SODAQ
M. 0031617737165
www.sodaq.com

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




--
Kees Bakker
Founder
SODAQ
M. 0031617737165
www.sodaq.com

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





--
Kees Bakker
Founder
SODAQ
M. 0031617737165
www.sodaq.com

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











--
Kees Bakker
Founder
SODAQ
M. 0031617737165
www.sodaq.com

___

[riot-devel] LITTLE_ENDIAN conflicts

[Kees Bakker]

What is the story of LITTLE_ENDIAN?

Recently a change was made in cpu/samd21 and cpu/saml21. The include
files from Atmel contain
#define LITTLE_ENDIAN   1
But it was changed to surround it with #ifndef / #endif

Commits: d2e8efc6, 7275f98
Is it too late to say that I don't like them? What problem was being 
solved by adding

the #ifndef/#endif ?

BTW.
I'm about to add a whole bunch of samXYZ.h files that all have that same 
define set.

And I'm also planning to update the existing include files.

And this process of updates and additions may happen again in the (near) 
future

when we want to update these Atmel CMSIS files.

--
Kees Bakker
Founder
SODAQ
M. 0031617737165
www.sodaq.com

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

Re: [riot-devel] Byte array should be uint8_t, not char

[Kees Bakker]

Hi Ludwig,

Well, it will be a challenge to smootly correct this.
There are 16 CPU's that use spi_transfer_byte(s) and 6 drivers.

I won't mind creating a PR, but of course I can only test it by building
examples for all boards that support SPI. And look at compile errors. Or are
there other procedures?

On 04-07-16 07:23, Ludwig Knüpfer wrote:

Hi Kees,

Unless there is a good reason to deviate from this guideline all violations 
should be corrected. This particular rule was added relatively recently, so it 
would not surprise me if not all occurrences in RIOT have been adapted yet.

Cheers,
Ludwig

Am 3. Juli 2016 22:50:10 MESZ, schrieb Kees Bakker <k...@sodaq.com>:

Hi,

The Coding Convention is clear about it.

"Guidelines for pointer types (as long as it is reasonable):

  * use |char *| for strings and only for strings
* use |uint8_t[]| as type for arbitrary byte buffers, but use |void *|
to pass them around. |uint8_t[]| because we're dealing with bytes
and not characters, |void *| to avoid unnecessary casting shall the
need arise to have their content to have a certain type
  * use |uint8_t *| to pass "typed" byte buffers, e.g., link-layer
addresses, where it avoids unnecessary temporary variable
  * use |void *| for generic typing"


In the SPI driver however the transfer functions use char * parameters,

but SPI is usually dealing with binary
information (bytes), not strings. This leads to unnecessary casts in
other parts of the code. (E.g. nvram_spi).

What is our policy about this? Are we going to correct this at some
point? Is it too late already (I hope not)?

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



--
Kees Bakker
Founder
SODAQ
M. 0031617737165
www.sodaq.com

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

Re: [riot-devel] Is samr21-xpro SPI working

[Kees Bakker]

This very same setup works perfectly with Arduino.
It is a SAMD21 on a Autonomo (very much like Arduine Zero).
It has a 16Mb "serial flash" chip on it.

I started with the code from cpu/samd21 that was developed for
the samr21-xpro board.

The "only" thing I had to change is the pins for the SPI. And with the
pins I also had to change the SERCOM, the PADs and the pin MUX.
And yes, I checked the SS pin (and all other pins) over and over.

So far I was able to get UART and I2C working. But for more than a
week now I am stuck at SPI. I use the tests/periph_spi test program.

�main(): This is RIOT! (Version: 
2016.07-devel-336-g38dc1-rapper-add-sodaq-autonomo)


RIOT low-level SPI driver test
This application enables you to test a platforms SPI driver implementation.
Enter 'help' to get started

> �main(): This is RIOT! (Version: 
2016.07-devel-336-g38dc1-rapper-add-sodaq-autonomo)


RIOT low-level SPI driver test
This application enables you to test a platforms SPI driver implementation.
Enter 'help' to get started

> help
Command  Description
---
init_master  Initialize node as SPI master
init_slave   Initialize node as SPI slave
send Transfer string to slave (only in master mode)
print_rx Print the received string (only in slave mode)
reboot   Reboot the node
>
> init_master 0 0 23
SPI_0 successfully initialized as master, cs: GPIO_1090536471, mode: 0, 
speed: 2

>
> send
Transfered 5 bytes:
MOSI   01234
 0x9f 0x00 0x00 0x00 0x00
  ??   ??   ??   ??   ??

MISO   01234
 0xff 0xff 0xff 0xff 0xff
  ??   ??   ??   ??   ??

It drives me nuts. Any hint is greatly appreciated.
-- Kees

On 08-07-16 19:03, Baptiste Clenet wrote:

Autonomo  uses samd21 CPU? You use same driver as samr21?
What's your problem?
Are you sure your SPI Slave chip is working correctly?

2016-07-07 21:01 GMT+02:00 Kees Bakker <k...@sodaq.com>:

Ah, _now_ it makes sense. :-) Thanks for letting me know.

That leaves me with my own SPI problem. On my Autonomo I can't get
it to work. It is working with Arduino, but with RIOT (under construction)
it's
not :-(



On 06-07-16 22:53, Baptiste Clenet wrote:

Yes I know, I changed it to make it work :)  (SPI1)

2016-07-06 22:48 GMT+02:00 Kees Bakker <k...@sodaq.com>:

OK thanks. However, your remark about SPI1 puzzles me a bit, because it
was
using
an incorrect PAD setting. PR #5609 fixed today.


On 05-07-16 23:21, Baptiste Clenet wrote:

I can confirm that it works properly.
SPI is used to communicate with the transceiver on samr21-xpro and
communication works so SPI works, I used SPI1 also with no problem

2016-07-05 21:50 GMT+02:00 Kees Bakker <k...@sodaq.com>:

Hey,

Can someone confirm that SPI is working on the samr21-xpro board?

I'm trying to make SPI work on my Autonomo board, but I haven't
succeeded yet. FYI, I'm also reorganizing the code so there are a lot
of parameters that can be of influence. I can't use the current code
because the pins and the SERCOMs are different.

It would help me to know that it works on samr21-xpro.

--
Kees Bakker
Founder
SODAQ
M. 0031617737165
www.sodaq.com

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




--
Kees Bakker
Founder
SODAQ
M. 0031617737165
www.sodaq.com

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





--
Kees Bakker
Founder
SODAQ
M. 0031617737165
www.sodaq.com

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






--
Kees Bakker
Founder
SODAQ
M. 0031617737165
www.sodaq.com

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

Re: [riot-devel] Is samr21-xpro SPI working

[Kees Bakker]

OK thanks. However, your remark about SPI1 puzzles me a bit, because it 
was using

an incorrect PAD setting. PR #5609 fixed today.

On 05-07-16 23:21, Baptiste Clenet wrote:

I can confirm that it works properly.
SPI is used to communicate with the transceiver on samr21-xpro and
communication works so SPI works, I used SPI1 also with no problem

2016-07-05 21:50 GMT+02:00 Kees Bakker <k...@sodaq.com>:

Hey,

Can someone confirm that SPI is working on the samr21-xpro board?

I'm trying to make SPI work on my Autonomo board, but I haven't
succeeded yet. FYI, I'm also reorganizing the code so there are a lot
of parameters that can be of influence. I can't use the current code
because the pins and the SERCOMs are different.

It would help me to know that it works on samr21-xpro.

--
Kees Bakker
Founder
SODAQ
M. 0031617737165
www.sodaq.com

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






--
Kees Bakker
Founder
SODAQ
M. 0031617737165
www.sodaq.com

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

[riot-devel] Progress of port to SODAQ Autonomo

[Kees Bakker]

Despite the ongoing discussion of how cpu/sam* should be configured
I am continuing with my effort to port RIOT to SODAQ Autonomo.

The changes are available in my add-sodaq-autonomo branch
at g...@github.com:keestux/RIOT.git

UART and I2C are working now, and so is xtimer. Next on my list is SPI.

For I2C there are a few changes in gpio that make the code simpler
and configuration easier to understand. (At least, that's what I think :-)

Coding.
While going through the code I notice that there are too many "magic"
constants. Hard coded numbers that are obvious for some, but not obvious
for others. My advise: always try to use defines and add a comment about
what constants mean. Or point to datasheet sections explaining the 
constants.


One example (not to blame, but to hopefully improve in the future).

cpu/samd21/cpu.c:
/* redirect all peripherals to a disabled clock generator (7) by 
default */

for (int i = 0x3; i <= 0x22; i++) {
What is that 0x22? It probably is SAMR21's GCLK_PTC, the last non-reserved
Generic Clock Selection ID. BTW, the last non-reserved ID for SAMD21 is 0x24
which is GCLK_I2S_1.
This particular should probable disable all peripherals, even the 
reserved ones.

But the point is, the number 0x22 should explained.

--
Kees Bakker
Founder
SODAQ
M. 0031617737165
www.sodaq.com

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

[riot-devel] Byte array should be uint8_t, not char

[Kees Bakker]

Hi,

The Coding Convention is clear about it.

"Guidelines for pointer types (as long as it is reasonable):

 * use |char *| for strings and only for strings
 * use |uint8_t[]| as type for arbitrary byte buffers, but use |void *|
   to pass them around. |uint8_t[]| because we're dealing with bytes
   and not characters, |void *| to avoid unnecessary casting shall the
   need arise to have their content to have a certain type
 * use |uint8_t *| to pass "typed" byte buffers, e.g., link-layer
   addresses, where it avoids unnecessary temporary variable
 * use |void *| for generic typing"


In the SPI driver however the transfer functions use char * parameters, 
but SPI is usually dealing with binary
information (bytes), not strings. This leads to unnecessary casts in 
other parts of the code. (E.g. nvram_spi).


What is our policy about this? Are we going to correct this at some 
point? Is it too late already (I hope not)?


--
Kees Bakker
Founder
SODAQ
M. 0031617737165
www.sodaq.com

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

[riot-devel] Support for SODAQ Autonomo was added

[Kees Bakker]

Hi,

It is my pleasure to announce that a new board is supported in RIOT, 
SODAQ Autonomo.
The board has many similarities to the Arduino Zero, so it shouldn't be 
too hard to get
that board supported as well. If anyone feels the need to pick that up, 
be my guest.
Meanwhile I'll continue to work on improving the support of my own 
board. And all

the devices that I'm interested in, such as:
 * data flash AT45DB161
 * SODAQ 3G/2G (Bee slot device with UBlox modem)
 * BME280

--
Kees Bakker
Founder
SODAQ
M. 0031617737165
www.sodaq.com

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

Re: [riot-devel] Byte array should be uint8_t, not char

[Kees Bakker]

Hi Joakim,

I've done a PR for SPI. https://github.com/RIOT-OS/RIOT/pull/5901
If you have a chance, can you have a look at it/

What this set of changes shows is that several developers have been
inserting casts to be able to get SPI code compile without errors. These 
casts

(from uint8_t to char) are now not needed anymore.

Yes, there were quite a few files to be modified, but the changes were 
straightforward.
I even patched a patch file :-) See 
pkg/u8g2/patches/0002-u8g2-add-riot-os-interface.patch

-- Kees

On 17-07-16 18:40, Joakim Nohlgård wrote:

Hi Kees,
Do you have the time/energy to resume the effort of updating the 
periph/spi interface in where Hauke left off in 
https://github.com/RIOT-OS/RIOT/pull/4780?


There are a lot of device drivers which need updating, and also some 
existing comments on the PR.


I can assist in reviewing the changes and updating device drivers, but 
I don't have a lot of time to spend on this right now.


Best regards,
Joakim

On Wed, Jul 6, 2016 at 7:00 AM, Ludwig Knüpfer 
<ludwig.knuep...@fu-berlin.de <mailto:ludwig.knuep...@fu-berlin.de>> 
wrote:


Hi Kees,

I assume there are more violations than the ones in the SPI
drivers... But of course every step forward is great!

Testing can be done by the community. We have plans to create a
distributed test system with actual hardware attached, but sadly
that has not become reality yet.

Compilation can be tested automatically by running `make
buildtest` for the respective test application (tests/periph_spi).

Cheers,
Ludwig

Am 5. Juli 2016 21:31:49 MESZ, schrieb Kees Bakker <k...@sodaq.com
<mailto:k...@sodaq.com>>:
>Hi Ludwig,
>
>Well, it will be a challenge to smootly correct this.
>There are 16 CPU's that use spi_transfer_byte(s) and 6 drivers.
>
>I won't mind creating a PR, but of course I can only test it by
>building
>examples for all boards that support SPI. And look at compile errors.
>Or are
>there other procedures?
>
>On 04-07-16 07:23, Ludwig Knüpfer wrote:
>> Hi Kees,
>>
>> Unless there is a good reason to deviate from this guideline all
>violations should be corrected. This particular rule was added
>relatively recently, so it would not surprise me if not all
occurrences
>in RIOT have been adapted yet.
    >>
>> Cheers,
>> Ludwig
>>
>> Am 3. Juli 2016 22:50:10 MESZ, schrieb Kees Bakker
<k...@sodaq.com <mailto:k...@sodaq.com>>:
>>> Hi,
>>>
>>> The Coding Convention is clear about it.
>>>
>>> "Guidelines for pointer types (as long as it is reasonable):
>>>
>>>   * use |char *| for strings and only for strings
>>> * use |uint8_t[]| as type for arbitrary byte buffers, but use
|void
>*|
>>> to pass them around. |uint8_t[]| because we're dealing with
>bytes
>>> and not characters, |void *| to avoid unnecessary casting
shall
>the
>>> need arise to have their content to have a certain type
>>>   * use |uint8_t *| to pass "typed" byte buffers, e.g., link-layer
>>> addresses, where it avoids unnecessary temporary variable
>>>   * use |void *| for generic typing"
>>>
>>>
>>> In the SPI driver however the transfer functions use char *
>parameters,
>>>
>>> but SPI is usually dealing with binary
>>> information (bytes), not strings. This leads to unnecessary
casts in
>>> other parts of the code. (E.g. nvram_spi).
>>>
>>> What is our policy about this? Are we going to correct this at
some
>>> point? Is it too late already (I hope not)?
>> ___
>> devel mailing list
>> devel@riot-os.org <mailto:devel@riot-os.org>
>> https://lists.riot-os.org/mailman/listinfo/devel
>
>
>--
>Kees Bakker
>Founder
>SODAQ
>M. 0031617737165
>www.sodaq.com <http://www.sodaq.com>
>
>___
>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



--
Kees Bakker
Founder
SODAQ
M. 0031617737165
www.sodaq.com

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

Re: [riot-devel] bitfeilds

[Kees Bakker]

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

Hi,

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


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

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

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

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


which could use bitfields and be written like this

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

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

Re: [riot-devel] bitfeilds

[Kees Bakker]

On 30-10-16 10:55, Juergen Stuber wrote:

On Fri, 28 Oct 2016 10:03:17 +0200
Juergen Stuber  wrote:

When you use shift and mask you usually do a single access for
all fields of a register.

Note that you shouldn't do it in two assignments
(I'm seeing this in cpu/stm32l1/periph/gpio.c):

 port &= ~mask;
 port |= (new_value << shift);

This will result in bigger code and the first assignment will write a
spurious value to the register, which might cause problems.

 port = (port & ~mask) | (new_value << shift);

is better. Or

 port = (port & ~mask)
  | (new_value1 << shift1)
 ...
  | (new_valueN << shiftN);

for multiple fields.


True.

But this would not be a good example for (named) bitfields, because
in this example the bitfield is dynamic. (Depends on runtime value of
pin number.)
--
Kees
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] BIN FILES

[Kees Bakker]

Yes, I have one, and I use it to burn and to debug.
I'm using openocd.

What do you want to know?

On 03-11-16 16:25, Ilias Seitanidis wrote:

Hi again,
I was given an Atmel Ice device, has anyone used it?
Thank you in advance!

Your Faithfully,
Ilias Seitanidis

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


Hi Ilias!

On Fri, Oct 07, 2016 at 03:51:48PM +0200, Ilias Seitanidis wrote:
> The problem is that I have a board based on samr21 but there is
no edbg usb
> port, on the datasheet it mentions only
> reprogramming using a usb pen drive and a .bin file, I know
nothing about
> the bootloader.

In this case, Joakim's advice should work. I think a similar trick
is used for
the mbed_lpc1768.

Cheers,
Oleg
--
Yo mamma is so fat that she sat on a binary tree and made it a
linked list in
constant time.

___
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



--
Kees Bakker
Founder
SODAQ
M. 0031617737165
www.sodaq.com

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

Re: [riot-devel] BIN FILES

[Kees Bakker]

To burn a program you only need the ELF file. No need to convert it to BIN.
Notice that I'm using a SODAQ Autonomo, with an Atmel SAMD21J18A. The 
openocd

command is:

  $ MYELF=tests/driver_bme280/bin/sodaq-autonomo/driver_bme280.elf
  $ openocd -d2 -f boards/sodaq-autonomo/dist/openocd.cfg -c 
"telnet_port disabled; init; halt; at91samd bootloader 0; program 
{{$MYELF}} verify reset; shutdown"


To be able to debug you must start openocd as a daemon waiting
for GDB to connect. (You are using GNU I hope. :-)

  $ openocd -d2 -f boards/sodaq-autonomo/dist/openocd.cfg -c "init; 
halt; at91samd bootloader 0"


Then start gdb with the ELF file.

  $ arm-none-eabi-gdb -i=mi 
tests/driver_bmp180/bin/sodaq-autonomo/driver_bmp180.elf


In gdb you first connect to the target, give it a reset, set breakpoints 
and give it a go.


  (gdb) target remote localhost:
  (gdb) monitor reset halt
  (gdb) b main
  (gdb) c

And of course, YMMV


On 06-11-16 21:08, Ilias Seitanidis wrote:


Thank you very much for your reply! I'm starting from scratch on using 
an external debugger. Everything is valuable :)



On Nov 6, 2016 20:30, "Kees Bakker" <k...@sodaq.com 
<mailto:k...@sodaq.com>> wrote:


Yes, I have one, and I use it to burn and to debug.
I'm using openocd.

What do you want to know?

On 03-11-16 16:25, Ilias Seitanidis wrote:

Hi again,
I was given an Atmel Ice device, has anyone used it?
Thank you in advance!

Your Faithfully,
Ilias Seitanidis

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

Hi Ilias!

On Fri, Oct 07, 2016 at 03:51:48PM +0200, Ilias Seitanidis wrote:
> The problem is that I have a board based on samr21 but
there is no edbg usb
> port, on the datasheet it mentions only
> reprogramming using a usb pen drive and a .bin file, I know
nothing about
> the bootloader.

In this case, Joakim's advice should work. I think a similar
trick is used for
the mbed_lpc1768.

Cheers,
Oleg
--
Yo mamma is so fat that she sat on a binary tree and made it
a linked list in
constant time.

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


-- 
Kees Bakker

Founder
SODAQ
M.0031617737165 
www.sodaq.com <http://www.sodaq.com>

___ 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

--
Kees Bakker
Founder
SODAQ
M. 0031617737165
www.sodaq.com
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Coding conventions amendment

[Kees Bakker]

On 14-10-16 10:05, Oleg Hahm wrote:

Hi Kees!

On Fri, Oct 14, 2016 at 08:05:51AM +0200, Kees Bakker wrote:

On 13-10-16 22:42, Kaspar Schleiser wrote:

On 10/13/2016 09:43 PM, Kees Bakker wrote:

Does anybody object to adding this to the coding

conventions explicitly?

What about `size_t`?

+1 for size_t

Well, any convention would need careful wording.

```
for (uint32_t timeout = 1; timeout < (10LU*1000*1000); timeout *= 2) {
if(try()) break;
}
```

... cannot blindly by convention converted to size_t as loop variable.

Of course not.
But I believe the question was more, in case of an unsigned type,
should we use "unsigned int" or size_t. In that case I would go for size_t.

No, the initial question was whether we should recommend (unsigned) int (or
(s)size_t) as loop iterator variable types.


OK. In that case I wouldn't recommend anything.

--
Kees Bakker
Founder
SODAQ
M. 0031617737165
www.sodaq.com

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

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

[Kees Bakker]

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);

--
Kees Bakker
Founder
SODAQ
M. 0031617737165
www.sodaq.com

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

Re: [riot-devel] Coding conventions amendment

[Kees Bakker]

On 13-10-16 22:42, Kaspar Schleiser wrote:

Hi,

On 10/13/2016 09:43 PM, Kees Bakker wrote:

Does anybody object to adding this to the coding

conventions explicitly?

What about `size_t`?

+1 for size_t

Well, any convention would need careful wording.

```
for (uint32_t timeout = 1; timeout < (10LU*1000*1000); timeout *= 2) {
if(try()) break;
}
```

... cannot blindly by convention converted to size_t as loop variable.


Of course not.
But I believe the question was more, in case of an unsigned type,
should we use "unsigned int" or size_t. In that case I would go for size_t.


IMHO this example also answers Oleg's initial concern: sometimes int or
unsigned int or size_t just don't work.


Sure.

--
Kees Bakker
Founder
SODAQ
M. 0031617737165
www.sodaq.com

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

Re: [riot-devel] End of I2C embargo

[Kees Bakker]

Great! This is quite an achievement, and something to be proud of.

On 02-08-18 12:49, Dylan Laduranty wrote:

Dear RIOTers,

The I2C rework is now merged into RIOT's master branch, then I am 
really happy to announce you the end of the I2C embargo ! Don't 
hesitate to ping pending PRs that were blocked by this embargo so 
maintainers can have a look at it.


This rework will not be present in the 2018.07 release as we lack of 
time to get things merged, but you can use the master branch if you 
want to use it.


We also create a wiki page [1] to summarize the changes introduced by 
this rework. We will keep working to improve this documentation.


Of course, we cannot guarantee that the new I2C interface is 
completely bug-free. So if you encounter any errors, weird behaviour 
or if you have any questions, don't hesitate to send an email to the 
mailing list or create an issue on Github. We will continue to improve 
our work.


Finally, I would like to deeply thanks every people involved in this 
huge rework, thank you for your time and your hard will. I'm really 
proud of what we have done here ! You guys are amazing :)


Keep RIOTing !

[1] https://github.com/RIOT-OS/RIOT/wiki/I2C-rework

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

[riot-devel] Driver AT, what is the concept of process_urc

[Kees Bakker]

Hey,

First of all, who is the maintainer of driver_at? In other words,
who should I be asking questions about this driver?

I have a bunch of modems that I am considering to write drivers
for (SIM800/900, several Ublox).

There is this concept of URC, Unsolicited Response Code, that some of
the modems can emit. I don't quite grasp how this is supposed to work
with our AT driver. There are no examples or uses of the AT driver.

Before throwing in my first question, here is an excerpt of the Ublox
datasheet
    "The DCE/MT interface can operate in these modes:
• Command mode: the DCE waits for AT command instructions. The DCE 
interprets all the characters received
as commands to execute. The DCE may send responses back to the DTE 
indicating the outcome of the
command or further information without having received any commands by 
the DTE (e.g. unsolicited response
code - URC). Any communication in the command mode (in both directions) 
is terminated by the command

line termination character.
..."

The way I interpret this is that the device may or may not output URCs
after sending a command. And it is not clear to me in which order URCs
are mixed with the normal output.

To be able to handle both normal output and URC there must be a single
function that reads responses from the device and while doing so it should
handle URCs. In any case, our (SODAQ) Arduino libraries do it that way.

The function process_urc has a while loop that reads lines from the device,
it processes URCs, but it also throws away anything else. That doesn't feel
right. Or does it?

Is somebody using the AT driver? Is somebody using the URC facility?
--
Kees
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Driver AT, what is the concept of process_urc

[Kees Bakker]

On 13-08-18 10:04, Vincent Dupont wrote:

Hi Kees,

Le dimanche 12 août 2018 à 14:44 +0200, Kees Bakker a écrit :

On 10-08-18 09:10, Kaspar Schleiser wrote:

He Kees,

On 08/05/2018 01:20 PM, Kees Bakker wrote:

First of all, who is the maintainer of driver_at? In other words,
who should I be asking questions about this driver?

As I'm the original author, I'd consider myself the author, but
Vincent
has contributed a lot. Asking on this mailing list was probably the
best.
Sorry for the delayed answer.


Sorry for the late answer!

I also contributed to this driver indeed, and wrote this part
originally. The idea was to find a simple way to parse URC and let the
user code decide when to parse them. The design is inspired by the AT
parser from MBED.

My understanding of the documentations from u-blox is that in between
the command echo and OK, there should not be any URC other than for the
given command. So parsing them in background while not doing anything
else should be fine.

The use-case and design have been discussed in [1] with @maxvankessel
who use this code in combination with the ring indicator interrupt.

As Kaspar said before, I'm also sure URC handling could be improved but
this might need a big rework of the UART interface and would involve
threads, which so far are kept out of this driver.

Anyway, do not hesitate to open an issue or a PR if the current code is
not good enough for you.


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




I started an issue [1]. Let me know if this is a good way to approach
this.

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

Re: [riot-devel] Driver AT, what is the concept of process_urc

[Kees Bakker]

On 10-08-18 09:10, Kaspar Schleiser wrote:

He Kees,

On 08/05/2018 01:20 PM, Kees Bakker wrote:

First of all, who is the maintainer of driver_at? In other words,
who should I be asking questions about this driver?

As I'm the original author, I'd consider myself the author, but Vincent
has contributed a lot. Asking on this mailing list was probably the best.
Sorry for the delayed answer.



What would be the best medium for me to start shooting at it?
Shall I start an "issue", so that we can keep everything together?
--
Kees
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Driver AT, what is the concept of process_urc

[Kees Bakker]

Hi,

There wasn't any reaction to my question, so I'm trying again.
Or, should I be opening an issue at GitHub?

Besides my question about the handling of URCs, I'm quite curious
if there are people using the generic AT module.
-- Kees

On 05-08-18 13:20, Kees Bakker wrote:

Hey,

First of all, who is the maintainer of driver_at? In other words,
who should I be asking questions about this driver?

I have a bunch of modems that I am considering to write drivers
for (SIM800/900, several Ublox).

There is this concept of URC, Unsolicited Response Code, that some of
the modems can emit. I don't quite grasp how this is supposed to work
with our AT driver. There are no examples or uses of the AT driver.

Before throwing in my first question, here is an excerpt of the Ublox
datasheet
    "The DCE/MT interface can operate in these modes:
• Command mode: the DCE waits for AT command instructions. The DCE 
interprets all the characters received
as commands to execute. The DCE may send responses back to the DTE 
indicating the outcome of the
command or further information without having received any commands by 
the DTE (e.g. unsolicited response
code - URC). Any communication in the command mode (in both 
directions) is terminated by the command

line termination character.
..."

The way I interpret this is that the device may or may not output URCs
after sending a command. And it is not clear to me in which order URCs
are mixed with the normal output.

To be able to handle both normal output and URC there must be a single
function that reads responses from the device and while doing so it 
should

handle URCs. In any case, our (SODAQ) Arduino libraries do it that way.

The function process_urc has a while loop that reads lines from the 
device,
it processes URCs, but it also throws away anything else. That doesn't 
feel

right. Or does it?

Is somebody using the AT driver? Is somebody using the URC facility?


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

Re: [riot-devel] Eliminating casts

[Kees Bakker]

PR per driver sounds good to me.

The required change in tcs37727 indeed involves a bit more. But I hope that
everyone agrees that you cannot change a const object into a non-const
object.

Take a look at the doxygen. The param[in] is misleading, the object will 
be modified.

Ha, it even says so in the description.

/**
 * @brief   Read sensor's data
 *
 * Besides an Autogain routine is called. If a maximum or minimum threshold
 * value of the channel clear is reached, then the gain will be changed
 * correspond to max or min threshold.
 *
 * @param[in]  dev device descriptor of sensor
 * @param[out] data    device sensor data, MUST not be NULL
 */
void tcs37727_read(const tcs37727_t *dev, tcs37727_data_t *data);


On 26-12-18 23:29, Joakim Nohlgård wrote:
I agree with your arguments. Placing casts where they are not needed 
may introduce errors in a future refactoring where a variable changes 
type.
If you want your changes merged as smoothly as possible you should 
open a separate PR for each module you modify. It will make the review 
much easier. Stuff like the cc2420 change is going to get merged right 
away pretty much since it's obvious that there are no side effects.
The tcs37727 change requires more thought for the correct change to 
make and may lead to some review comments.


Best regards,
Joakim

Den ons 26 dec. 2018 23:17 skrev Kees Bakker <mailto:k...@sodaq.com>>:


Hey,

In general, I'm not happy with casts when they are not really needed.
A cast takes away an opportunity for the compiler to check things.
Sometimes a cast is there to get rid of "const". That's not good.
Sometimes a cast is there to get rid of "volatile". That's not
good either.

Suppose I make a Pull Request to eliminate casts, would that be
picked up?
Who would pick them up? Who decides if the PR is valid? What the
general
opinion about these sorts of PRs?

If you want examples, here are some, from various drivers.

8X8X---
void at86rf2xx_tx_exec(const at86rf2xx_t *dev)
{
 netdev_t *netdev = (netdev_t *)dev;
8X8X---

8X8X---
void kw2xrf_setup(kw2xrf_t *dev, const kw2xrf_params_t *params)
{
 netdev_t *netdev = (netdev_t *)dev;
8X8X---

8X8X---
static void _isr(netdev_t *netdev)
{
 ethos_t *dev = (ethos_t *) netdev;
 dev->netdev.event_callback((netdev_t*) dev,
NETDEV_EVENT_RX_COMPLETE);
8X8X---
Cast flipflop.

8X8X---
void tcs37727_read(const tcs37727_t *dev, tcs37727_data_t *data)
{
...
 tcs37727_trim_gain((tcs37727_t *)dev, tmpc);
8X8X---
Here tcs37727_trim_gain is actually modifying the const object. Bad.

8X8X---
 return cc2420_init((cc2420_t *)dev);
8X8X---
In this case, dev is already of that type.

In the Coding Conventions I like to see something written about casts.
I'm not sure exactly about the wording. Here is an attempt.

Casts
* Try to avoid casts (a bit vague, but it should get people's
attention)
* Introduce helper variables to avoid multiple casts within a function
* Don't cast a const pointer into a non-const pointer without an
explanation in a comment.
* Don't cast a pointer to a volatile object dropping the volatile
without an
explanation in a comment.
* ...
-- 
Kees

___
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] Eliminating casts

[Kees Bakker]

On 27-12-18 13:54, Kaspar Schleiser wrote:

Hi,

On 12/26/18 11:16 PM, Kees Bakker wrote:

Suppose I make a Pull Request to eliminate casts, would that be picked up?

Always welcome! +1 on Joakim's hint to keep the PR's small.

Sure

void at86rf2xx_tx_exec(const at86rf2xx_t *dev)
{
     netdev_t *netdev = (netdev_t *)dev;

What would be the way to go here? 'netdev_t netdev = >netdev;'?

Yes, please. It's already done in several drivers.

In this case, it won't work. Would need to recurse into
netdev_ieee802154_t, like 'netdev_t *netdev = >netdev.netdev;'.

That might be less error.prone, but more confusing. Unfortunately C is
not much help here.
Is it more confusing? I don't think so. Personally, I prefer the 
>netdev.netdev

above the (netdev_t *)dev.

Casts
* Try to avoid casts (a bit vague, but it should get people's attention)
* Introduce helper variables to avoid multiple casts within a function
* Don't cast a const pointer into a non-const pointer without an
explanation in a comment.
* Don't cast a pointer to a volatile object dropping the volatile
without an
explanation in a comment.
* ...

* use dereferenced superclass field instead of "blind" cast

(the netdev case above).

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] RN2xx3, MAC status stuck at 4

[Kees Bakker]

Hey Alexandre,

Sorry to bother you with a question about the RN2483.

I am playing with your rn2xx3 driver in RIOT, with the test program.
I have a test account at KPN and I have the necessary keys to send
messages. Joining ABP to keep it simple.

Here is something weird that I can't get right.
I'm sending a test message and it gets to my server alright. But the RN2483
gives a timeout on the TX command.

Next, the RN2483 goes into a state that I can't recover from. If I read the
MAC status (with a slightly modified driver), it gives
    0x000D
Meaning, 110 1
110 -> Ack_timeout
1 -> network joined

Then, after a while (several minutes) it goes to state 0x0009
Meaning, 100 1
100 -> Between Receive window 1 and Receive window 2
1 -> network joined

And it stays in that state forever. When I try a new message it fails
with an error "MAC state is in an Idle state".

Now, all that I can do is to do a reset. After that I can send again.

Would you have a hint as to what this can be?
--
Kees Bakker
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Eliminating casts

[Kees Bakker]

Hey,

In general, I'm not happy with casts when they are not really needed.
A cast takes away an opportunity for the compiler to check things.
Sometimes a cast is there to get rid of "const". That's not good.
Sometimes a cast is there to get rid of "volatile". That's not good either.

Suppose I make a Pull Request to eliminate casts, would that be picked up?
Who would pick them up? Who decides if the PR is valid? What the general
opinion about these sorts of PRs?

If you want examples, here are some, from various drivers.

8X8X---
void at86rf2xx_tx_exec(const at86rf2xx_t *dev)
{
    netdev_t *netdev = (netdev_t *)dev;
8X8X---

8X8X---
void kw2xrf_setup(kw2xrf_t *dev, const kw2xrf_params_t *params)
{
    netdev_t *netdev = (netdev_t *)dev;
8X8X---

8X8X---
static void _isr(netdev_t *netdev)
{
    ethos_t *dev = (ethos_t *) netdev;
    dev->netdev.event_callback((netdev_t*) dev, NETDEV_EVENT_RX_COMPLETE);
8X8X---
Cast flipflop.

8X8X---
void tcs37727_read(const tcs37727_t *dev, tcs37727_data_t *data)
{
...
    tcs37727_trim_gain((tcs37727_t *)dev, tmpc);
8X8X---
Here tcs37727_trim_gain is actually modifying the const object. Bad.

8X8X---
    return cc2420_init((cc2420_t *)dev);
8X8X---
In this case, dev is already of that type.

In the Coding Conventions I like to see something written about casts.
I'm not sure exactly about the wording. Here is an attempt.

Casts
* Try to avoid casts (a bit vague, but it should get people's attention)
* Introduce helper variables to avoid multiple casts within a function
* Don't cast a const pointer into a non-const pointer without an
explanation in a comment.
* Don't cast a pointer to a volatile object dropping the volatile without an
explanation in a comment.
* ...
--
Kees
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Hello world stopped working

[Kees Bakker]

Hey Alex,

Thanks, that did the trick. Wow, what happened with that compiler?
I now see that we have PR #10404 and a few issues about it. Hmm,
that PR could have given me a warning.
-- Kees

On 05-12-18 21:20, Alexandre Abadie wrote:

Hi Kees,

You need a more recent version of the GNU ARM compiler, 7.x, and you only have 
6.3. The recommended toolchain is the official one from ARM that can be 
downloaded at [1].

Just uncompress the archive somewhere in your filesystem (in /opt for example) 
and update your PATH variable. This is what I do and it works well.

Cheers!

Alex

[1] https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads

- Le 5 Déc 18, à 21:09, Kees Bakker k...@sodaq.com a écrit :


Hi,

This may sound like a stupid question, but I can't get output
from hello world anymore. On my Sodaq Explorer and also on my
Sodaq One.

I have been away from RIOT for a few weeks and now that I get back
there is no output on UART0, and the LEDs don't work either.

Since last time, I upgraded my Ubuntu to 18.04. It has a newer compiler.
Could that be it?

binutils-arm-none-eabi      2.27-9ubuntu1+9
gcc-arm-none-eabi      15:6.3.1+svn253039-1build1
gdb-arm-none-eabi      7.10-1ubuntu3+9
libnewlib-arm-none-eabi      2.4.0.20160527-3
libstdc++-arm-none-eabi-newlib      15:6.3.1+svn253039-1+10

If not, what else could it be? It must be something obvious, but
so far I haven't found it.
--
Kees
___
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] Hello world stopped working

[Kees Bakker]

Hi,

This may sound like a stupid question, but I can't get output
from hello world anymore. On my Sodaq Explorer and also on my
Sodaq One.

I have been away from RIOT for a few weeks and now that I get back
there is no output on UART0, and the LEDs don't work either.

Since last time, I upgraded my Ubuntu to 18.04. It has a newer compiler.
Could that be it?

binutils-arm-none-eabi      2.27-9ubuntu1+9
gcc-arm-none-eabi      15:6.3.1+svn253039-1build1
gdb-arm-none-eabi      7.10-1ubuntu3+9
libnewlib-arm-none-eabi      2.4.0.20160527-3
libstdc++-arm-none-eabi-newlib      15:6.3.1+svn253039-1+10

If not, what else could it be? It must be something obvious, but
so far I haven't found it.
--
Kees
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Hello world stopped working

[Kees Bakker]

:-) Thanks

I was also trying to find a way to report the conflict between the 
packages gcc-avr
and gcc-arm-embedded. It will be a tough one to get it recognized by the 
right people.



On 06-12-18 21:24, Ken Bannister wrote:

I replaced the package using this same approach. [1]

Ken

[1] https://github.com/RIOT-OS/RIOT/issues/9248#issuecomment-416532408


On 12/6/18 8:11 PM, Kees Bakker wrote:

For Ubuntu 18.04 there is a possibility to install the PPA. See [1].
What I did was to first remove (uninstall) all arm-none-eabi 
packages, and
I also had to uninstall the gcc-avr packages due to a conflict with 
/usr/lib/libcc1.so.0.0.0


Next, enable the PPA and install gcc-arm-embedded. That's it.

[1] https://launchpad.net/~team-gcc-arm-embedded/+archive/ubuntu/ppa

On 06-12-18 08:49, smlng wrote:

Hi all,

Joakim is right - there are several reports of broken/non-working 
firmwares

compiled with the arm-none-eabi-gcc and libs provided by Ubuntu:Bionic

see for instance:

- 
https://bugs.launchpad.net/ubuntu/+source/gcc-arm-none-eabi/+bug/1767223 


- https://bugs.launchpad.net/ubuntu/+source/newlib/+bug/1768125

That's why our riotdocker image (and with that the Murdock-CI) uses the
official releases instead of the apt-packages.

Best,
   Sebastian


On 6. Dec 2018, at 08:43, Joakim Nohlgård  wrote:

Hi,
I don't believe that we require GCC 7 anywhere, it should still work
fine to build with for example the ARM provided GCC 6 release, or the
older Ubuntu/Debian toolchains. It seemed more like there is a problem
with the Ubuntu packaged arm-none-eabi toolchain that produces broken
binaries.

/Joakim

On Wed, Dec 5, 2018 at 10:05 PM Kees Bakker  wrote:

Hey Alex,

Thanks, that did the trick. Wow, what happened with that compiler?
I now see that we have PR #10404 and a few issues about it. Hmm,
that PR could have given me a warning.
-- Kees

On 05-12-18 21:20, Alexandre Abadie wrote:

Hi Kees,

You need a more recent version of the GNU ARM compiler, 7.x, and 
you only have 6.3. The recommended toolchain is the official one 
from ARM that can be downloaded at [1].


Just uncompress the archive somewhere in your filesystem (in /opt 
for example) and update your PATH variable. This is what I do and 
it works well.


Cheers!

Alex

[1] 
https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads


- Le 5 Déc 18, à 21:09, Kees Bakker k...@sodaq.com a écrit :


Hi,

This may sound like a stupid question, but I can't get output
from hello world anymore. On my Sodaq Explorer and also on my
Sodaq One.

I have been away from RIOT for a few weeks and now that I get back
there is no output on UART0, and the LEDs don't work either.

Since last time, I upgraded my Ubuntu to 18.04. It has a newer 
compiler.

Could that be it?

binutils-arm-none-eabi  2.27-9ubuntu1+9
gcc-arm-none-eabi  15:6.3.1+svn253039-1build1
gdb-arm-none-eabi  7.10-1ubuntu3+9
libnewlib-arm-none-eabi  2.4.0.20160527-3
libstdc++-arm-none-eabi-newlib 15:6.3.1+svn253039-1+10

If not, what else could it be? It must be something obvious, but
so far I haven't found it.
--
Kees
___
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

___
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] Hello world stopped working

[Kees Bakker]

For Ubuntu 18.04 there is a possibility to install the PPA. See [1].
What I did was to first remove (uninstall) all arm-none-eabi packages, and
I also had to uninstall the gcc-avr packages due to a conflict with 
/usr/lib/libcc1.so.0.0.0


Next, enable the PPA and install gcc-arm-embedded. That's it.

[1] https://launchpad.net/~team-gcc-arm-embedded/+archive/ubuntu/ppa

On 06-12-18 08:49, smlng wrote:

Hi all,

Joakim is right - there are several reports of broken/non-working firmwares
compiled with the arm-none-eabi-gcc and libs provided by Ubuntu:Bionic

see for instance:

- https://bugs.launchpad.net/ubuntu/+source/gcc-arm-none-eabi/+bug/1767223
- https://bugs.launchpad.net/ubuntu/+source/newlib/+bug/1768125

That's why our riotdocker image (and with that the Murdock-CI) uses the
official releases instead of the apt-packages.

Best,
   Sebastian


On 6. Dec 2018, at 08:43, Joakim Nohlgård  wrote:

Hi,
I don't believe that we require GCC 7 anywhere, it should still work
fine to build with for example the ARM provided GCC 6 release, or the
older Ubuntu/Debian toolchains. It seemed more like there is a problem
with the Ubuntu packaged arm-none-eabi toolchain that produces broken
binaries.

/Joakim

On Wed, Dec 5, 2018 at 10:05 PM Kees Bakker  wrote:

Hey Alex,

Thanks, that did the trick. Wow, what happened with that compiler?
I now see that we have PR #10404 and a few issues about it. Hmm,
that PR could have given me a warning.
-- Kees

On 05-12-18 21:20, Alexandre Abadie wrote:

Hi Kees,

You need a more recent version of the GNU ARM compiler, 7.x, and you only have 
6.3. The recommended toolchain is the official one from ARM that can be 
downloaded at [1].

Just uncompress the archive somewhere in your filesystem (in /opt for example) 
and update your PATH variable. This is what I do and it works well.

Cheers!

Alex

[1] https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads

- Le 5 Déc 18, à 21:09, Kees Bakker k...@sodaq.com a écrit :


Hi,

This may sound like a stupid question, but I can't get output
from hello world anymore. On my Sodaq Explorer and also on my
Sodaq One.

I have been away from RIOT for a few weeks and now that I get back
there is no output on UART0, and the LEDs don't work either.

Since last time, I upgraded my Ubuntu to 18.04. It has a newer compiler.
Could that be it?

binutils-arm-none-eabi  2.27-9ubuntu1+9
gcc-arm-none-eabi  15:6.3.1+svn253039-1build1
gdb-arm-none-eabi  7.10-1ubuntu3+9
libnewlib-arm-none-eabi  2.4.0.20160527-3
libstdc++-arm-none-eabi-newlib  15:6.3.1+svn253039-1+10

If not, what else could it be? It must be something obvious, but
so far I haven't found it.
--
Kees
___
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] sched_active_thread is a volatile pointer, but volatile is ignored

[Kees Bakker]

On 08-01-19 16:10, Kaspar Schleiser wrote:

Hi Kees,

Hey Kaspar,

On 1/7/19 9:19 PM, Kees Bakker wrote:

My main concern is: who made it volatile in the first place?

I did, almost a decade ago.


And what was the reasoning behind it? Volatile is one of the least
understood properties of the C language (my personal opinion). I'm
hoping that the volatile was not just thrown in because it feels good
when doing threads. And in other places the volatile is ignored,
hopefully for a good reason (optimisation is _not_ a good reason).

IIRC the intention was so the IPC code would create read / write
accesses whenever accessing fields of thread_t.

E.g.:

void msg_recv(...)
{
if (!sched_active_thread->waiters) {
 // platform specific macro to suspend thread
}

thread_t *waiter = sched_active_thread->waiters;

// ...
}

(or similar)

My understanding of volatile back then was that the compiler could,
without volatile, assume that sched_active_thread->waiters equals NULL.
Well, in the example code, the compiler would just read 
sched_active_thread->waiters

once and keep it in a register. If either sched_active_thread or waiters
can change in between the uses in that function you must declare some
things volatile. What is also interesting here is to ask ourselves,
can sched_active_thread change in between? If so you would need to declare
that variable as
    thread_t * volatile sched_active_thread;
(( This was mentioned in one of the Github issues, but the discussion 
stalled. ))



This was certainly a case of only (at most) half-understanding volatile,

Which proves my point :-)

which then turned into "if it is not broken, don't fix it".

I'm not a fan of that. It is like looking away and hoping there
are no problems. No matter how hard it is, we need to fully
understand, especially a thing like a scheduler.


Nowadays such code is always guarded with disabled IRQs.

I seem to remember that we tried making sched_active_thread non-volatile
at some point, breaking things, but that has also been a long time ago.

I'm all for removing the qualifier. But we do have to make sure to
thoroughly test core/ on all platforms.



Of course we need thorough testing. Let's not rush. If I wanted to
experiment with volatile changes, what would be good test programs
for this?
--
Kees
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] sched_active_thread is a volatile pointer, but volatile is ignored

[Kees Bakker]

On 07-01-19 11:21, Juan Ignacio Carrano wrote:

Hi Kees,


Hey Juan,



On 1/4/19 10:18 PM, Kees Bakker wrote:


In a lot of our code sched_active_thread is converted into
a non-volatile pointer. Is that correct? Here [1] it is described
that such conversion is undefined behavior.


My understanding is that `sched_active_thread` is volatile in a thread 
context, but not in the kernel context. Therefore I thought that 
discarding the qualifier in code that runs in the scheduler should be 
OK, although a bit dirty. Now, if you tell me it's undefined behavior 
then it is NOT OK.


I had thought of two ways to fix this:

* Linker-level aliasing: define `sched_active_thread` once (in the 
scheduler, as non volatile) and declare it as `extern volatile` in 
those headers that are seen by user applications, and as `extern` in 
headers seen by the kernel.


* C-level aliasing: redefine sched_active_thread as a union of a 
volatile and non-volatile.


AFAICT neither of those ways of accessing should result in undefined 
behavior, as there as no casts being performed. What do you think?


My main concern is: who made it volatile in the first place? And what 
was the
reasoning behind it? Volatile is one of the least understood properties 
of the
C language (my personal opinion). I'm hoping that the volatile was not 
just thrown
in because it feels good when doing threads. And in other places the 
volatile is

ignored, hopefully for a good reason (optimisation is _not_ a good reason).

Your two alternatives result in basically the same situation as the 
casted pointer.

The problem will always be that we need someone to judge whether the cast
is correct (in the case of the union, do I need the volatile or the non 
volatile

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

[riot-devel] sched_active_thread is a volatile pointer, but volatile is ignored

[Kees Bakker]

Hey,

Sorry if this has been discussed in the past, I couldn't
find anything much about it.

In a lot of our code sched_active_thread is converted into
a non-volatile pointer. Is that correct? Here [1] it is described
that such conversion is undefined behavior.

Interestingly, there was an issue [2] which was closed with the following
remark:
  "Abandoned, since I don't think that there are two reviewers that 
understand the meaning of volatile."


Some more food for thought, from an artical by John Regehr [3]
  "Arch Robison says that volatile is almost useless for multi-threaded 
programming. [4]"


[1] https://en.cppreference.com/w/c/language/volatile
[2] https://github.com/RIOT-OS/RIOT/issues/252
[3] https://blog.regehr.org/archives/28
[4] 
http://software.intel.com/en-us/blogs/2007/11/30/volatile-almost-useless-for-multi-threaded-programming/

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

[riot-devel] What's the password of the user in RIOT-LORA-VM

[Kees Bakker]

Hey Alexandre,

It was nice to meet you at the RIOT event. Thanks for all the
work you put into this. For me it was also beneficial because
I never had much experience with LoRa, and with your tutorial
I learned about how to use the keys and such.

Anyway, what is the password of the user "user" in the VM?
--
Kees Bakker
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] SAM Flash Read-While-Write

[Kees Bakker]

Hey Federico,

Thanks for doing the flashpage stuff.
I have some SODAQ boards, basically all SAMD21, that I use
to run the flashpage test.
Unfortunately, the test program crashes for read_rwwee

main(): This is RIOT! (Version: 2019.04-devel-16-gc2c6f-sam_rwee_support)
ROM flash read write test

Please refer to the README.md for further information

Flash start addr:   0x
Page size:  256
Number of pages:    1024
RWWEE Flash start addr: 0x0040
RWWEE Number of pages:  8
> read_rwwee 0

Context before hardfault:
   r0: 0x2c24
   r1: 0x0040
   r2: 0x0100
   r3: 0x
  r12: 0x
   lr: 0x381b
   pc: 0x3f78
  psr: 0x2100

Misc
EXC_RET: 0xfffd
Attempting to reconstruct state for debugging...
In GDB:
  set $pc=0x3f78
  frame 0
  bt

ISR stack overflowed by at least 8 bytes.

What can that be?
-- Kees

On 28-01-19 04:32, Federico Pellegrin wrote:

Hi Marian,
Sure, no problem. I just created a PR at
https://github.com/RIOT-OS/RIOT/pull/10884

As it was still very early and uncertain how to structure I've started
like this, but indeed maybe easier to keep track directly as a PR.

Thanks!
Federico


Il giorno dom 27 gen 2019 alle ore 13:08 Marian Buschsieweke
 ha scritto:

Hi,

do you mind to create a pull request for it? This imho would make discussion of 
the code easier. You can add [WIP] in the title to highlight it's work in 
progress.

Cheers,
Marian

Am 27. Januar 2019 11:44:21 MEZ schrieb Federico Pellegrin :

Hi,
I did a mostly working (please see below for why mostly!) scratch of
the implementation and put it here for now:
https://github.com/fedepell/RIOT/commit/3b9de66ce0a9d722460c3b236ef67835df91cd90

I tested it and it is working on my saml21-xpro board. I can write on
the 8KBs of RWWEE memory and read it and see that it is still there
after rebooting and stuff. I took care to make it compile also on
saml11 (define names are different) although I cannot test this. As
you will see the code is mostly a copy & paste of the standard
flashpage, with a bunch of different defines used (for base adresses
and registers).
As I presumed in previous emails, it looks kinda ugly to me, but I'm
not sure we could reuse totally the code without a major refactoring
or by making many if-s in the common code (even asserts would depend
on if we are using RWWEE or not) to keep them united (and therefore
less performant). Please give it a look and let me know what do you
think!


As for "mostly working" what is still puzzling me is that the code
seems to have some kind of alignment issue or so (although I take care
of using aligned memory structures are required) since if I add/remove
some statement it may then just hang or generate a hardfault. It is
quite puzzling me since I tried to rule out all possibilities but
cannot get it working. But maybe it's just that I'm stubbornly doing
this from some time and I need to detach from it mentally for a while
;) But since I have to go out in a while I wanted to commit it so if
someone wants to give it a look in the meantime, mostly refering to
the structural question of how to implement it, it is there on github.
And maybe someone has a general suggestion about this maybe-alignment
issue from previous experience!

Thanks!

Cheers,
Federico






Il giorno sab 26 gen 2019 alle ore 05:46 Federico Pellegrin
 ha scritto:


  Hi Dylan and Oleg,
  Thanks for the feedback!

  Sorry I meant kilobyte indeed, but always write it wrong, both the k-s
  (should be K I see now) and b-s ;)

  Regarding implementation:

  To make it interrupt driven I guess it would be quite more a radical
  change, so I would look at least for now for a blocking one, which
  basically makes it just an additional flash area no different than the
  main one.

  About doing it similar to eeprom what I see, API wise, is that the
  eeprom one you link (and eeprom in general) is not page based, while
  the flash one (and also the RWWEE since the interface is the same) is
  page based. So you need always to work with pages (erase especially).
  So I would see it more indeed like the flashpage itself indeed. That's
  why my doubts on having it separate or not, since mostly what changes
  in the code would be the start offset, various limits now #defines
  (such as FLASHPAGE_NUMOF) and some flags when accessing the CPU (ie
  using NVMCTRL_CTRLA_CMD_RWWEEER instead of NVMCTRL_CTRLA_CMD_ER)


  Cheers,
  Federico

  Il giorno ven 25 gen 2019 alle ore 09:21 Dylan Laduranty
   ha scritto:

  Hello Federico,

  IIRC, this flash can be use as a virtual EEPROM. Maybe It would be better to 
write a eeprom driver (like STM32 [1]) rather than add it to the flashpage 
driver ?
  I also think this memory is 8KB for SAML21J18 (not 8Kb), which is a lot :)

  As a side note: SAML21 also have 8KB of Low Power SRAM in addition to its 32 
KB of SRAM

  I've never played with these additional memories but I'll be happy to help.

  Cheers,
  Dylan

  [1] 

Re: [riot-devel] SAM Flash Read-While-Write

[Kees Bakker]

Hey Federico,

Yes, checking for NVMCTRL_RWW_EEPROM_SIZE seems to be a good
approach.

BTW. Be careful with using the term "revision". Where you mentioned A,
B and L, that is what Atmel calls "device variant" to denote functional
differences. There is also a die revision, which can be read from
DSU.DID.REVISION

To quote the datasheet:
"Bits 11:8 – REVISION[3:0]: Revision Number
Identifies the die revision number. 0x0=rev.A, 0x1=rev.B etc.
Note: The device variant (last letter of the ordering number) is 
independent of the die revision
(DSU.DID.REVISION): The device variant denotes functional differences, 
whereas the die revision marks

evolution of the die."


On 30-01-19 06:41, Federico Pellegrin wrote:

Hi Kees,
I gave a better look and I think the fact is that not *all* SAMD21
have the RWWEE, but just revision B and L, while not A.

I got the information from this ATMEL's application note:
http://ww1.microchip.com/downloads/en/AppNotes/Atmel-32219-Differences-between-SAMD21-Variants-A-B-and-L_ApplicationNote_AT04470.pdf

Which revision are you using? As far as I see in RIOT the sodaq ones
may indeed be As:

sodaq-sara-aff/Makefile.include:export CPU_MODEL = samd21j18a
sodaq-explorer/Makefile.include:export CPU_MODEL = samd21j18a
samd21-xpro/Makefile.include:export CPU_MODEL = samd21j18a
sodaq-autonomo/Makefile.include:export CPU_MODEL = samd21j18a

In the include files we have in RIOT the defines I'm using are inside
the generic samd so somehow were applying to all of them:

vendor/samd21/include/instance/nvmctrl.h:#define NVMCTRL_RWWEE_PAGES
   32   // Page size
vendor/samd21/include/instance/nvmctrl.h:#define
NVMCTRL_RWW_EEPROM_ADDR 0x0040 // Start address of the RWW
EEPROM area

But I could add for a presence of NVMCTRL_RWW_EEPROM_SIZE which seems
to be just in the chips that have it, ie:

vendor/samd21/include/samd21j16b.h:#define NVMCTRL_RWW_EEPROM_SIZE
0x800UL /* 2 kB */
vendor/samd21/include/samd21e15bu.h:#define NVMCTRL_RWW_EEPROM_SIZE
0x400UL /* 1 kB */
vendor/samd21/include/samd21g15b.h:#define NVMCTRL_RWW_EEPROM_SIZE
0x400UL /* 1 kB */
vendor/samd21/include/samd21g16b.h:#define NVMCTRL_RWW_EEPROM_SIZE
0x800UL /* 2 kB */
vendor/samd21/include/samd21e15b.h:#define NVMCTRL_RWW_EEPROM_SIZE
0x400UL /* 1 kB */
vendor/samd21/include/samd21j15b.h:#define NVMCTRL_RWW_EEPROM_SIZE
0x400UL /* 1 kB */
vendor/samd21/include/samd21g15l.h:#define NVMCTRL_RWW_EEPROM_SIZE
0x400UL /* 1 kB */
vendor/samd21/include/samd21e16b.h:#define NVMCTRL_RWW_EEPROM_SIZE
0x800UL /* 2 kB */
vendor/samd21/include/samd21e16bu.h:#define NVMCTRL_RWW_EEPROM_SIZE
0x800UL /* 2 kB */
vendor/samd21/include/samd21e15l.h:#define NVMCTRL_RWW_EEPROM_SIZE
0x400UL /* 1 kB */
vendor/samd21/include/samd21g16l.h:#define NVMCTRL_RWW_EEPROM_SIZE
0x800UL /* 2 kB */
vendor/samd21/include/samd21e16l.h:#define NVMCTRL_RWW_EEPROM_SIZE
0x800UL /* 2 kB */

Cheers,
Federico

Il giorno mer 30 gen 2019 alle ore 04:34 Federico Pellegrin
 ha scritto:

Thanks for testing first of all!

That sounds strange, I even see that you just did just the read test,
which is basically:

void flashpage_rwwee_read(int page, void *data)
{
 assert(page < (int)FLASHPAGE_RWWEE_NUMOF);

 memcpy(data, flashpage_rwwee_addr(page), FLASHPAGE_SIZE);
}

Is the RWWEE displayed info correct for the SAMD:

RWWEE Flash start addr: 0x0040
RWWEE Number of pages:  8

I will get the datasheet now and check if there is some difference not
obvious from the include files.

Cheers,
Federico


Il giorno mar 29 gen 2019 alle ore 22:50 Kees Bakker 
ha scritto:

Hey Federico,

Thanks for doing the flashpage stuff.
I have some SODAQ boards, basically all SAMD21, that I use
to run the flashpage test.
Unfortunately, the test program crashes for read_rwwee

main(): This is RIOT! (Version: 2019.04-devel-16-gc2c6f-sam_rwee_support)
ROM flash read write test

Please refer to the README.md for further information

Flash start addr:   0x
Page size:  256
Number of pages:1024
RWWEE Flash start addr: 0x0040
RWWEE Number of pages:  8
  > read_rwwee 0

Context before hardfault:
 r0: 0x2c24
 r1: 0x0040
 r2: 0x0100
 r3: 0x
r12: 0x
 lr: 0x381b
 pc: 0x3f78
psr: 0x2100

Misc
EXC_RET: 0xfffd
Attempting to reconstruct state for debugging...
In GDB:
set $pc=0x3f78
frame 0
bt

ISR stack overflowed by at least 8 bytes.

What can that be?
-- Kees

On 28-01-19 04:32, Federico Pellegrin wrote:

Hi Marian,
Sure, no problem. I just created a PR at
https://github.com/RIOT-OS/RIOT/pull/10884

As it was still very early and uncertain how to structure I've started
like this, but indeed maybe easier to keep track directly as a PR.

Thanks!
Federico


Il giorno dom 27 gen 2019 alle ore 13:08 Marian Buschsieweke
 ha scritto:

Hi,

do you mind to create a pull request for it? This imho would make discussion of 
the code easier. You can add [WIP]

Re: [riot-devel] How to properly use cortexm_sleep

[Kees Bakker]

Thanks Juan,

That's a lot of information to digest. It will take me a bit of time
to go through.
-- Kees

On 27-05-19 14:17, Juan Ignacio Carrano wrote:

Hi Kees,

Some observations:

1- WFI will not send you to the deepest sleep states- clocks are 
gated, but many things remain powered.


2- If you are using the timer module and depending on you clock 
configuration you may experience more or less frequent wake ups. 
Whether this is acceptable is up to you.


3- Normally, if no thread is runnable (i.e. all are waiting/blocked) the
idle thread is run and that has a loop which sends the MCU to the 
deepest state possible (considering the currently-enabled 
peripherals). This means that in many cases the explicit WFI is not 
needed if in your
"while(forever)" loop you put some call that blocks waiting for the 
events you are interested in.


The interaction between (1) and (3) means that by doing a WFI in a 
thread it is possible that you don't sleep as deep as you could:


- The current thread will be blocked on the WFI instruction until an
  event arrives.
- In the meantime, control will not go back to the kernel.
- This means the idle thread will not run (from the schedulers point of
  view, you thread is still running).
- The pm_whatever() call in the idle thread will not run.

In conclusion, try to use the default mechanism if you can.

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] How to properly use cortexm_sleep

[Kees Bakker]

Hey Oleg,

Are you using the watchdog?

On 27-05-19 07:30, Oleg Artamonov wrote:

Hi
We do. On STM32L0, STM32L1, nRF52, etc.
Checking for interrupt flags is absolutely useless here - 1) WFI 
checks for any relevant interrupt flags, 2) interrupt still can happen 
between check and WFI.

--
/Sincerely yours,/
/Oleg Artamonov/
/+7 (916) 631-34-90/
/www.unwds.com/ <http://www.unwireddevices.com>
26.05.2019, 18:40, "Kees Bakker" :

Hey

Is there anyone using cortexm_sleep for a real application? And if
yes, would you want to share how exactly that's done?

Let me say that I've never written a real application with RIOT, but
I would like to. One of the important requirements is that the app
must be in sleep (deep sleep) and only wake up to do some work.
And another requirement is to use the watchdog.

That said, I'm familiar with the following Arduino pseudo code.

 while (forever) {
 do stuff

 disable interrupts
 if !certain condition
 __WFI();
 enable interrupts
 }

That "certain condition" is mostly checking that no WDT or RTC
interrupt
occurred before disabling the interrupts. These interrupts are handled
by ISR's and they set a flag. This is a fairly common thing to do,
I think.

I don't see (or understand) how this can be achieved with RIOT-OS and
cortexm_sleep. It is essential to check the condition AFTER
disabling the
    interrupts.

--
Kees Bakker
___
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

[riot-devel] How to properly use cortexm_sleep

[Kees Bakker]

Hey

Is there anyone using cortexm_sleep for a real application? And if
yes, would you want to share how exactly that's done?

Let me say that I've never written a real application with RIOT, but
I would like to. One of the important requirements is that the app
must be in sleep (deep sleep) and only wake up to do some work.
And another requirement is to use the watchdog.

That said, I'm familiar with the following Arduino pseudo code.

    while (forever) {
    do stuff

    disable interrupts
    if !certain condition
    __WFI();
    enable interrupts
    }

That "certain condition" is mostly checking that no WDT or RTC interrupt
occurred before disabling the interrupts. These interrupts are handled
by ISR's and they set a flag. This is a fairly common thing to do, I think.

I don't see (or understand) how this can be achieved with RIOT-OS and
cortexm_sleep. It is essential to check the condition AFTER disabling the
interrupts.
--
Kees Bakker
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] How to properly use cortexm_sleep

[Kees Bakker]

Thanks

On 29-05-19 13:02, Robert Hartung wrote:

Hey everyone,

let me say a few words as Kaspar and I have been driving the
implementation of this. In general there is no need to manually go to
sleep, as the deepest sleep mode will always be selected from the idle
thread depending on the deepest mode possible.
Which mode is possible depends on the used periphs. For STM32 sleep was
long not possible, as PM_BLOCKER_INITIAL was initialized with 1 for each
mode, which resulted in never going to a sleep mode.
 From what I can see is that it is still initialized with ones?
Nevertheless, to make us of it PM_BLOCKER_INITIAL should be initialized
with 0. All periph modules should then individually block the sleep
modes they can not operate in. For now the biggest problem was the
shell/uart, as it would always block any sleep modes.
An exception are some platforms, as they have a Uart which can wake them
up from sleep modes.

I have modified the atmega1284p implementation to make use of it [0] and
[1].

Best Regards
Robert

[0]
https://github.com/ibr-cm/RIOT/blob/idealvolting-rc1/cpu/atmega1284p/periph/pm.c
[1]
https://github.com/ibr-cm/RIOT/blob/idealvolting-rc1/cpu/atmega_common/periph/

On 28.05.19 20:01, Kees Bakker wrote:

Nice,

Thanks for sharing

On 28-05-19 08:48, Oleg Artamonov wrote:

Hi.

Yes, but for emergency reboots only.
  
Implementations:

https://github.com/unwireddevices/RIOT/blob/loralan-public/cpu/stm32_common/periph/iwdg.c
and
https://github.com/unwireddevices/RIOT/blob/loralan-public/cpu/nrf5x_common/periph/iwdg.c
  
For task scheduling on sleepy devices we use RTC-based timers with 1

ms resolution and 1 week max period
(https://github.com/unwireddevices/RIOT/tree/loralan-public/sys/rtctimers-millis;
on STM32L, we use regular HW RTC with SSR register, on nRF52 —
"software" RTC implemented on top of HW RTT unit).
  
--

/Sincerely yours,/
/Oleg Artamonov/
/+7 (916) 631-34-90/
/www.unwds.com/ <http://www.unwireddevices.com>
  
  
  
27.05.2019, 21:57, "Kees Bakker" :


 Hey Oleg,

 Are you using the watchdog?
  
 On 27-05-19 07:30, Oleg Artamonov wrote:


 Hi
  
 We do. On STM32L0, STM32L1, nRF52, etc.
  
 Checking for interrupt flags is absolutely useless here - 1)

 WFI checks for any relevant interrupt flags, 2) interrupt
 still can happen between check and WFI.
  
 --

 /Sincerely yours,/
 /Oleg Artamonov/
 /+7 (916) 631-34-90/
 /www.unwds.com/ <http://www.unwireddevices.com/>
  
  
  
     26.05.2019, 18:40, "Kees Bakker" 

 <mailto:k...@sodaq.com>:

 Hey

 Is there anyone using cortexm_sleep for a real
 application? And if
 yes, would you want to share how exactly that's done?

 Let me say that I've never written a real application with
 RIOT, but
 I would like to. One of the important requirements is that
 the app
 must be in sleep (deep sleep) and only wake up to do some
 work.
 And another requirement is to use the watchdog.

 That said, I'm familiar with the following Arduino pseudo
 code.

  while (forever) {
  do stuff

  disable interrupts
  if !certain condition
  __WFI();
  enable interrupts
  }

 That "certain condition" is mostly checking that no WDT or
 RTC interrupt
 occurred before disabling the interrupts. These interrupts
 are handled
 by ISR's and they set a flag. This is a fairly common
 thing to do, I think.

 I don't see (or understand) how this can be achieved with
 RIOT-OS and
 cortexm_sleep. It is essential to check the condition
 AFTER disabling the
     interrupts.

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

  


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

 ,

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


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


___
devel mai

Re: [riot-devel] How to properly use cortexm_sleep

[Kees Bakker]

Nice,

Thanks for sharing

On 28-05-19 08:48, Oleg Artamonov wrote:

Hi.

Yes, but for emergency reboots only.
Implementations: 
https://github.com/unwireddevices/RIOT/blob/loralan-public/cpu/stm32_common/periph/iwdg.c 
and 
https://github.com/unwireddevices/RIOT/blob/loralan-public/cpu/nrf5x_common/periph/iwdg.c
For task scheduling on sleepy devices we use RTC-based timers with 1 
ms resolution and 1 week max period 
(https://github.com/unwireddevices/RIOT/tree/loralan-public/sys/rtctimers-millis; 
on STM32L, we use regular HW RTC with SSR register, on nRF52 — 
"software" RTC implemented on top of HW RTT unit).

--
/Sincerely yours,/
/Oleg Artamonov/
/+7 (916) 631-34-90/
/www.unwds.com/ <http://www.unwireddevices.com>
27.05.2019, 21:57, "Kees Bakker" :

Hey Oleg,

Are you using the watchdog?
On 27-05-19 07:30, Oleg Artamonov wrote:

Hi
We do. On STM32L0, STM32L1, nRF52, etc.
Checking for interrupt flags is absolutely useless here - 1)
WFI checks for any relevant interrupt flags, 2) interrupt
still can happen between check and WFI.
-- 
/Sincerely yours,/

/Oleg Artamonov/
/+7 (916) 631-34-90/
/www.unwds.com/ <http://www.unwireddevices.com/>
    26.05.2019, 18:40, "Kees Bakker" 
<mailto:k...@sodaq.com>:

Hey

Is there anyone using cortexm_sleep for a real
application? And if
yes, would you want to share how exactly that's done?

Let me say that I've never written a real application with
RIOT, but
I would like to. One of the important requirements is that
the app
must be in sleep (deep sleep) and only wake up to do some
work.
And another requirement is to use the watchdog.

That said, I'm familiar with the following Arduino pseudo
code.

 while (forever) {
 do stuff

 disable interrupts
 if !certain condition
 __WFI();
 enable interrupts
 }

That "certain condition" is mostly checking that no WDT or
RTC interrupt
occurred before disabling the interrupts. These interrupts
are handled
by ISR's and they set a flag. This is a fairly common
thing to do, I think.

I don't see (or understand) how this can be achieved with
RIOT-OS and
cortexm_sleep. It is essential to check the condition
AFTER disabling the
    interrupts.

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

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

,

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


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


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

[riot-devel] What program do you use to connect to (USB) serial

[Kees Bakker]

Hey guys,

This is a question for people using Linux to develop for RIOT-OS.

What program do you use to connect to the (USB) serial?
picocom? minicom? miniterm? grabserial? something else?

I'm looking for a program that can automatically reconnect to the
USB serial after the RIOT board does a restart. So far I only found
that minicom will do that, but not automatically.

I like the three others much better because I can more easily log
the output. However, when the board resets, it loses the connection.
-- 
Kees
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] What program do you use to connect to (USB) serial

[Kees Bakker]

On 17-05-2020 00:42, Michael Richardson wrote:
> Kees Bakker  wrote:
> > This is a question for people using Linux to develop for RIOT-OS.
>
> > What program do you use to connect to the (USB) serial?  picocom?
> > minicom? miniterm? grabserial? something else?
>
> I sometimes use minicom, because it's generally available and can send BREAK,
> but I usually wind up using screen, because then I can run it on my serial
> console server, and connect to it from multiple places.
>
> I also use rtty, but it isn't as useable because USB serial devices don't
> number consistently.
>
> > I'm looking for a program that can automatically reconnect to the USB
> > serial after the RIOT board does a restart. So far I only found that
> > minicom will do that, but not automatically.
>
> > I like the three others much better because I can more easily log the
> > output. However, when the board resets, it loses the connection.
>
> Which board?
> Are you using a board with an FTDI chip attached to a serial console?
> Or one with a built-in USB?

It's a SODAQ board (basically an Arduino Zero compatible board) with
a SAMD21 that has onchip USB.

> There is also the interaction with the
> flashing process, which sometimes needsd the USB connection.
> I'd like to convince the minicom and screen guys to do some kind of back-off
> when the flasher asks.
> (This is also kinda a call for dual TTY devices that showed up in SunOS
> 4,AIX,etc. back in the 1990s that let UUCP run well before we had mgetty.)
Well, minicom is kinda old, from the modem era. The thing I don't like
about it that it really tries to emulate a terminal. With a curses-style
popup when the tty device is gone. You can hit enter and it reconnects.

Picocom, miniterm (Python pyserial) and grabserial is what I like. I can
pipe (or tee) the output in a file.

But like I said, if my program hits a watchdog reset, it reboots, and my
USB connection is gone. In my startup I want to print the reset cause
to know what was going on.

In the past I was using one of the UARTs of the SAMD21. In a sense that
was much easier.

I hate to say it, but it seems on Windows there is a solution (they tell
me).
That, by itself, bothers me too :-)
-- 
Kees
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] What program do you use to connect to (USB) serial

[Kees Bakker]

On 17-05-2020 22:36, Benjamin Valentin wrote:
> On Sat, 16 May 2020 22:49:54 +0200
> Kees Bakker  wrote:
>
>> I'm looking for a program that can automatically reconnect to the
>> USB serial after the RIOT board does a restart. So far I only found
>> that minicom will do that, but not automatically.
> pyterm [1] will do that. It's the default when you run
>
> make term
>
> in RIOT's build system.
> It will output to the console and keep logs in ~/.pyterm, so it's
> pretty handy.
>
> [1] https://github.com/RIOT-OS/RIOT/tree/master/dist/tools/pyterm
>
Wow, I never knew it was there. Great. It even has timing. Impressive.

Minor twit. It's missing the first 45 characters or so.

2020-05-18 20:41:02,547 # Connect to serial port /dev/ttyACM0
Welcome to pyterm!
Type '/exit' to exit.
2020-05-18 20:41:03,550 # -602-g39227-add-sodaq-sff)
2020-05-18 20:41:03,551 # Hello World!
2020-05-18 20:41:03,552 # You are running RIOT on a(n) sodaq-sara-sff board.
2020-05-18 20:41:03,553 # This board features a(n) samd21 MCU.
2020-05-18 20:46:06,269 # Serial port disconnected, waiting to get
reconnected...
2020-05-18 20:46:07,276 # Serial port disconnected, waiting to get
reconnected...
2020-05-18 20:46:08,277 # Try to reconnect to /dev/ttyACM0 again...
2020-05-18 20:46:08,278 # Reconnected to serial port /dev/ttyACM0
2020-05-18 20:46:08,279 # -602-g39227-add-sodaq-sff)
2020-05-18 20:46:08,280 # Hello World!
2020-05-18 20:46:08,281 # You are running RIOT on a(n) sodaq-sara-sff board.
2020-05-18 20:46:08,281 # This board features a(n) samd21 MCU.

Even so, I'm quite happy.
-- 
Kees
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Problem with test connecting to ttyACM0

[Kees Bakker]

Found it.

There is a MAKE_TERM_CONNECT_DELAY that defaults to 0. This is the time
between "make reset" and "make cleanterm".

In my case (and I'm guessing, all boards with Arduino bootloader) you
need a brief delay, for example 2 seconds.

The default of MAKE_TERM_CONNECT_DELAY can be overruled by setting
envvar TESTRUNNER_CONNECT_DELAY.

Hurray, my first successful test

$ TESTRUNNER_CONNECT_DELAY=3
~/src/RIOT/dist/tools/compile_and_test_for_board/compile_and_test_for_board.py
~/src/RIOT sodaq-sara-sff ~/src/RIOT/results --applications
tests/evtimer_msg
INFO:sodaq-sara-sff:Saving toolchain
INFO:sodaq-sara-sff.tests/evtimer_msg:Board supported: True
INFO:sodaq-sara-sff.tests/evtimer_msg:Board has enough memory: True
INFO:sodaq-sara-sff.tests/evtimer_msg:Application has test: True
INFO:sodaq-sara-sff.tests/evtimer_msg:Run compilation
INFO:sodaq-sara-sff.tests/evtimer_msg:Run test
INFO:sodaq-sara-sff.tests/evtimer_msg:Run test.flash
INFO:sodaq-sara-sff.tests/evtimer_msg:Success
INFO:sodaq-sara-sff:Tests successful

On 27-05-2020 21:31, Kees Bakker wrote:
> Alexandre, do you have a suggestion?
> Anyone?
>
> On 26-05-2020 21:59, Kees Bakker wrote:
>> Hi,
>>
>> My setup is more or less correct. When I do
>> $ BOARD=sodaq-sara-sff make -C tests/evtimer_msg flash term
>> ...
>> 2020-05-26 21:50:39,186 # Are the reception times of all 4 msgs close to
>> the supposed values?
>> 2020-05-26 21:50:39,187 # At   2361 ms received msg 0: "#2 supposed to
>> be 2361"
>> 2020-05-26 21:50:39,187 # At   2702 ms received msg 1: "#0 supposed to
>> be 2701"
>> 2020-05-26 21:50:39,670 # At   3202 ms received msg 2: "#1 supposed to
>> be 3202"
>> 2020-05-26 21:50:42,116 # At   5656 ms received msg 3: "#3 supposed to
>> be 5656"
>> 2020-05-26 21:50:42,127 # By now all msgs should have been received
>> 2020-05-26 21:50:42,127 # If yes, the tests were successful
>>
>> It connects nicely to the /dev/ttyACM0 with all the expected
>> output.
>>
>> However, when I make the "test" target it fails to find /dev/ttyACM0
>>
>> $ BOARD=sodaq-sara-sff make RIOT_CI_BUILD=1 CC_NOCOLOR=1
>> --no-print-directory -C /home/kees/src/RIOT/tests/evtimer_msg test
>> r
>> /home/kees/src/RIOT/dist/tools/pyterm/pyterm -p "/dev/ttyACM0" -b
>> "115200" --no-reconnect --noprefix --no-repeat-command-on-empty-line
>> Connect to serial port /dev/ttyACM0
>> could not open port /dev/ttyACM0: [Errno 2] No such file or directory:
>> '/dev/ttyACM0'
>> make[1]: *** [/home/kees/src/RIOT/Makefile.include:726: cleanterm] Error 2
>> Traceback (most recent call last):
>>   File "/usr/lib/python3/dist-packages/pexpect/spawnbase.py", line 166,
>> in read_nonblocking
>>     s = os.read(self.child_fd, size)
>> OSError: [Errno 5] Input/output error
>>
>> In fact, I'm trying to run compile_and_test_for_board.py, but that fails
>> on the "make test" command.
>>
>> Is there a timeout value somewhere that needs to be increased?
> ___
> 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] Problem with test connecting to ttyACM0

[Kees Bakker]

I was wondering why TERM_DELAY is only defined if

ifeq ($(PROGRAMMER),bossa)
    ...
    ifneq (,$(filter reset flash flash-only, $(MAKECMDGOALS)))
    ...
    TERM_DELAY ?= 2

Because now we have to set an envvar to do a "make test"


On 27-05-2020 22:06, Alexandre Abadie wrote:
> Ok, I replied in the meantime :)
>
> Good to know that you solved your issue!
>
> - Le 27 Mai 20, à 22:04, Kees Bakker k...@ijzerbout.nl a écrit :
>
>> Found it.
>>
>> There is a MAKE_TERM_CONNECT_DELAY that defaults to 0. This is the time
>> between "make reset" and "make cleanterm".
>>
>> In my case (and I'm guessing, all boards with Arduino bootloader) you
>> need a brief delay, for example 2 seconds.
>>
>> The default of MAKE_TERM_CONNECT_DELAY can be overruled by setting
>> envvar TESTRUNNER_CONNECT_DELAY.
>>
>> Hurray, my first successful test
>>
>> $ TESTRUNNER_CONNECT_DELAY=3
>> ~/src/RIOT/dist/tools/compile_and_test_for_board/compile_and_test_for_board.py
>> ~/src/RIOT sodaq-sara-sff ~/src/RIOT/results --applications
>> tests/evtimer_msg
>> INFO:sodaq-sara-sff:Saving toolchain
>> INFO:sodaq-sara-sff.tests/evtimer_msg:Board supported: True
>> INFO:sodaq-sara-sff.tests/evtimer_msg:Board has enough memory: True
>> INFO:sodaq-sara-sff.tests/evtimer_msg:Application has test: True
>> INFO:sodaq-sara-sff.tests/evtimer_msg:Run compilation
>> INFO:sodaq-sara-sff.tests/evtimer_msg:Run test
>> INFO:sodaq-sara-sff.tests/evtimer_msg:Run test.flash
>> INFO:sodaq-sara-sff.tests/evtimer_msg:Success
>> INFO:sodaq-sara-sff:Tests successful
>>
>> On 27-05-2020 21:31, Kees Bakker wrote:
>>> Alexandre, do you have a suggestion?
>>> Anyone?
>>>
>>> On 26-05-2020 21:59, Kees Bakker wrote:
>>>> Hi,
>>>>
>>>> My setup is more or less correct. When I do
>>>> $ BOARD=sodaq-sara-sff make -C tests/evtimer_msg flash term
>>>> ...
>>>> 2020-05-26 21:50:39,186 # Are the reception times of all 4 msgs close to
>>>> the supposed values?
>>>> 2020-05-26 21:50:39,187 # At   2361 ms received msg 0: "#2 supposed to
>>>> be 2361"
>>>> 2020-05-26 21:50:39,187 # At   2702 ms received msg 1: "#0 supposed to
>>>> be 2701"
>>>> 2020-05-26 21:50:39,670 # At   3202 ms received msg 2: "#1 supposed to
>>>> be 3202"
>>>> 2020-05-26 21:50:42,116 # At   5656 ms received msg 3: "#3 supposed to
>>>> be 5656"
>>>> 2020-05-26 21:50:42,127 # By now all msgs should have been received
>>>> 2020-05-26 21:50:42,127 # If yes, the tests were successful
>>>>
>>>> It connects nicely to the /dev/ttyACM0 with all the expected
>>>> output.
>>>>
>>>> However, when I make the "test" target it fails to find /dev/ttyACM0
>>>>
>>>> $ BOARD=sodaq-sara-sff make RIOT_CI_BUILD=1 CC_NOCOLOR=1
>>>> --no-print-directory -C /home/kees/src/RIOT/tests/evtimer_msg test
>>>> r
>>>> /home/kees/src/RIOT/dist/tools/pyterm/pyterm -p "/dev/ttyACM0" -b
>>>> "115200" --no-reconnect --noprefix --no-repeat-command-on-empty-line
>>>> Connect to serial port /dev/ttyACM0
>>>> could not open port /dev/ttyACM0: [Errno 2] No such file or directory:
>>>> '/dev/ttyACM0'
>>>> make[1]: *** [/home/kees/src/RIOT/Makefile.include:726: cleanterm] Error 2
>>>> Traceback (most recent call last):
>>>>   File "/usr/lib/python3/dist-packages/pexpect/spawnbase.py", line 166,
>>>> in read_nonblocking
>>>>     s = os.read(self.child_fd, size)
>>>> OSError: [Errno 5] Input/output error
>>>>
>>>> In fact, I'm trying to run compile_and_test_for_board.py, but that fails
>>>> on the "make test" command.
>>>>
>>>> Is there a timeout value somewhere that needs to be increased?
>>> ___
>>> 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] Problem with test connecting to ttyACM0

[Kees Bakker]

Alexandre, do you have a suggestion?
Anyone?

On 26-05-2020 21:59, Kees Bakker wrote:
> Hi,
>
> My setup is more or less correct. When I do
> $ BOARD=sodaq-sara-sff make -C tests/evtimer_msg flash term
> ...
> 2020-05-26 21:50:39,186 # Are the reception times of all 4 msgs close to
> the supposed values?
> 2020-05-26 21:50:39,187 # At   2361 ms received msg 0: "#2 supposed to
> be 2361"
> 2020-05-26 21:50:39,187 # At   2702 ms received msg 1: "#0 supposed to
> be 2701"
> 2020-05-26 21:50:39,670 # At   3202 ms received msg 2: "#1 supposed to
> be 3202"
> 2020-05-26 21:50:42,116 # At   5656 ms received msg 3: "#3 supposed to
> be 5656"
> 2020-05-26 21:50:42,127 # By now all msgs should have been received
> 2020-05-26 21:50:42,127 # If yes, the tests were successful
>
> It connects nicely to the /dev/ttyACM0 with all the expected
> output.
>
> However, when I make the "test" target it fails to find /dev/ttyACM0
>
> $ BOARD=sodaq-sara-sff make RIOT_CI_BUILD=1 CC_NOCOLOR=1
> --no-print-directory -C /home/kees/src/RIOT/tests/evtimer_msg test
> r
> /home/kees/src/RIOT/dist/tools/pyterm/pyterm -p "/dev/ttyACM0" -b
> "115200" --no-reconnect --noprefix --no-repeat-command-on-empty-line
> Connect to serial port /dev/ttyACM0
> could not open port /dev/ttyACM0: [Errno 2] No such file or directory:
> '/dev/ttyACM0'
> make[1]: *** [/home/kees/src/RIOT/Makefile.include:726: cleanterm] Error 2
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/pexpect/spawnbase.py", line 166,
> in read_nonblocking
>     s = os.read(self.child_fd, size)
> OSError: [Errno 5] Input/output error
>
> In fact, I'm trying to run compile_and_test_for_board.py, but that fails
> on the "make test" command.
>
> Is there a timeout value somewhere that needs to be increased?

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

Re: [riot-devel] How to make my boards appear in the info-boards-supported list

[Kees Bakker]

OK thanks for looking into this.

A quick-and-dirty investigation shows these boards that
could potentially be missing.

adafruit-clue
arduino-mkr1000
arduino-mkrfox1200
arduino-mkrwan1300
arduino-mkrzero
arduino-nano-33-ble
feather-m0
nrf52840dongle
sodaq-autonomo
sodaq-explorer
sodaq-one
sodaq-sara-aff
sodaq-sara-sff


On 25-05-2020 09:13, Francois-Xavier Molina wrote:
> Hi,
>
> I bisected and found the origin in [1], we are investigating. Cheers,
>
> Francisco
>
> [1] 
> https://github.com/RIOT-OS/RIOT/pull/13738/commits/64552a3b9a05b2dac116008fa61d1842651ffa85
>
> - Mail original -
>> De: "Alexandre Abadie" 
>> À: "devel" 
>> Envoyé: Lundi 25 Mai 2020 08:58:32
>> Objet: Re: [riot-devel] How to make my boards appear in the 
>> info-boards-supported list
>> Hi Kees,
>>
>> This is not normal, they should appear. This is a bug in the build system. I
>> tried locally and could reproduce.
>>
>> The best would be to open an issue on GitHub that describes the problem.
>>
>> Alex
>>
>> - Le 24 Mai 20, à 23:32, Kees Bakker k...@ijzerbout.nl a écrit :
>>
>>> Hey,
>>>
>>> I want to run tests on my SODAQ board(s), but they don't
>>> appear in the output of
>>>    make -C examples/hello-world info-boards-supported
>>>
>>> What are they missing?
>>> --
>>> Kees
>>> ___
>>> 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] How to make my boards appear in the info-boards-supported list

[Kees Bakker]

It's because of bootloader_arduino and the following lines in
makefiles/stdio.inc.mk

ifeq (,$(filter stdio_cdc_acm,$(USEMODULE)))
  # The arduino and nrfutil bootloader features cannot be used if the
  # stdio_cdc_acm module is not used
  FEATURES_BLACKLIST += bootloader_arduino
  FEATURES_BLACKLIST += bootloader_nrfutil
endif

It thinks that stdio_cdc_acm is not included in USEMODULE

But the strange this is: USEMODULE **does** contain stdio_cdc_acm

$ echo 'print: ; @echo "$(USEMODULE)"' | BOARD=sodaq-autonomo make
--no-print-directory -C examples/hello-world -f Makefile -f - print
auto_init auto_init_usbus board boards_common_samd21-arduino-bootloader
boards_common_sodaq core core_init core_msg core_panic core_thread_flags
cortexm_common cortexm_common_periph cpu event isrpipe newlib
newlib_nano newlib_syscalls_default periph periph_common periph_gpio
periph_init periph_init_gpio periph_init_pm periph_init_usbdev periph_pm
periph_usbdev pm_layered sam0_common_periph stdio_cdc_acm sys tsrb
usb_board_reset usbus usbus_cdc_acm



On 25-05-2020 12:11, Kees Bakker wrote:
> OK thanks for looking into this.
>
> A quick-and-dirty investigation shows these boards that
> could potentially be missing.
>
> adafruit-clue
> arduino-mkr1000
> arduino-mkrfox1200
> arduino-mkrwan1300
> arduino-mkrzero
> arduino-nano-33-ble
> feather-m0
> nrf52840dongle
> sodaq-autonomo
> sodaq-explorer
> sodaq-one
> sodaq-sara-aff
> sodaq-sara-sff
>
>
> On 25-05-2020 09:13, Francois-Xavier Molina wrote:
>> Hi,
>>
>> I bisected and found the origin in [1], we are investigating. Cheers,
>>
>> Francisco
>>
>> [1] 
>> https://github.com/RIOT-OS/RIOT/pull/13738/commits/64552a3b9a05b2dac116008fa61d1842651ffa85
>>
>> - Mail original -
>>> De: "Alexandre Abadie" 
>>> À: "devel" 
>>> Envoyé: Lundi 25 Mai 2020 08:58:32
>>> Objet: Re: [riot-devel] How to make my boards appear in the 
>>> info-boards-supported list
>>> Hi Kees,
>>>
>>> This is not normal, they should appear. This is a bug in the build system. I
>>> tried locally and could reproduce.
>>>
>>> The best would be to open an issue on GitHub that describes the problem.
>>>
>>> Alex
>>>
>>> - Le 24 Mai 20, à 23:32, Kees Bakker k...@ijzerbout.nl a écrit :
>>>
>>>> Hey,
>>>>
>>>> I want to run tests on my SODAQ board(s), but they don't
>>>> appear in the output of
>>>>    make -C examples/hello-world info-boards-supported
>>>>
>>>> What are they missing?
>>>> --
>>>> Kees
>>>> ___
>>>> 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] How to make my boards appear in the info-boards-supported list

[Kees Bakker]

Oh, I see it got fixed in #14129

On 25-05-2020 23:17, Kees Bakker wrote:
> It's because of bootloader_arduino and the following lines in
> makefiles/stdio.inc.mk
>
> ifeq (,$(filter stdio_cdc_acm,$(USEMODULE)))
>   # The arduino and nrfutil bootloader features cannot be used if the
>   # stdio_cdc_acm module is not used
>   FEATURES_BLACKLIST += bootloader_arduino
>   FEATURES_BLACKLIST += bootloader_nrfutil
> endif
>
> It thinks that stdio_cdc_acm is not included in USEMODULE
>
> But the strange this is: USEMODULE **does** contain stdio_cdc_acm
>
> $ echo 'print: ; @echo "$(USEMODULE)"' | BOARD=sodaq-autonomo make
> --no-print-directory -C examples/hello-world -f Makefile -f - print
> auto_init auto_init_usbus board boards_common_samd21-arduino-bootloader
> boards_common_sodaq core core_init core_msg core_panic core_thread_flags
> cortexm_common cortexm_common_periph cpu event isrpipe newlib
> newlib_nano newlib_syscalls_default periph periph_common periph_gpio
> periph_init periph_init_gpio periph_init_pm periph_init_usbdev periph_pm
> periph_usbdev pm_layered sam0_common_periph stdio_cdc_acm sys tsrb
> usb_board_reset usbus usbus_cdc_acm
>
>
>
> On 25-05-2020 12:11, Kees Bakker wrote:
>> OK thanks for looking into this.
>>
>> A quick-and-dirty investigation shows these boards that
>> could potentially be missing.
>>
>> adafruit-clue
>> arduino-mkr1000
>> arduino-mkrfox1200
>> arduino-mkrwan1300
>> arduino-mkrzero
>> arduino-nano-33-ble
>> feather-m0
>> nrf52840dongle
>> sodaq-autonomo
>> sodaq-explorer
>> sodaq-one
>> sodaq-sara-aff
>> sodaq-sara-sff
>>
>>
>> On 25-05-2020 09:13, Francois-Xavier Molina wrote:
>>> Hi,
>>>
>>> I bisected and found the origin in [1], we are investigating. Cheers,
>>>
>>> Francisco
>>>
>>> [1] 
>>> https://github.com/RIOT-OS/RIOT/pull/13738/commits/64552a3b9a05b2dac116008fa61d1842651ffa85
>>>
>>> - Mail original -
>>>> De: "Alexandre Abadie" 
>>>> À: "devel" 
>>>> Envoyé: Lundi 25 Mai 2020 08:58:32
>>>> Objet: Re: [riot-devel] How to make my boards appear in the 
>>>> info-boards-supported list
>>>> Hi Kees,
>>>>
>>>> This is not normal, they should appear. This is a bug in the build system. 
>>>> I
>>>> tried locally and could reproduce.
>>>>
>>>> The best would be to open an issue on GitHub that describes the problem.
>>>>
>>>> Alex
>>>>
>>>> - Le 24 Mai 20, à 23:32, Kees Bakker k...@ijzerbout.nl a écrit :
>>>>
>>>>> Hey,
>>>>>
>>>>> I want to run tests on my SODAQ board(s), but they don't
>>>>> appear in the output of
>>>>>    make -C examples/hello-world info-boards-supported
>>>>>
>>>>> What are they missing?
>>>>> --
>>>>> Kees
>>>>> ___
>>>>> 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] Which tests are expected to succeed for my board

[Kees Bakker]

Hi,

Now that I'm happily running automated tests for my SAMD21 board(s) I am
wondering which tests should succeed. There are several that fail, but I
don't know if that "normal" or not.

Some examples of test that fail

xtimer_periodic_wakeup: hangs at the end, last couple of printf don't
come out
tests/thread_flood: [ERROR] expected 30, created 29

Is there maybe a wiki with the status of the tests (per board?).
-- 
Kees
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Which tests are expected to succeed for my board

[Kees Bakker]

OK, first one created. I'm afraid there are many more to come.

On 30-05-2020 21:27, Alexandre Abadie wrote:
> Hi Kees,
>
> To my knowledge, there is no wiki page for this kind of thing.
> The simplest is probably to open an issue and list there the failures with 
> their output. This way we can easily track the on going work to fix them.
>
> See [1] as an example.
>
> Alex
>
> [1] https://github.com/RIOT-OS/RIOT/issues/12651
>
> - Le 29 Mai 20, à 23:14, Kees Bakker k...@ijzerbout.nl a écrit :
>
>> Hi,
>>
>> Now that I'm happily running automated tests for my SAMD21 board(s) I am
>> wondering which tests should succeed. There are several that fail, but I
>> don't know if that "normal" or not.
>>
>> Some examples of test that fail
>>
>> xtimer_periodic_wakeup: hangs at the end, last couple of printf don't
>> come out
>> tests/thread_flood: [ERROR] expected 30, created 29
>>
>> Is there maybe a wiki with the status of the tests (per board?).
>> --
>> Kees
>> ___
>> 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] Which tests are expected to succeed for my board

[Kees Bakker]

Well, not easier for me, I'm afraid. It will delay adding my board
even longer (which is already several months in progress).
And it's just a hobby for me. Otherwise it begins to look like
work :-)

Nevertheless, I'll see what I can do.

On 30-05-2020 22:14, Alexandre Abadie wrote:
> Hi,
>
> You can just put all of them in the same issue. It will be easier to track. 
> That is what is done in [1].
>
> Alex
>
> [1] https://github.com/RIOT-OS/RIOT/issues/12651
>
> ----- Le 30 Mai 20, à 21:42, Kees Bakker k...@ijzerbout.nl a écrit :
>
>> OK, first one created. I'm afraid there are many more to come.
>>
>> On 30-05-2020 21:27, Alexandre Abadie wrote:
>>> Hi Kees,
>>>
>>> To my knowledge, there is no wiki page for this kind of thing.
>>> The simplest is probably to open an issue and list there the failures with 
>>> their
>>> output. This way we can easily track the on going work to fix them.
>>>
>>> See [1] as an example.
>>>
>>> Alex
>>>
>>> [1] https://github.com/RIOT-OS/RIOT/issues/12651
>>>
>>> - Le 29 Mai 20, à 23:14, Kees Bakker k...@ijzerbout.nl a écrit :
>>>
>>>> Hi,
>>>>
>>>> Now that I'm happily running automated tests for my SAMD21 board(s) I am
>>>> wondering which tests should succeed. There are several that fail, but I
>>>> don't know if that "normal" or not.
>>>>
>>>> Some examples of test that fail
>>>>
>>>> xtimer_periodic_wakeup: hangs at the end, last couple of printf don't
>>>> come out
>>>> tests/thread_flood: [ERROR] expected 30, created 29
>>>>
>>>> Is there maybe a wiki with the status of the tests (per board?).
>>>> --
>>>> Kees
>>>> ___
>>>> 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] Which tests are expected to succeed for my board

[Kees Bakker]

On 31-05-2020 12:33, Martine Sophie Lenders wrote:
> Hi,
>
> Am 31.05.20 um 12:25 schrieb Kaspar Schleiser:
>> "... FAILED (due to $reason)", and maybe not change return code to
>> something that's an error.
> While I like this idea I foresee a usage problem since some tests in
> that script fail due to missing root permissions (or missing
> scapy_unroot). If we say 'FAILED (due to missing root permissions)' I
> virtually expect any sane developer to re-run the script then with
> `sudo`, leading to people wondering why they are not able to compile
> applications anymore, just using `make all`, as the `bin` directory was
> created with root permission. Sure this can be easily fixed, I just say
> "mind the consequences" ;-).
>

I don't agree with the "sane" part in that sentence. ;-)
-- 
Kees

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

Re: [riot-devel] Which tests are expected to succeed for my board

[Kees Bakker]

)
- [tests/gnrc_rpl_srh](tests/gnrc_rpl_srh/test.flash.failed)
- [tests/gnrc_sixlowpan](tests/gnrc_sixlowpan/test.flash.failed)
- [tests/gnrc_sixlowpan_frag](tests/gnrc_sixlowpan_frag/test.flash.failed)
-
[tests/gnrc_sixlowpan_iphc_w_vrb](tests/gnrc_sixlowpan_iphc_w_vrb/test.flash.failed)
-
[tests/gnrc_sock_async_event](tests/gnrc_sock_async_event/test.flash.failed)
- [tests/gnrc_sock_dns](tests/gnrc_sock_dns/test.flash.failed)
- [tests/gnrc_sock_ip](tests/gnrc_sock_ip/test.flash.failed)
- [tests/gnrc_sock_neterr](tests/gnrc_sock_neterr/test.flash.failed)
- [tests/gnrc_sock_udp](tests/gnrc_sock_udp/test.flash.failed)
- [tests/gnrc_tcp](tests/gnrc_tcp/test.flash.failed)
- [tests/heap_cmd](tests/heap_cmd/test.flash.failed)
- [tests/irq](tests/irq/test.flash.failed)
- [tests/irq_disable_restore](tests/irq_disable_restore/test.flash.failed)
- [tests/isr_yield_higher](tests/isr_yield_higher/test.flash.failed)
- [tests/kconfig](tests/kconfig/test.flash.failed)
- [tests/l2util](tests/l2util/test.flash.failed)
- [tests/libc_newlib](tests/libc_newlib/test.flash.failed)
- [tests/log_color](tests/log_color/test.flash.failed)
- [tests/log_printfnoformat](tests/log_printfnoformat/test.flash.failed)
- [tests/lwip_sock_ip](tests/lwip_sock_ip/test.flash.failed)
- [tests/lwip_sock_tcp](tests/lwip_sock_tcp/test.flash.failed)
- [tests/lwip_sock_udp](tests/lwip_sock_udp/test.flash.failed)
- [tests/malloc](tests/malloc/test.flash.failed)
- [tests/memarray](tests/memarray/test.flash.failed)
- [tests/msg_avail](tests/msg_avail/test.flash.failed)
- [tests/msg_send_receive](tests/msg_send_receive/test.flash.failed)
- [tests/msg_try_receive](tests/msg_try_receive/test.flash.failed)
- [tests/mtd_flashpage](tests/mtd_flashpage/test.flash.failed)
- [tests/mtd_mapper](tests/mtd_mapper/test.flash.failed)
- [tests/pkg_tensorflow-lite](tests/pkg_tensorflow-lite/test.flash.failed)
- [tests/stdin](tests/stdin/test.flash.failed)
- [tests/vfs_plus_stdio](tests/vfs_plus_stdio/test.flash.failed)
-
[tests/xtimer_mutex_lock_timeout](tests/xtimer_mutex_lock_timeout/test.flash.failed)
-
[tests/xtimer_periodic_wakeup](tests/xtimer_periodic_wakeup/test.flash.failed)


On 30-05-2020 22:19, Kees Bakker wrote:
> Well, not easier for me, I'm afraid. It will delay adding my board
> even longer (which is already several months in progress).
> And it's just a hobby for me. Otherwise it begins to look like
> work :-)
>
> Nevertheless, I'll see what I can do.
>
> On 30-05-2020 22:14, Alexandre Abadie wrote:
>> Hi,
>>
>> You can just put all of them in the same issue. It will be easier to track. 
>> That is what is done in [1].
>>
>> Alex
>>
>> [1] https://github.com/RIOT-OS/RIOT/issues/12651
>>
>> - Le 30 Mai 20, à 21:42, Kees Bakker k...@ijzerbout.nl a écrit :
>>
>>> OK, first one created. I'm afraid there are many more to come.
>>>
>>> On 30-05-2020 21:27, Alexandre Abadie wrote:
>>>> Hi Kees,
>>>>
>>>> To my knowledge, there is no wiki page for this kind of thing.
>>>> The simplest is probably to open an issue and list there the failures with 
>>>> their
>>>> output. This way we can easily track the on going work to fix them.
>>>>
>>>> See [1] as an example.
>>>>
>>>> Alex
>>>>
>>>> [1] https://github.com/RIOT-OS/RIOT/issues/12651
>>>>
>>>> - Le 29 Mai 20, à 23:14, Kees Bakker k...@ijzerbout.nl a écrit :
>>>>
>>>>> Hi,
>>>>>
>>>>> Now that I'm happily running automated tests for my SAMD21 board(s) I am
>>>>> wondering which tests should succeed. There are several that fail, but I
>>>>> don't know if that "normal" or not.
>>>>>
>>>>> Some examples of test that fail
>>>>>
>>>>> xtimer_periodic_wakeup: hangs at the end, last couple of printf don't
>>>>> come out
>>>>> tests/thread_flood: [ERROR] expected 30, created 29
>>>>>
>>>>> Is there maybe a wiki with the status of the tests (per board?).
>>>>> --
>>>>> Kees
>>>>> ___
>>>>> 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] Which tests are expected to succeed for my board

[Kees Bakker]

The reason I ask all these questions is that I'm adding support for
another SODAQ board. And I was trying to do it the right way and
run some tests. Maybe that was a mistake :-)

Anyway, I've created the first issue.

On 30-05-2020 21:30, Marian Buschsieweke wrote:
> Hi,
>
> every failing test indicates a bug. (From time to time the bug is found in the
> test rather than in the code to test.) Feel free to open an issue for the
> failing tests. I personally favor a tracking issue that lists each failing 
> test
> with a checkbox. It is motivating to tick them of one by one; and with the
> tiring task of bug hunting some motivation is always welcome :-)
>
> Kind regards,
> Marian
>
> On Fri, 29 May 2020 23:14:19 +0200
> Kees Bakker  wrote:
>
>> Hi,
>>
>> Now that I'm happily running automated tests for my SAMD21 board(s) I am
>> wondering which tests should succeed. There are several that fail, but I
>> don't know if that "normal" or not.
>>
>> Some examples of test that fail
>>
>> xtimer_periodic_wakeup: hangs at the end, last couple of printf don't
>> come out
>> tests/thread_flood: [ERROR] expected 30, created 29
>>
>> Is there maybe a wiki with the status of the tests (per board?).
>
> ___
> 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] Which tests are expected to succeed for my board

[Kees Bakker]

Thanks Alex,

The tests that need sudo, I've skipped. For now I don't care about
these. I was able to
rerun quite a few tests by skipping the ones that caused the the board
to hang. I also
skip all the tests that need sudo. For now I don't care about these.

I'll look at LOW_MEMORY_BOARDS, but if other SAMD21 don't need it, then
my board
shouldn't need it either.

I also need to look at my execution environment. I don't docker (yet),
so maybe I'm
using incompatible gcc and/or newlib. I've seen strange problems with
puts/printf, where
part of the output is missing (and thus I get test timeouts).
-- Kees

On 31-05-2020 21:40, Alexandre Abadie wrote:
> Hi Kees,
>
> Indeed that's a lot of failures!
>
> Regarding the failures during flash, the flashing over USB workflow is rather 
> fragile: if something went wrong (a crash) when testing an application, the 
> board might no recover and cannot be flashed automatically anymore after. 
> There's also the issue with connecting the terminal application to stdio that 
> can timeout sometimes.
>
> The main issues are with the "failures during test" list. I tried some of 
> them on arduino-mkr1000 and also got failures. So there are bugs.
>
> Note that you can run each of them individually using "make BOARD= board> -C tests/ flash test". This is what is called by the 
> "compile_and_test_board.py" script.
>
> Regarding "tests/bench_xtimer", you can fix the build issue by adding your 
> board to the LOW_MEMORY_BOARDS list [1]. For the other build failures, I 
> guess some Python packages are missing. Maybe add BUILD_IN_DOCKER=1 to the 
> test command.
>
> Alex
>
> [1] https://github.com/RIOT-OS/RIOT/blob/master/tests/bench_xtimer/Makefile#L7
>
> - Le 31 Mai 20, à 21:06, Kees Bakker k...@ijzerbout.nl a écrit :
>
>> Let me explain a little bit more why I am struggling right now.
>>
>> First thing you should know is that I'm creating the support for
>> a new SODAQ board (Sara SFF).
>>
>> Second, I haven't run the automated tests before, so I don't
>> know what to expect.
>>
>> The complete run gives me the result below. No need to comment
>> on it. I just wanted to let you know what I have to chew on. I will
>> probably get back with more questions.
>>
>> ERROR:sodaq-sara-sff:Tests failed: 110
>> Failures during compilation:
>> - [tests/bench_xtimer](tests/bench_xtimer/compilation.failed)
>> - [tests/pkg_nanopb](tests/pkg_nanopb/compilation.failed)
>> - [tests/suit_manifest](tests/suit_manifest/compilation.failed)
>>
>> Failures during test:
>> - [examples/micropython](examples/micropython/test.failed)
>> - [tests/bench_runtime_coreapis](tests/bench_runtime_coreapis/test.failed)
>> - [tests/bench_sizeof_coretypes](tests/bench_sizeof_coretypes/test.failed)
>> - [tests/bloom_bytes](tests/bloom_bytes/test.failed)
>> - [tests/cond_order](tests/cond_order/test.failed)
>> -
>> [tests/cpp11_condition_variable](tests/cpp11_condition_variable/test.failed)
>> - [tests/cpp11_mutex](tests/cpp11_mutex/test.failed)
>> - [tests/cpp11_thread](tests/cpp11_thread/test.failed)
>> - [tests/gnrc_ipv6_nib_dns](tests/gnrc_ipv6_nib_dns/test.failed)
>> - [tests/mutex_order](tests/mutex_order/test.failed)
>> - [tests/periph_gpio](tests/periph_gpio/test.failed)
>> - [tests/periph_rtt](tests/periph_rtt/test.failed)
>> - [tests/periph_timer](tests/periph_timer/test.failed)
>> - [tests/periph_timer_periodic](tests/periph_timer_periodic/test.failed)
>> -
>> [tests/periph_timer_short_relative_set](tests/periph_timer_short_relative_set/test.failed)
>> - [tests/periph_uart_nonblocking](tests/periph_uart_nonblocking/test.failed)
>> - [tests/periph_wdt](tests/periph_wdt/test.failed)
>> - [tests/pkg_c25519](tests/pkg_c25519/test.failed)
>> - [tests/pkg_cifra](tests/pkg_cifra/test.failed)
>> - [tests/pkg_cn-cbor](tests/pkg_cn-cbor/test.failed)
>> - [tests/pkg_hacl](tests/pkg_hacl/test.failed)
>> - [tests/pkg_heatshrink](tests/pkg_heatshrink/test.failed)
>> - [tests/pkg_libb2](tests/pkg_libb2/test.failed)
>> - [tests/pkg_libbase58](tests/pkg_libbase58/test.failed)
>> - [tests/pkg_libcose](tests/pkg_libcose/test.failed)
>> - [tests/pkg_libhydrogen](tests/pkg_libhydrogen/test.failed)
>> - [tests/pkg_littlefs](tests/pkg_littlefs/test.failed)
>> - [tests/pkg_littlefs2](tests/pkg_littlefs2/test.failed)
>> - [tests/pkg_monocypher](tests/pkg_monocypher/test.failed)
>> - [tests/pkg_nanocbor](tests/pkg_nanocbor/test.failed)
>> - [tests/pkg_qcbor](tests/pkg_qcbor/test.failed)
>> - [tests/pkg_qdsa](tests/pkg_qdsa/test.failed)
>> - [tests/pkg_relic](tests/pkg_relic/test.fail

[riot-devel] Problem with test connecting to ttyACM0

[Kees Bakker]

Hi,

My setup is more or less correct. When I do
$ BOARD=sodaq-sara-sff make -C tests/evtimer_msg flash term
...
2020-05-26 21:50:39,186 # Are the reception times of all 4 msgs close to
the supposed values?
2020-05-26 21:50:39,187 # At   2361 ms received msg 0: "#2 supposed to
be 2361"
2020-05-26 21:50:39,187 # At   2702 ms received msg 1: "#0 supposed to
be 2701"
2020-05-26 21:50:39,670 # At   3202 ms received msg 2: "#1 supposed to
be 3202"
2020-05-26 21:50:42,116 # At   5656 ms received msg 3: "#3 supposed to
be 5656"
2020-05-26 21:50:42,127 # By now all msgs should have been received
2020-05-26 21:50:42,127 # If yes, the tests were successful

It connects nicely to the /dev/ttyACM0 with all the expected
output.

However, when I make the "test" target it fails to find /dev/ttyACM0

$ BOARD=sodaq-sara-sff make RIOT_CI_BUILD=1 CC_NOCOLOR=1
--no-print-directory -C /home/kees/src/RIOT/tests/evtimer_msg test
r
/home/kees/src/RIOT/dist/tools/pyterm/pyterm -p "/dev/ttyACM0" -b
"115200" --no-reconnect --noprefix --no-repeat-command-on-empty-line
Connect to serial port /dev/ttyACM0
could not open port /dev/ttyACM0: [Errno 2] No such file or directory:
'/dev/ttyACM0'
make[1]: *** [/home/kees/src/RIOT/Makefile.include:726: cleanterm] Error 2
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/pexpect/spawnbase.py", line 166,
in read_nonblocking
    s = os.read(self.child_fd, size)
OSError: [Errno 5] Input/output error

In fact, I'm trying to run compile_and_test_for_board.py, but that fails
on the "make test" command.

Is there a timeout value somewhere that needs to be increased?
-- 
Kees
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] How to make my boards appear in the info-boards-supported list

[Kees Bakker]

Hey,

I want to run tests on my SODAQ board(s), but they don't
appear in the output of
   make -C examples/hello-world info-boards-supported

What are they missing?
-- 
Kees
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel