compiled, flashed and tested default example on my WaspMote. Shell + basic commands (ps, help, reboot) work.

@emmanuelsearch Could you try some of the timer tests?

@emmanuelsearch Could you try some of the timer tests?

scratch that, they probably fail in similar ways as on arduino-2560.

@kaspar030 I think @kYc0o is looking into that. Will test as soon as you tell me to!

xtimer works but a very specific initialisation ticks, for instance now is working at XTIMER_USEC_TO_TICKS(57600ul) thus we need a way to specify lower speeds for slower boards.

waiting for #5529 to factorise the code.

Just updated the code to make it consistent with #5529 and #5537, will need rebase after merging those PRs.

Updated and ready for review @emmanuelsearch ! However, xtimer is not working (hardware timers work very well though), because the default initialisation (1000000 ticks) is not compatible with the board frequency (14745600). Maybe @kaspar030 can help?

@kYc0o, first try on my side on Linux, the port is not /dev/ttyACM0 but /dev/ttyUSB0.

@kYc0o, I'm trying to test the xbee on the board. Is there some specific code to add.
I already tried to add USE_MODULE += xbee in the gnrc_minimal example but it fails with the error:

auto_init_xbee.c:27:25: fatal error: xbee_params.h: No such file or directory
 #include "xbee_params.h"

Did you uncomment this line?

Did you uncomment this line?

Just did that plus the lines mentioned above. It does build now but no IP address is displayed in the terminal.

As the XBee socket on this board is shared with the USB output, you need to specify another serial port for STDOUT. You can see here that a physical mux is used to select between the XBee socket and the USB output.

This can be done by uncommenting this line and commenting this. For now is the solution I propose, but maybe it's worth considering to manage that using CFLAGS.

You maybe need to specify UART1 for the STDIO here, since UART0 will be used by the XBee.

This can be done by uncommenting this line and commenting this. For now is the solution I propose, but maybe it's worth considering to manage that using CFLAGS.

You can use #ifdef MODULE_XBEE in the code to choose the right MUX.

For the record, I could have the second UART working when the XBee is initialized but no packet is received when running the gnrc_minimal example. Also the UART can work only if one initializes the xtimer with the correct value (default is 1000000), e.g 921600 here.

Maybe you can issue a PR for making the xtimer init value customizable (using an #ifndef).

A PR for the XTIMER issue was made, I'll also open an issue to explain why we need that here and try to find a solution. Besides that I think this is in a stable state and can be merged.

The manual configuration for the MUXes in the board to select the UART is now done automatically, and it's switched when the XBee port is used.

tested on my Waspmote. Default example and perish_timer test work.
(assuming I initialize the timer speed to 230400 instead of 1000000).

Ok great, that initialisation is necessary since the clock on the waspmote is not compatible with 1MHz. So I'll squash and wait for an ACK and Murdock ;)

Since this is new supported hardware and the issue for xtimer is already open, I'm inclined to ACK (assuming Murdock does not complain etc.)

please squash.

squashed and put Murdock to look into it

Murdock failed because the waspmote wasn't blacklisted for the tests it is not able to pass. Added a commit to fix that and restarting Murdock.

Murdcok green -> GO!

This board has been plagued by broken timer configuration a few times. And to be honest the board support is not up to our standard and has no documentation at all.

To my knowledge @jdavid is the only users of this board and new boards can be only obtained under the new Plug&Sense name with a fancy case and sensors for thousands of EUR.

Are there more users besides @jdavid using the boards? If not, maybe we should consider dropping the board?

It's been longtime I haven't seen the timer changes etc, and so far I remember it was already complicated to get a timer running correctly, due to the "weird" clocking configuration. Dropping support seems the most sensible in this case unfortunately...