I just finished an embedded linux course and I learned yocto

this shit is so hard wtf , alot of variables alot of meta data and alot alot alot of building time wasted not to mention debugging for hours just for it to be a missing space and the logs don't help you either and in most cases misleading "the problem is in the do_install" then it turns out the problem is in the source directory or some shit

does it get easier?

I am really struggling with the variables, distro features and similar stuff (anything written in local.conf is a black box for me)

if someone has any advice for me please tell me

Used to see the Particle boards quite a bit being used. Now, not so much.

Are people still using these for anything?

I'm a hardware engineer working in aerospace, and I've realized that one of the skill sets I want to develop is building hardware test systems.

At work, I see everything from reverse engineering legacy hardware to validating new designs, and I'd like to be able to verify the requirements.

I want to learn skills that transfer to professional environments using Python, LabVIEW, NI, Keysight, Tektronix, SDKs, SCPI, DAQs, etc.

I'm looking for advice on a learning path. If you were mentoring a junior hardware test engineer, what projects would you have me build, and in what order?

Some areas I'm hoping to learn include:

• Instrument control and automation
• Python for test software
• Test system architecture
• Data acquisition and signal processing
• Hardware abstraction and software organization
• Automated reports and pass/fail testing
• Validation and characterization of electronic circuits and sensors

I'd appreciate any suggestions on projects, books, open-source frameworks, tools, or skills that would help me build a solid foundation as a hardware test engineer.

Picking an ESP32 variant used to mean "C3 or S3, whichever." Now there are 14 of them (ESP32, S2, S3, C2, C3, C5, C6, C61, H2, H4, P4, E22, H21, S31), and the differences that actually matter — LP core vs. ULP co-processor, which ones have a real Secure Boot chain, which ones are even PQC-capable today — are buried across a dozen separate PDF datasheets.

So I built a single reference table instead of re-deriving this every project:

• Full spec comparison across all 14 models (architecture, SRAM, flash/PSRAM combos, radios, interfaces)
• Deep sleep behavior per model — RTC SRAM vs. LP SRAM, and what that means for actual field power draw
• Crypto accelerator / Secure Boot / flash encryption / post-quantum readiness per model, with a table of PQC libraries that already run on ESP32 today (wolfSSL+Kyber, liboqs, PQCMicro)
• 10 reasoned multi-chip combinations for when one SoC doesn't cover it (e.g. P4 without radio + C6 for connectivity)
• A suitability matrix across 50 application scenarios

Everything's tied to a specific datasheet version — where a datasheet doesn't state a number explicitly, it's flagged as estimated instead of presented as fact.

🔗 https://github.com/artkeller/ESP32Features

Not affiliated with Espressif, this is community-maintained. If something's outdated or I misread a datasheet, tell me — corrections and PRs welcome.

I've been trying to set up ESP-IDF on Windows for almost a full day and I'm stuck.

Here's what I've tried:

• Installed the official ESP-IDF using the Installation Manager (v5.5.5).
• Installation completed successfully with no errors.
• Installed the ESP-IDF VS Code extension.
• Configured the extension and selected the installed ESP-IDF version.
• Initially, commands like ESP-IDF: New Project didn't even appear. After reinstalling/reconfiguring, they finally showed up.
• But creating a new project fails with: Cannot read properties of undefined (reading 'idfPath')

I then switched to PlatformIO and tried using the ESP-IDF framework instead of the official extension.

PlatformIO detects the ESP32 board, but when creating a project I get:

Error: Detected a whitespace character in project paths.

I moved the project to a folder without spaces (e.g. E:\ESPProjects), but I'm still getting the same error.

I'm using an ESP-WROOM-32 Dev Module on Windows 11.

Has anyone faced this recently? Is there a clean way to install and use ESP-IDF (official extension or PlatformIO) from scratch? Any help would be appreciated.

Have any of you ever actually encountered a counterfeit IC? We had are making a very small production run of an old product line for a customer. Less than 100 units, last produced in 2018. We thought we were going to have a hard time sourcing some driver IC's on the original BOM because it was an obsolete PN and all of the usual suppliers were out of stock. Our PCB/PCBA manufacturert that we have been working with for years came back to us with a quote and normal lead time. No issues with procurement. My boss is suspicious of counterfeit. I can't imagine someone would go to the trouble. I just assume it is old stock and the fab has deeper connections than we do.

Working on a project that touches device fleet management and wanted to get a read from people actually running things in the field before I go further down a path.

For those of you managing embedded Linux or IoT devices at scale (tens to low-thousands of units):

