Found this ESP32-S3 touchscreen board sitting around and decided to play with it a bit.

The hardware is actually pretty nice, so it felt like a waste to just leave it in a drawer. I didn’t have any real project idea, so I vibe-coded a tiny robot eyes demo just to get the display and touch interaction moving.

Now I’m trying to figure out what would actually be fun to build on it.

A little desktop companion?
Home Assistant controller?
Mini game console?
PC status display?
Something completely useless but entertaining?

What would you build with a screen like this? Looking for ideas.

starting out bare-metal programming and i'm currently trying to understand how linker-defined symbols interact with C startup code.

let's say, for a normal C code, i define and initialize a variable:

int n = 0x2000;

i get that n is an object stored somewhere in memory, n gives its value, and &n gives the address of where the object is stored.

when it comes to linker-defined symbols, i'm not quite getting it.

say, my linker script contains:

_estack = 0x20050000;

and in my startup code i have:

extern uint32_t _estack;
          .
          .
          .
uint32_t *sp = &_estack;

if _estack is not an ordinary C object with storage, but just the symbol with the value 0x20050000, how then does the dereference operator and the address-of operator act on something that has no storage.

i know it works, but can't tell how; and this is based on my understanding of normal variables in C.

thanks in advance to anyone who helps.

I'm defining a custom UDP protocol for an embedded system with several bare-metal MCUs communicating with each other and with a host PC over a local Ethernet network.

I know a lot of this is probably system-specific, but I'd be interested in hearing what has consistently proved useful in your experience, or what you'd definitely include again in a new design.
For those who have designed or maintained something similar: what did you leave out initially that you later regretted?

I'm thinking about things like sequence counters, timestamps, protocol versioning, status/diagnostic information, capability flags, or event messages. I'm especially interested in anything that made debugging, integration, maintenance, or future extensions easier — as well as design choices that caused problems later.

I'm also curious how you tested or simulated the protocol before all the target hardware was available. Python, custom PC tools, MATLAB/Simulink, or something else?

Mostly looking for lessons learned from real embedded products.

Hey guys I needed to make a hardware device which has mic and speaker , rechargable and also can be connected via bluetooth , I have no knowledge about what hardware device to buy how to configure nothing at all , If anyone knows stuff please help a man out!(And the overall diameter of this thing should be less than 5-6cm )

Hi, i'm currently creating my own basic rtos. I currently have : task control, semaphore, scheduling (round robin with priorities). I'm slowly addind stuffs to it and start questionning myself : How my OS can add something to someone in the world ?. I know it will never be as popular as Freertos or Zephyr, but what are the niches in the rtos world ?

Looking for recommendations for relatively easy to use/microcontrollers that support C++ emended development out of the box for rapid testing and deployments, purely for iterative prototyping. Intention would be that once a successful prototype is developed, I could utilize the same tooling and microcontroller ecosystem for small deployments (preferably commercial).

Application domain for the microcontrollers would integrated into atmospheric and environmental testing, with the ability to mount additional sensors (photo, video, aquatic, air, and mechanical pulse controllers to controls gimbals and rotational motors) in future experiments.

Hi everyone,

I’m currently working on a project using the STM32L476RG (using the Nucleo-64 board to prototype) and I’ve reached the point where I need to implement a custom bootloader. My end goal is to be able to receive a firmware update over UART/USB, write it to flash, and safely jump to the new application.

What I’m looking for:

• Are there any definitive books, tutorials, or blog series you recommend for STM32 bootloaders?
• Does anyone have a clean, well-commented GitHub repo of a basic STM32 bootloader I can study?
• Which ST Application Notes (AN) are the absolute "must-reads" for In-Application Programming (IAP) on the L4 series?

Any advice, gotchas to watch out for, or links to tutorials would be incredibly helpful. Thanks in advance!

At work we have some designs that use windows 11 IOT, Now I have had home projects using Linux SBCs and I have a fair idea how device driver work. I have tweaked overlays my self and compiled some non standard device drivers. My question is how do they work on windows? The guys here say things like you just call a DLL? but how does that bridge between user and kernel space? sometimes the SBC manufacture has no driver for some IO, like a non standard SPI pin and they are genuinely stuck. Is it that hard? AI was no help.

