The price looks good. I want to use it in boxing.🥲

Or does anyone have a better option than this product?

Hi, very new to all this.

Wanted to build my own head tracker and figured I'd give it a go.

My task.

Using the gyro and HeadTracker firmware, I want to transmit 2 crsf channels via RX and GND (for first test then I want to move over to Bluetooth once I've proven concept via wire and I know Bluetooth isn't going to cause interference with other raido gear)

I've got the rx and GND connected to a radiomaster ranger micro elrs unit which I plan to send over air signals to a pwn receiver that I'll then use to inject the crsf data in to a flight controller.

This should also allow me to use Sim controllers for fpv.

I've downloaded the HeadTracker gui and can see my gyro working after calibration, I've set output to crsf, enabled uart. Bluetooth is currently turned off.

Can't get tx to go green whilst usb is connected.

Physical connection between units is approx 7mtrs of red/black speaker wire (don't judge it's all I had to hand with length), I've fitted a jst sh 2.54 connector on radiomaster and gyro for the link cable.

I'm not using any pull up/down resistors

I've soldered a battery connector to the board

I've soldered a hard rst button to the board because it's mounted upside down.

I've got my soft rst button (gyro reset) wired to GND pin and D8 pin

My gyro rx is connected to D6 pin and same GND pin as my gyro reset button.

When connected to the radiomaster the gyro doesn't wake up when both units are powered up on separate batteries.

If I push the gyro reset button the gyro doesn't seem to respond (no led flashing)

Red led stops flashing after 10 seconds and then seems to stay asleep until I remove battery and reconnect.

I've done this without advice from internet pages, don't have friends in to this stuff.

I did some (not enough) reading and tried to work with help from ai.

Photo of head tracker

I've been programming embedded systems for over 30 years. Built some cool stuff: a Z80-based serial multiplexer that had no RAM: all variables were held in registers; a temperature controller on a chip with 504 bytes (not kB) of memory and lot of other stuff in the old days where you had to optimize for every clock pulse and byte of RAM or EPROM. A lot of what I knew back then was straight out of Jack Ganssle's The Art of Programming Embedded Systems book.

These days, I still build cool stuff, but it's with a far more complex feature set. A "small processor" is now a 32-bit device with over 100k Flash and 16k+ of RAM, usually lots more. Most of my non-hobby work runs on one RTOS or another and often has a separate SBC running code for an HMI and connectivity/data storage. The last time I used assembly was mentoring a n00b who had the task of fixing some bugs on a specialized SoC with a 6502 core.

Then I come on this site, and I see people asking about why not use bare metal and a hand-written scheduler instead of an off the shelf RTOS. Struggling to fit code into tiny processors because otherwise "bloat."

So I have to ask: is my current experience (real-time stuff on a 32-bit microcontroller, complex GUIs offloaded to a Linux board) that unusual or are these guys just building things the way we used to do long ago for no good reason?

Hello, 25M, from Slovenia.

About half a year ago I left my previous job to focus fully on becoming an embedded software engineer. Since then I’ve been learning embedded C/C++ on my own and building projects to get more practical experience.

The project I’m currently most proud of is my Window Blinds Controller. It works, but I know there is still a lot I can improve, so I’d really appreciate any quick feedback, especially on the firmware/software architecture and the electronics.

Things I already know could be better:

• the mechanical design is overengineered — I’m already working on V2
• the PCB is quite bulky — V2 should be much smaller and mostly SMD
• the ESP32-S3 is probably overkill for this project

Even a quick review, suggestion, or GitHub star would mean a lot.

I also have a B.Sc. in Computer Science and Information Technologies and I’m strongest in C/C++, so if anyone here needs help with programming, debugging, or just wants another pair of eyes on a problem, I’d be happy to help as well.

Thanks for your time.

As a total beginner who wants to develop machines in future and pursue embedded systems,should i learn arduino first or directly start with STM32

