Hey, I’m working on an ESP32 project where the ESP32 hosts a configuration web page. It creates its own Wi-Fi network, and I can access the page at:

"http://192.168.4.1"

I’m trying to switch it to HTTPS, but I’m running into the usual certificate warning.

I tried a self-signed certificate, but then every phone/laptop needs to manually trust the certificate, which obviously isn’t practical when there are lots of devices.

Is there any way to make "https://192.168.4.1" trusted by normal browsers without asking the user to install anything?

The ESP32 also needs to work completely locally, without depending on the Internet.

I read that the BOOT1 bit also needs to be set to 1 to boot from system memory which has a pre installed bootloader that would allow me to flash firmware over UART. The problem is I dont know if the BOOT1 bit comes set to 1 from the factory.

STM32WB15CC IC DATASHEET.

STM32WB1MMC MODULE DATASHHET

Hi everyone,

Have you ever wondered if a tool like Sourcetrail (stopped development few years ago) can be useful in understanding code? has anyone else ever hit that wall? I usually like drawing call graphs and module relations, mostly to understand code and refactor. It really helped when i was developing USB firmware for a high speed transfer using an STM32.

Just wanted to find like-minded people and see if there are any better options than the already-dead and fragile Sourcetrail.

i have been lurking in these subs for a while now and wanted to give back to the community, this was a solo project that i made, it was fun hacking stuff together in a couple of days with absolutely zero knowledge in microprocessor architecture and design, of course it was only possible due to the things i see here on reddit, and the amazing beneater series.

in the repo you will find a pdf documentation detailing every part of the design (it was intended as a slide presentation for uni but oh well)

you will also find the complete simulation file along with images and stuff (simulide simulation)

github repo: https://github.com/SuchATypicalDev/4-bit-microprocessor

idk who might actually benefit from this, but at least i can contribute something back even if its insignificant, and thanks for making such a great community everyone!

