The last log was generally about finishing the setup of a development environment. In fact, it was ready to experiment with its own device, catching logs and communication. The next steps were pretty straightforward: configure the microprocessor, define protocols, set up FreeRTOS, and implement base logic.

Configuring a microprocessor is simple. As a framework, the STM32Cube through PlatformIO was selected earlier. It provides a pretty clear and almost low-level communication with hardware by HAL (Hardware Access Layer). But the most important thing here is the LIN interrupt handling. It is crucial as the LIN allows for a very short amount of time to receive a response to a request.

The time here is around 74us. So, it means that MCU should send its response in approximately 100us. The LIN bus can transfer the data frame in only one direction at the same time. It is the same as saying that LIN communicates in a format: request data processing by one frame and then grab the response using another one. Here, the delay is a lot bigger, almost infinity - 10ms. FreeRTOS has a lot of features, and one of the important ones here is the queues. Queues allow for organizing the work into a format that a Request PID sends the frame to the requests queue, and the response request PID just reads the result from the response queue. This approach allows for complete tasks in a non-blocking way and provides a lot more time for processing the exact job. The ECU can communicate in three areas: Hardware Buttons, BAP, and UDS. Each of them will have a pair of request-response queues. Additionally, the BAP protocol has a heartbeat functionality. Also, BAP and UDS have the possibility to send data by multiple frames, and it should be accounted for, too.

From this place, some logical structure already appears: route the request/response to the appropriate queue by PID, the exact queues, and task for processing queues. To prevent blocking of the router task, it will be wrapped in a separate FreeRTOS task too.

Now, it looks a bit simpler, and each task can be processed independently. It also gives great opportunities to have non-blocking processing, a queue of requests, and, most valuable, the free time for processing. It still does not include the business logic.

Still not a final, but a working one. UDS and BAP are pretty large ones, as they include the logic of combining data frames into a complete data request. Additionally, BAP has a heartbeat functionality. The simplest one is handling hardware buttons. The requests and responses are strictly related to the appropriate LIN PIDs:

• UDS Request queue handles the request frames from 0x3C PID.
• UDS Response queue stores responses for 0x3D PID.
• BAP Request queue handles the request frames from 0x1F PID.
• BAP Response queue stores responses for 0x20 PID.
• Buttons Request queue handles the request frames from 0x2E PID.
• Buttons Response queue stores responses for 0x2F PID

A lower-level diagram with hardware configuration and attraction shows the code organization for stuff like port configuring, drivers, etc.

Nothing specific here, just a classic configuration for regular MCU.