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?

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

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

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;

}

Writing code comments is such an enjoyable activity.

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?

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.

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?

Part of a series on the open-source J1939 emulator. This post covers how J1939 puts Parameter Groups on the bus and how ECUs join the network in the first place.

If you've stared at a raw J1939 CAN ID and wondered why the same byte means completely different things on different frames, this post is for you. We'll walk through the 29-bit identifier, the PDU1/PDU2 split that trips up almost everyone at first, and how an ECU claims its address on the network.

The 29-Bit J1939 Identifier

Every extended CAN frame on a J1939 bus uses this layout:

On the emulator, priority is 3 for EEC1 (engine speed/torque) and 6 for most other messages — this only affects bus arbitration, not meaning. Receivers ignore it entirely when interpreting the message content.

PDU1 vs PDU2 — The #1 Source of Confusion

This is where most people get tripped up, because the same field (PS) means two different things depending on the value of PF.

PDU1 (PF = 0–239): peer-to-peer / directed

• PS = Destination Address — literally who this message is for
• PGN = (DP << 16) | (PF << 8) — note that PS is not part of the PGN here
• Examples: Address Claimed (PF=0xEE, PS=0xFF for global), Request (PF=0xEA, PS=0x00 to address the engine directly), TP.CM/TP.DT sessions

PDU2 (PF = 240–255): broadcast / group

• PS = Group Extension — it's part of the PGN number itself, not a destination
• PGN = (DP << 16) | (PF << 8) | PS
• No single destination; any listener on the bus may consume it

On this emulator specifically:

The important thing to internalize: Group Extension is not a multicast group in the networking sense. It's simply the low byte of the PGN, baked into the CAN ID.

Scenario 1 — Cyclic Broadcast

On START, the emulator puts five J1939-71 parameter groups on the bus, plus address claim, VIN, and DM1 as configured. All five broadcast PGNs are PDU2 — PS is the PGN's low byte, not a destination address. Dash, ABS, telematics, and a logger all see the identical frames; each one simply filters by PGN for what it cares about.

This mirrors how a real engine works: on key-on, it publishes speed and temperature continuously, so the instrument cluster never has to poll for it.

EEC1 deep dive

PGN 61444, CAN ID 0x0CF00400. Example payload at 1250 RPM: F0 AF AD 10 27 F3 FF FF. Change the RPM slider in the GUI and watch bytes 3–4 update live — that's the actual RPM encoding in action, not a mocked value.

ET1 deep dive

PGN 65262, CAN ID 0x18FEEE00. Engine coolant temperature (SPN 110) feeds both the dash gauge and the DTC logic — the same signal that later triggers a fault (SPN 110 / FMI 3, voltage-high) is broadcast here. Broadcast every 1 second, no request required for normal driving — though a service tool can still request it directly for an immediate sample, which brings us to the next scenario.

Broadcast timing, no handshake involved:

Listeners filter by PGN/CAN ID — there's no CTS, no application-layer ACK. (Classical CAN's data-link-layer ACK still happens, from any healthy node on the bus, but that's a different layer entirely.)

Scenario 2 — Tester Requests a PGN

Sometimes a tool doesn't want to wait for the next broadcast cycle — it asks directly. This uses PGN 59904 (0xEA00), and it's a PDU1 message, which means PS finally does mean "destination."

Remember: SA = who sent it, PS on a PDU1 frame = who it's for.

A tool at SA 0xF9 asking the engine (SA 0x00) for ET1 looks like:

• Request frame: CAN ID 0x18EA00F9, 3 data bytes containing the little-endian PGN being requested
• Here, PS=0x00 means "destination = engine" — it is not the PGN low byte, because this is a PDU1 frame
• The engine typically replies as a normal PDU2 broadcast — on that reply frame, PS=0xEE is the Group Extension of PGN 65262

That contrast — same byte position, two different meanings depending on message type — is exactly why PDU1/PDU2 trips people up.

One honesty note: v1.0 of the emulator primarily broadcasts; it doesn't yet implement full request/response handling. It's still worth understanding this scenario, though, since it's exactly what a real scanner tool expects.

And there's a dependency worth calling out: if the engine hasn't claimed its address yet, a request just gets silence. Which brings us to address claim.

Scenario 3 — Address Claimed

PGN 60928 (0xEE00), governed by J1939-81, is how a node joins the network. On the emulator, SA 0x00 is claimed on start.

CAN ID: 0x18EEFF00. Worth noting: PF is 0xEE because that's simply the SAE-assigned PGN for Address Claimed (60928 = 0xEE00) — it's not a special "claim bit" hidden somewhere in the ID.

The NAME field

The 8 data bytes carry a 64-bit NAME, stored in the ECU's flash and copied into the Address Claimed payload every time it's sent. Peers decode this little-endian 64-bit value and update their internal address table: "SA 0x00 belongs to this NAME."

Conflict resolution: if two nodes claim the same SA, the one with the smaller 64-bit NAME wins. The loser either changes its SA (if it's configured as address-capable, AAC=1) or goes silent.

Timing

On start, the engine sends Address Claimed. Other nodes store the SA→NAME mapping and wait roughly a 250 ms class window for any contenders. A node may also explicitly request Address Claimed from others, prompting a re-announce. If a rival claims the same SA with a lower NAME, the current node loses that address. Once claiming succeeds, cyclic broadcast (EEC1, CCVS, etc.) begins.

Summary

• PDU2 broadcast: PS = PGN low byte; anyone may listen.
• PDU1 Request: PS = destination SA; SA = the requester.
• Address Claimed: the data payload is the NAME; the CAN ID carries PGN 60928 plus the node's preferred SA.
• Lower NAME wins a contested source address.

Watch It Live

Reading about PGN structure only gets you so far — seeing the actual frames change on a logger while you interact with the emulator makes it click. The full walkthrough, including a live address-claim capture, is in the YouTube series. Source and setup instructions: github.com/EmbeddedVerse/j1939-emulator.

Next in this series: how DTCs get packed into DM1 and split across multiple frames once you have more than one active fault.

I'm developing an open-source thermostat/HVAC controller based on the ESP32-C5, and I've ended up maintaining two PCB designs with the same intended functionality.

One uses the Seeed XIAO ESP32-C5; the other uses a generic 30-pin ESP32-C5 DevKit. The attached render shows the EU version with the generic DevKit installed.

The XIAO version is the one I'm optimizing for as a finished product. A compact, defined module makes it easier to work toward a consistent mechanical design, assembly process and manufacturable product.

The generic DevKit version is for people who prefer a more conventional development board and want another way to build the project. It adds design and testing work, but avoids making one particular module the only option.

I'm trying to balance two goals: designing something that can realistically be manufactured as a product, while keeping the hardware accessible to people who want to build or modify it themselves.

I'm curious how others approach this. Would you maintain separate PCB variants for these two use cases, or try to accommodate both on one board? What trade-offs would you consider before deciding?

I have some background in programming micro-controllers and now out of pure interest, I would like to understand how GPUs work and how they are programmed.

Can somebody recommend some resources to understand the basics?

Thanks.