ChibiOS Free Embedded RTOS

Hello, I'm completely new to ChibiOS/RT and HAL but I've read the ChibiOS book and tinkered with the source codes to understand its structure, so I have some understanding.

I must make a decision about the application structure (should I use synchronous messages or events or buffer queues? etc..) and I'm still not very familiar with their internals, so any help will be appreciated. I don't want code, just advice about the general structure of the code.

There are two devices which talk to each other through USART using a well known protocol.
[nfo]------------ ------------
| | | |
| device 1 | | device 2 |
| >TX---------RX> |
| | | |
| <RX---------TX< |
|__________| |__________|[/nfo]
The protocol consists of messages of variable lengths:

0xFF 0xNN (0xNN bytes) (CRC)

I need to create a proxy (using a STM32 Nucleo board), a better word would be a MITM device:

[nfo]_ -----------------
|sens 1 |sens 2 |
| | |
| TX RX | TX RX |
|_V__^__|_V__^__|
\ \ | |
\__- / /
------------ -\\--||| ------------
| | |MITM | | |
| device 1 | | | | device 2 |
| >TX--->RX--TX>--RX> |
| | | | | |
| <RX---<TX--RX<--TX< |
|__________| |______| |__________|[/nfo]

As you can see the MITM uses 4 USART interfaces. Depending on the 2 sensors data the MITM should add/edit/delete packets in either direction (transparently for the device 1 and device 2).

It can't just blindly pass the data. It should get a packet, parse it, make a decision (about deleting or editing) based on sensors information and only then pass (or not) it forward, possibly with additional (inserted in between) data packets.

What threads and communication mechanisms between them do you suggest to use?

Thank you for your time!

Hi,

If you have 2 threads handling the two ports in the MITM device then you could use 2 mailboxes that would form a bidirectional queue of packets. In addition you could get/release packet structures from a memory pool. The size of the pool should be the depth of the mailboxes X2.

The decision about editing/discarding packets would be done on the side of the thread posting in a mailbox. The two threads could notify each other about packets available in the mailboxes using events.

You could also use 4 threads and do not even need events:
1) Reads RX1 posts in MB1.
2) Writes TX2 fetches from MB1.
3) Reads RX2 posts in MB2.
4) Writes TX1 fetches from MB2.
This way each thread would wait for a single thing, no multiple events needed.

I could sound complex but it is quite trivial, look into: mailboxes, pools, events.

About HAL, you could use both the serial driver or the UART driver. Serial is usually easier to use, UART is more efficient because DMAs.

Giovanni

Grazie!

Really, your post is very helpful, thanks a lot.

I'll try to go with 4 threads (or even more, because I need to talk to sensors too).

Concerning UART vs. Serial, I think I'll go with UART for its speed because there is constant flow of messages at 57600bps in both directions (commands, reports, acknowledgements, pings, etc.).

Now it's time to code