Add Raspberry Pi Pico platform

[sashacmc]

This pull request adds support for the Raspberry Pi Pico series to Zenoh-Pico, enhancing compatibility with a wider range of embedded platforms. The main changes include:

• A system layer based on FreeRTOS.
• An IP network layer utilizing lwIP, integrated with the Raspberry Pi Pico SDK.
• A serial network layer based on the Raspberry Pi Pico SDK.
• A USB serial network layer based on TinyUSB, integrated with the Raspberry Pi Pico SDK.

These additions extend Zenoh-Pico’s capabilities, enabling efficient, scalable communication for IoT and edge computing applications on popular microcontroller platforms.

[github-actions]

PR missing one of the required labels: {'bug', 'new feature', 'dependencies', 'breaking-change', 'enhancement', 'internal', 'documentation'}

[cguimaraes]

Since you are relying on FreeRTOS for this port, any specific reason for not using (and maybe extending) the existing freertos_plus_tcp port?

[sashacmc]

Since you are relying on FreeRTOS for this port, any specific reason for not using (and maybe extending) the existing freertos_plus_tcp port?

It was my original idea, but, unfortunately, freertos_plus_tcp don't support this Wi-Fi module yet.
(Zephyr is also not supported yet, although a PR on this topic recently appeared there, but when it will be finished and when it will be released is unclear.)
I am also currently making serial port support for this board, which will also require implementation based on the Raspberry Pi Pico SDK

[ur8us]

I am also currently making serial port support for this board, which will also require implementation based on the Raspberry Pi Pico SDK

Thank you!

It would be very, very nice to have an example or two of how to reconnect to the zenoh router if something goes wrong: either during initial connection attempts, and also during the established session.

[ur8us]

I am so pleased to see to see the serial port support added for my lovely RPI Pico boards. Thank you so much!
For completeness, it only lacks the USB serial port support, the main method how people actually connect their RPI Picos to computers.

[sashacmc]

It would be very, very nice to have an example or two of how to reconnect to the zenoh router if something goes wrong: either during initial connection attempts, and also during the established session.

It is currently expected behavior that Zenoh does not support serial port reconnection if the link is dropped. We are actively working on a fix.

[sashacmc]

I am so pleased to see to see the serial port support added for my lovely RPI Pico boards. Thank you so much! For completeness, it only lacks the USB serial port support, the main method how people actually connect their RPI Picos to computers.

Great idea, thanks!
I liked it so much that I couldn't go to bed until I checked its functionality, and when I checked it, I decided to finish it.
This will be enabled by a separate flag, since this is an experimental feature.

[sashacmc]

And so far I haven't figured out how to best solve the startup problem. While Pico is not running, the /dev/ttyACM0 is missing and Zenoh cannot open it, but as soon as it appears, zenoh-pico tries to open a session, but cannot, since Zenoh has not yet been launched. At the moment, I have made a stub in the form of a 10s timeout between enabling the port and the start of opening the session (to start the router at this moment). I'll think about it with a fresh mind.

[ur8us]

It would be very, very nice to have an example or two of how to reconnect to the zenoh router if something goes wrong: either during initial connection attempts, and also during the established session.

It is currently expected behavior that Zenoh does not support serial port reconnection if the link is dropped. We are actively working on a fix.

Thank you!

What I mean here is an example of how to handle a case when, for instance, the zenoh router has not been started yet but the microcontroller is already active. All existing examples just print an error message and halt. It should be demonstrated how to handle this case to get connected to the router ASAP. Another real-time situation is when the router shuts down or reboots. What exactly should the microcontroller do?

[ur8us]

I am so pleased to see to see the serial port support added for my lovely RPI Pico boards. Thank you so much! For completeness, it only lacks the USB serial port support, the main method how people actually connect their RPI Picos to computers.

Great idea, thanks! I liked it so much that I couldn't go to bed until I checked its functionality, and when I checked it, I decided to finish it. This will be enabled by a separate flag, since this is an experimental feature.

Definitely, with better support of serial ports in zenoh, people will get attracted to use CDC. Most boards which are already supported by zenoh-pico already have a USB link.

[ur8us]

And so far I haven't figured out how to best solve the startup problem. While Pico is not running, the /dev/ttyACM0 is missing and Zenoh cannot open it, but as soon as it appears, zenoh-pico tries to open a session, but cannot, since Zenoh has not yet been launched. At the moment, I have made a stub in the form of a 10s timeout between enabling the port and the start of opening the session (to start the router at this moment). I'll think about it with a fresh mind.

Thank you!

Please take a look at handling of the serial ports in the terminal window of the Arduino environment. Unlike traditional terminals, this one was specifically designed for handling of serial ports which can can suddenly disappear from the system. Obviously, this happens very often when the user is debugging a program :-) The terminal window automatically activates when the selected port appears in the system, and gets deactivated if the port disappears.

As you see, this is all not a magic and the proper serial port handling can be added to the zenoh router, as well.

I can think of a scenario when, on the startup of the RPI, a script collects information about all serial ports in the system, select the ones we are interested in (for example, by specific VID/PID combination) and then configures zenoh to use these ports:

-l "serial//dev/ttyACM0#baudrate=115200" -l "serial//dev/ttyACM1#baudrate=115200"

There is another interesting issue with serial ports naming, which you can check yourself. Suppose a program opens /dev/ttyACM0, then the microcontroller resets, then the port re-appears in the system under a different name, such as /dev/ttyACM1. This is because the program still holds the port's file handle.

I can imagine how to handle this in a good way:

1. The program should release the serial port's file handle ASAP after the communication error occurs.
2. Instead of regular symbolic names -

-l "serial//dev/ttyACM0#baudrate=115200"

we can open a serial port by location -

-l "serial//dev/serial/by-path/pci-0000:00:14.0-usbv2-0:1:1.1#baudrate=115200"

I hope this info will be usefil.

P.S. Please take a look at a new proposed "H" byte in the serial protocol, I think it does not make sense.

https://github.com/ZettaScaleLabs/z-serial/pull/9

[bjsowa]

I see that you based the system implementation on the FreeRTOS port which I wrote and you added condition variable support. Hope you don't mind me using it in #821 .

[bjsowa]

@sashacmc Could you consider just using system.c from freertos_plus_tcp port, especially after #821 and #822 is merged. This would be less code to maintain, as both ports share 99% of the system implementation.

[sashacmc]

@sashacmc Could you consider just using system.c from freertos_plus_tcp port, especially after #821 and #822 is merged. This would be less code to maintain, as both ports share 99% of the system implementation.

@bjsowa There is a lot of duplicate code in many platforms now, I have plans to move it into common modules, this will be done later. At the moment, using code from one platform for another would be breaking the current architecture.