u/Unfair-Reception856

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.

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.

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.

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!

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.

System Overview:

• MCU layer (STM32) for real-time machine control
• Planning to add a high-level display controller, Network management (Wi-Fi + GSM), Cloud Communication and Data Store and Handling (Linux or Android)

Functional Requirements:

Display / UI:

• Ads (images, GIFs, videos)
• Instruction & service videos
• Future: dynamic UI updates from cloud

Connectivity:

• Wi-Fi + Cellular (SIM)
• GPS support

IoT:

• MQTT-based cloud communication (AWS)
• Remote diagnostics and telemetry

OTA:

• Secure firmware + application updates
• Must handle unreliable networks and power failures

AI (Future Scope):

• Edge inference (recommendation engine / usage analytics)
• Possible integration with NPU-capable SoCs

Key Decision Areas:

1. OS Selection (Critical)

We are evaluating:

• Embedded Linux
• Android (AOSP-based)

Looking for insights on:

• Long-term maintainability (5–7 years lifecycle)
• OTA reliability (A/B updates, rollback safety)
• Field failures (if any) observed in production
• Security patching and update complexity

Also:

• Licensing / royalty considerations:
  • Android (GMS / certification / compliance)
  • Linux

1. Processor / SoC Selection

Currently considering:

• Rockchip (RK3568 / RK3588)
• NXP i.MX8 series

Criteria:

• Industrial stability (temperature, uptime)
• Long-term availability (5+ years)
• BSP and Linux/Android support quality
• AI/NPU capability for future use

1. OTA Strategy (Very Critical)

Looking for proven approaches:

• Full image vs delta updates
• A/B partitioning vs single partition
• Handling power failure during update
• Tools used in production (RAUC, Mender, SWUpdate, etc.)

1. Scaling Challenges (50k+ Devices)

From your experience:

• What typically breaks when scaling from 100 → 50,000 devices?
• OTA rollout strategies (phased vs global)
• Device fleet management pitfalls
• Debugging issues in the field

1. UI Framework

Options being considered:

• Qt (Linux)
• LVGL (lightweight)
• Android UI
• Flutter

Looking for:

• Real-world performance vs maintainability trade-offs
• Best option for video-heavy UI + animations

Decision Priorities:

1. Reliability (24/7 uptime)
2. OTA safety (zero-brick tolerance)
3. Maintainability (remote updates, debugging)
4. Scalability (50k+ devices)
5. Performance (secondary)

Goal:

We are trying to choose an architecture that:

• Scales reliably to tens of thousands of devices
• Supports OTA and remote feature rollout
• Allows future AI/ML integration without redesign
• Minimizes licensing and long-term maintenance risks

Would really appreciate insights from engineers with experience in:

• Vending machines
• Digital signage
• Kiosks
• Large-scale IoT deployments

Thanks in advance!