board config files

[biot]

The current board configuration system requires two entries in platformio.ini, and a lengthy entry in config/hardware.h. Since the config is based solely on C definitions, it's also not very flexible. For example, declaring multiple values would run into a syntax problem, and necessitate a clumsy workaround to get it configured.

Instead, I propose doing per-board configuration files, in .ini style like platformio for convenience. This would include all configuration currently in hardware.h, but opens the way for better future expansion: it's a much more flexible way to declare config.

Adding a new board is just a matter of adding a single, small config file.

The device config file gets read during the pio run stage, which is called with the board name in the environment variable ESPURNA_BOARD, and converted to entries in BUILD_FLAGS. The board name has an entry in the top-level devices/ directory, with .ini extension.

I'm adding a first patch (on top of dev branch) that does the above, and adds config files for all known devices. These were auto-generated from their hardware.h entries so as to avoid pin number mistakes when transcribing. Some comments were preserved where possible. This saves tons of entries in platformio.ini, and removes the hardware.h file entirely.

Not everything is finished, but I wanted to get some comments in before I take this further.
I test with the Sonoff Dual R2, and certainly it works there, but that means I've only really tested config entries for manufacturer/device, buttons, relays and LEDs. Other definitions from hardware.h get translated just the same to .ini entries, but may not generate the right BUILD_FLAGS definition yet. That's the following .ini sections:

• cse7766
• dallas
• debug
• dht
• dummy
• hlw8012
• led1
• light
• my92xx
• relay

...and lots of keywords in those sections, everything but pin/pin_inverse/relay/type. Lots of these will do the right thing, but are just unchecked/untested.

Code is here: https://github.com/biot/espurna

[mcspr]

Isn't it just trading one format for the other? And Arduino IDE compatibility is still expected, so you might want to generate hardware.h back from the device configs instead of removing it :) (see code/espurna/config/arduino.h) One can also include custom platform.txt, but idk how it would look for this many boards.

As for numbered tokens, there are actually more options:

1. Name them instead. Some section naming trickery?

[button:green_one]
pin = 0
...

[relay:main]
button = green_one
pin = 3
...

2. Have it like you propose, but use .ini list syntax and have some substitution in place (examples from biot/espurna still use button1, button2, [light]/ch1_... etc.):

[switch]
input_pins =
    0
    4
output_pins =
    3
    5
input_mask = 0b10 0b10 // or without '0b' - "mask" input output relation. "pin 0 -> pin 3, pin 4 -> pin 3. pin 5 not used (but declared as possible option)"
input_type_default = pushbutton
input_value_default = high

i.e. translate this as "when pins 0 4 go high->low toggle pin 3 output value (default low, may be explicitly set though)". although, index just goes to mask instead...

3. Or just create array directly instead of managing indexes in names at all and figure out things at runtime (yet, with coming software pin<->relay via config, might be better option)

const PROGMEM whatever button_pins = {1, 3, 4};
... relay_pins = {3,5}
... mask (as before) ...

Sidenote: it is possible to store structs in progmem alike everything else and just memcpy_P at runtime.

[biot]

I think you get the idea -- this format opens up a lot of possibilities wrt more flexible options, stuff that is hard enough to express in hardware.h that it probably holds back features that require this.

There is a LOT of demand for more custom handling of buttons, events etc. The project HAS to be able to express this in config, or you're forcing people to hardcode their functionality in non-upstreamable forks.

However, before that happens the codebase needs to switch over to the board file format. The best way to do that is to switch with feature parity, nothing more, and only when it's all verified and working start getting creative with the options.

[Valcob]

@biot Could you please help me I cant get your code working have this error line 9, in
Import("env")
NameError: name 'Import' is not defined

[biot]

genboards.py is run by platformio, you can't run it directly. To build for a board:

ESPURNA_BOARD=itead-sonoff-dual-r2 pio run

[Valcob]

genboards.py is run by platformio, you can't run it directly. To build for a board:

ESPURNA_BOARD=itead-sonoff-dual-r2 pio run

yeah, sorry, already got that :)

[xoseperez]

I like the idea and it's certainly more readable than the current monster platformio.ini file.

One of the goals for v2 is to not only reduce the board definition files (platformio.ini, hardware.h) but also to have fewer binaries and being able to configure the device at runtime. So those configuration files are coded as JSON files of key-values in the v2 branch.

Now my question is: having fewer binaries is really a benefit? Are users looking for a specific binary for their devices or will they be ok with having to configure or loading an extra configuration file for the device?

[biot]

You can have both. Nothing about this stops you from compiling a few binaries with different feature sets, tacking on a runtime config device tree style, and putting those up for download.

However that's sort of separate from this board config file issue. As I mentioned earlier, I think it's more important to make headway by switching to a board config file-based build and do away with the big platformio.ini/hardware.h setup, and only then start looking into extending the board config format, or using it as a runtime format. It's just much easier to do a gradual switchover this way.