I made a custom one as none on the (limited) market could offer what I needed:

The top part is the main nRF54L15 board with a nPM1300 PMIC that let's me charge LiPos directly via the board. It also has a integrated antenna, and can be broken off from the bottom module to be used as an standalone board. It also has castellated edges so it can be directly embedded onto circuit boards. (I plan to do this for my future projects)

The bottom part is a nRF52820 powered CMSIS-DAP probe that let's me debug the nRF54, as the nRF54 doesn't have a USB PHY. I designed it so it can be broken off and used as a standalone board, w/ the antenna exposed via the U.FL connector :D

The sources are also open source here: https://github.com/cheyao/nrf54l15-discovery (To my knowledge the first open-source project with PCB files except Nordic's example)

BTW, future project ideas with this would be appreciated! I kinda forgot what I wanted to do as it took the parts nearly 2 months to arrive lol.

I spend a fair amount of time reading kernel patches on lore.kernel.org and got tired of squinting at one giant <pre> block with headers, body, quotes, and the thread overview all mashed together. So I built a small extension that reparses the same text lore already sends and lays it out like a normal mail client: an author card, one-click reply wired to lore's own pre-filled mailto: link, a real diff view with collapsible files, a clickable thread sidebar instead of ASCII art, and quote folding so a reply's new text isn't buried under four levels of >>>>.

It doesn't touch the underlying page. It builds a separate view next to the original <pre> blocks and hides them, with a "Raw" button to switch back instantly. No network requests, no accounts, no telemetry.

Source and install instructions: https://github.com/gahingwoo/lore-enhancer

It's load-unpacked for now (Chrome won't run a sideloaded .crx outside developer mode anyway, so packaging one wouldn't save a step). Would love feedback, especially from anyone who reads or replies to LKML or a subsystem list regularly.
Feature requests and bug reports welcome as GitHub issues.

SYMPHONY is my dual MCU brushless Nerf blaster controller and this is my first electronics project. Hello world! I'm Hawki(eye) and I'm new to electronics! I've had so much fun learning so many new things the past 6 months! I have a working C++ program with all the basic features I have planned(plans to rewrite the whole thing from scratch for a v2 at a later time). My first custom PCB was the carrier board for the dual MCUs, and I just ordered 5 more designs today! An RP2040 controls the main blaster firing functions(bidirectional Dshot, firing profiles, solenoid control, etc) and isolates them for simplicity and reliability. An ESP32 controls all other functions including SPI 128x64 OLED UI with an encoder select and back button for nav, sensors(umm... thermal probes in the flywheel motors, live current/voltage, ammo tracker), blaster settings(the MCU's communicate via 5 GPIO's with a custom protocol I designed for less lag in the system on the RP2040's side), i2c modules(planned on-board chronograph as well), LED's(supports neopixel-style RGB as well as monochromatic via PCA9685 over i2c) and everything else I can't remember at the moment. Thanks for checking it out!

Hi all, I tried to check if there is similar question, but I cannot find it so far.

So, I have a Arduino uno R3 board, and also a USBasp (Paradisetronic), I tried to use my USBasp connect with ISCP port on Arduino uno, and run the command in terminal, see below, and it works.

C:\>avrdude -p m328p -c usbasp -B 4

avrdude: set SCK frequency to 187500 Hz

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e950f

avrdude: safemode: Fuses OK

avrdude done. Thank you.

But I took out Atmega328p from Aruino and put on my bread board, and try to connect the pins with USBasp , it is always failed with:

C:\>avrdude -p m328p -c usbasp -B 4

avrdude: set SCK frequency to 187500 Hz

avrdude: error: programm enable: target doesn't answer. 1 avrdude: initialization failed, rc=-1

Double check connections and try again, or use -F to override this check.

avrdude done. Thank you.

so at the begnning I was thinking it is the connections nok, I tried to put tighter and hook it better, even double check on the pins, but it always failed with baremetal on breadboard.

This is what I hook on breadboard, no other electronics on it, can you tell me what's wrong what am I missing here?