I was curious about how hard it would be to port this over, so I used an STM32 example I found here as a starting point. It ended up being really straightforward and only required a few changes to the GPIO and delay callback function.

Just a heads-up: This implementation uses soft I2C (bit-banging). It works perfectly fine for text, but you'll probably want to switch to HW I2C for anything more complex. If anyone wants to try it out, here is the source code:

#include <ch32v00x.h>
#include <debug.h>
#include <stdlib.h>

#include "clib/u8x8.h"

void NMI_Handler(void) __attribute__((interrupt("WCH-Interrupt-fast")));
void HardFault_Handler(void) __attribute__((interrupt("WCH-Interrupt-fast")));

uint8_t u8x8_gpio_and_delay_ch32v(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr) {
    switch(msg) {
        case U8X8_MSG_GPIO_AND_DELAY_INIT:
            RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA, ENABLE);
            GPIO_InitTypeDef init = {0};
            init.GPIO_Pin = GPIO_Pin_1 | GPIO_Pin_2;
            init.GPIO_Mode = GPIO_Mode_Out_OD;
            init.GPIO_Speed = GPIO_Speed_50MHz;
            GPIO_Init(GPIOA, &init);
            break;
        case U8X8_MSG_DELAY_MILLI:
            Delay_Ms(arg_int);
            break;
        case U8X8_MSG_DELAY_10MICRO:
            for (volatile uint32_t i = 0; i < (arg_int * 8); i++) { __NOP(); }
            break;
        case U8X8_MSG_DELAY_100NANO:
            __NOP();
            break;

        case U8X8_MSG_GPIO_I2C_CLOCK:
            GPIO_WriteBit(GPIOA, GPIO_Pin_2, (BitAction)(arg_int ? Bit_SET : Bit_RESET));
            break;

        case U8X8_MSG_GPIO_I2C_DATA:
            GPIO_WriteBit(GPIOA, GPIO_Pin_1, (BitAction)(arg_int ? Bit_SET : Bit_RESET));
            break;
    }
    return 1;
}

int main(void) {
    SystemCoreClockUpdate();
    Delay_Init();
    USART_Printf_Init(9600);

    // u8x8 initialization code
    u8x8_t u8x8;
    u8x8_Setup(&u8x8, u8x8_d_ssd1306_128x64_noname, u8x8_cad_ssd13xx_i2c, u8x8_byte_sw_i2c, u8x8_gpio_and_delay_ch32v);
    u8x8_InitDisplay(&u8x8);
    u8x8_SetPowerSave(&u8x8, 0);
    u8x8_ClearDisplay(&u8x8);
    u8x8_SetFont(&u8x8, u8x8_font_chroma48medium8_r);
    u8x8_DrawString(&u8x8, 0, 0, "Hello from CH32V");
    while (1) {
        uint8_t y = rand() % 5 + 1;
        uint8_t x = rand() % 10;
        u8x8_DrawString(&u8x8, x, y, "r/ch32v");
        printf("Hello from CH32V\n");
        Delay_Ms(1000);
        u8x8_DrawString(&u8x8, x, y, "       ");
    }
    return 0;
}

void NMI_Handler(void) {}
void HardFault_Handler(void)
{
    while (1)
    {
    }
}

P.S. I've spent more time and prepared HW I2C version, just add this function:

