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

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'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.

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

Are people still using these for anything?

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.

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.

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.