Libosdp for Microcontrollers

[dmercer-google]

I've been working with libosdp on some microcontrollers which has required some changes to some of the core files because of limited support for things like message queues, files, serial port details, etc. In particular, I've got a port that integrates with the ESP32 VS Code ESP-IDF as a component running under FreeRTOS.

Is there any interest in adding these ports to the main libosdp tree? Maybe under a "ports" dir of the main repo?

Thoughts?

[sidcha]

LibOSDP treats embedded hardware as first class citizens and any change to the library to allow/ease adoption is always welcome.

That said, adding a platform specific "port" (at least the way I understood it) is probably not the best approach for a number of reasons.

If you already have a branch with the changes you had to make in these ports, I can take a closer look and respond.

[dmercer-google]

Understood.

It just occurred to me that the porting issues I faced were not so much with libosdp but with c-utils. Some changes had to me made to make libosdp into an ESP-IDF component but the MCU specific stuff was pretty much limited to c-utils.

There are several issues I've encountered porting to the ESP32:

1. The c-utils channel includes modes unknown to FreeRTOS (unix_bus, etc.) so the code wouldn't build. I cut them but they could easily be managed using CMake defines.
2. The c-utils serial port semantics are also very linux device driver centric and do not contain sufficient information to set up a micro controller (e.g. pin numbers, magic RS485 UART mode used by the ESP, etc.). The underlying mechanisms of flushing the UART buffers are different than is used on linux.

I ended up creating ESP32 specific versions of channel.c and serial.c.

When integrating libosdp and c-utils into the ESP-IDF I found that the stock CMakeFiles.txt was rejected because the IDF is very picky about what is in it so it had to be completely replaced.

I am now in the process of porting to an NXP processor and I am sure I will encounter even more MCU specific issues. All of which will be addressable but when you get down to dealing directly with hardware, I don't think there is a good way to do this in a one size fits all manner. Every platform will have its own way of doing things down at the hardware level.

I'm happy to share what I've done and I think that there is value in having ports to popular MCUs in the main repo if for no other reason than to serve as an example of what one might have to do to port to new metal.

[dmercer-google]

I uploaded the ESP32 version of c-utils for you to take a look at. There should be an invite for you in your inbox or something. If you are interested I can also upload the changes I made to libosdp.

[sidcha]

[..] The c-utils channel includes modes unknown to FreeRTOS (unix_bus, etc.) so the code wouldn't build.
[..] The c-utils serial port semantics are also very linux device driver centric

This wasn't an issue with the core library (built with CONFIG_OSDP_LIB_ONLY), but a glaring design flaw in tests, osdpctl, and python :). One which I noticed later when adding rust support and fixed :-). Now, LibOSDP core and rust/python module don't link with those problematic parts of c-utils.

If you are interested I can also upload the changes I made to libosdp.

With the latest version, I expect there to be no changes required. If it is not the case, we must make it so.