Tools for serial ports as container

[mikehaller]

It should be possible and easy for a Leda user to configure and troubleshoot serial ports.

Example use cases: Enabling GPS HAT requires testing via "AT" commands on serial port. Vendor documentaiton of the GPS HAT often is based on RaspiOS tutorials, which can rebuild .c files natively, and serial terminals like minicom are either preinstalled or can easily be installed via apt.

On Leda, it's much harder to get the tools installed. Our concept for that is containers. But there are no prebuilt containers for such tools (or they are very outdated, or for wrong platform etc.).

Leda should provide tutorial / documentation / preconfigured container descriptor or maybe even container images with the following tools (list is not exclusive):

• minicom - good for manual testing
• qmicli - mentioned/used in the Waveshare GPS HAT docs and scripts)
• maybe there are tools for "probing" serial ports (like nmap). If not, we may implement a simple one with pyserial, just probing for GPS or Modems by using "AT" commands.

It's also good to document how to configure the containers, e.g. do they need to run in privileged more, or can serial devices be mapped into Kanto containers etc. How does the sysfs filesystem under /sys mapped into the containers. Does it require write access or additional Linux capabilities (permission).

Current manual workflow:

for each serial device:
 stty -F 115200 /dev/ttyUSB3
 cat /dev/ttyUSB3
 echo "AT" > /dev/ttyUSB3

Let's focus on specific GPS and GSM devices.

[d-s-e]

I would suggest picocom instead of minicom. It has less dependencies and does the job. There is also a recipe available. stty is part of the system anyway.

If gpsd should run on the host, it would be good to have those tools also available on the host system. Depending on how Kanto provides serial access to containers, this could also help with debugging.

Another thought: Usually serial devices can only be used by one process exclusively, I don't know if that will work out with multiple containers that want to access the same device. BTW, this is one of the reasons, why software like gpsd exists.

[mikehaller]

Hm that's a good point.

The conceptual idea is to have services containerized, e.g. a "Location Service" which can be deployed or undeployed at runtime depending on the needs of the current situation. We also don't know whether the GPS module will be on the same device, or whether it is on another device in the vehicle network (a separate CCU, a separate HPC, ...)

The services expose their interface using a standardized higher-level API to vehicle applications (VSS via Kuksa.VAL databroker). In our example here, it could look like this: CAN -> NMEA2000 -> [container: gpsd + kuksa gps2val] -> [container: VSS databroker] -> [container: vehicle app] or another setup: Serial -> NMEA2000 -> [container: gpsd + kuksa gps2val] -> [container: VSS databroker] -> [container: vehicle app] or even this kind of setup: (CCU) -> Proprietary Location Information -> Some/IP via vehicle network (automotive ethernet) -> [container: custom2val] -> [container: VSS databroker] -> [container: vehicle app]

For the first two scenarios, the difference is only the configuration of gpsd, which is easily done via environment variable or config files mounted into a container. It's not a "static" system configuration per device model any more, but becomes part of the cloud-managed system configuration ("Desired State").

For the third scenario, the interface may be a customized, proprietary implementation, but from the viewpoint of the vehicle app, it's still the same interface. (These kind of things happen a lot in commercial setups)

The general idea of the SDV container layer is to "shrink" the layers related to the base system (OS, drivers, ...) and put more responsibility or flexibility into the top layers, which are more dynamic in nature.

Regarding the "the serial port can only be used by one process" topic: in production mode (eg once configured correctly), it would only be accessed by gpsd. in dev mode, I would stop the gpsd container and start the "serial-tools" container. This is great for development time, troubleshooting, hackathons etc.

And I would only install the deployment descriptors if I have a gps device.

[mikehaller]

graph TD;
    app-->databroker;
    databroker-->gps2val;
    gps2val-->gpsd;
    gpsd-->serial;
    gpsd-->CAN;
    databroker-->custom2val;
    custom2val-->SomeIP;
    SomeIP-->LocService;

[vasilvas99]

Tio can probe serial ports and work as a simple (good enough) terminal. Implemented in https://github.com/eclipse-leda/meta-leda/pull/198

With this I think the current issue can be closed.