Adding: boards/avr-rss2 and AtMega256RFR2 based board See doc.txt for details. #12668

herjulf · 2019-11-07T20:58:36Z

Contribution description

Support for a new boards/avr-rss2 an AtMega256RFR2 based. See doc.txt for detail. PR does not touch any core files. The PR also demonstrates ease and small footprint in RIOT. PR uses in total 426 bytes.

Testing procedure

Tested with examples/gnrc_networking using the at86rf2xx radio with the recent PR #12537 using ping6 RPL over 6LowPAN.

Issues/PRs references

Follow-up work is planned to enable eui64 chip support see PR #12592

herjulf · 2019-11-07T21:14:00Z

Tested with gnrc_networking and PR #12537 radio ping6 RPL. Planned integration with HW eui64 see PR #12598

herjulf · 2019-11-07T21:26:12Z

Also a demonstration of board footprint in RIOT. In total only 426 bytes used here.

benpicco

You can also expose your LEDs and the Button through SAUL so users can interact with it on the command line.
You just have to add a gpio_params.h file and use the saul_gpio module.

boards/avr-rss2/Makefile.dep

boards/avr-rss2/Makefile.include

boards/avr-rss2/include/board.h

herjulf · 2019-11-07T22:44:33Z

Thanks for review! Tried to address the comments in last the commit. More?

aabadie · 2019-11-08T07:41:57Z

boards/avr-rss2/Makefile.features

+CPU = atmega256rfr2
+
+# This board is based on an atmega CPU, thus import the features from it
+include $(RIOTBOARD)/common/arduino-atmega/Makefile.features


Is this board a clone of an Arduino ATmega ? If no, I would just remove this line.

boards/avr-rss2/Makefile.features

aabadie · 2019-11-08T07:46:14Z

boards/avr-rss2/board.c

+    LED_PORT |= (LED1_MASK | LED0_MASK);
+}
+
+void board_init(void)


This function is not needed since your board is already using board_init from common/atmega: rename this led_init.c and remove the useless board_init implementation.

aabadie · 2019-11-08T07:46:36Z

boards/avr-rss2/board.c

+#include "board.h"
+#include "cpu.h"
+#include "net/eui64.h"
+#include <string.h>


These system includes doesn't seem required.

aabadie · 2019-11-08T07:46:44Z

boards/avr-rss2/board.c

+
+#include "board.h"
+#include "cpu.h"
+#include "net/eui64.h"


aabadie · 2019-11-08T07:48:43Z

boards/avr-rss2/doc.txt

+* Light Sensor.
+* 32kHz RTC clock xtal
+* HW comparator chip and input. 
+* Progammable power FET, (relay) for power on/off of sensors.


Codespell should report this kind of typo: progammable => programmable. There's another one on the same word below.

aabadie · 2019-11-08T07:50:28Z

boards/avr-rss2/doc.txt

+for 3 seconds.
+
+Flashing hello-wprld line example 256k MCU:
+ avrdude -p m256rfr2 -c stk500v2 -P /dev/ttyUSB0 -b 115200 -e -U flash:w:bin/rss2-mega256rfr2/hello-world.elf


Isn't make BOARD=avr-rss2 flash doing this ?

aabadie · 2019-11-08T07:51:03Z

boards/avr-rss2/include/board.h

