BluePill: bidirectional UART communication between STM32F103C and ESP8266

[its-nott-me]

I’m working on a project that requires bidirectional communication between daisy-chained STM32F103C bluepill boards and an ESP8266. I’m using a master-slave architecture and UART for initial testing and prototyping. The chain has 3–6 STM32 boards.

Right now I’m having trouble getting reliable two-way data transfer between the ESP8266 (master) and the STM32 boards (slaves). Can anyone help me get this working? 

[TDK]

Here are multiple examples for UART on the STM32F1 series.

https://github.com/STMicroelectronics/STM32CubeF1/tree/master/Projects/STM32F103RB-Nucleo/Examples/UART

Get one of these working, then use it as a code base for your own project.

[Andrew Neil]

Note that BluePill is not an ST Product, and likely will not have a genuine STM32 fitted.

---

@its-nott-me wrote:

 bidirectional communication between daisy-chained STM32F103C bluepill boards and an ESP8266. ? 

---

What, exactly, does that mean?

A diagram would probably explain best...

---

@its-nott-me wrote:

Right now I’m having trouble getting reliable two-way data transfer between the ESP8266 (master) and the STM32 boards (slaves).

---

So what, exactly, have you tried?

And what, exactly, is/are the problem(s) you're having?

As always, the secret is to not try to do everything all at once - see this.

As @TDK says, there are plenty of examples of doing UART serial comms on STM32; no doubt there are also plenty of examples of doing UART serial comms on ESP32 ESP8266...

Test each part on its own before bringing them together.

Tips specifically on Debugging Serial Comms.

PS:

Corrected ESP32 to ESP8266 - although the principles remain the same for communications between any two devices.

[Bermingham]

For reliable bidirectional UART between an ESP8266 (master) and multiple STM32F103C slaves, I’d recommend breaking it down into small, testable steps:

1. Test individual links first – Connect the ESP8266 to a single STM32 and confirm you can send/receive data reliably.

2. Implement simple addressing – Each STM32 slave should respond only when addressed, to prevent bus collisions. Even a single-byte ID at the start of each message works.

3. Use hardware flow control if possible – RTS/CTS can reduce lost bytes, especially at higher speeds or with daisy chains.

4. Add checksums or simple CRC – Detect corrupted packets and request retransmission.

5. Incrementally scale – Once one link works reliably, add the next slave, testing communication each time.

For debugging: log everything with timestamps, and keep messages short while you refine timing. UART is simple, but daisy-chaining multiple devices can introduce collisions or buffer overflows if timing isn’t managed carefully.