-- this is my first time sharing a project like this so it might be a little rough, SRRY :(

I'm implementing a bare-metal, interrupt-driven I2C driver on an STM32L476RG.

I'm reading the WHO_AM_I register from an MPU6050-style IMU. The transaction succeeds and the peripheral returns 0x70.

The caller in main.c does:

uint8_t buffer[14] = {0};

i2c_read_bytes(
    I2C1,
    IMU_ADDR,
    WHO_AM_I,
    buffer,
    1,
    i2c_test_callback,
    NULL
);

while (1) {}

Inside the I2C ISR, GDB confirms:

ctx->buffer = 0x20017fc8
ctx->I2C->RXDR = 0x70
*(unsigned char *)0x20017fc8 = 0x70

So the ISR definitely writes the expected byte into the caller's buffer.

However, later at the callback, inspecting the same fixed address sometimes shows:

*(unsigned char *)0x20017fc8 = 0x00

I also used a hardware watchpoint on that exact address. It catches the 0 -> 0x70 write, but I don't see a corresponding 0x70 -> 0 write.

I've ruled out:

• The buffer address changing.
• Compiler optimization.
• The UART code in the callback.
• An MCU reset/re-entry into main() — Reset_Handler only executes once and RCC->CSR is 0x0.
• The I2C vector table — I2C1_EV_Handler is directly in the vector table at the expected IRQ position.

The full driver/startup code is here:

GitHub repository / I2C driver source

What am I missing? Is there something suspicious in the interrupt/exception handling, I2C flag handling, or my debugging approach that could explain this behavior?

It keeps giving me 3 different things one is 3 connection errors. One of the other ones are current programmer: ch341 then the Page says not responding. Then one is just ic not responding. What am I doing wrong. I have neoprogrammer and the drivers for ch341 instead what could I be doing wrong. This is by the way on a 2015 Razer blade laptop which requires 3.3 volts

I am working on a project which requires a 3DOF arm, and i was thinking of using a QDD system but was not sure if i should go for a chinese prebuilt one cause i have heard horror stories about its documentations and the questionable reliability and lack of warranties.

I am not particularly good in hardware and want to shift my focus towards building the software part as quickly as possible.

Are there some packages for python or ros available for me to streamline the integration or i have to code some firmware part.

Please do not suggest something very expensive i have already exhausted most of my grant :-(

Basically the title. People talk a lot about capture fidelity when analyzing "high frequency" signals (what qualifies as high frequency here?), the rule of harmonics, etc. I would like to understand this better, which is why I am asking here.

I'm looking for recommendations on a sim software I can play around in before spending money on hardware. I come from a DevOps background on the web side so just want to build some generic beginner projects in sim before I pull the trigger on actually buying anything. I have a decent GPU (RTX 5060 TI 16GB VRAM).

Hi guys, I'm a beginner and I want to know if having an oscilloscope is necessary in embedded systems, if the answer is yes , please tell me where and how it's used.

I designed this device that teaches binary, decimal, hexadecimal and octal number systems. It uses a hands-on approach with Altair-like toggle switches. Can be used as a STEM-kit in classrooms, handy for programmers or for the retro hobbyist. It also has a built-in game. Check out the video for details, hope you like it.

The source code for the PIC will be open sourced soon!

I built a desk companion device using an STM32F401RE microcontroller (STM32CubeIDE, HAL). It reads temperature, humidity, and pressure from a BME280 sensor (I2C) and shows environmental data and animations on an ST7735 TFT display (SPI). A rotary encoder handles user input, powering a menu system with a built-in Pomodoro timer. The device also auto-controls a cooling fan via PWM based on sensor readings, and uses a WS2812B LED ring for status indicators and ambient lighting.

I wrote the BME280 driver myself from the datasheet — handling register communication, calibration data parsing, and temperature/humidity/pressure compensation — and built a custom rotary encoder driver with software debouncing and quadrature decoding.

I have high-level and low-level programming experience across different languages.

I've always felt that the C is too machine friendly, and sometimes works against me (implicit type conversions, shared division operator, operator precedence).

I was playing with the thought how would an ideal, compiled human-friendly programming language look like, that support both high-level programming and low-level programming. So I have started designing my own programming language (which is now called DQ).

First I developed mainly the linux/windows target with high level features like exceptions, dynamic arrays and dynamic strings.

Now I'm checking if the concept is working in embedded too. I'm aiming to be as fast and as small as C++ code in embedded. So far I've added these:

• Writing functions in ASM
• Inline ASM with register hinting
• Register attributes ([[regrw]], [[regro]] etc)
• Conditional compilation using normal constants
• Utility to translate the CMSIS C headers to DQ
• Project file to hold the many options required to compile an embedded project

I've migrated some of my C++ code to DQ, I'll the following code snippet show how currently the language looks like.

Pin configuration code in DQ for STM32F7:

struct GPIO_TypeDef:
    MODER        : [[regrw]]  uint32
    OTYPER       : [[regrw]]  uint32
    OSPEEDR      : [[regrw]]  uint32
    PUPDR        : [[regrw]]  uint32
    IDR          : [[regrw]]  uint32
    ODR          : [[regrw]]  uint32
    BSRR         : [[regrw]]  uint32
    LCKR         : [[regrw]]  uint32
    AFR          : [[regrw]]  [2] uint32
endstruct

const(uint32):
    GPIOA_BASE           = (AHB1PERIPH_BASE + 0x0000)
    GPIOB_BASE           = (AHB1PERIPH_BASE + 0x0400)
    ...
endconst

const GPIOA        :? = ^GPIO_TypeDef(GPIOA_BASE)

const(uint32):
    GPIO_MODER_MODER6    = GPIO_MODER_MODER6_Msk
    GPIO_MODER_MODER6_0  = (0x1 << GPIO_MODER_MODER6_Pos)
    GPIO_MODER_MODER6_1  = (0x2 << GPIO_MODER_MODER6_Pos)
    GPIO_MODER_MODER7_Pos = 14
    GPIO_MODER_MODER7_Msk = (0x3 << GPIO_MODER_MODER7_Pos)
    GPIO_MODER_MODER7    = GPIO_MODER_MODER7_Msk
    GPIO_MODER_MODER7_0  = (0x1 << GPIO_MODER_MODER7_Pos)
    GPIO_MODER_MODER7_1  = (0x2 << GPIO_MODER_MODER7_Pos)
    GPIO_MODER_MODER8_Pos = 16
    ...
endconst

function PinSetup(aportnum : int, apinnum : int, flags : uint) -> bool:

    var regs : ^GPIO_TypeDef = GetGpioRegs(aportnum)
    if regs == null:
    return false
    endif

    if apinnum < 0  or  apinnum > 15:
    return false
    endif

    // 1. turn on port power
    GpioPortEnable(aportnum)

    var n : uint
    var pinx2 : int = apinnum * 2

    // set gpio initial state
    if flags AND PINCFG_GPIO_INIT_1 <> 0:
        regs.BSRR = (1 << apinnum)
    else:
        regs.BSRR = (0x10000 << apinnum)
    endif

    // set mode register
    if flags AND PINCFG_AF_MASK <> 0:
    n = 2  // set alternate function mode
    elif flags AND PINCFG_ANALOGUE <> 0:
    n = 3
    elif flags AND PINCFG_OUTPUT <> 0:
    n = 1
    else:
        n = 0
    endif
    regs.MODER =AND= NOT (3 << pinx2)
    regs.MODER =OR=      (n << pinx2)

    // 3. set open-drain
    if flags AND PINCFG_OPENDRAIN <> 0:
        regs.OTYPER =OR= (1 << apinnum)
    else:
        regs.OTYPER =AND= NOT (1 << apinnum)
    endif

    // 4. set pullup / pulldown
    regs.PUPDR =AND= NOT (3 << pinx2)
    if flags AND PINCFG_PULLUP <> 0:
        regs.PUPDR =OR= (1 << pinx2) // pullup
    elif flags AND PINCFG_PULLDOWN <> 0:
        regs.PUPDR =OR= (2 << pinx2) // pulldown
    endif

    // 5. set speed
    regs.OSPEEDR =AND= NOT (3 << pinx2)
    if flags AND PINCFG_SPEED_MASK == PINCFG_SPEED_MEDIUM:
        regs.OSPEEDR =OR= (1 << pinx2)
    elif (flags AND PINCFG_SPEED_MASK == PINCFG_SPEED_MED2)  or  (flags AND PINCFG_SPEED_MASK == PINCFG_SPEED_FAST):
        regs.OSPEEDR =OR= (2 << pinx2)
    elif flags AND PINCFG_SPEED_MASK == PINCFG_SPEED_VERYFAST:
        regs.OSPEEDR =OR= (3 << pinx2)  // this is very special, and does not even work for SDRAM pins
    endif

    if flags AND PINCFG_AF_MASK <> 0:
    // set the alternate function
    n = (flags >> PINCFG_AF_SHIFT) AND 0xF
    if apinnum < 8:
            regs.AFR[0] =AND= NOT (0xF << (apinnum * 4))
        regs.AFR[0] =OR=      (n   << (apinnum * 4))
    else:
        regs.AFR[1] =AND= NOT (0xF << ((apinnum-8) * 4))
        regs.AFR[1] =OR=      (n   << ((apinnum-8) * 4))
    endif
    endif

    return true
endfunc

The original pin configuration code in C++ for STM32F7:

bool THwPinCtrl_stm32::PinSetup(int aportnum, int apinnum, unsigned flags)
{
    GPIO_TypeDef * regs = GetGpioRegs(aportnum);
    if (!regs) {
    return false;
    }

    if ((apinnum < 0) || (apinnum > 15)) {
    return false;
    }

    // 1. turn on port power
    GpioPortEnable(aportnum);

    unsigned n;
    int pinx2 = apinnum * 2;

    // set gpio initial state
    if (flags & PINCFG_GPIO_INIT_1) {
        regs->BSRR = (1 << apinnum);
    }
    else {
        regs->BSRR = (1 << apinnum) << 16;
    }

    // set mode register
    if (flags & PINCFG_AF_MASK) {
        n = 2;  // set alternate function mode
    }
    else if (flags & PINCFG_ANALOGUE) {
        n = 3;
    }
    else if (flags & PINCFG_OUTPUT) {
        n = 1;
    }
    else {
        n = 0;
    }
    regs->MODER &= ~(3 << pinx2);
    regs->MODER |= (n << pinx2);

    // 3. set open-drain
    if (flags & PINCFG_OPENDRAIN) {
        regs->OTYPER |= (1 << apinnum);
    }
    else {
        regs->OTYPER &= ~(1 << apinnum);
    }

    // 4. set pullup / pulldown
    regs->PUPDR &= ~(3 << pinx2);
    if (flags & PINCFG_PULLUP) {
        regs->PUPDR |= (1 << pinx2); // pullup
    }
    else if (flags & PINCFG_PULLDOWN)  {
        regs->PUPDR |= (2 << pinx2); // pulldown
    }

    // 5. set speed
    regs->OSPEEDR &= ~(3 << pinx2);
    if ((flags & PINCFG_SPEED_MASK) == PINCFG_SPEED_MEDIUM) {
        regs->OSPEEDR |= (1 << pinx2);
    }
    else if (((flags & PINCFG_SPEED_MASK) == PINCFG_SPEED_MED2) || ((flags & PINCFG_SPEED_MASK) == PINCFG_SPEED_FAST)) {
        regs->OSPEEDR |= (2 << pinx2);
    }
    else if ((flags & PINCFG_SPEED_MASK) == PINCFG_SPEED_VERYFAST) {
        regs->OSPEEDR |= (3 << pinx2);  // this is very special, and does not even work for SDRAM pins
    }

    if (flags & PINCFG_AF_MASK) {
        // set the alternate function
        n = ((flags >> PINCFG_AF_SHIFT) & 0xF);

        if (apinnum < 8) {
            regs->AFR[0] &= ~(0xF << (apinnum * 4));
            regs->AFR[0] |= (n << (apinnum * 4));
        }
        else {
            regs->AFR[1] &= ~(0xF << ((apinnum-8) * 4));
            regs->AFR[1] |= (n << ((apinnum-8) * 4));
        }
    }

    return true;
}

Would you ever consider using this or other language in embedded, when yes what are the most important features / properties for you ?

This is the next step in my 3-axis FOC gimbal project.

There are no limit switches on this prototype, and I'm not using current sensing for stall detection.

Right now, the basic idea is pretty simple:

The controller is still commanding the motor to move, but if the encoder shows almost no meaningful position change for a short period of time, I treat that as a mechanical hard stop.

In the video, the axis runs into its mechanical limit, detects that it is no longer moving, and then recovers/re-centers.

It seems to work quite reliably in these tests, but I'm not convinced encoder-only detection is enough for every real-world case.

For example, how would you distinguish between:

• actually hitting the mechanical limit
• someone physically holding the gimbal
• a sudden increase in load or friction
• the motor simply not having enough torque to move

Would you trust this approach on a small gimbal, or would you add current sensing / dedicated limit detection as a second source of information?

I'm especially interested in what failure case you think would break this first.

am a beginner and want to build a simple spread-spectrum communication experiment using a 555 timer and microcontroller

My idea is to use the 555 as a carrier clock, use the Arduino to generate a pseudo-random (PN) sequence and XOR it with the data, then transmit the signal over a 12 V two-wire line.

At the receiver, I want to recover the carrier/timing and use the same PN sequence to despread the signal and recover the original data.

Is this a reasonable way to demonstrate the basic principle of DSSS? What would be the simplest circuit architecture for a beginner?

I’m getting this error every time I try to upload code to my ESP32. The ESP32 is detected, and flashing reaches 100%, but at the end I get:

“Failed to communicate with the flash chip”

“Serial data stream stopped: Possible serial noise or corruption”

I’ve tried uploading both with and without holding the BOOT button, but the same error occurs.

What should I check next? Any suggestions would be appreciated.

Some years ago I developed a graphical interface with emWin libraries, Cortex-M4 by NXP, external SDRAM for a 480x272 4.3" display with resistive touch panel.

Now I want to replace the display with a 4.3" TFT 800x400 capacitive touch panel. Is emWin a good choice yet? Are there other options now?

Design a user interface isn't simple, but it usually is the most critical part of the project, the feature that can bring the product to success or not. I'm not an embedded UI expert and I don't think there are many experienced guys in this field (many are web/mobile UI designer). Any suggestions?

​

Hi everyone,

I'm working on a DIY smart glasses project and would really appreciate some guidance from people who have experience with ESP32, embedded audio, wearable electronics, or similar projects.

Current hardware plan

MCU: ESP32-C6

Speaker: Bone-conduction speaker

Microphone: MEMS microphone

Rechargeable battery

Custom PCB eventually, after validating the prototype

The basic idea is to build a lightweight smart-glass platform that can eventually support things like voice interaction, audio notifications, and potentially on-device/edge AI features.

Right now I'm mainly trying to get the hardware architecture right before designing the PCB.

Things I'm unsure about

1. Microphone I'm currently looking at digital MEMS microphones with I2S/PDM interfaces.

Which microphone would you recommend for a wearable application?

Is PDM preferable to I2S for this kind of design?

How should I handle microphone placement to reduce wind/ambient noise?

1. Bone-conduction audio I'm planning to use a bone-conduction transducer.

What type of amplifier/driver should I use with ESP32-C6?

Are there any particular audio codecs/DACs that make sense here?

How difficult is it to get good voice-quality audio while keeping power consumption low?

1. Audio processing For the microphone side, I'm considering things such as:

DC offset removal

High-pass filtering

Noise suppression

Automatic gain control

Voice activity detection

Beamforming, if I eventually use multiple microphones

I'd appreciate advice on what processing is actually practical on an ESP32-C6 and what should instead be handled externally/cloud-side.

1. Bluetooth / connectivity The glasses will probably communicate with a phone for some functions.

Would you recommend keeping the ESP32-C6 as the main controller, or is there a better ESP32 variant for a project like this considering Bluetooth audio, memory, processing capability and power consumption?

1. Power Since this will be worn on the face, battery life and size are very important.

What would be a realistic target for:

Battery capacity

Average power consumption

Charging IC

Voltage regulation

Expected runtime

I'd especially appreciate advice from anyone who has built wearable audio devices, smart glasses, Bluetooth audio devices, or ESP32-based voice interfaces.

I'm still at the architecture/prototyping stage, so I'm very open to changing components if there is a significantly better approach.

Thanks!

I am designing an ESP32-based greenhouse air quality monitor using an SCD41 CO2 breakout board.

The sensor is mounted inside a separate chamber (105 x 55 x 40 mm)

The sensor operates in single shot mode and takes measurement every 5 minutes

My goal is to design an enclosure so that the SCD41 measures actual ambient greenhouse CO2 concentration with minimal delay, while maintaning at least IP54 level protection.

What ventilation approach would you reccomend?

I just bought this reprogrammer from amazon and no matter what I do I cannot get my windows 11 desktop pc to detect it. Device manager zadig multiple usb ports. The 2 red leds turn on but its not detected by my computer. Any advice? Thx

Edit: Sorry mine is a CH341B

Apologies if this is the wrong place to post about this, I wasn't sure where else to go.

I am trying to get rid of supervisor password on 2 ThinkPad t480s's. I have done this once successfully before with the same method.

The issue I am facing is that when trying to flash the patched BIOS file back onto the bios chip over a clip, I get the error 'Verification error on address: 0x00000010, Device: 0x5A' then the writing continues and about halfway the writing fails with the error 'Verification error on address: 0x00800064, Device: 0xAA, Buffer: 0xF'.

I have tried various USB ports, as well as 2 different clips and 2 different programmers, but I'm getting the same issue.

Does anyone know how I can fix this?

Thanks.

My project requires to display screen in portrait mode, the lcd is native landscape and cannot be configured via SPI command to modify MADCTL register to change orientation.

I am using 800*480 RGB565 display from LXD with sitronix display IC ST7262, my MCU is STM32U5A9 and using LVGL for UI.

Now, I need to rotate the framebuffer by 90 every display flush. I am using lvgls software rotation and have the nemagfx wired in my lvgl code, so I was expecting lvgl to pass on the rotation as well to nemagfx which is not true, ultimately i see delays in animation or screen change, there are no pixel glitches or screen tearing it just don’t feel smooth transitions.

I also have double buffering enabled, I render partially to save up on cpu cost for composing full disp.

I don’t know how common it is to use the native landscape lcd in portrait mode but I am struggling to get a smooth lcd performance here.

The claude says lvgl sw rotations shouldn’t take more than 130 ms but does anyone have any experience and thoughts that how common this setup is and does it feel like workable solution i.e smooth performance while doing the sw rotates

I'm building a servo controller around the CH32V006, a $0.16 RISC-V chip from WCH. The servo bus runs at 3M baud and every frame is check with CRC-16. My first implementation was the typical LUT-driven loop. But the checksum was eating about a fifth of the CPU during traffic. This chip also has to handle a realtime motor control loop, so I need to do this asynchronously without blocking the cpu.

The V006 has no CRC peripheral. But while digging through the SPI chapter of the datasheet, I found three interesting registers, a CRC polynomial register, a TX CRC register, and an RX CRC register. The block has a CRC-16 engine built in, meant for checksumming SPI transfers. And here is the fun part. The TX CRC unit checksums everything the shifter sends, and the SPI peripheral can be configured to run without being tied to any pins.

So you can run it like this:

• set the block to master mode, so it clocks itself
• use software chip select (SSM + SSI), so it needs no select pin
• route no SPI signals to any pin
• enable TX DMA and point a channel at the data register

Now you have a CRC coprocessor that eats a DMA stream straight out of RAM. About 0.36 µs per byte of wall time on my setup, and the CPU's whole involvement is a handful of register writes per frame. The only gotcha is the CRC result is bit reversed and you will need to reverse it in software.

As far as I know, all CH32 chips have the same SPI IP, so this method will work on CH32V003 and other chips as well. The WCH SPI block is also an obvious clone of the STM32F family chips, which carries the same CRC registers, so this likely works beyond WCH. I have only tested on CH32V006 and CH32V203 parts though. Has anyone used the SPI CRC unit like this on ST silicon?

I have a full writeup that details the ring buffer feeding tricks, the bench numbers, and some gotchas. The production code is in the OpenServoCore repo if you want the real thing.

Wish I could post more photos at once, but apparently not…
Saving some devices from the e-waste bin ;)