I have a software engineering background. Okaish C++, but new to C language and also learning Embedded with STM32 family.

I have tried Rust few years ago i loved it for it's toolchain and ease of adding libraries just like NodeJs's NPM.

I understand it took some time for C++ to catch up in embedded, but now due to AI I felt Rust might catch up faster than C++.

Now that big tech in AI are taking Rust. Do you think i should also learn Rust. I'm not a person who likes everything to be vibe coded, as I'm waiting for AI prices to go high and enjoy the show. (Too ambitious)

But that's what I am.

So I appreciate your feedback and your thoughts, what do you think about Rust in embedded ro should I stick to C language. I enjoy CMSIS and bare metal too.

I want to start career in embedded systems, i have beed going through this course mastering microcontroller and embedded driver development by fastbit embedded brain academy on udemy.

I have almost completed this course now in parallel I want to learn RTOS. Buy without AI I feel the learning gets slow, this is a 28hr course which took 3 months of time still 10% is pending (I'm not always following the lectures as it is since my controller is different and more advanced than the instructors, I'm designing my drivers a little different).

I have started to get frustrated since these months I haven't worked on a single project, I'm being so desperate now to learn RTOS fast, do some projects and get a job.

Curious how you do this, because it's quite of a painful experience for me every time. Designing takes some time but it's at least kinda fun. Ordering from Chinese stores not really.

So the design side is done. Schematic, layout and firmware are ready faster or slower depending on complexity, but AI helps quite a bit. Then comes ordering the components which is painful by itself (at least for my wallet 😄). Digikey for the MCU and passives, LCSC because some of it is half the price, JLC for the boards, Amazon for whatever I need fast. Either way there is a lot of searching, clicking and a 100 tabs open.

Every vendor has its own minimums and shipping, so I end up moving parts between carts to dodge a $20 shipping fee on a $6 order. Then something is out of stock and I'm back in the BOM picking an alternate.

For people who build more than a board or two a year, what does your actual flow look like? Do you stick to one distributor and accept the price, or handle it somehow differently?

I’m building a tool to help small hardware teams screen firmware applicants. The role is an ECU for a small turbojet: FSM design, interrupts and timing, CAN/SPI/ADC, fault handling. I don’t want to guess what matters. What question reveals real hands-on experience in 15 minutes, and what’s the difference between a strong and a weak answer? Also, what do you think AI interviewers get wrong? Happy to share what I learn.

Short write-up in case it saves someone time with MediaTek's LK on MT8183.

The board was unlocked (kaeru), and it booted Amazon's 32-bit kernel fine, but nothing 64-bit ran. No console because the stock cmdline disables the UART. I found TX/RX on TP103/TP104 (1.8V, 921600) and the causes turned out to be:

- ramdisk size and address swapped in the boot header (header v1, load at 0x40080000)
- LK wanted Image.gz, not a raw Image
- no /chosen/bootargs in my DTB, so LK hits an ASSERT and resets about 45 seconds later
- my DTB declared atf/tee/sspm reserved memory that LK also carves out, which fails its overlap check
- bootopt has to say 64-bit (64S3,32N2,64N2)

After that, mainline 6.18 came up. Audio was its own fight. The I2C bus the amp and ADC sit on is shared with the SCP, and the hardware controller never completes a transfer from Linux, so it's bit-banged. The mainline AFE also wrote clock gates while the regmap was still cache-only. TAS5805M amp at 96 kHz and TLV320ADC5140 mics are working now.

This will be added to my TECHO5 project (Linux + Home Assistant on Echo Shows): https://github.com/HuskerMinion/techo5

At my previous job, we used Squish to automate our UI test suites. I recently changed jobs and am researching alternatives.

The only thing that's shown up in my searches other than Squish is "Spix", but I want to make sure that I'm not missing something obvious when it comes to setting up automation from the ground up. Additionally, if there are any video tutorials on automating embedded systems to help refresh myself please feel free to recommend some.

I previously did automated testing with pytest and a legacy junit automation suite. As far as I know they aren't QT compatible, but if anyone has any expertise in this I'd appreciate any comments.

Hi all,

I'm an EE undergrad (hardware track). My diploma thesis is a 2-in/2-out USB studio audio interface on my own PCB. It's my first PCB, so before I spend real money on boards and parts I'd love some experienced eyes on the plan. Block diagram attached.

The idea
- 2 mic inputs (XLR), shared 48 V phantom (one switch), gain 0–60 dB in 10 dB steps (rotary switch + fixed RG resistors, cap in series with RG).
- Noise-reduction technique I'm evaluating: each input drives BOTH channels of a stereo ADC (dual-mono) and the MCU averages them. The host still sees 2 mono channels, with ~3 dB lower ADC noise. I'll measure the gain from averaging at every gain step, comparing same-chip vs two-chip channel pairs.

