Port discussion

[Cyril-debug]

Hello Rob,

It seems that echidna is using ev library for:

• Software timer
• Signal capability
• One (or multiple) threads

Is it possible to change the mechanism by using:

1. A thread waiting for events (a periodic timer and signals)
   • Windows: WaitForMultipleObjects()
   • FreeRTOS: xQueueReceive()
   • Linux: Don't know yet
2. A dedicated timer (running at 10ms or faster) thats unblocks 1)
   • Windows: Usage of periodic timer (timeSetEvent() or new API)
   • FreeRTOS: Usage of kernel timers (xTimerCreate() + xQueueSend())
   • Linux: Don't know yet
3. Management of signals will send dedicated type of message
   • Windows: Usage of a semaphore
   • FreeRTOS: Usage of message queue (xQueueSend())
   • Linux: Don't know yet

It will simplify port to other platforms.

What do you think ?

Best regards,
Cyril

[61131]

Hello Cyril,

Your summary is accurate and very much on-point.

This being said, the use of a common library for timing (libev) was a deliberate decision, primarily for portability reasons, as earlier versions of this code used a custom select-based timing loop. I had looked at other libraries including libevent and libuv, but settled on libev due to maturity, platform support, and interface preference. The libev library is supported on Windows, Linux, Mac OS X, although I have not personally tested echidna on anything other than Linux. A different abstraction would be required for operation on FreeRTOS - For such an implementation however, I would probably look at significantly cutting down echidna into separate compiler and run-time components (which is where this code base originally started).

What platforms/use-cases are you looking to support?

Regards,
Rob

[Cyril-debug]

Rob,
The goal is to have a small architecture to do something like https://soda.crouzet.com/pn/?i=88983902 with or without OS.
Platform is not yet defined.
The plan is to try on Windows to evaluate the solution and then move to final solution.
I think, it is only a personal point of view, that having a dedicated high level API with libev implementation will offer the capability to the user to use a different implementation.
But, it's true, if I need a FreeRTOS port for libev, I have to do it.

Regards,
Cyril