Allow external TCP/UDP support for udp_transport_datagram_internal

[driftregion]

Hello,
I'm building for a FreeRTOS-based platform using FreeRTOS-Plus-TCP. Its socket API lacks the functions and structs defined in linux's <sys/socket.h> .

My toolchain file contains:

set(CMAKE_SYSTEM_NAME Generic)

I'm able to make use of the sensible defaults for UDP and TCP defined in udp/tcp_transport_internal.h for the transport functionality. I'm compiling Micro-XRCE-DDS-Client as a static library. The implementations of the stubbed functions (using FreeRTOS-Plus-TCP) are inside my application code. All is well at link time.

I can't do the same thing for udp_transport_datagram_internal.h, because it defines uxrUDPTransportDatagram such that there's no means for extension

I propose something like this:

typedef struct uxrUDPTransportDatagram
{
    uint8_t buffer[UXR_UDP_TRANSPORT_MTU_DATAGRAM];
#if defined(UCLIENT_PLATFORM_POSIX)
    struct pollfd poll_fd;
#elif defined(UCLIENT_PLATFORM_WINDOWS)
    WSAPOLLFD poll_fd;
#else
    void *poll_fd;
#endif

[julionce]

Hi @driftregion,

Yes, it could be a short-term solution, but I think a more appropriate way is to handle FreeRTOS platform similar to nuttx or LwIP. For this purpose the following changes are required:

• Modify CMakeLists.txt to support freertos PLATFORM_NAME.
• Move uxrUDPTransportDatagram type declaration to udp_transport_datagram_posix.c and udp_transport_datagram_windows.c.
• Create a udp_transport_datagram_freertos.c with its own uxrUDPTransportDatagram type (it seems that FreeRTPS-Plus-TCP` has a pollfd structure.

You can purpose the short-term solution by a PR and we will create an issue in order to put in the roadmap the long-term solution.

[driftregion]

Got it, thanks @Julibert
I wrongly assumed that supporting FreeRTOS-Plus-TCP was out of scope. I've got a workaround for this now. Let's work towards the long-term solution.

[driftregion]

@Julibert, I'm attempting the long-term solution.
Question: does LwIP guarantee a clock_gettime? I'm curious where that comes from when compiling for LwIP targets.

I find that the FreeRTOS-Plus-TCP headers depend on FreeRTOS.h, which in turn depends on a slew of port-specific headers. Since this is a cross build (these aren't system headers), I think we need a mechanism for passing a set of include paths to microxrcedds_client when building it.

I'm currently doing this by including the following in ExternalProject_Add

CMAKE_ARGS
    -DCMAKE_PROJECT_microxrcedds_client_INCLUDE=${CMAKE_CURRENT_LIST_DIR}/microxrcedds_client_include_patch.cmake

where microxrcedds_client_include_patch.cmake is

include_directories(
...
)

This is my current working approach. I'm new to CMake. Is there a neater way of doing this dependency injection?

[FranFin]

@driftregion Hi! Thank you for your interest in Micro XRCE-DDS. Notice that we’ll discuss the recent contributions and developments in the next Embedded WG meeting. You’re invited to bring your Micro XRCE-DDS related issue to this platform. We’ll be very happy to have you join us and discuss your questions with the community.