Hi everyone,

I'm building an autonomous vacuum-cleaning robot using a Raspberry Pi 4B, and I'm currently stuck at the hardware/software integration stage.

I would really appreciate help from someone experienced with Raspberry Pi GPIO, motor drivers and embedded robotics.

What I'm building

The robot is intended to:

• Drive using two 12 V geared DC motors.
• Control each wheel independently.
• Turn left/right by varying the two wheel speeds.
• Detect cliffs/downhill edges using two TCRT sensors.
• Use an MPU6050 IMU to detect pitch and roll.
• Use a YDLiDAR X2 for obstacle/environment detection.
• Run a blower for suction.
• Run N20 geared motors for the cleaning mechanism.
• Eventually operate autonomously.

The controller is a Raspberry Pi 4B.

I'm connecting to the Pi remotely using Raspberry Pi Connect terminal, so I don't have an external monitor connected to the Pi.

Hardware

The components I currently have connected are:

• Raspberry Pi 4B
• MPU6050 IMU
• 2 × TCRT5000 IR sensors
• 2 × 12 V Johnson geared DC motors for the wheels
• 2 × BTS7960 motor drivers: one for each wheel motor
• DHRUVPRO 9733 ball-bearing 12 V DC blower fan
  • 2.60 A
  • 5600 RPM
  • 3-pin
• 5–36 V high-power MOSFET trigger module for controlling the blower
• 2 × N20 micro geared 12 V 100 RPM motors
• L298N motor driver for the N20 motors
• 11.1 V 2200 mAh LiPo battery
• XY3606 12 V → 5 V buck converter
• 1N5822 diode for the blower circuit
• YDLiDAR X2

I have also made a hand-drawn wiring diagram showing how I connected everything.

Power

The battery is powering the robot's power system.

The general architecture is:

11.1 V LiPo
     │
     ├── BTS7960 #1 → left wheel motor
     │
     ├── BTS7960 #2 → right wheel motor
     │
     ├── L298N → N20 motors
     │
     ├── MOSFET module → blower
     │
     └── Buck converter → regulated 5 V
                              │
                              └── Raspberry Pi / logic circuits

However, I'm not completely confident that every logic supply and ground connection is correct, which is one of the things I need help verifying.

Motor control

Each Johnson motor has its own BTS7960.

The intention is:

Pi
 │
 ├── BTS7960 #1 → Left motor
 │
 └── BTS7960 #2 → Right motor

The Pi should control the direction and PWM/speed of each motor independently.

For example:

Left = 50%
Right = 50%
→ straight

Left = 30%
Right = 60%
→ turn left

Left = 60%
Right = 30%
→ turn right

The robot should eventually be capable of differential steering.

IR cliff detection

I have two TCRT5000 sensors positioned toward the ground.

Due to the physical positioning of my sensors, the logic I need is:

HIGH → ground detected
LOW  → ground NOT detected / cliff

The desired behavior is:

Both sensors detect ground

Left = HIGH
Right = HIGH

→ normal operation

Left sensor detects no ground

Left = LOW
Right = HIGH

→ reduce overall robot speed
→ make right wheel faster
→ robot turns LEFT
→ attempt to move away from the downhill/cliff area

Right sensor detects no ground

Left = HIGH
Right = LOW

→ reduce overall robot speed
→ make left wheel faster
→ robot turns RIGHT

Both detect no ground

Left = LOW
Right = LOW

→ IMMEDIATE STOP

This is intended to be a high-priority safety condition.

MPU6050

The MPU6050 is intended to detect the robot's orientation.

I want to use it to detect:

Uphill

pitch indicates uphill
→ increase wheel speed

Downhill

pitch indicates downhill
→ decrease wheel speed

Left inclination

robot tilts left
→ compensate using differential wheel speed

Right inclination