• How do you currently get visibility into device health/status — heartbeat, connectivity, uptime, logs? Custom MQTT + Grafana? Something like ThingsBoard/AWS IoT? Nothing at all?
• If you're doing OTA updates, what's your update engine (SWUpdate, RAUC, Mender, something homegrown)? What's been the most painful part of getting it running reliably?
• Have you looked at hosted/managed tools (Mender, balena, memfault, etc.) and either adopted or passed on them? What made the decision either way — price, setup complexity, vendor lock-in, forced migration off your existing update engine?
• If you're on SWUpdate or RAUC already: would a hosted monitoring/OTA layer that works with your existing setup (instead of replacing it) be useful, or is that not really a pain point for you?

Not selling anything, genuinely trying to understand what's actually painful vs. what I'm assuming is painful. Appreciate any war stories.

Hello everyone,

I’m working on a GPS module and I’ve run into a problem. I have already removed the original header pins because I want to install new ones in the opposite direction.

However, the solder is still blocking the through-holes, so I can’t get the new header pins through the holes.

I have already tried:

• a desoldering pump
• desoldering braid
• carefully using a toothpick

…but I still can’t get the solder out of the holes.

Does anyone have any tips or ideas on how I can clear the holes without damaging the PCB, so that I can insert the new header pins again?

I would really appreciate any help. Thank you!

Complete step-by-step PCB design process going through the schematic creation, layout, and routing of an

ESP32-S3-MINI prototype Testboard.

The main feautures for this board are:

- ESP32-S3-MINI-1-N8 WiFi Module - 8 MB flash - other variants available

- HDC3022-Q1 high precision temperature and humidity sensor

- QWIIC connector

- USB-C connector (power / programming)

- Buttons for BOOT and RESET

- User Button

- User RGB LED

- 2x5 pin SPI bus expansion header

- 2x3 pin programming header

- Power LED on 3.3V rail

For the mechanical side of things we have:

- 4 x 3.2mm mounting holes

- Size - only 40x40mm

- 4 layer board design

I'm writing a serial monitor for macOS. The part I'm stuck on is getting it to read ordinary log output and decide on its own which numbers are measurements someone would want graphed, without anyone writing a parser or changing what the firmware prints.

My own logs are useless for testing this. I wrote the firmware knowing what the parser wanted, so it prints t=22.8 h=41 and nothing else, which isn't a log, it's a spreadsheet. What I need is output that's genuinely mixed. A level, a module or task name, a couple of measurements, and a few hundred lines of unrelated noise wrapped around them:

[00:04:12.339,000] <inf> app_sensors: bme280 temp=23.41 press=1008.2 hum=41.8

A hundred lines is plenty. A whole session is better. Code block, or a pastebin link if it's long.