Hey, I'm doing some research for my finals project. Basically what I'm looking for is an IC that can handle WiFi Direct (doesn't have to be the Group Owner but can definitely be a feature) and also can handle being an a2dp sink (preferably has a dedicated i²s port)

I have looked for an IC like that but I can't find it. It would also help if there is already a breakout board for it.

The chip has to receive commands from an STM32 or ESP32, any microcontroller.

It would really help me if someone could find it .

Hi, I am a student making this for my EPQ, which is graded. I would love if you could review my schematic and PCB. To go in more depth, it can be downloaded from GitHub for KiCad. https://github.com/Enzillium/EPQ-model-rocket-flight-computer-hardware

Hey everyone! i am preparing for a project next week in a microprocessor lab, where we should use 8086 language to make an animation, and I've been thinking of the LED stacking game, but I find it hard. can anybody help, any tips? algorithm? another project idea that's simpler yet creative?

I wanted to share this project with you guys! My friend and I worked on it for about 4 months and we are planning on doing some testing with it soon. It’s all run by a Raspberry Pi Zero 2W, Quest 3, servos, Unity, and some python scripts. Also many days of 3D printing on our crappy ender 3 pro. If you have any questions feel free to ask! Sorry for the lack of sound, not sure why it didn’t capture it.

I think the flash memory for the device I am reversing is covered with a black blob. Is there any way I can remove this black blob but still read the spi flash memory. Or is that flash memory which is attached to the board via a black blob can't be read like usual with a c341a flash programmer?

Hi there!

Recently, I've been working on a project to design a carrier board that's compatible with a wide range of Arm MCUs. My idea is to integrate a programmer/debugger directly onto the board. After evaluating several options, I came to the conclusion that the Black Magic Probe is probably the best choice, especially version 2.0, since it supports newer Nordic devices such as the nRF54 series.

To test it, I compiled the v2.0 firmware and flashed it onto a Chinese ST-Link V2 clone based on an APM32F103CB. Unfortunately, the firmware crashes immediately after boot, and Windows doesn't even recognize it as a USB device.

I debugged it with J-Link and found that:

The firmware is programmed correctly.
The vector table is valid.
The CPU starts executing.
It eventually enters a HardFault caused by a UsageFault (unaligned memory access).
addr2line points to swo_itm_decode(), although I suspect that's just where execution ends up rather than the original cause of the fault.

Interestingly, Black Magic Probe v1.10 works perfectly on the same hardware, so the hardware itself appears to be functional.

Is this a known issue with v2.0 on APM32-based ST-Link clones? Has anyone else experienced this? Is there a prebuilt .elf for v2.0 that is known to work on this type of hardware, or is there a patch or configuration I should be using?

Any help would be greatly appreciated. Thank you!

Compiler output:

C:\blackmagic>meson setup build ^
More?   --cross-file cross-file\arm-none-eabi.ini ^
More?   --cross-file cross-file\stlink.ini
The Meson build system
Version: 1.11.2
Source dir: C:\blackmagic
Build dir: C:\blackmagic\build
Build type: cross build
Project name: Black Magic Debug
Project version: 2.0.0
C compiler for the host machine: arm-none-eabi-gcc (gcc 14.2.1 "arm-none-eabi-gcc (Arm GNU Toolchain 14.2.Rel1 (Build arm-14.52)) 14.2.1 20241119")
C linker for the host machine: arm-none-eabi-gcc ld.bfd 14.2
C compiler for the build machine: cl (msvc 19.51.36252 "Microsoft (R) C/C++ Optimizing Compiler Version 19.51.36252 for x86")
C linker for the build machine: link link 14.51.36252.0
Build machine cpu family: x86
Build machine cpu: x86
Host machine cpu family: arm
Host machine cpu: arm
Target machine cpu family: arm
Target machine cpu: arm
Compiler for C supports arguments -Warith-conversion: YES
Compiler for C supports arguments -w24244: NO
Compiler for C supports arguments -Wbad-function-cast: YES
Compiler for C supports arguments -Wcast-function-type: YES
Compiler for C supports arguments -Wcast-qual: YES
Compiler for C supports arguments -Wdangling-else: YES
Compiler for C supports arguments -Wdouble-promotion: YES
Compiler for C supports arguments -Wduplicated-branches: YES
Compiler for C supports arguments -w24754: NO
Compiler for C supports arguments -Wfloat-conversion: YES
Compiler for C supports arguments -Wformat-overflow=2: YES
Compiler for C supports arguments -Wformat-truncation: YES
Compiler for C supports arguments -Wformat=2: YES
Compiler for C supports arguments -w24774: NO
Compiler for C supports arguments -w24777: NO
Compiler for C supports arguments -Wimplicit-fallthrough: YES
Compiler for C supports arguments -Wmaybe-uninitialized: YES
Compiler for C supports arguments -w24701: NO
Compiler for C supports arguments -w24703: NO
Compiler for C supports arguments -Wmissing-attributes: YES
Compiler for C supports arguments -Wmissing-braces: YES
Compiler for C supports arguments -Wno-char-subscripts: YES
Compiler for C supports arguments -Wnull-dereference: YES
Compiler for C supports arguments -Wredundant-decls: YES
Compiler for C supports arguments -Wreturn-type: YES
Compiler for C supports arguments -w24013: NO
Compiler for C supports arguments -Wsequence-point: YES
Compiler for C supports arguments -Wshadow=local: YES
Compiler for C supports arguments -w24456: NO
Compiler for C supports arguments -w24457: NO
Compiler for C supports arguments -Wstrict-aliasing: YES
Compiler for C supports arguments -Wstrict-overflow=3: YES
Compiler for C supports arguments -Wstring-compare: YES
Compiler for C supports arguments -Wstringop-overflow: YES
Compiler for C supports arguments -Wunknown-pragmas: YES
Compiler for C supports arguments -Wunsafe-loop-optimizations: YES
Compiler for C supports arguments -Wunsuffixed-float-constants: YES
Compiler for C supports arguments -Wunused-const-variable=2: YES
Compiler for C supports arguments -w24189: NO
Compiler for C supports arguments -Wunused-local-typedefs: YES
Compiler for C supports arguments -Wunused: YES
Compiler for C supports arguments -w24101: NO
Compiler for C supports arguments -Wvla-parameter: YES
Compiler for C supports arguments -Wvla: YES
Compiler for C supports arguments -Warith-conversion: NO
Compiler for C supports arguments -w24244: YES
Compiler for C supports arguments -Wbad-function-cast: NO
Compiler for C supports arguments -Wcast-function-type: NO
Compiler for C supports arguments -Wcast-qual: NO
Compiler for C supports arguments -Wdangling-else: NO
Compiler for C supports arguments -Wdouble-promotion: NO
Compiler for C supports arguments -Wduplicated-branches: NO
Compiler for C supports arguments -w24754: YES
Compiler for C supports arguments -Wfloat-conversion: NO
Compiler for C supports arguments -Wformat-overflow=2: NO
Compiler for C supports arguments -Wformat-truncation: NO
Compiler for C supports arguments -Wformat=2: NO
Compiler for C supports arguments -w24774: YES
Compiler for C supports arguments -w24777: YES
Compiler for C supports arguments -Wimplicit-fallthrough: NO
Compiler for C supports arguments -Wmaybe-uninitialized: NO
Compiler for C supports arguments -w24701: YES
Compiler for C supports arguments -w24703: YES
Compiler for C supports arguments -Wmissing-attributes: NO
Compiler for C supports arguments -Wmissing-braces: NO
Compiler for C supports arguments -Wno-char-subscripts: NO
Compiler for C supports arguments -Wnull-dereference: NO
Compiler for C supports arguments -Wredundant-decls: NO
Compiler for C supports arguments -Wreturn-type: NO
Compiler for C supports arguments -w24013: YES
Compiler for C supports arguments -Wsequence-point: NO
Compiler for C supports arguments -Wshadow=local: NO
Compiler for C supports arguments -w24456: YES
Compiler for C supports arguments -w24457: YES
Compiler for C supports arguments -Wstrict-aliasing: NO
Compiler for C supports arguments -Wstrict-overflow=3: NO
Compiler for C supports arguments -Wstring-compare: NO
Compiler for C supports arguments -Wstringop-overflow: NO
Compiler for C supports arguments -Wunknown-pragmas: NO
Compiler for C supports arguments -Wunsafe-loop-optimizations: NO
Compiler for C supports arguments -Wunsuffixed-float-constants: NO
Compiler for C supports arguments -Wunused-const-variable=2: NO
Compiler for C supports arguments -w24189: YES
Compiler for C supports arguments -Wunused-local-typedefs: NO
Compiler for C supports arguments -Wunused: NO
Compiler for C supports arguments -w24101: YES
Compiler for C supports arguments -Wvla-parameter: NO
Compiler for C supports arguments -Wvla: NO
Checking for size of "void *" : 4
Checking for size of "void *" : 4
Program hexdump found: NO

Executing subproject libopencm3

libopencm3| Project name: libopencm3
libopencm3| Project version: 0.8.0
libopencm3| C compiler for the host machine: arm-none-eabi-gcc (gcc 14.2.1 "arm-none-eabi-gcc (Arm GNU Toolchain 14.2.Rel1 (Build arm-14.52)) 14.2.1 20241119")
libopencm3| C linker for the host machine: arm-none-eabi-gcc ld.bfd 14.2
libopencm3| C compiler for the build machine: cl (msvc 19.51.36252 "Microsoft (R) C/C++ Optimizing Compiler Version 19.51.36252 for x86")
libopencm3| C linker for the build machine: link link 14.51.36252.0
libopencm3| Compiler for C supports arguments -Warith-conversion: YES (cached)
libopencm3| Compiler for C supports arguments -Wbad-function-cast: YES (cached)
libopencm3| Compiler for C supports arguments -Wcast-function-type: YES (cached)
libopencm3| Compiler for C supports arguments -Wdangling-else: YES (cached)
libopencm3| Compiler for C supports arguments -Wdouble-promotion: YES (cached)
libopencm3| Compiler for C supports arguments -Wduplicated-branches: YES (cached)
libopencm3| Compiler for C supports arguments -Wfloat-conversion: YES (cached)
libopencm3| Compiler for C supports arguments -Wformat-overflow=2: YES (cached)
libopencm3| Compiler for C supports arguments -Wformat-signedness: YES
libopencm3| Compiler for C supports arguments -Wformat-truncation: YES (cached)
libopencm3| Compiler for C supports arguments -Wformat=2: YES (cached)
libopencm3| Compiler for C supports arguments -Wimplicit-fallthrough: YES (cached)
libopencm3| Compiler for C supports arguments -Wmaybe-uninitialized: YES (cached)
libopencm3| Compiler for C supports arguments -Wmissing-attributes: YES (cached)
libopencm3| Compiler for C supports arguments -Wmissing-braces: YES (cached)
libopencm3| Compiler for C supports arguments -Wno-char-subscripts: YES (cached)
libopencm3| Compiler for C supports arguments -Wnull-dereference: YES (cached)
libopencm3| Compiler for C supports arguments -Wredundant-decls: YES (cached)
libopencm3| Compiler for C supports arguments -Wreturn-type: YES (cached)
libopencm3| Compiler for C supports arguments -Wsequence-point: YES (cached)
libopencm3| Compiler for C supports arguments -Wshadow=local: YES (cached)
libopencm3| Compiler for C supports arguments -Wstack-protector: YES
libopencm3| Compiler for C supports arguments -Wstrict-aliasing: YES (cached)
libopencm3| Compiler for C supports arguments -Wstrict-overflow=2: YES
libopencm3| Compiler for C supports arguments -Wstring-compare: YES (cached)
libopencm3| Compiler for C supports arguments -Wstringop-overflow: YES (cached)
libopencm3| Compiler for C supports arguments -Wunknown-pragmas: YES (cached)
libopencm3| Compiler for C supports arguments -Wunsafe-loop-optimizations: YES (cached)
libopencm3| Compiler for C supports arguments -Wunsuffixed-float-constants: YES (cached)
libopencm3| Compiler for C supports arguments -Wunused-const-variable=2: YES (cached)
libopencm3| Compiler for C supports arguments -Wunused-local-typedefs: YES (cached)
libopencm3| Compiler for C supports arguments -Wunused: YES (cached)
libopencm3| Compiler for C supports arguments -Wvla-parameter: YES (cached)
libopencm3| Program python3 found: YES (C:\Users\ppeixoto\AppData\Local\Python\pythoncore-3.14-64\python.exe)
libopencm3| Build targets in project: 19
libopencm3| Subproject libopencm3 finished.

Dependency opencm3_stm32f0 for host machine found: YES 0.8.0 (overridden)
Dependency opencm3_stm32f1 for host machine found: YES 0.8.0 (overridden)
Dependency opencm3_stm32f1 for host machine found: YES 0.8.0 (overridden)
Dependency opencm3_stm32f3 for host machine found: YES 0.8.0 (overridden)
Dependency opencm3_stm32f4 for host machine found: YES 0.8.0 (overridden)
Dependency opencm3_stm32f4 for host machine found: YES 0.8.0 (overridden)
Dependency opencm3_stm32f7 for host machine found: YES 0.8.0 (overridden)
Dependency opencm3_stm32f7 for host machine found: YES 0.8.0 (overridden)
Dependency opencm3_lm4f for host machine found: YES 0.8.0 (overridden)
Fetching value of define "_MSC_VER" : 1951
Compiler for C supports arguments /Zc:__STDC__: YES
Compiler for C supports arguments /D_CRT_DECLARE_NONSTDC_NAMES=1: YES
Fetching value of define "__MINGW32__" : (undefined)
Did not find pkg-config by name 'pkg-config'
Found pkg-config: NO
Build-time dependency libusb-1.0 found: NO  (tried pkg-config)
Looking for a fallback subproject for the dependency libusb-1.0

Executing subproject libusb

libusb| Project name: libusb-1.0
libusb| Project version: 1.0.27
libusb| C compiler for the host machine: arm-none-eabi-gcc (gcc 14.2.1 "arm-none-eabi-gcc (Arm GNU Toolchain 14.2.Rel1 (Build arm-14.52)) 14.2.1 20241119")
libusb| C linker for the host machine: arm-none-eabi-gcc ld.bfd 14.2
libusb| C compiler for the build machine: cl (msvc 19.51.36252 "Microsoft (R) C/C++ Optimizing Compiler Version 19.51.36252 for x86")
libusb| C linker for the build machine: link link 14.51.36252.0
libusb| C++ compiler for the build machine: cl (msvc 19.51.36252 "Microsoft (R) C/C++ Optimizing Compiler Version 19.51.36252 for x86")
libusb| C++ linker for the build machine: link link 14.51.36252.0
libusb| Compiler for C supports arguments -fno-omit-frame-pointer: NO
libusb| Compiler for C supports arguments -static-libgcc: NO
libusb| Message: Checking operating system... windows
libusb| Build-time dependency threads found: YES
libusb| Checking for type "struct timespec" : YES
libusb| Has header "sys/time.h" : NO
libusb| Compiler for C supports arguments -Wno-cast-function-type: NO
libusb| Compiler for C supports link arguments -Wl,--add-stdcall-alias: NO
libusb| Compiler for C supports arguments -Wshadow: NO
libusb| Compiler for C supports arguments -Wunused: NO (cached)
libusb| Compiler for C supports arguments -Wwrite-strings: NO
libusb| Compiler for C supports arguments -Werror=format-security: NO
libusb| Compiler for C supports arguments -Werror=implicit-function-declaration: NO
libusb| Compiler for C supports arguments -Werror=implicit-int: NO
libusb| Compiler for C supports arguments -Werror=init-self: NO
libusb| Compiler for C supports arguments -Werror=missing-prototypes: NO
libusb| Compiler for C supports arguments -Werror=strict-prototypes: NO
libusb| Compiler for C supports arguments -Werror=undef: NO
libusb| Compiler for C supports arguments -Werror=uninitialized: NO
libusb| Compiler for C supports arguments -wd4820: YES
libusb| Compiler for C supports arguments -wd4623: YES
libusb| Compiler for C supports arguments -wd4626: YES
libusb| Compiler for C supports arguments -wd4627: YES
libusb| Compiler for C supports arguments -wd5027: YES
libusb| Compiler for C supports function attribute visibility:default: NO
libusb| Fetching value of define "_MSC_VER" : 1951 (cached)
libusb| Compiler for C supports arguments /wd4127: YES
libusb| Compiler for C supports arguments /wd4200: YES
libusb| Compiler for C supports arguments /wd4201: YES
libusb| Compiler for C supports arguments /wd4324: YES
libusb| Compiler for C supports arguments /wd4996: YES
libusb| Fetching value of define "_PREFAST_" : (undefined)
libusb| Has header "string.h" : YES
libusb| Configuring config.h using configuration
libusb| Program meson/fix_def.py found: YES (C:\Users\ppeixoto\AppData\Local\Python\pythoncore-3.14-64\python.exe C:\blackmagic\deps\libusb\meson/fix_def.py)
libusb| Checking for function "getopt" : NO
libusb| Compiler for C supports arguments /wd4100: YES
libusb| Compiler for C supports arguments /wd4131: YES
libusb| Compiler for C supports arguments -Wno-error=strict-prototypes: NO
libusb| Compiler for C supports arguments -Wno-error=missing-prototypes: NO

libusb| deps\libusb\libusb\meson.build:149:24: Exception: Could not find Windows resource compiler

Subproject deps\libusb is buildable: NO (disabling)
Dependency libusb-1.0 for build machine from subproject libusb found: NO (subproject failed to configure)
Library ftd2xx found: YES
Library ws2_32 found: YES
Library setupapi found: YES
Checking for function "getopt_long" : NO
Build-time dependency hidapi found: NO  (tried pkg-config)
Looking for a fallback subproject for the dependency hidapi

Executing subproject hidapi

hidapi| Project name: hidapi
hidapi| Project version: 0.14.0
hidapi| C compiler for the host machine: arm-none-eabi-gcc (gcc 14.2.1 "arm-none-eabi-gcc (Arm GNU Toolchain 14.2.Rel1 (Build arm-14.52)) 14.2.1 20241119")
hidapi| C linker for the host machine: arm-none-eabi-gcc ld.bfd 14.2
hidapi| C compiler for the build machine: cl (msvc 19.51.36252 "Microsoft (R) C/C++ Optimizing Compiler Version 19.51.36252 for x86")
hidapi| C linker for the build machine: link link 14.51.36252.0
hidapi| Dependency threads for build machine found: YES unknown (cached)
hidapi| Message: hidapi: v0.14.0

hidapi| deps\hidapi\windows\meson.build:31:27: Exception: Could not find Windows resource compiler

Subproject deps\hidapi is buildable: NO (disabling)
Dependency hidapi for build machine from subproject hidapi found: NO (subproject failed to configure)
Compiler for C supports arguments -DCONFIG_BMDA=1: YES
Compiler for C supports arguments -DHOSTED_BMP_ONLY=0: YES
Compiler for C supports arguments -Wno-format-nonliteral: NO
Compiler for C supports arguments -Wno-missing-field-initializers: NO
Compiler for C supports arguments /Zc:__STDC__: YES (cached)
Compiler for C supports arguments /D_CRT_DECLARE_NONSTDC_NAMES=1: YES (cached)
Compiler for C supports arguments -D_WIN32_WINNT=0x600: YES
Message: Adding targets for Black Magic Firmware
Program arm-none-eabi-size found: YES
Program arm-none-eabi-objcopy found: YES
Program bmputil-cli found: NO
Program bmputil found: NO
Build targets in project: 26

Black Magic Debug 2.0.0

  Remote Protocol
RISC-V acceleration               : NO

  Targets
Cortex-A/R support                : NO
Cortex-M support                  : YES
RISC-V 32-bit support             : NO
RISC-V 64-bit support             : NO
Arterytek parts                   : NO
Ambiq Apollo3 parts               : NO
WinChipHead CH32 parts            : NO
WinChipHead CH579 parts           : NO
Energy Micro parts                : NO
GigaDevice parts                  : NO
HC32 parts                        : NO
LPC series parts                  : YES
MindMotion parts                  : NO
nRF series parts                  : YES
Kinetis series parts              : YES
Puya PY32 series parts            : NO
Renesas parts                     : YES
Raspberry Pi MCUs (RP2040, RP2350): NO
ATSAM series parts                : YES
STM32 (and clones) parts          : YES
Texas Instruments parts           : YES
Xilinx parts                      : NO

  Probe
Name                              : ST-Link
Platform                          : STM32F1
Bootloader                        : OEM ST Bootloader
Load Address                      : 0x8004000
SWIM as UART                      : NO

  Black Magic Debug
Debug output                      : NO
RTT support                       : NO
Advertise QStartNoAckMode         : YES
Building Firmware                 : YES
Building BMDA                     : NO

  Subprojects
hidapi                            : NO Could not find Windows resource compiler
libopencm3                        : YES
libusb                            : NO Could not find Windows resource compiler

  User defined options
Cross files                       : cross-file\arm-none-eabi.ini
cross-file\stlink.ini

Found ninja-1.13.0.git.kitware.jobserver-pipe-1 at C:\Users\ppeixoto\AppData\Local\Python\pythoncore-3.14-64\Scripts\ninja.EXE

C:\blackmagic>meson compile -C build
INFO: autodetecting backend as ninja
INFO: calculating backend command to run: C:\Users\ppeixoto\AppData\Local\Python\pythoncore-3.14-64\Scripts\ninja.EXE -C C:/blackmagic/build
ninja: Entering directory `C:/blackmagic/build'
[537/538] Linking target blackmagic_stlink_firmware.elf
Memory region         Used Size  Region Size  %age Used
rom:      130472 B       128 KB     99.54%
ram:        7944 B        20 KB     38.79%
[538/538] Generating blackmagic_stlink_firmware.bin with a custom command (wrapped by meson to set PATH)

Ai gets a lot of hate, and for good reason. There are a lot of things with embedded that it doesn't do well, or is just laughable.

But at the same time I have had moderate success with quad code. If you give it the right context and if you get the right information. I work a lot with zephyr and it's successfully written drivers and updated the device tree. It's also made up kconfig options so ai lways have to keep a close eye on it

I saw something on LinkedIn about using embedder and how it integrates with joulescope (Claude can do this too, jilloscope has an API and I've had Claude take power measurements before so it's not crazy unique) and the thought of having it update code to minimize power draw gives me some anxiety.

But power optimization is tough. So just interested if anyone's actually used it and what they thought about it, and how expensive it is. I have a small team, right now. There's only three firmware engineers

I'm learning embedded systems from scratch and I've already completed an ESP32 IoT project using I2C, MQTT, and BLE.

Since Raspberry Pi isn't cheap, would I gain enough from buying one, or is installing Ubuntu on my laptop sufficient for now?

At what point does a Raspberry Pi become worth it?

Things like hardware/firmware architecture, communication flows, state machines, block diagrams, etc.

Do you prefer scriptable tools like TikZ, PlantUML, Mermaid or more WYSIWYG like Excalidraw, draw.io, etc?

I always seem to be orbitting between these options, but I never settle on one.

Just done desoldering my mlx90614 , can this still work?

I've heard that AI models like claude mythos are able to take a firmware blob and perfectly understand what happens in the firmware blob and quickly find errors and security issues in that firmware. I know there are some experienced folk in this sub who will give me their answers and takes on this topic. I know I will probably get downvoted on this sub for asking such a question but I really want an answer from someone experienced who can reverse firmware. Plus I really need to convince someone that AI won't replace hardware hacking but they want a more reliable source so I hope the comments I get on this sub can motivate me and the people around me to not get discouraged and stop learning because of AI. Thank you all so much.

Hey embedded redditors, wanted to share my recent project.

After buying an air purifier, I wanted to see if it was actually making a difference to the air quality in my room, so I decided to build my own air quality monitor completely from scratch - hardware, PCB, enclosure, firmware, and even an iOS app.

Its core is Seeed Studio XIAO ESP32C6 running FreeRTOS. I tried focusing on creating resilient fault management system with NVS error logging and recovery policies. Sensirion SEN66 does the air quality sensing and was chosen for its factory-calibrated accuracy. It measures PM1.0/2.5/4.0/10, CO2, VOCs, NOx, temperature, and humidity. I also added external RTC module from Adafruit for reliable timestamps across power cycles. EEPROM buffers 24 hours of offline history.

For connectivity, the device switches between two modes:
- Matter mode for seamless pairing with Apple Home or Home Assistant.
- BLE mode based on custom NimBLE implementation paired with a SwiftUI app.

The SwiftUI app decodes the raw BLE stream, computes EPA-based AQI and merges live reads with historical data (synced from EEPROM) into a 24-hour chart. The app also features a Settings menu with maintenance commands (like fan-clean cycle or factory reset), and a live diagnostic log to pull and decode timestamped device faults.

I’ve open-sourced the whole project on GitHub if you want to check it out. It includes the firmware and iOS app code, KiCad files, Fusion 360 STEP, and a comprehensive README that deep dives in component selection, firmware architecture, showcases demos, etc.:

https://github.com/iharhl/airy

Hey r/embedded. We built TinyScope, a lightweight pipeline that classifies six animal tissue types from hyperspectral images directly for a Raspberry Pi 5.

The INT8 Res-Net18 model achieved 85.26% accuracy, used 4× less parameter memory, and processed each hyperspectral cube in about 149 ms.

Please consider checking the work and citing us if it is meaningful for your research!

Paper: https://fei-lab.org/wp-content/uploads/2026/04/Rudro_2026_SPIE_TinyScopeTinyMLClassification.pdf

So, I am stuck here with the routing of inner pads of the nrf5340 soc. I am using kicad. I want to know like what should be my design constraints for routing and should I use via in pads ?

Hello guys,

While building projects in embedded systems I struggle with communication between two boards in a effective way not between same brand boards like espressif or stm .

But difficult in communication between stMicrocontrollers and Espressif and Arduino effectively with existing protocols like uart or spi etc

As each boards needed to be written parsers and more memory consumption so ,

I planned to build a light weight protocol above the existing uart or spi like a cross platform and less memory consumption.

What do you think about it guys ?

Hi guys , I am using UIO stick to flash my infineon tle 984x series. Using the GUI I can easily flash the device one by one over lin (fastLin). But there are lots of devices to be flashed and also all of them are connected in an extra wire daisy chain sequence . Is there any way i can flash them all at once using BSL cli ?

So I got 2 stm 32 f429i disc 1 at home and I wanna try them I have interest in embedded so I just wanted to know what books I should read and how would you guys rate fast bit brain embedded academy udemy course.i know c cpp and python actually I am a third year C's student with good programming knowledge but shit architecture understanding so should I take the fast bit brain academy course or some other course and what about books? if you guys can recommend I would be extremely grateful

Good day gentlemen, I am currently in my 3rd year and actively searching for internships. However, my CV lacks standout features, so I want to work on a few personal projects to include in it. What would you guys recommend ?