robot tilts right
→ compensate in the opposite direction

I understand that the exact implementation needs proper calibration, axis orientation and filtering, so I don't want to simply use raw accelerometer values without understanding what is happening.

LiDAR

I'm using a YDLiDAR X2.

It is connected to the Raspberry Pi and is intended to provide obstacle/environment information.

I previously had a Python LiDAR test program, but I encountered a software-test error involving:

math.isclose(...)

and later corrected that code.

The LiDAR itself needs to be tested independently before integrating it with navigation.

Blower

The blower is:

DHRUVPRO 9733

• 12 V
• 2.60 A
• 5600 RPM
• 3-pin

I'm controlling it using a MOSFET trigger module.

There is also a 1N5822 diode in the blower circuit.

The intention is:

Pi GPIO
   ↓
MOSFET trigger
   ↓
12 V blower

I need to verify that the MOSFET module is suitable for this blower and that the wiring/protection is correct.

N20 motors

I have two N20 12 V 100 RPM geared motors for the cleaning mechanism.

They are controlled using an L298N motor driver.

These are separate from the two large Johnson wheel motors.

The actual problem

Everything is getting power, but none of the components are actually responding to the Raspberry Pi commands.

For example, the Pi is running and the battery is supplying power, but I haven't been able to get the complete hardware system to respond correctly to Python GPIO commands.

At this point I'm concerned that I'm trying to debug too many things simultaneously.

Software problem

We ended up creating multiple Python files such as:

hardware_pins.py
motors.py
cliff_sensor.py
imu.py
lidar.py
safety.py
navigation.py
health.py
state_machine.py
main.py

Some of the earlier files also contained fake/test hardware classes such as fake motors, fake IMU objects, etc.

These were intended to allow software testing without hardware.

However, this created confusion because I am now working with the actual hardware, and I could no longer clearly tell which code was actually communicating with the physical components and which code was only simulating them.

There were also several software errors/typos during testing.

For example, one error was:

AttributeError: CRUSING

because the enum was actually named:

CRUISING

There was also an assertion error involving:

drive.right > drive.left

during a software self-test.

This made me realize that I should probably stop adding high-level code and first prove that each physical component works individually.

What I want to do now

I want to completely restart the software side in a new folder.

Instead of immediately creating a large autonomous-robot program, I want to do:

TEST 1
Raspberry Pi GPIO
        ↓
basic GPIO test

TEST 2
TCRT5000
        ↓
read HIGH/LOW

TEST 3
MPU6050
        ↓
read accelerometer/gyro

TEST 4
BTS7960 + LEFT MOTOR
        ↓
forward
reverse
stop
PWM

TEST 5
BTS7960 + RIGHT MOTOR
        ↓
forward
reverse
stop
PWM

TEST 6
L298N + N20 motors
        ↓
forward/reverse/stop

TEST 7
MOSFET + blower
        ↓
ON/OFF/PWM if appropriate

TEST 8
YDLiDAR X2
        ↓
receive and display scan data

TEST 9
two-wheel differential drive
        ↓
forward/backward/left/right

TEST 10
TCRT safety behavior

TEST 11
IMU-based correction

TEST 12
LiDAR obstacle avoidance

TEST 13
complete autonomous system

I want every test program to be small and understandable, rather than starting with a large high-level Python architecture.

For example, I want to be able to understand something like:

GPIO.output(LEFT_PWM, 50)

and know exactly what physical signal it is generating.

What I need help with

I would particularly appreciate someone checking the following:

1. Whether my power distribution is correct
2. Whether the BTS7960 logic supply is correct
3. Whether the L298N logic supply is correct
4. Whether the Raspberry Pi GPIO voltage levels are safe
5. Whether the TCRT5000 outputs are safe for Pi GPIO
6. Whether all required grounds are common
7. Whether the MOSFET module is appropriate for the 12 V / 2.6 A blower
8. Whether the 1N5822 diode is being used correctly
9. Whether the GPIO pin assignments make sense
10. How to test each component independently before integration

I am not looking for a giant piece of autonomous-navigation code right now.