Current part choices
- Preamp: SSM2019 (the THAT1512 went EOL in Sept 2026).
- ADC driver: passive divider (6.2k/1k, ~17 dB) + RC into a PCM1808, so the ADC reaches full scale ~1.8 dB before the preamp clips (≈ +20 dBu max input at minimum gain).
- ADC: 2 × PCM1808. DAC: PCM5102A.
- Line outs: DRV134 on TRS jacks. Headphones: op-amp + BUF634A. Output mute relays with a brown-out detector.
- Digital: STM32F407G-DISC1 board stacked on headers above the analog board. TinyUSB, UAC2 asynchronous with explicit feedback endpoint, 48 kHz / 24-bit in 3-byte subslots (the 1.25 KB USB FIFO rules out 4-byte subslots and 96 kHz).
- Clock: 24.576 MHz oscillator → ADC/DAC system clock and the MCU's external I2S clock input.
- Between boards: SN74LVC244A buffer (Ioff, to avoid back-powering) + a power-good line; 5 V to the dev board through a Schottky.
- Power (version A): bench triple supply (±15 V, +5 V), local LDOs for the ADC's 5.0 V and the 3.3 V. Phantom from a boost converter + capacitance multiplier (soft start, ripple filtering, output disconnect).
- Phantom protection following Bortoni & Kirkwood, "The 48 Volt Phantom Menace Returns". The single-channel test board will start from ojg's open-source thatmicpre KiCad project.
- Metal enclosure, XLR pin 1 to chassis at the entry point.

Noise budget (unweighted, 20 Hz–20 kHz, 150 Ω source)
- Predicted EIN at 60 dB gain: −128.7 dBu (target ≤ −125 dBu; worst case with min-spec ADC ≈ −127.5 dBu).
- Because of the divider, the ADC dominates up to ~50 dB gain. That's where averaging should help (~3 dB); at 60 dB the source dominates (~0.3 dB).

Plan
1. Demo on the dev board with cheap PCM1808/PCM5102A modules (incl. a first averaging measurement).
2. Small 2-layer single-channel preamp board.
3. 4-layer analog board for the full 2×2 interface.

Questions
1. Any obvious mistakes or bad part choices?
2. Is a passive divider + RC into the PCM1808 reasonable, or would you drive it differently?
3. Phantom: boost + capacitance multiplier, or something simpler? Anything missing in the protection network?
4. Is stacking the dev board right above the analog board realistic for low noise at 60 dB gain? Any layout/grounding advice?
5. Measuring without an audio analyzer: the card's own ADC + a 0.1 % attenuator + a true-RMS meter + REW for noise/EIN, and loopback as an upper bound for THD+N. Sensible?
6. Anything you'd simplify for a first PCB?

Thanks!

Hello from the yes or no? post X-Y problem:

What im actually trying to do is write to eeprom whenever a switch is pressed and then recall that information from eeprom so that the Microchip MCU can recall what position the switch is in at power up.

I do not know how to write or read from eeprom without assembly. I already know how to do so in assembly so I was trying to not learn an additional step if I could translate from the WREG to a C variable.

Any suggestions much appreciated.

Hi everyone,

I'm working on a project to replace physical coins on buses with a smart ID card.

Here are some specific questions I have:

• Hardware: What is a reliable, low-cost NFC or RFID reader module for a handheld device?
• Offline Mode: How should the scanner handle payments when the bus loses internet connection?
• Data Sync: What is the best way to sync local transaction logs to the cloud once the device is back online?

Hey everybody, I was taking a course in Embedded Operating Systems, and since my primary way of taking notes is Obsidian, I found it pretty annoying to deal with it since it’s missing some basic stuff like highlighting for ARM or RISC-V, and also dealing with memory maps and registers.

So I vibecoded a plugin to fix this small niche issues, it has some pretty comfy features, with hover cards for instructions and conversion of numbers in different basis, diagrams and also syntax for other smaller things such as Makefile, Linker Script, Verilog etc…

I wanted some opinions from external users, and thought that could be useful for the few people in my situation

Any tips or recommendations are welcome!

Cool project I had a lot of fun building.

A fully trained neural network running on a low-end FPGA (Digilent Nexys 3), WITH parallel computing of course (why even use an FPGA if not for that).
Had fun making a microprocessor on this thing last year, so I figured I might as well go for a quantized neural network.

GitHub repo for anyone interested :
https://github.com/Si7li/MNIST-Neural-Network-On-FPGA

Story

After working on numerous hobbyist projects with microcontrollers and external hardware—such as sensors, relays, and motors—I noticed a recurring challenge: every new device required rebuilding the same core features from scratch. Tasks like serial communication, HTTP services, MQTT, logging, and, above all, a modern, full-featured web interface for configuration had to be re-implemented every time.