+ * @{
+ */
+#ifndef STDIO_UART_BAUDRATE
+#define STDIO_UART_BAUDRATE (115200)       /**< Sets Baudrate for e.g. Shell */


Define not needed, it's already the default value for stdio_uart

aabadie · 2019-11-08T07:51:58Z

boards/avr-rss2/include/periph_conf.h

+ * @name RTC configuration
+ * @{
+ */
+#define RTC_NUMOF    (1U)


Define is not needed.

aabadie · 2019-11-08T07:53:20Z

boards/avr-rss2/include/rss2.h

@@ -0,0 +1,39 @@
+


Please move these defines with proper doxygen documentation in board.h. Then remove rss2.h.

aabadie · 2019-11-08T07:57:21Z

Please also fix the issues reported by Travis.

herjulf · 2019-11-08T17:07:04Z

Thanks comments and improvements!
Most things should be addressed. So we give it a try.

miri64 · 2019-11-09T13:24:21Z

@herjulf please have a look at our contribution guidelines regarding formatting of commit and PR summaries.

maribu · 2019-11-12T12:28:32Z

@herjulf: I changed the PR description, as you accidentally entered the details between . This resulted in your text being treated as comments and hidden in the web site.

herjulf · 2019-11-12T16:43:16Z

Thanks a lot! My first PR just from the command line so more confused than usual. I'll push a better approximation for doxygen to see if travis gets happier.

herjulf · 2019-11-14T23:28:43Z

Thanks!. Pushing the changes.

boards/avr-rss2/Makefile.dep

benpicco · 2019-11-15T22:39:42Z

boards/avr-rss2/doc.txt

+
+### Flashing/Programming hardware
+Programming using avrdude using serial bootloader using a TTL-USB cable.
+Press the RESET button. The bootloader with wait for boot commands for 3 seconds. Program with:


Press the RESET button.

You should highlight this more.
With most boards that are flashed over UART the reset is triggered automatically by e.g. the CTS line.

At first I thought I connected it wrong or broke it by using 5V Vcc, but then I read the docs more carefully again.

Probably doesn't hurt to mention that the Vcc pin on the FTDI header is connected to the LDO, so supplying 5V is perfectly fine.

boards/avr-rss2/include/board.h

benpicco · 2019-11-15T23:16:05Z

boards/avr-rss2/include/board.h

+#define LED0_PIN            (1 << PE4) /* RED */
+#define LED1_PIN            (1 << PE3) /* YELLOW */


Are those the same on my revision of the board?
when I do saul write 1 1 in examples/default I'd expect the LED to light up.

benpicco · 2019-11-15T23:25:02Z

boards/avr-rss2/Makefile.dep

+USEMODULE += boards_common_atmega
+
+ifneq (,$(filter saul_default,$(USEMODULE)))
+  USEMODULE += bmx280


Suggested change

USEMODULE += bmx280

USEMODULE += bme280

bme280 is a pseudo-module that selects the bmx280 driver.
Also it looks like it doesn't have the driver-default I2C address of 0x77, so you'll have to define BMX280_PARAM_I2C_ADDR in board.h

i2c_scan reports

2019-11-16 00:22:49,213 # i2c_scan 0 2019-11-16 00:22:49,216 # Scanning I2C device 0... 2019-11-16 00:22:49,222 # addr not ack'ed = "-", addr ack'ed = "X", addr reserved = "R", error = "E" 2019-11-16 00:22:49,225 # 0 1 2 3 4 5 6 7 8 9 a b c d e f 2019-11-16 00:22:49,228 # 0x00 R R R R R R R R R R R R R R - - 2019-11-16 00:22:49,231 # 0x10 - - - - - - - - - - - - - - - - 2019-11-16 00:22:49,236 # 0x20 - - - - - - - - - - - - - - - - 2019-11-16 00:22:49,239 # 0x30 X - - - - - - - - - - - - - - - 2019-11-16 00:22:49,242 # 0x40 - - - - - - - - - - - - - - - - 2019-11-16 00:22:49,245 # 0x50 X - - - - - - - X - - - - - - - 2019-11-16 00:22:49,248 # 0x60 - - - - - - - - - - - - - - - - 2019-11-16 00:22:49,253 # 0x70 - - - - - - - - R R R R R R R R

Using the 2.4 Rev board? Should on 77. I see with
tests/driver_bmx280:

Temperature [°C]: 24.0
Pressure [Pa]: 101301
Humidity [%rH]: 46.72

In Contiki avr-rss2 port
#define BME280_ADDR (0x77 << 1) /* Alternative 0x76 */

BTW. There is a indoor AQ variant BME680. It can be soldered as a replacement for BME280. I did have sort of driver in Contiki. But the mapping to actual AQ was not knot known as that time.

Ah I got the 2.3a revision of the board.

0x58 is the EEPROM - what is 0x50 and 0x30?

edit: I just checked the data sheet - AT24MAC has two addresses, 0x50 for the EEPROM and 0x58 for the EUI functionality.

Still wondering what 0x30 is then.

AT24MAC has address selections pin. In avr-rss2 EUI chip get's 0xB0 and the EEPROM should get 0XA0 but I've never used the EEPROM actually you pointed out it was on another address. For 0x30 I'm confused. Where can I find the i2_scan your're using?

Where can I find the i2_scan your're using?

In e.g. examples/default add USEMODULE += i2c_scan to your Makefile.
Then it's available as a shell command.

@benpicco You had another AtMega256RFR2 board? Can you run i2c_scan on this?

I have a Microduino CoreRF with the ATmega128RFA1. It's basically just a breakout for the MCU with nothing connected but the bare necessities.
There i2c_scan prints

2019-11-18 13:46:59,160 # Scanning I2C device 0... 2019-11-18 13:46:59,239 # addr not ack'ed = "-", addr ack'ed = "X", addr reserved = "R", error = "E" 2019-11-18 13:46:59,240 # 0 1 2 3 4 5 6 7 8 9 a b c d e f 2019-11-18 13:46:59,241 # 0x00 R R R R R R R R R R R R R R - - 2019-11-18 13:46:59,242 # 0x10 - - - - - - - - - - - - - - - - 2019-11-18 13:46:59,243 # 0x20 - - - - - - - - - - - - - - - - 2019-11-18 13:46:59,244 # 0x30 - - - - - - - - - - - - - - - - 2019-11-18 13:46:59,245 # 0x40 - - - - - - - - - - - - - - - - 2019-11-18 13:46:59,246 # 0x50 - - - - - - - - - - - - - - - - 2019-11-18 13:46:59,247 # 0x60 - - - - - - - - - - - - - - - - 2019-11-18 13:46:59,248 # 0x70 - - - - - - - - R R R R R R R R

Thanks!
I desoldered the 24MAC602 chip

0x00 R R R R R R R R R R R R R R - -
0x10 - - - - - - - - - - - - - - - -
0x20 - - - - - - - - - - - - - - - -
0x30 - - - - - - - - - - - - - - - -
0x40 - - - - - - - - - - - - - - - -
0x50 - - - - - - - - - - - - - - - -
0x60 - - - - - - - - - - - - - - - -
0x70 - - - - - - - - R R R R R R R R

Same result. So it's the address chip. And reading the chip doc carefully on page 15. Chapter 11. Write protection:

Once the permanent software write protection
has been enabled, the device will no longer acknowledge the ‘0110’ (6h) control byte and cannot be reversed
even if the device is powered down.

So 0x30 addr will dissapear when EEPROM becomes write protected. So I think we solved this...

Alright, thank you for clearing this up.
So what about the LEDs? Are they wired different in version 2.3a?

Yes LED has same wiring. Actually the rss2.h I was asked to remove has very concise summary of the boards.

herjulf · 2019-11-18T22:20:40Z

EU requires all radio equipment to be approved by Radio Equipment Directive (RED) IoT stuff was a driving force behind this. Products having some kind of radio and put on the market must has this approval. Before RED the directive was R&TTE. Not fun but that's the way it is. Rev 2.3 was R&TTE Rev 2.4 is RED. So we can forget Rev 2.3.

boards/avr-rss2/include/board.h

herjulf · 2019-11-19T08:46:19Z

A bit off-topic but bme680 is in PR #12717. As said it can be mounted instead of bme280 for indoor AQ.

benpicco · 2019-11-19T12:17:53Z

boards/avr-rss2/Makefile.dep

+USEMODULE += boards_common_atmega
+
+ifneq (,$(filter saul_default,$(USEMODULE)))
+  USEMODULE += bmx280


Suggested change

USEMODULE += bmx280

USEMODULE += bme280

bmx280 is the generic driver, depending on whether you use USEMODULE += bme280 or USEMODULE += bmp280 different code paths are activated by #ifdefs in the driver.

Thanks. OK I see now. The driver is also checking chip-id. So it's a "feature" of the driver allow inconsistency. Yes patch needed. Anything more?

Actually we should probably add a warning if a pseudomodule is used directly…

benpicco · 2019-11-19T12:50:44Z

With the USEMODULE change this should be good.
Please squash directly.

benpicco · 2019-11-19T13:35:38Z

A bit off-topic but bme680 is in PR #12717. As said it can be mounted instead of bme280 for indoor AQ.

@herjulf you can always help advancing a PR by testing it or adding your comments :)

herjulf · 2019-11-19T13:49:05Z

@benpicco Yes there are many interesting PR in the queue. EUI64, async timer stuff, BME680, RDC. But also RFID are current interests. PM-sensors we're using and have in ported to Contiki. But this focus right now.

herjulf · 2019-11-19T14:16:46Z

The tests/leds is not working until led_init is added
also need a to declared.
board_init() was removed during the review process.
cpu/atmega_common/startup.c: board_init();

Seems like this has to be added and execute led_init()
Or any other suggestion?

benpicco · 2019-11-19T21:33:02Z

Uh this is actually a bug that got introduced recently when common code for the ATmega boards got factored out - will provide a PR with the fix.

Just one more nit: Please reword your commit message so it's consistent with the coding conventions.

Something like boards/avr-rss2: add AtMega256RFR2 based board would do.

Co-Authored-By: benpicco <benpicco@googlemail.com> Support: Alexandre Abadie aabadie, Marian Buschsieweke maribu, Martine Lenders miri64

herjulf · 2019-11-20T11:03:09Z

Fine. Happy to see #12745. I'll try a PR renaming,

benpicco

Code looks fine and tested on the board, this should be good.

herjulf · 2019-11-20T19:47:54Z

Thanks a lot! For the code review and the intro to the RIOT world and eco-system. First a beer. Later, at least my plan is to find a way to get the HW EUI64 get out.

benpicco · 2019-11-20T19:52:31Z

Later, at least my plan is to find a way to get the HW EUI64 get out.

#12746 should address that, the interesting part is how to wire it up with the rest of the stack so it get's used automatically when available.

benpicco added Area: boards Area: Board ports Platform: AVR Platform: This PR/issue effects AVR-based platforms Type: new feature The issue requests / The PR implemements a new feature for RIOT labels Nov 7, 2019

benpicco requested review from aabadie and maribu November 7, 2019 21:53

benpicco reviewed Nov 7, 2019

View reviewed changes

herjulf force-pushed the avr-rss2-PR branch from 43e1211 to d6cea36 Compare November 7, 2019 22:41

aabadie reviewed Nov 8, 2019

View reviewed changes

boards/avr-rss2/Makefile.features Show resolved Hide resolved

aabadie reviewed Nov 8, 2019

View reviewed changes

boards/avr-rss2/board.c Outdated

#include "board.h"

#include "cpu.h"

#include "net/eui64.h"

Copy link

Contributor

aabadie Nov 8, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove

aabadie reviewed Nov 8, 2019

View reviewed changes

boards/avr-rss2/include/periph_conf.h Outdated

* @name RTC configuration

* @{

*/

#define RTC_NUMOF (1U)

Copy link

Contributor

aabadie Nov 8, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Define is not needed.

aabadie reviewed Nov 8, 2019

View reviewed changes

herjulf force-pushed the avr-rss2-PR branch from d6cea36 to bd26c7a Compare November 8, 2019 17:05

herjulf force-pushed the avr-rss2-PR branch from 68a93e5 to 4ce95b6 Compare November 12, 2019 16:46

benpicco added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Nov 13, 2019

herjulf force-pushed the avr-rss2-PR branch 2 times, most recently from e6f3e11 to 04f24b1 Compare November 13, 2019 21:03

benpicco reviewed Nov 15, 2019

View reviewed changes

boards/avr-rss2/Makefile.dep Show resolved Hide resolved

benpicco reviewed Nov 15, 2019

View reviewed changes

boards/avr-rss2/include/board.h Show resolved Hide resolved

benpicco reviewed Nov 15, 2019

View reviewed changes

benpicco reviewed Nov 18, 2019

View reviewed changes