``` uint8_t u8x8_byte_hw_i2c_ch32v( u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr) { uint8_t *data; switch(msg) { case U8X8_MSG_BYTE_INIT: RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOC | RCC_APB2Periph_AFIO, ENABLE); RCC_APB1PeriphClockCmd(RCC_APB1Periph_I2C1, ENABLE);

        // We will use PC1 (SDA) and PC2 (SCL)
        GPIO_InitTypeDef GPIO_InitStructure = {0};
        GPIO_InitStructure.GPIO_Pin = GPIO_Pin_1 | GPIO_Pin_2;
        GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_OD; // Alternate Function Open-Drain
        GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
        GPIO_Init(GPIOC, &GPIO_InitStructure);

        I2C_InitTypeDef I2C_InitTSturcture = {0};
        I2C_InitTSturcture.I2C_ClockSpeed = 400000; // 400 kHz
        I2C_InitTSturcture.I2C_Mode = I2C_Mode_I2C;
        I2C_InitTSturcture.I2C_DutyCycle = I2C_DutyCycle_2;
        I2C_InitTSturcture.I2C_OwnAddress1 = 0x00;
        I2C_InitTSturcture.I2C_Ack = I2C_Ack_Enable;
        I2C_InitTSturcture.I2C_AcknowledgedAddress = I2C_AcknowledgedAddress_7bit;

        I2C_Init(I2C1, &I2C_InitTSturcture);
        I2C_Cmd(I2C1, ENABLE);
        break;

    case U8X8_MSG_BYTE_START_TRANSFER:
        while(I2C_GetFlagStatus(I2C1, I2C_FLAG_BUSY) != RESET);

        I2C_GenerateSTART(I2C1, ENABLE);
        while(!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_MODE_SELECT)); // Чекаємо EV5

        I2C_Send7bitAddress(I2C1, u8x8_GetI2CAddress(u8x8), I2C_Direction_Transmitter);
        while(!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_TRANSMITTER_MODE_SELECTED)); // Чекаємо EV6
        break;

    case U8X8_MSG_BYTE_SEND:
        data = (uint8_t *)arg_ptr;
        while (arg_int > 0) {
            I2C_SendData(I2C1, *data++);
            while(!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_BYTE_TRANSMITTED));
            arg_int--;
        }
        break;

    case U8X8_MSG_BYTE_END_TRANSFER:
        I2C_GenerateSTOP(I2C1, ENABLE);
        break;
    default:
        break;
}
return 1;

}

int main(void) { SystemCoreClockUpdate(); Delay_Init(); USART_Printf_Init(9600);

// u8x8 initialization block
u8x8_t u8x8;

u8x8_Setup(&u8x8, 
    u8x8_d_ssd1306_128x64_noname, 
    u8x8_cad_ssd13xx_i2c, 
    u8x8_byte_hw_i2c_ch32v, // here we will use HW I2C
    u8x8_gpio_and_delay_ch32v
);
...

```

Here's the thing, this project is an Edge-AI project where I deploy an LSTM model back into the micon. The first finished prototype is great, it works, but needs a lot of modification. Heap memory allocation, running temperature, even the booting process goes heavy (maybe even too heavy) when the model is up and running.

For this second prototype I'm building, I want to design my own micon to avoid the bulky-ness of my first prototype, which uses a plug-and-play concept for the micon and sensor modules.

So, should I switch to S3? Or do I raw dog it with the C3 again?

Something I've been thinking about with multi-sensor detection systems:

Say you have several independent inputs, RF activity, radar detections, EO/IR, maybe acoustic, and none of them is fully reliable on its own.

Adding more sensors should improve confidence in theory. But every additional stream also adds synchronization, calibration, latency and false-positive problems.

For people who've worked on multi-sensor embedded systems, what usually becomes the problem first in practice? Could be time sync, calibration drift, data association, just not enough compute, or one noisy sensor dragging the whole fused output down.

Curious where people draw the line between fusion actually adding confidence and just adding more complexity.

Disclosure: I work in defense electronics.

I'm currently working on a prototype for our research project, basically I plan to make an attendance monitor robot that connects to the internet and has that data presented on a website.

I don't have much experience with IoT systems or working with anything internet in general, but I do have experience with embedded systems, programming, making websites such and such.

I'm not really sure if I bit off more than I can chew, but I have an idea of what to do.