With powerful, Wi-Fi-enabled microcontrollers like the ESP32 family, which offer ample processing power and rich web-server libraries, I realized there was a better way.

This led to the concept of a micro-OS with a Hardware Abstraction Layer (HAL)—designed to integrate different boards seamlessly while providing a comprehensive suite of essential IoT services out of the box.

That is how LoopMxPro was born!

https://github.com/SmartiLabIt/LoopMaxPro

LoopMxPro allows you to skip the tedious boilerplate and focus entirely on developing your core device logic. By building on top of this micro-OS, your custom setup turns into a LoopMxPro Module with its own dedicated web interface. What's more, this interface can be easily replicated on a remote control server.

Today, I’m excited to share LoopMxPro + 6 Modules with the community. It is completely free and open-source for personal use!

Zappy 2Ch 3D viewer

Writing code comments is such an enjoyable activity.

PIC16F1824-I/SL

I want to do something if the working register is 0x0A for example or 0xA0. I need to access it somehow and Im not sure how besides getting it into a C variable. Like this for example,

if(WREG == 0x0A){

bypassed = 0b00000000;

}

else if (WREG == 0xA0){

bypassed = 0b11111111;

}

My team is in a refresh process with our hardware supplier, we've been using a propriertary RTOS until now. This time our supplier suggests going for a yocto linux solution that they will support for us (for a additional cost)

Our real-time requirements are firm, i.e. a missed deadline in a 20ms window renders the system useless but it doesn't explode and kill anyone, thus a real time patched linux kernel will probably work (most of the time)

Regarding yocto and an expected lifetime support of 4 years, I have concerns with patching, CVE, updates etc. our current system has been running for 12 years now with minimal need for updates, less than 10 CVE's, and when we need to update software, we can do it easily.

Licensing for the propriertary RTOS is expensive, we're a small team (less than 5 devs), and our system is managing processes worth magnitudes of the licensing cost.

I'm concerned that we're saving pennies now and it ends up costing us dimes both in time and resources in the long run.

Anyone been in a similar situation and got some insight to share?

Want to design Nano-SIM male plug (4FF), a flexible ribbon, and a rigid breakout board housing the push-type SIM socket and analyzer header.Please Guide me !

I am new to all this so I am not sure what exactly I am even asking, and why I need to thisn, well.... For educational purposes

Hey, does anyone know of a low-cost site for manufacturing a 4-layer PCBA that includes a Linux-based microprocessor?

Just curious as to what type of cross-section of users are here and if this would be a good place for me to share and ask questions.

Does anyone tend to run ESP32 boards and/or micropython primarily?

