r/embeddedlinux

Hi everyone,

I am working on continuous UART communication between an STM32H563 and a Linux-based application processor such as RK3568, Raspberry Pi, or similar embedded processors.

Current setup:

• MCU: STM32H563
• Peer device: Linux-based processor (RK3568 / Raspberry Pi / similar)
• Communication: UART
• UART mode: Interrupt mode
• Hardware flow control: Disabled (RTS/CTS not used)

Issue:

During continuous high-frequency communication, I am frequently getting UART ORE (Overrun Error) on the STM32 side. Once ORE occurs, incoming data gets lost and communication becomes unstable.

I would like to understand the best industry approach for handling this kind of communication reliably without hardware flow control.

Questions:

1. What is the best workaround to avoid ORE errors without enabling RTS/CTS?
2. Is continuous UART communication considered reliable without hardware flow control in production systems?
3. What UART settings or software architecture are recommended for STM32H5 series?
4. Is DMA reception mandatory for stable high-throughput UART communication on STM32H563?
5. What is the proper ORE recovery sequence on STM32H563?
6. Are there recommended buffering or packet-handling strategies when communicating with Linux processors over UART?

Additional details:

• Using HAL UART interrupt APIs currently
• Bidirectional communication is frequent
• Packet sizes are variable
• Looking for a production-grade reliable solution

Would appreciate suggestions, best practices, or reference implementations from anyone who has handled STM32 ↔ Linux processor UART communication in real products.

Thank you.

Evaluating adding Qualcomm to the supported silicon list on our embedded Linux platform.

Currently shipping production on Jetson, imx, pi 4/5, and others.

Previous round of Qualcomm work was choppy. Rough areas were around:

- BSP source fragmentation (Linaro QCOMLT, Qualcomm direct, board vendors)

- Kernel and Yocto release alignment

- Blob and licensing handling

- General integration overhead

For reference, Jetson BSP refresh runs us 3-4 engineer-weeks at minimum.

Curious whether things have improved, especially on robotics-class parts (QRB5165, QCS6490, IQ-9, Dragonwing).

How much engineering overhead per BSP refresh are folks seeing today vs Jetson or i.MX? Worth supporting at production grade?

Hi all,

We are designing a commercial drink vending machine platform and would appreciate guidance from engineers who have worked on large-scale embedded/Linux/Android deployments.

This is a production system (not a prototype), targeting ~50,000+ machines, with a subscription-based business model. Reliability, OTA robustness, and long-term maintainability (5–7 years) are top priorities.

Current architecture:

• STM32 for real-time control (pumps, sensors)
• Planning Linux/Android SOM for:
  • UI (ads, videos, touch)
  • Networking (Wi-Fi + cellular fallback, GPS)
  • Cloud (AWS MQTT)
• 24/7 uptime, no planned reboots

Key questions:

1. OS: Linux vs Android (AOSP)

• Linux (Yocto/Debian): more control, no GMS, easier long-term maintenance?
• Android: faster dev, better ecosystem?

👉 At scale, what actually breaks?

• Memory leaks / long uptime issues?
• OTA failures?
• Security updates after BSP EOL?

2. SoC: RK3568 / RK3588 vs i.MX8

• Need: industrial temp, 5+ year supply, stable BSP
• RK3588 looks strong (NPU + media)
• i.MX8M Plus offers long lifecycle + stability

👉 Real-world experience with BSP stability & supply?

3. OTA (most critical)
Planned:

• A/B partition
• Delta updates
• Considering RAUC / Mender

👉 Looking for:

• What are you using in production?
• Handling power failure mid-update?
• Rollout strategy (canary % / rollback triggers)?
• Lessons when scaling to 10k+ devices?

4. UI stack

• Currently: Qt6/QML
• Considering: Flutter

👉 Is Qt still the safest long-term choice for embedded?
Any production use of Flutter in similar systems?

Goal:
Build a system that:

• Never bricks in the field
• Scales to 50k+ devices
• Supports OTA + future AI
• Minimizes long-term maintenance risk

Would really value insights from anyone who has worked on:

• Kiosks / vending machines
• Digital signage
• Large-scale IoT deployments

Thanks!

1. Architecture & Implementation

• Partitioning via Buildroot: Architected a strict A/B partition layout to completely isolate the Kernel and RootFS. Decoupled user storage (/data, /user) to guarantee data persistence across updates. Selectively applied specialized filesystems (e.g., ext4, squashfs, ubifs) optimized for specific read/write characteristics and system security requirements.
• Custom U-Boot & Flash Memory Mapping: Recalculated memory maps and offsets to allocate a dedicated, isolated flash sector for the U-Boot Environment. This ensures U-Boot accurately locates OTA variables while completely eliminating the risk of accidental overwrites by the Kernel or RootFS.
• Userspace IPC & C++ OTA Daemon: Integrated fw_printenv/fw_setenv utilities for secure userspace interaction with the Flash Environment. Developed a robust C++ OTA Manager daemon to handle the deterministic state machine, providing clean APIs for higher-level applications (Web/App) to easily orchestrate the update process.
• Firmware Packager: Automated payload generation to abstract complexity from the Web/App layers (exposing only a single compressed archive). The toolchain automatically embeds metadata, versioning, and cryptographic signatures, allowing the device to rigorously verify firmware integrity prior to installation.

https://preview.redd.it/p4s9us3kthyg1.png?width=778&format=png&auto=webp&s=1d1f79440656f8ffd8bb7249e7102300431901ed

2. Validation & Resilience

The system is engineered for high availability and autonomous recovery under the most extreme edge cases:

• Scenario 1 – OTA Rollback (Logic Error / App Crash): If the update completes and the Kernel boots, but the primary application enters a crash-loop, the service monitor automatically detects the failure state and transparently triggers a rollback to the previous working partition.
• Scenario 2 – System Fallback (Physical Error / Data Corruption): If the active partition degrades over time (e.g., bad blocks or corrupt data) resulting in a boot failure, the Hardware Watchdog or U-Boot intervenes to automatically fall back to the redundant standby partition.
• Scenario 3 – Power-Loss Tolerance: Fully mitigates sudden power failures during firmware downloads or while writing to the offline flash partition. The architecture guarantees the device will never be bricked, ensuring it always safely boots back into the intact active partition.

I'm in my 4th year of computer engineering BS, and for the last ~4mo I've been working on an Debian-based aerospace application. My issue is that... I'm obsessed; and I think it's taking a toll. The optimization problems are so fun and interesting, but lately I get fatigued so quickly. Linux and embedded systems just feels like this inexhaustible source of new topics; so what helps you stay focused and motivated?

It probably doesn't help that I'm taking a full-time class load, volunteering with student orgs, networking, and working a part-time engineering gig...