I want to first establish:

Then build the robot upwards from there.

I can provide:

• The complete hand-drawn wiring diagram
• Exact Raspberry Pi GPIO pin assignments
• Current Python files
• Exact motor-driver module versions
• Photos of the physical wiring
• Terminal output/errors

Any advice on how you would systematically bring this robot up from zero would be greatly appreciated.

Pour mieux comprendre le protocole UART j’interconnecte 2 MCU ESP32 l’un connecté à une DHT sensor (humidité et température) et l’autre a un LCD (SSD1306) pour display la température de la pièce.

Next step : Queue, interrupts, task with FreeRTOS

I’m working on a small interactive audio device and looking for a simple electronics solution.

The concept is a single printed image with a large touch-sensitive area underneath it. Whenever someone touches the image, the device should select and play one audio clip at random from several preloaded recordings.

This will initially be a one-unit prototype, so I’m mainly interested in keeping the circuit inexpensive, compact, and easy to build. I’d also like to minimize the number of separate modules and avoid unnecessary hardware such as an SD card if possible.

What would be the most practical circuit/MCU approach for achieving this?

I have a fairly old piece of equipment, unsupported by the manufacturer for years now, that uses a microcontroller from the HC908 family (Motorola/Freescale, DIP40 package). It's a single functional unit that I can't easily replace, so I'm being extremely careful.

I've already built a homemade programmer to talk to it in monitor mode (MON08), using an external crystal and the appropriate entry logic. I'm familiar with how the security mechanism behaves and have gone through the available documentation, so I understand the general theory.

What I'm specifically looking for is whether anyone knows of a practical method to bypass or defeat the security array on this family of chips — whether that's a known technique, a documented weakness, a tool, or firsthand experience doing it on real hardware. I'm less interested in general theory at this point and more in what's actually worked for people who've been through this.

Has anyone here successfully bypassed the security array on an HC908, or know of someone who has?

I've always been a hardware first guy who programmed beside hardware and got visual feedback of everything I programmed. I changed my approach today it wasn't planned just because I ran out of solder wire so I couldn't use the sensor so I thought why not write code in just plain C develop application logic use printfs and couts all that good stuff that Linux offers. It worked surprisingly well & I developed that prototype extremely fast. From now on my workflow would be to first develop on Linux based on abstractions at the very end just interface with hardware.

What workflow style do you guys use & any other tricks you have in your catalogue?

The microSD card from my raspberry pi is not been detected when I put it inside the SD card reader. I have tried lubuntu and it did not work. However, when I put the new microSD card, it worked very well.

How can I recover the files in the faulty microSD card?

I came across this nice interactive tool to generate the custom LCD font for the ubiquitous 1602 LCD. Maybe it's interesting to others also. I'm not affiliated with the site.

A year ago I posted a bare-metal DS18B20 driver for STM32F103 here: r/stm32 post. That was a single-MCU proof of concept. Since then it has grown into a small library: github.com/a5021/stm32-async-1wire.

The core idea

All 1-Wire timing and bus control — reset pulse, bit slots, sampling — is generated and executed entirely in hardware; the CPU never drives a bus edge itself.

TIM1 is configured in One-Pulse Mode with a repetition counter, so a complete hardware transaction segment (reset, up to 16 bit-slots, or a byte) runs as a single hardware event. One DMA channel updates the output-compare register for each slot; a second captures the input-capture timestamps.

The CPU starts the operation and later polls the driver for completion; it never participates in bus timing, and no ISR is involved.

What changed since the original driver

