Split config files into UI and pinout fragments - #54
Split config files into UI and pinout fragments#54Milosz Wasilewski (mwasilew) wants to merge 8 commits into
Conversation
|
Milosz Wasilewski (@mwasilew), could you share why this change is needed and which use case it addresses? |
|
This is an attempt to make configs available to any possible client. You can think about it as an alternative approach to #41. The end goal is to move the UI independent configs to a separate repository and import them through git submodule. This way there would be a single source of truth for any client to use with alpaca debug boards. |
|
Milosz Wasilewski (@mwasilew) , I understand your request to split the configuration into UI and pin mappings but it leads to tracking two different files (versioning, loading, mapping). Typically, we want users to leverage the TACDev APIs to control the board without worrying about configurations. Are you running into a limitation with the Python TACDev module that we can help address? |
When using CMake=3.22 as advertised in the top level CMakeLists.txt, the build fails because of how cmake expands lists. This version of cmake treats the target_link_libraries argument as a list and splits on ; before evaluating the generator expression — tearing $<$<CONFIG:Debug>:foo;bar> into $<1:foo + bar + bar> and leaking the broken fragments to the linker. Proper syntax demands quotations. This feature changes in version 3.23 Kitware/CMake@c1e812ad4f3 Signed-off-by: Milosz Wasilewski <milosz.wasilewski@oss.qualcomm.com>
|
Biswajit Roy (@Biswajee) The only "unique" part of the project is the config. Config files describe how to interact with the debug board hardware. The rest is "implementation detail". I'd like to enable alternative clients to talk to the debug boards without requiring to carry all the overhead and dependencies that QTAC introduces. If the configs are maintained as a part of a separate repository any project (including QTAC) can import them as submodule. This would prevent fragmentation. IMHO this is a preferred solution over copying the config files which inevitably leads to fragmentation. This PR also includes a fix for CMake. I moved it to #76 so it can be merged without the functional change. I'll rebase once the merge is done. |
Signed-off-by: arko816 <reach.arko112@gmail.com>
Added fix for TACDev.dll generation
Fix CMakeLists.txt files for all applications
Original configuration files describe both automation interface pinout and the UI for Qt application to present the controls. This patch splits the UI and pinout into separate files. This allows to re-use the pinout files without carrying any UI related configs. Platforms address a pin differently - chip_index + bus + pin_number for FTDI/PSOC/PIC32CX, a single pin for STM32 - so every addressing field is treated as an identity key, kept in both halves and used to join them back together on load. Signed-off-by: Milosz Wasilewski <milosz.wasilewski@oss.qualcomm.com>
Split the schema files into two following the split of the config files themselves. This allows to validate the pinout and UI config files separately. Signed-off-by: Milosz Wasilewski <milosz.wasilewski@oss.qualcomm.com>
A "GPIO with I2C" board drives some pins through an I2C GPIO expander, described by variant, slaves[] and i2c_addr[]. All three were landing whole in the .tcnf UI overlay: i2c_addr[] mixes the expander address and hardware behaviour with labels and grid placement, so the hardware half was only reachable by parsing the UI file - exactly what the pinout file exists to avoid. Partition them the way pins[] already is. variant and slaves[] describe which expander chips are fitted, so they move to the pinout file whole. i2c_addr[] is split per entry: pin_number + slave_addr + write_addr identify the pin and are repeated into the overlay's "ref", command/inverted/classic_action travel with the hardware, and the rest stays in the overlay. The per-entry logic is now shared with pins[] rather than duplicated. write() also has to persist variant. read() already looked for it, but nothing ever wrote it, so a saved GPIO+IIC board reopened as ePSOCUnknown and the guard in write() then dropped its slaves and i2c_addr - editing an existing config silently destroyed its entire I2C configuration. Signed-off-by: Milosz Wasilewski <milosz.wasilewski@oss.qualcomm.com>
Opening a configuration can now fail in a way it never could before the split: the .tcnf reads fine but the *.pinout.json it references is missing, unparseable or not a pinout file. Copying a .tcnf on its own is an easy mistake to make. openPlatformConfiguration() ignored load()'s return value, so all of those cases handed the caller a default-initialised board that looked valid. In the editor that meant a config for a different board silently appeared under the opened file's name, and saving it wrote that default over the user's settings. Discard the half-built configuration instead, and report which file failed and why - the editor previously did nothing at all on a failed open. Saving now also names the pinout file it wrote alongside the .tcnf, so the second half of the pair is visible rather than implied. Signed-off-by: Milosz Wasilewski <milosz.wasilewski@oss.qualcomm.com>
a080fe9 to
1c3bea5
Compare
3 participants
Pull Request
Description
Split the config files into UI and pinout related parts. This will allow to re-use the pinout files externally without carrying all the UI related configs
Type of Change
Please delete options that are not relevant.
Checklist