I’m trying to get the three front ultrasonic sensors working on my Lymow One Plus, using the original STM32 board’s power and interface circuitry as intended. I’d like to figure out the factory supply path before adding an external supply or changing any GPIO outputs.
I’ve attached full-board photos and close-ups. The coating makes the small component markings difficult to read. Does anyone recognize the three matching six-pin devices or the two three-pin parts beside them? More importantly, can anyone help work out where the front sensor supply comes from and what enables it?
Here’s what we have so far.
Hardware and measurements
Main MCU is an STM32F407V-series, 100-pin package. The second MCU is an AT32F403ARCT7.
Both chips’ flash has been backed up over SWD, with two matching reads of each. No firmware changes or GPIO writes have been made.
There are three front sensors: left, center and right. Each has red, black and yellow wiring. The modules are marked C26A03 / 0255E, but I haven’t found a matching module datasheet.
Their connections have been traced to the unpopulated 2×14 header footprint. My photo labels RR/RY, CR/CY and LR/LY mean right red/yellow, center red/yellow and left red/yellow; G marks confirmed grounds.
The three red-wire pads have continuity to each other. All measured 0 V with the mower running. The shared red net measured approximately 20 kΩ to confirmed ground with power disconnected.
A separate harness point labelled ULT_PWR measured 5 V, but there’s no measured continuity between that point and the front red-wire net. I’m not assuming they’re the same supply.
On earlier isolated bench tests, yellow idled around 2.6 V with 3.3 V supplied, and 4.2 V with about 4.9 V supplied. No convincing sensor reply was captured. That doesn’t establish the module’s rated voltage or prove the sensors are bad.
What the firmware shows
The STM32 contains a three-channel pulse interface whose timing is a very strong match for the Elmos E524-family IO protocol:
150 µs bits, with 100/50 µs or 50/100 µs phases.
A 250 µs command-mode interval.
Measurement windows of 8.25–46.25 ms, followed by additional captured edges consistent with a status reply.
Separate transmit and receive MCU pins: PA5 → PB1, PA1 → PB0, PA2 → PA7. The receive side uses TIM3 channels 4, 3 and 2.
Those are firmware pin pairs; their exact correspondence to the three physical yellow-wire connections still needs confirmation.
The Elmos E524.33 document specifies a 6–18 V operating supply, typically 12 V. That’s a useful lead, not a confirmed voltage rating for these exact modules. I haven’t applied 9 or 12 V based on that assumption. If you’re reading this you’re cool.
We also took read-only snapshots while the mower was running, roughly 19–46 seconds after boot:
TIM3 was configured for capture but stopped: CR1 = 0, DIER = 0, CCER = 0.
All three capture-event counters were zero.
The pulse driver’s state and descriptor records were all zero.
The three front-distance cache values stayed zero.
The rear ultrasonic readings changed normally during the same checks.
The firmware retains names ULT_F_1_task, ULT_F_5_task and ULT_F_10_task, but we haven’t found those tasks being created or a routine updating the front-distance cache at 0x2000130C. That strongly suggests dormant front acquisition in this build. It doesn’t prove nothing could enable it later in another operating state.
Possible supply controls
STM32 PD3 goes high during sensor initialization and was high in the live snapshots. It’s associated with the working rear-sensor code, but its physical supply net hasn’t been traced.
PE1 and PE8 are configured as outputs and have identified low-setting paths at startup/shutdown, without a discovered high-setting path. They’re candidates for an unused enable, not confirmed front-power controls. Other less certain candidates are PB8, PE4, PE5, PE6 and PE12. I haven’t toggled any of them.
Parts we’ve looked at
The eight-pin chip beside R250 is marked 8870 / TI…, matching a TI DRV8870 motor driver. The earlier idea that it was a sensor-supply regulator was a guess and should be discarded. Neither end of R250 showed continuity to the front red net in our checks.
Another eight-pin device appears to have a 4407-family marking, possibly an AO4407 P-channel MOSFET. That identification is tentative. The nearby two-pad footprint also showed no continuity to the front red net.
There are three matching six-pin circuits beside the sensor header, each surrounded by similar resistors/capacitors. They look like interface stages, but we haven’t identified the parts.
The two three-pin components beside those circuits are still unidentified. We also initially mistook a piece of grass for a jumper wire—there is no confirmed factory rework wire there.
I have a meter, logic analyzer, a Waveshare adapter that successfully accesses both chips over SWD, and the saved firmware/disassembly.
What I’m hoping someone can help identify is the original switched supply for the three front sensors: which component feeds the common red net, what voltage it should provide, and which MCU pin—if any—controls it. A schematic fragment, recognizable part marking, or a specific trace to check would be a huge help. I’d rather establish that circuit than keep guessing at nearby components or blindly switching GPIOs.

R-Right
L-Left
C-Center

I tried making it easy for myself.

I got Deere for embedded systems/firmware and RTX for a devops/simulation role. My goal is to work for vehicle firmware or flight software at a company such as Tesla, Rivian, SpaceX Anduril or firmware at Apple, Nvidia, AMD for my next internship. RTX has more aura and more of a weighted brand name, but Deere has more of the work I want to do in later companies.

I need a serial data logger which supports RS-232 and RS-422(maximum possible baud rate). I want to capture samples from sensors to the SD card. I will be mounting this on a DJI drone or a car, so it should be battery-powered.
What off-the-shelf options do I have?

Pretty much the title; I want to buy an osciloscope for hobbyist use (I’m a recent EEE graduate) and I can afford to go for the MHO954 from Rigol.

The only problem is that I’m just not sure if it’s worth it or not. Does it bring significant benefits over a 100MHz oscilloscope?

Edit: issue was resolved, it was pin 11 AVDD shorted to ground. Credit to u/Hangoverman who caught the issue.

Full disclosure, this is a work project, so the question is probably doomed since I can't show the whole circuit.

We have a managed network switch on our hardware. One of the ports was meant to go to a W5500 to give ethernet connection to the microcontroller.

It just doesn't work, and I've tried for 9 months and 5 revisions. Every one of the other dozens of features and peripherals on the board work perfectly. This isn't blocking anything important, so my bosses are ready to drop the feature, but it is driving me crazy.

I connect to the W5500 and the KSZ8895MLUB network switch over spi with no issues.

I have tried multiple sets of magnetics, right now what's in there is actually the Hanrun HR681616

The other 3 ports of the switch all connect fine

The switch has a diagnostic that checks the connection, but it gets back that TX4_P and TX4_N are open, but that the RX side is OK.

The PHY won't form a link in any mode. I believe my configuration is right for the W5500, but I could be wrong.

I will admit that I am not very experienced with networking. I have put an oscilloscope on all the ports of the magnetics and have seen what looks like data going both ways during startup, but I don't know if it looks right at all.