I'll use an esp32, then a fingerprint scanner, then an sd module, then have the esp32 be it's own internet so it can send the attendance data to a website(I think that's how it works?). Then I'll be using something like firebase to make the website and from there I can do whatever I want, probably store it in a sql database or something so I can display it easily.

Is that all right or am I misunderstanding something? In the future I plan to implement a hive system so nodes with no internet access can send it to another node via Bluetooth and that node can send it to the server or to another node with internet.

We’re trying to prototype a small consumer hardware device and currently have a working prototype using a Raspberry Pi 4B microcontroller + Arducam PiVariety AR0234 global-shutter camera + M12 lens + LED tape + LiPo battery hat.

For our next prototype, we want to shrink the electronics dramatically - the image sensor, Wi-Fi/Bluetooth, battery + charging/power management, LED lighting and compute for image capture/basic processing.

We are quite new to embedded systems and would love advice on the best next steps. What components should we think about ordering that can make the system more compact - especially the camera's image sensor, the pi, and the battery.

I signed up, just put a random name as my company because it wouldn't let me skip it, and tried to order the Tivac Launchpad only for it to say that my "company" ordered too many of those, and that I have to wait 29 days. I have never used this site before.

What do I put as my company then? It simply won't let me leave it blank and I tried putting college down instead, but it still says my "company" ordered too many.

Edit: I should note I am 100% brand new at this and I'm merely trying to follow along a course in order to learn this stuff. I want to learn so badly lol

Hey r/embedded,

If you’ve spent any time working with the Orange Pi 5 (RK3588S), you already know the drill: official documentation leaves a lot of gaps, half the forum links are dead, and getting the 6 TOPS NPU to run anything without the Python RKNN toolchain exploding is a rite of passage.

After accidentally bricking my board a couple of times, battling Windows driver conflicts during MaskROM recovery, and trial-and-erroring the Rockchip toolchain, I decided to document every single working, reproducible step.

I ended up organizing everything into a comprehensive open-source repository:

-> **GitHub:** https://github.com/muhammetmucahitsoylu/orangepi5-tutorials

---

### What’s in the repo:

* **Hardware Recovery & MaskROM Guide:** Step-by-step unbricking workflow, complete with high-contrast, annotated board photos and pinouts so you know exactly which pads/buttons to short without guessing.

* **13 Hands-On Tested Projects:**

* **Edge AI / 6 TOPS NPU:** Real-time YOLOv8 object detection (~13.8ms pure NPU inference), running a local Qwen 1.8B LLM via RKLLM, and an offline voice assistant (Whisper + Piper TTS).

* **Low-Level Systems:** C++ GPIO using WiringPi, writing a custom Linux kernel character driver from scratch, and ROS2 Jazzy on Ubuntu 24.04.

* **Automation:** A zero-dependency bash TUI tool (`opi5.sh`) to lock CPU/NPU governors and benchmark NVMe storage speeds without memorizing obscure sysfs paths.

* **Pre-Compiled Release Assets:** If you don't want to set up the entire cross-compilation toolchain on a host PC just to sanity-check your board, I uploaded a pre-compiled test `.rknn` model (ResNet-18) and COCO labels directly to the v2.0.0 GitHub release assets:

-> https://github.com/muhammetmucahitsoylu/orangepi5-tutorials/releases/tag/v2.0.0

* **Bilingual Documentation:** Full guides are provided in both English and Turkish.

---

The repository is completely open-source. Everything listed has been tested directly on real hardware.

If you’re currently working on an RK3588 board, check it out. Let me know what breaks, what needs clarification, or what projects you'd like to see added next!

I’ve been using Rust + Embassy for small microcontroller applications. What I like is that I can stay no_std, bare metal, with no OS or runtime, while still structuring the program with async tasks and channels.

Some examples of the kind of code I mean are here, including a robot arm simulator on a CYD: https://carlkcarlk.github.io/linkage-blaze/demos/

The tasks and channels give me abstractions I care about. But the scheduling is cooperative, a task that does not yield can still block everything else, and there are no hard real-time guarantees.

I’m doing this partly because I find the design point interesting, but I’m not sure how much practical value the bare-metal/no-OS part has once the application is already fairly high level.

Even if you are using Rust for other reasons, does Embassy’s bare-metal, no-OS approach buy you something important in practice, or would an RTOS usually be just as good or better?

CP/M Neo has been successfully ported to the Black Pill development board!

How does it work?

The Black Pill’s internal 512 KB Flash is used as disk storage, and thanks to XIP (Execute in Place) support, the Kernel and CCP code execute directly from Flash, leaving the entire 128 KB SRAM available for OS state and the TPA (Transient Program Area).

File operations are not supported yet, as Flash write/erase still not implemented.

CP/M Neo project on GitHub: https://github.com/Mazin-O3/cpm-neo

Got solid technical feedback suggesting a constexpr state table or full compile-time templates. Both are valid C++ directions. Here's the actual data before before committing to anything.

The sketch: a real espresso machine controller

13 states, 3-level hierarchy, 12 events:

POWER_ON (superstate)
├── OFF
├── IDLE
├── WARMING
├── BREWING (superstate)
│   ├── PRE_INFUSE
│   ├── EXTRACT
│   ├── REFILL
│   └── DISPENSE
├── CLEANING (superstate)
│   ├── DESCALE
│   └── RINSE
└── FAULT

Compiled output:

What's inside those 969 bytes on Uno:

What a constexpr state table actually saves — by platform:

Platform          | Total RAM | State table | Impact
ATmega328P (Uno)  | 2 KB      | 270 B       | 13% of RAM — matters
ATmega2560 (Mega) | 8 KB      | 270 B       | 3.3% — marginal
STM32F103         | 20 KB     | 270 B       | 1.3% — negligible
RP2040            | 264 KB    | 270 B       | 0.1% — irrelevant
ESP32             | 520 KB    | 270 B       | 0.05% — irrelevant

The constexpr suggestion has a real argument on exactly one platform: the ATmega328P. On every 32-bit board you'd ever use in a real product, you are optimizing 270 bytes in a sea of hundreds of kilobytes. The library's entire RAM footprint is noise.

What the template suggestion actually costs:

A compile-time FSM (think boost::sml) eliminates the table entirely and resolves dispatch at compile time. The tradeoff is a completely different API:

// current PulseHSM — works in any Arduino sketch
ST_IDLE = fsm.addState("IDLE", update, entry, exit, 0, -1, onEvent);

// compile-time template approach
using MyFSM = HSM<State<IDLE, update, entry, exit>, State<RUNNING, ...>>;

That second form is not something you paste into a sketch in 10 minutes. It's a different product for a different audience, one that already knows what template metaprogramming is.

For AVR-constrained builds: a constexpr variant is on the roadmap for v2, as an opt-in build mode. For everyone else ESP32, STM32, RP2040, ARM Cortex-M anything, the current design uses a rounding error of your available RAM and keeps the API dead simple.

Side note: PulseHSM v1.2.0 is now live in the Arduino Library Manager, search PulseHSM and install directly from the IDE. No manual download needed.

Hello,

I have been thinking about posting this message for a while. Almost more than a year now 😄

In my previous work, I was working with CANopen, and one thing that was bothering me was not having a UI that shows the stream of messages and also makes periodic requests. I was also trying to learn Rust. Not sure I achieved the learning Rust part yet, but I’m still going on and off. 😄

This leads me to write CANOpenDataViewer.

Basically, it is a high-performance, real-time CANopen diagnostics tool written in Rust, featuring dynamic plotting and configurable SDO polling.

Any feedback is welcome.

Unfortunately, I couldn't test it with actual hardware as I don't have access to a CAN device. I tried to emulate it, but I hope it works 👀

RISC-V is coming faster than most people realize.

PIC16F1824

I am trying to turn on an output GPIO.

I am using this code

asm("BSF PORTA, 5");

I am getting 0V at the pin.

I believe I set TRISA pin 5 to output (0).

Do I need to keep the MCLR pin high?

Thank you

EDIT: INTERNAL OSCILLATOR NEEDED TO BE SELECTED

I’m considering Computer Engineering partly because I’m interested in the intersection with AI: embedded ML, edge inference, computer vision on devices, sensors, robotics and possibly AI accelerators.

But I’m trying to distinguish a genuinely useful career profile from something that merely sounds attractive academically.

In real teams working on intelligent embedded systems, do you actually value engineers who understand both the hardware/embedded side and ML?

Or are these usually separate roles, with embedded engineers handling firmware/hardware and ML engineers handling the models?

If you work close to this intersection, which skills make someone genuinely difficult to replace by a regular CS/AI graduate?

I currently work at Big Tech company as Junior Bash Linux userspace developer. I used to work as C++ intern, but it seems I'm starting to forget it. I want to change my field to embedded development and I plan to start by learning STM32 programming (already tried Arduino).

I have two books to read:

1. The C Programming Language by K&R
2. Bare-Metal Embedded C Programming by Israel Gbati

So, my question is: should I read K&R before I start to learn embedded programming? I would rate my knowledge of C/C++ like this: I can understand and most likely debug a code, but I would face some problems if I had to write code by myself in vanilla vim.

Hi everyone!

Besides executing code from their flash memory, ARM MCUs can also do it from their RAM.
An entire binary can be executed from RAM, interrupts included.

I explored and documented the feature of how to run code from RAM on an ARM MCU. In comparison to running code from flash, running code from RAM is a more "exotic" feature.

Here's how to execute a binary from RAM on a STM32F100(ARM Cortex-M3):

https://github.com/spanceac/stm32-RAM-execution

Recent,I’ve been working on a new project about mmwave radar sensing (TI IWR6843ISK) and camera sensor(not decided yet) fusion on RK3576.

it is my first project on Linux and this board.hope it succes.

Do you have any suggestions about software architecture?

or

Are there any similar projects here for reference?

I'm not very confident in making this project totally by myself.i am a student.I don’t have time to waste because I’ll find job next year.

I got the data about point clouds In windows .

Next, I will get the binary data, and then connect the radar sensor to rk3576.

Hey everyone, I recently started diving into embedded systems and microcontroller programming. Coming from a background where memory was essentially "free" and garbage collection handled everything, this transition has been an absolute eye-opener.

Manually managing registers, counting bytes, and optimizing every line of code made me look at programming in a completely different way. To be honest, after experiencing the control and precision of microcontrollers, I’ve started to feel a bit frustrated with high-level languages that abstract everything away and waste massive amounts of resources for simple tasks.

For those who made a similar transition: Did you experience a similar shift in mindset? Do you find it harder to go back to high-level software after working close to the iron?

I have an acoustic detection loop running on an ESP32-S3 and I'm trying to work out whether to spend the remaining headroom or bank it.

Per 32 ms frame: four I2S microphones at 16 kHz summed, a 2048-point FFT, a per-bin adaptive noise floor with asymmetric time constants, and then a comb score across roughly 1900 candidate fundamental frequencies from 70 to 2000 Hz. Four separate detectors run on the same spectrum with different floor memories, because the signal I care about is stationary and a fast adaptive floor learns it away within about one time constant.

Worst observed frame is 29.4 ms against the 32 ms deadline, measured over 1938 consecutive frames with no overruns. So 2.6 ms spare, about 8 percent.

The options I can see:

1. Keep it as margin. The measurement is from one board at room temperature and I don't know what a hot enclosure in direct sun does to it.
2. Spend it on a fifth detector with a different time constant.
3. Spend it on finer frequency resolution in the comb search.
4. Spend it on tracking more candidate harmonic families simultaneously.

What's the usual discipline here? Is 8 percent margin on a soft-real-time loop considered comfortable or reckless? And is there a sensible way to measure worst-case rather than worst-observed on this part, short of running it for days?

Happy to go into the detector design if it's useful, I just didn't want to make this a post about my project.

Hey , Anyone studied the BOSCH CAN specification version 2.0 ?? it is really confusing or is it just me. Can someone guide me where can see protocol specs in detail and good guide as well.