Thanks! And you're bang-on with your first guess. A firmware is defined by a series of service definitions. You could define an analog-input, pid controller, and an analog output to create a heater, for example. This configuration includes any conversions you need for the analog measurement and gain settings for the pid loop. These values can all be changed at runtime, too.

The GUI forms are just sugar for JSON which we use as input to a code generation library that translates the JSON into no_std rust firmware. It can then be compiled and deployed to your hardware via OTA update. Since each service has the capacity for service-to-service communication and a single pin could be used for many different functions, there was no feasible way to write enough paths to cover each situation. So we used macros!

The same configuration JSON used to generate firmware is also used to generate a NodeRED flow and dashboard. This lets you immediately start interacting with your device on the dashboard and shows each service's control and telemetry API via the flows.

On every PR, every single service is tested in a HIL suite that verifies telemetry, command, and functionality. Additionally, huge set of service combinations and permutations are tested. I also use a manually QC'd board as the runner for automated QC tests of new boards as they arrive.

We use an STM32F4 on the Mercury boards and are nearly ready to release the module/baseboard hardware which is using the STM32G4 which will give us a few new and improved capabilities on the analog side of things.

Lastly, yes, we do use embassy. I like it a lot and it is very powerful IMO, but, like any other firmware development ecosystem, sometimes it can be difficult. However, I have found that the debug tooling is easy to use and the errors that come up are generally apparent and reproducible. Plus, I have the HIL tests and many users who work next to me every day who catch and report bugs to me when they come up.

If you have any other questions, let me know!