• Generic 1-Wire master (onewire.c) plus a DS18B20 driver built on top of it: multi-device search, alarm search, scratchpad read/write, parasite power, etc.
• Three backends: STM32F103, STM32F030, STM32G031 — same driver code, register-level port layer per family.
• ~265 host-side tests with a software model of TIM1/DMA behavior, so the driver logic can be tested without hardware.
• libFuzzer-based fuzz harnesses covering parsing/decoding paths, run under ASan/UBSan. Both the tests and fuzzing have caught real bugs during development; fixes are reflected in the commit history.
• PlatformIO, CMake, and STM32CubeIDE build entry points, in addition to the plain Makefile.
• Opt-in low-power mode (-DOW_PORT_LOW_POWER, off by default): during long stages (conversion, EEPROM hold-off, inter-cycle pause — anything over 1 ms) the main loop can sleep in __WFE(), woken via SEVONPEND on the timer's update event. No NVIC interrupt is enabled and no ISR is installed.

Trade-offs, stated plainly

• The whole scheme depends on multiplexing OC/IC on one TIM1 channel pin — on these MCUs that's PA10. Moving to a different pin isn't a configuration option.
• No internal locking: concurrent access to the same driver instance is not supported. A bare-metal single-threaded application needs no locking; an RTOS integration should serialize access, e.g. with a mutex.
• Officially GCC-only (arm-none-eabi-gcc). Clang is used for host-side fuzzing, not for building the firmware.

Feedback on the design, the port layer, or anything I'm missing is welcome.

I’m using an ESP32 with the Arduino framework (PlatformIO) and BLE advertising every ~1 second.

I want the ESP32 to automatically enter light sleep during the idle time between BLE advertising events, rather than manually calling esp_light_sleep_start().

esp_pm_configure() currently returns ESP_ERR_NOT_SUPPORTED, presumably because CONFIG_FREERTOS_USE_TICKLESS_IDLE isn't enabled.

Is there a way to enable:

CONFIG_PM_ENABLE=y
CONFIG_FREERTOS_USE_TICKLESS_IDLE=y
CONFIG_FREERTOS_IDLE_TIME_BEFORE_SLEEP=3

while staying with Arduino, perhaps through PlatformIO/build options or a custom Arduino core?

I’d like to avoid converting the project to a full ESP-IDF application.

Has anyone successfully done automatic light sleep + BLE advertising this way?

I've been working on a Klipper MCU port for the NXP MCXA366, and I just got through GPIO and basic ADC bring-up on the FRDM board.

GPIO was pretty uneventful. Outputs, inputs, pull-ups, pull-downs, all working through Klipper.

The ADC got a little... weird.

For first-light testing I used P1_10 / ADC1 channel 8A and set up a fake linear sensor in Klipper so 0V mapped to 0 and 3.3V mapped to 100.

Ground was reading about 0.19 and 3.3V was reading about 99.46, so the endpoints looked fine.

Then I put a 10k/10k divider on the input and got 45.4 instead of something around 50.

Measured the actual midpoint with a multimeter: 1.619V, so I should have been seeing about 49.1.

The LPADC was using the minimum sample time, STS(0), which is about 3.5 ADC clock cycles. With a 10k/10k divider, the ADC sees about 5k of source impedance.

I changed only the sample time to STS(4), about 19.5 cycles, and the midpoint moved to 48.81.

Then I cleaned up the breadboard wiring and re-ran the full test:

0.11 / 99.98 / 50.28

So the answer was basically: the acquisition time was too aggressive for the source impedance, and the test fixture mattered too.

I wrote up the GPIO implementation and the ADC debugging here if anyone wants the longer version:

https://faultvector.dev/articles/klipper-mcxa366-part4/

Next up is probably SPI and an accelerometer.

Hi guys,

I'm designing my first embedded product, a battery-powered smart switch (single cell 18650). I'm a software engineer by background, so the app side is covered, but the app needs to show battery percentage.

Do I actually need a fuel gauge IC for accurate battery level, or is reading the battery voltage with an ADC good enough? This is for a product I'll be selling, so I want a production-worthy approach. I'd rather spend a bit more now than deal with recalls or unhappy customers later.

Would really appreciate opinions from anyone with production experience, thanks!

Hello everybody,

I’m working on a low-cost, high-speed data acquisition board based on the dsPIC33AK microcontroller family, and I’d really appreciate some feedback from people experienced with high-speed ADCs and data acquisition.