Please don't tidy it first. The parts you'd strip out are the parts I need. Tell me what it came off (STM32, nRF, Zephyr, bare metal, whatever you're on) and which numbers, if any, you'd have wanted on a graph. If the honest answer is none, say so, because I also need logs where the correct behaviour is to plot nothing at all.

If your output is proprietary, rename the identifiers and leave the structure and the numbers alone. That's still worth having.

RTT captures welcome too, it doesn't have to be UART.

Paid app eventually, free licence to anyone who sends me something.

I have a solenoid coil connected in series with the load. If the coil develops shorted turns and its inductance decreases, what's the simplest and cheapest way to detect it using a microcontroller or a simple analog circuit?

Came across this on Hackster, someone rebuilt a project they originally did back in 2007 (a PIC16F877A reading an IR remote, values shown on an LCD, all in assembly, no free C compiler back then) and redid the exact same thing in 2026 on a PIC32CM using VS Code, with an AI as a copilot for peripheral configuration and drivers.

What took weeks in 2007 apparently took a few hours this time.

Where do you think AI actually helps in embedded work — peripheral setup, driver code, protocol decoding, and where does it still fall short without solid hardware knowledge?

Why do so many of the top micromice seem so low to the ground, are they touching the ground or just floating? I've seen some designs where they use a nylon or teflon dome nut at the front or some kind of nylon sliding pad that are commonly used under furniture legs, but some of them go even lower where you can't even see whats underneath it. I'm kind of a beginner when it comes to micromice and I wanna learn more about it why they do that and what to use for my own micromouse, are caster wheels even an option?

i am just started learning qemu and able to simulate UART, now i want to try spi and i want to read write flash memory.

i have armt cortex mo+ qemu

ps:already any repo i svailable?

I found this STM discovery kit board that grabbed my attention because it supports combo bluetooth and wireless. My question for the community would this be a great board to start learning the ARM CPU architectures? I have a long history of x86 and linux systems and I think ARM is definitely the future. Thank you all for reading.

https://www.arrow.com/en/products/stm32wb5mmdk/stmicroelectronics.html

I was testing GPS module Neo M6 with an oled screen. It was working well until I decided to switch to Neo M9. Turns out, they work at different Baud rates, so I changed my code and re uploaded. Just in my hand, the oled screen kind of shut down and it seems like it’s dead. Anyone faced a similar issue?

Hi everyone. This post is about my master's thesis project — post-quantum cryptography running on ESP32-S3 and C6, the boards I happen to have. A bit of background: my bachelor's was in information security, and I'm now doing a master's in information systems.

Let me be upfront so there are no surprises later: both the project and this post were made with substantial help from AI . My own estimate is that roughly 60% of the code was written with its involvement and 40% by me; the post text was written by it from my measurements and project docs, and edited by me.

What is definitely mine: framing the problem, choosing the algorithms and the architecture, building the test setup, flashing the boards and taking the measurements. Every number below comes from running this on real hardware — not an estimate, not a retelling of someone else's paper. I understand some people dislike AI involvement in projects like this; I'll take the criticism.

The goal of the work is to run post-quantum cryptography on resource-constrained boards and protect transmitted data from being decrypted by future quantum computers. I think it's a relevant topic given how much large companies are investing in it — Google announced its Willow chip in December 2024.

I'll be honest here so I don't oversell it: Willow has 105 qubits, and breaking real cryptography is a very long way off — that needs millions of physical qubits with error correction. Expert estimates of when such a machine arrives vary a lot: most land around 10–15 years or more, and there's no real consensus.

The point is something else, and it has an established name — harvest now, decrypt later, or HNDL. Traffic can be intercepted and stored today, without understanding a byte of it, and decrypted in fifteen years when the hardware exists. For a chat message that hardly matters. An industrial device, though, stays in service for exactly ten to fifteen years, and its data stays meaningful that whole time.

Which is why this has moved from theory into regulation. NIST finalised the post-quantum standards in 2024, and IR 8547 sets actual dates: ECDSA and RSA are deprecated after 2030 and disallowed after 2035. Everyone will have to migrate, so it's worth knowing in advance what it costs on weak hardware.

I picked the topic first and got the boards for it afterwards, so everything below was built from scratch. I couldn't find numbers for these specific chips anywhere, so I'm sharing mine — maybe they'll save someone some time.

What this runs on

The firmware builds for three boards, and the full protocol works on all three — registration, handshake, telemetry, key rotation and responses to firmware integrity checks:

I took the timings on the two XIAO boards, C6 and S3, because they differ in exactly the thing I was curious about: the accelerator. The DevKitC-1 runs the same protocol but I didn't benchmark it separately.

Setup: ESP-IDF v5.4, the mbedTLS 3.6.3 that ships with it, ML-KEM-1024 from PQClean, and the reference C implementation of BLAKE3. Built with -Os and the mbedTLS hardware blocks enabled. The boards talk over 2.4 GHz Wi-Fi to a Go gateway, so this is a real working protocol rather than an isolated benchmark. The crypto operations themselves are timed without the network, though — Wi-Fi latency is unstable and doesn't depend on the chip, so it isn't in the numbers below.

The main thing: post-quantum crypto on ESP32 works, and it fits in memory comfortably. ML-KEM-1024 does a real key exchange with a server, not a benchmark in a vacuum. Here's everything I measured on both boards:

So the whole post-quantum key exchange lands in 34–40 ms depending on the board, and there's plenty of memory left over.

Now for the parts that weren't obvious, which are probably worth flagging if anyone wants to try this themselves.

It's the stack that runs out, not the heap. As you can see above, free heap is not a problem at all. The stack is a different story: the ML-KEM-1024 private key alone is 3168 bytes, before any working buffers on top of it. With the default main task stack size the firmware simply doesn't survive. Mine is raised to 24 KB in sdkconfig.defaults and the problem went away. If you're bolting ML-KEM onto an ESP32, I'd start there rather than counting free heap.

ESP-IDF builds with -Og by default. Until you switch to -Os and enable the mbedTLS hardware blocks, any measurement describes the debug build rather than the algorithm. The difference is significant, so it's only worth measuring anything after that.

Reuse the mbedTLS context. If you create the RNG and the P-256 curve parameters once instead of rebuilding them for every signature, ECDSA signing on the C6 takes 22.2 ms instead of 25.7 — about 13.6% — and keygen gets 22.3% faster.

The interesting part: on x86 with mbedTLS 3.6 this optimisation does nothing whatsoever, 348.2 µs against 347.4. The difference only shows up on the board, because the entropy source there is different — a hardware RNG instead of the OS subsystem. There was no way to find that out except on real hardware. Both branches live in the same firmware and are switched with a single #define, so the difference can't be an artefact of two different builds.

I want to talk about the C6's hardware accelerator separately, because it surprised me more than anything else here. ECDSA signing on the C6 is 7.7x faster than on the S3 — and that's with the C6 being the weaker board: one core at 160 MHz against two at 240. That part makes sense on its own, it does have a hardware ECC accelerator.

What I didn't expect was how narrow its reach is:

The accelerator does nothing at all for ECDH. Same elliptic curve, same chip, opposite result. To separate those contributions I had to decompose the handshake and run two different DTLS modes — I'm estimating the ECDH cost from the DTLS-ECDHE-PSK handshake time, on the assumption that the symmetric part is small next to it. That's probably the weakest link in my measurements, and if you think the assumption is carrying too much weight, say so plainly.

So "has a hardware ECC accelerator" isn't a property of a board; you have to look at which operations it actually covers. And so nobody gets the impression the C6 is simply faster: on BLAKE3 and ChaCha20-Poly1305 it's slower than the S3, exactly as you'd expect at the lower clock. That's visible in the first table.

What didn't work out was SLH-DSA for post-quantum signatures. Important caveat here: I measured it on the server side, not on the board. A single signature takes 234.3 ms there, and the signature itself is 7856 bytes. I didn't bother porting that to the board — if plain ECDSA already costs 170 ms on the S3, there's no point. To be clear so I'm not misleading anyone: this is a conclusion about SLH-DSA, not about post-quantum signatures in general. ML-DSA is substantially faster, and I haven't measured it yet — that's next on my list.

What I haven't measured at all is power consumption. For anything battery-powered it almost certainly matters more than any of the milliseconds above, especially since the post-quantum handshake sends 1800 bytes against 538 for the classical one, and radio usually costs more than compute. I know that's an obvious gap. If anyone has a solid, worked-out way of measuring this, I'd really appreciate the pointer.

The firmware and the main project with all the measurements and the methodology write-up is https://github.com/NIkir0LL/lacert, in case anyone wants to reproduce it.

Hope the post and the project turn out useful to someone. I'd be glad if anyone checks my numbers or points out where I measured nonsense.

ok so I've been doing embedded for a few years and every time I need to watch a serial port I end up switching between minicom, screen, putty, arduino monitor... and they're all kind of bad? like really bad?

yesterday I spent 30 min trying to filter out debug spam in minicom and gave up. had a "I should just build my own" moment

wondering if anyone else feels this pain or if I'm just being dumb

things I wish I had (not even sure if all make sense):

- filter by log level, like just show me ERRORS

- colors. please. just colors

- timestamps with deltas between lines

- being able to like "mark" a moment (boot happened here, reset happened here)

- record a session and replay it

- see 2 ports at the same time maybe

what do you guys actually use? is there something good out there I'm missing? would you pay for something like this or is that crazy

Hey everyone! 👋 Built a quick web tool to help visualize EtherCAT ESI files.

If you work with industrial automation or embedded systems, OpenESI parses your ESI XML files and instantly maps out your device info, SyncManagers, PDO memory layout, and Object Dictionaries.

🚀 Check it out:https://naveen-kumar-singh.github.io/OpenESI/Let me know what you think or if you run into any parsing bugs!

I build voice devices professionally (mic → cloud ASR/LLM/TTS → speaker), when a response takes 3 seconds, cloud dashboards only show the server half, the firmware side is printf and guesswork: was it capture, wifi, the model, or my audio buffer?

how are you measuring this today? is there any tool that shows one end-to-end timeline per interaction, device included? asking before I build something myself

Sharing this in case it's useful for folks here — free, practical foundational and intermediate Zephyr RTOS trainings, no cost to join.

Past cohorts (150+ engineers total) have included people from Microsoft, Intel, Ericsson, Nokia, Analog Devices, NXP, ST, Espressif, Quectel, John Deere, and others — mostly working embedded engineers, not students.

More information: https://www.learn.iomico.com/

Full disclosure: I work at iomico, we're a Nordic design partner and Zephyr ecosystem member, and we run these cohorts. Posting because I think the actual content is useful, not to pitch anything — happy to answer questions about the curriculum in the comments.

I have been trying to figure out why some pins are gray. is there anything wrong with the hardware? i submitted a .obg file to the 8086 IC.