slot configuration not completely implemented

[cuvoodoo]

this is more a status report from trying the project, since the README does not mention it.
currently it is not possible to configure the IO boards on the slots.

cgi_config_ioBoards_config in webserver.cpp is actually implemented, and is reachable using an HTTP request (such as http://169.254.59.1/config/ioBoards/config.json?slot=0&boardType=3&port0dir=3&port0con=2&port1dir=3&port1con=2&port2dir=0&port2con=0&port3dir=0&port3con=0 , values are from boardconfig.h ), but the configuration is not reflected back (in the UI or functions).

currently 4 DMX outputs is hard coded and this can't be changed using the config.

[kripton]

Perfectly fine if this is more a status report. Reminds me to add a section about what actually works and what doesn't to the Readme. Thanks :)

cgi_config_ioBoards_config is a function that is not necessarily meant to be used by "end users" since it overwrites the "personality" of attached IO boards. The personality is actually given by the hardware, i.e. the type of board. Every IO board has an on-board I2C EEPROM so that the base board can detect it and see what type of board it is. The function you found is to "program" "new" boards that have an empty EEPROM so they know which hardware type they are. (Hint: Current IO boards' EEPROM is small (256 byte if I remember correctly). I plan to use larger ones in the future to be able to store WiFi configuration and other stuff)

The WebUI will only show IO Boards actually present, no matter how you configured them. The "personality" of the IO boards is only stored on them, not on the base board. This makes it possible to have completely different configurations depending in which order you arrange your IO boards..

If you call it without IO board attached (or with nothing at all on the I2C bus), the firmware will try to write an EEPROM that doesn't exist. That should fail but I'm not sure if error reporting is implemented for that function.

If you call it while the IO board is actually connected, it should at least be detected correctly after a board reset. The IO boards are scanned and enumerated as the firmware starts up.

Regarding your "currently 4 DMX outputs is hard coded and this can't be changed using the config": Yes and No. If there are IO boards connected (or more simply: EEPROMs on the I2C bus), they should show up. If the content of the EEPROM tells the base board that it's an "4-input" or an "2-port-IN/OUT/RDM"-board, it should show up as such. However, since at the moment only DMX output is implemented, connecting or emulating any other board than the "4 outputs" won't do much.
DMX input is WIP in this branch: https://github.com/kripton/rp2040-dongle/tree/dmxIn. It's basically working but all the infrastructure around it (support for different IO board types, configuring the PIOs correctly and buffer patching) is still TODO.