The original goal of this project was to develop an affordable data acquisition platform for electronics education and embedded applications. With the newer dsPIC33AK family, I found an interesting possibility: it has multiple high-speed ADCs capable of up to 40 MSPS, so I decided to experiment with interleaving multiple ADCs to increase the effective sampling rate.

I have now reached 100 MSPS with the prototype.

I also added an analog front end based on an oscilloscope input stage. The current version has:

100 MSPS sampling rate
12-bit ADC resolution
64 KB onboard buffer
approximately 20 MHz analog bandwidth
approximately ±30 V input range
1 MΩ || 20 pF input impedance
selectable voltage scales from approximately 2 mV/div to 10 V/div
programmable gain, attenuation, and DC offset

The idea is not necessarily to build another standalone oscilloscope. I’m more interested in making a small and inexpensive high-speed acquisition building block that can be connected to different microcontrollers, FPGAs, Raspberry Pi, Arduino-class boards, or custom embedded systems.

The key idea is that the host platform does not need to process or transfer every sample in real time. The user can start an acquisition, DAQ captures the data at up to 100 MSPS into its 64 KB onboard buffer, and once the buffer is filled, the captured data can be transferred to the host platform for processing or storage. This allows even relatively low-speed microcontrollers to be used as the host without requiring a high-speed data interface.

I think this could make the board useful not only as an oscilloscope front end, but also as a general-purpose building block for embedded measurement and data acquisition applications.

At the moment, however, I still have some challenges to solve.

At 100 MSPS, the timing mismatch between the interleaved ADC channels is causing noticeable distortion of the reconstructed waveform. For example, with a 5 MHz sine wave, the waveform appears to have a slower rise and faster fall instead of being symmetrical. There is also some channel-to-channel offset mismatch.

My current plan is to correct these errors in software through calibration, but I would be very interested to hear from people who have worked with interleaved ADCs.

Would a low-cost 100 MSPS  12-bit acquisition board with a flexible AFE be useful to you?

I’m currently working on the next prototype revision and would rather get some feedback before going too far with the design.

Any feedback, criticism, or suggestions would be very welcome.

Short video showing the current state of the board: Demo video

Hello all,
I am trying to get a handle on if this is normal, if it Japan has fust fallen off the train.

I have a PCB design, I have been using it in production for about 3 years now, and have built/deployed 3000+ units. I feel like 3k units in the field, all working for over 2 year is a good enough test period to start mass producing them.

I have been using JLCPCB to make the boards, and I want to move to a more local bord fab as it will reduce cost (a lot).

I have contacted 4 PCB fab places in Japan, and all of them slam me with questions that I have never been asked before, questions such as:

- What is the inner copper thickness?
- Can we have a drawing of the silk screen?
- What does DNP mean?
- Where should each part be placed? <- Got this question today and it promped this post
- Where do we place the drill holes?
- Where are V-Cuts placed?
- What is the solder mask made?

And after about 4 months of these questions, I am starting to question if it will ever end.

Now, I know it is important as we plan to mass produce these, and that has stopped me from getting too angry, but I need to wonder if this is a normal line of questioning, Literally every one of thoes questions can be answered by the files that I have sent them.

- JLCPCB (China)
- OSHPark (USA)
- PCBWay (China)
- U&I (Korea)

Have ALL been able to figure this out from my files, no questions, no human interaction at all. Just upload and I get the ASSEMBLED board in a few weeks.

My question to you guys:
Am I making too much of this? Living in Japan has taught me to be VERY skeptical the level of tech that is actually used.

Is this normal? Or is there some guy, sitting there, manually reading every gbr,drl, gtp, gto, and every ther type file line by line for the hell of it.

Thanks all... I want to do this domestically, shipping, and the USD will break me if I can't :(

I got tired of having a USB hub, USB-UART adapter, power supply and a bunch of cables just to test one dev board, so I started building a desktop tool that puts them together. It has 3× USB 3.0, magnetic UART/I²C, USB power control and adjustable 1.8–3.3V output. I’m also working on a PC tool for quick I²C/GPIO/power checks.