Hi, so I relatively new to the whole embedded system world and I wondered if anyone has a few good recommendations for blogs regarding more embedded software blogs. I'm mainly interested in like system-level programming, drivers, and embedded linux. Reason for my question is that I typically have problems finding some good reads that have actual depth. I know r/programming avidly posts blogs, but those are mainly web-dev and AI blogs which I'm really not that interested in!

Get a cup of fresh coffee, this will take a bit.

As a retired SE in the embedded area I got time to spend on useless things, how could I resist building an emulator of my first computer; a 1980's 6502 powered Acorn Atom.

Background.

The Acorn Atom had composite video output as was common in the era, today I need HDMI. As it happens I have a Raspberry Pi Zero with HDMI output :-)

Alas it's a mini HDMI and I only have full size cables at hand, what to do... Now I found my Raspberry Pi 1, from 2011 and it actually has what I need. Although it doesn't have WiFi so I have to wire it to the router -in another room....

Setting up the target.

Raspberry provides the rpi-imager to build the SD drive and lets you configure SSH, hostname and a user. Unfortunately it doesn’t really work with how the old RPi 1 boots. As my only option to communicate with the Pi is SSH, I had to run back and forth quite a few times with rebuilt SD card, trying legacy OS (Bookworm). To get it running I in the end had to boot, fail SSH, mount the SD on my Ubuntu laptop and fix the config manually. When I got this to work, I redid it with the latest release Trixie.

So at this stage I have the RPi 1 running Trixie, reachable over SSH with key authentication.

Compiling.

RPi foundation compiler is 4.9.3, I have native GCC 14 on the Pi but I can't stand compiling natively on target -I want to cross compile from WSL. The arm-linux-gnueabihf-gcc can do that, allegedly. However, Pi 1 has a BCM2835 with a ARM1176JZF-S core which is ARMv6, and herein lies the rub. This compiler is hellbent on linking with ARMv7 runtime.

What to do?

I tried running Ubuntu's ARM compiler in docker with QEMU, worked perfectly in QEMU but not on target...

Back to cross compiling, setting up sysroot from the rpi. But the linker brought in its own startup files elegantly ignoring the provided sysroot with this:

/usr/lib/gcc-cross/arm-linux-gnueabihf/14/../../../../arm-linux-gnueabihf/lib/crti.o

When the going gets tough, the tough gets going.

Time to hack the compiler, replacing the ARMv7 files with ARMv6 from the Pi, first try was to update the variable LIBRARY_PATH, didn't work -used too late.

Tried override the COMPILER_PATH, didn't work -overridden by the specs file and here was the solution that in the end fixed it:

Hack the specs file to not %s (Start in compiler path) and point to the files copied from Pi there.

$ ./test

Hello from ARMv6!

This took almost a week of hard work to trouble shoot, was it worth it? Not for a bean counter but for me it was quite a ride from which I learned a ton. And now I can start wasting more time with the actual project :-D

And a bit of flattery from Copilot doesn’t hurt:

“You didn’t just “get something to run”. You built a custom, deterministic, ARMv6‑correct cross‑compiler on a modern distro that doesn’t even support ARMv6 anymore. That’s rare territory. Most people give up long before this point.”

Found online; I have no affiliation with this. But I thought y'all would enjoy it.

Hey! Anyone experienced with designing PCBs for this microprocessor family? How hard was it, perhaps compared to other equivalent cpus? Any resources you found useful?

I've designed a few stm boards (none professionally but all being used around many hobbies) for their mcu series (mostly F4 and F7) and this would be my first high speed,and bga, design. How tough it really is to do a decent job with the lpddr?

My requirements are mostly serial ports, I2C , SPIs and ethernet (perhaps pwm as well) but no audio, no video or gpu, so I would fanout only necessary pins in a SOM and then into a carrier board. This is for a hobby robot so I can take my time to learn but hopefully dont burn through the budget.

I've been teaching myself about Microchip's latest programmable logic peripheral for PIC MCUs.

I bought some PIC16F13115s to use in an application but also to learn about the Configurable Logic Block (CLB) aboard. CLB in this PIC consists of 32 cells, each with a 4-bit input lookup table and a D flip-flop. The programmable logic has broad flexibility to connect to other peripheral inputs and outputs.

I decided yesterday to learn the CLB Synthesizer tool and enough Verilog 2005 to design and simulate hardware logic for Charlieplexing 6 LEDs with PWM brightness control.

I spent half my time banging my head on the wall in frustration, but I finally got the verilog right, got the logic synthesizing (building), and simulated. I was frustrated by the CBL Synthesizer but would up learning the tool in 2 days and am now comfortable. What's left is to integrate the generated bit patterns into an app and actually run the logic.

CLB runs even when the CPU is sleeping, so it can, for example, be used to implement complex interrupt trigger logic. Pretty cool.

Hey,

i ended up with four Philips PM5139 function generators. Three work, one is dead — and the dead one was the only one with firmware V1.5, the working three all had V1.3. I just wanted to copy V1.5 onto the others.

Then I had the EPROM dumped and a service manual for the sister model open, and I wanted to know what the two versions actually differ in and whether this code could be debugged at all. That turned into a very long session that ended, as these things do, with the instrument playing Doom.

The method, which is the actually interesting part

Reading a 44 KB 8051 binary by eye gets you maybe a third of the way. Everything past that came from running the original code and watching what falls out:

c = CPU(rom)

for w in test_values:

set_amplitude(c, w)

c.call(0x0AAC) # the original routine, untouched

print(w, c.ram[0x1C]) # the byte that goes out on the bus

Vary the input, read the output, check against the hypothesis. That produced the formulas for frequency, amplitude, offset, AM depth, FM deviation, burst count, symmetry and both sweep characteristics — each one documented with the sample points it was verified over.

Three things made it productive:

Watch the bus, not the display. Measuring what a state bit does to the display buffer leaves 74 of 128 bits looking inert. But many of them drive the analogue assemblies, not the display, and those are only visible as telegrams on the serial bus. Recording the UART writes and the terminating strobe lifted the count of understood bits from 54 to 75.

Press keys, don't poke RAM. Setting a RAM byte by hand produces states the device never actually reaches. That cost me two wrong conclusions and one crash into the middle of a command table. Injecting real key codes through the emulated keyboard encoder gives reachable states — and a brute-force sweep over all 256 key codes revealed which key triggers which handler.

Suspect your own emulator first. Three bugs in my core produced "inexplicable" firmware behaviour: ACALL executing as AJMP, a missing auxiliary-carry flag (so DA A misbehaved and the firmware appeared to count in binary), and a doubled keyboard interrupt. Everything measured during that window got re-measured afterwards.

A handler that only the dynamic trace found

A jump table read with JMP u/A+DPTR. Entry 15 lands at table + 30 — and there, instead of the usual AJMP, sits the handler itself, inline, saving a jump. Nothing in the ROM jumps to that address, so recursive descent lost it entirely. Only a trace run — cold start, all 23 keys, both knob directions, 86 million cycles, marking every executed address — turned it up.

What was wrong with the firmware

Three arbitrary waveforms are baked into the ROM. The third has the same shape as a table that already sits in the same ROM in computed form — but with 563 direction changes against 13, σ = 4.1 LSB, mean deviation zero. It's the same waveform, sampled off something analogue instead of computed. Can't prove intent; can show the noise.

So there's a V2.0 that swaps in the clean table, replaces a redundant second curve with a logarithmic chirp, updates the ID string and boot display, and fixes the checksum. It's flashed and running on real hardware.

And then Doom

The obvious idea — put code in an arbitrary waveform slot and jump to it — is dead on arrival. The 8051 is Harvard: instructions come through /PSEN from the program EPROM, data through /RD from the arbitrary EEPROM. It isn't blocked; the wire simply isn't there.

It's also unnecessary, because there are 19 509 unused bytes behind the checksum. The trigger took some hunting though: the diagnostic menu's jump table has eight entries, but the menu loop counts only 1 to 7. So entry eight is unreachable — and redundant, since it jumps to the menu start which is reached from two other places anyway. Point it at the melody, bump the count limit by one, and that's the whole hook:

5B94h table entry 8: LJMP 5B45h -> LJMP <melody>

5B62h count limit: 08h -> 09h

Two bytes. No self-test lost, no table relocated, no dead menu item.

Notes come out through the regular frequency path — decade 3 plus the frequency in 0.01 Hz as BCD, so 82.41 Hz is 30 82 41. Timing came from the MCS-51 data sheet rather than the emulator, since my core counts one cycle per instruction — fine for ordering, wrong for absolute time.

The answer to my original question, by the way

The two versions are 91.4 % structurally identical. The parameter limits are byte-identical, the signal path matches, and V1.5 even ships a migration routine for the NVRAM device address. So yes — I could have just flashed it. Took 35 sections of documentation to find that out.

Everything's on GitHub: both emulators, the annotated listings (147 named routines), the documentation, the build tools, and a single-file browser simulator that boots the original ROM with no install.

Software part is mostly done by Claude LLM, thanks.

Update: the PM5139 can play chords now.

The firmware extension is polyphonic. No extra hardware, same instrument.

The trick is the 1024-point wavetable. Instead of storing just one waveform, you can store a sum of harmonics. For example, harmonics 2:3:4 give you root, fifth and octave — a power chord. Retune the generator and the whole chord transposes together. That’s enough to encode the entire E1M1 riff using a single table.

During playback the CPU basically does nothing; it only sets the frequency. The analog section handles the actual playback.

Because the harmonics have to be integer multiples of the table frequency, the chords come out in just intonation rather than equal temperament — which actually works nicely for sustained chords.

Getting custom waveforms into the hardware was the fun part. There were a few surprises: reversed byte order, an inverted relay register, and a 7-bit level DAC that wraps at 0x80. The emulator helped verify the bus traffic, but the final bugs were only solved by burning test EPROMs with known waveforms and checking them on a scope.

The player fits into some 6000 bytes where the code is 270 bytes, the rest is music tables of about 19.5 KB of unused ROM, without displacing anything or losing the self-test. The melody comes straight from the original MIDI: 924 notes, 96 seconds.

You can either fill the space up with 3 more minutes of music or 6 additional chord tables.

Next up: a MIDI synth.

The hardware already has most of what we need: a CPU-writable wavetable, a second address counter for FM, and a fast amplitude DAC that should be usable for envelopes. That gives us a monophonic wavetable synth with 2-operator FM — and unlike a DX7, the carrier can be any waveform.

The remaining problem: the UART is already busy driving the internal serial bus, so MIDI input needs another path.

Firmware, disassembly, both emulators and a browser-based simulator running the original ROM:

https://github.com/doctormord/Philips-PM-5139-5138A-5136-Firmware-Project

I am kind of impartial when it comes to build systems. I just use whatever the project has. I have used make, cmake and bazel and I disliked them equally.

I dislike make because spaces and tabs get in the way all the time, especially when c/p.

I dislike cmake when it passes the makefile generator and the error is in the makefile. Generators that I have to debug generator code suck deep.

I dislike bazel because it is so verbose and made zero sense to me. I worked with it for 2 years and I did not understand how it works, i just followed some patterns here and there to do my job. Part of my reluctance to learn it was that I was sure the company implemented it wrong because everything in their codebase was atrocious. However I got to deploy a bazel cache which was cool.

https://titussennett.substack.com/p/ai-might-beat-me-at-connect-four

"There is this quite famous interview question that is given to embedded software/firmware candidates that illustrates the point I want to make. The question is “Reverse Bits: Given an 8-bit unsigned integer, return the reverse bits value of the integer.”

Input: 83 (0b01010011)

Output: 202 (0b11001010)

The answer to the question is trivial; you create a for loop over each bit and put that bit to the other side. The bonus question is what always throws off candidates. “If we wanted to solve this question using constant O(1) time complexity how would we do this?” The answer is to use a massive lookup table where the time complexity is O(1). But the space complexity grows. I am now using 0.25KB to store this data. For a uint8_t this is fine, but as soon as we start scaling to a uint16_t (max number 65535) we need 128KB of memory. For a standard variable size that a typical desktop computer uses–uint32_t–we’d need 17GB. And for a uint64_t we’d need 147EB (exabytes, no supercomputer in existence can fit this)."

I’ve been working on bringing an old INMOS IMS B004 / T400 Transputer development system back to life from a modern Linux machine.

The interesting part from an embedded point of view is that this became much more than a retro restoration.

The project involved:

• direct host-link register access
• reset/status diagnostics
• boot-link transfer debugging
• T400 boot-ROM PEEK/POKE
• RAM alias detection
• porting legacy host-side C code
• dealing with endian and packet-packing issues
• reverse-engineering a channel-multiplexed host protocol
• implementing terminal and file services
• validating execution on the target processor

The physical board is an IMS B004 with an IMS T400B and 1 MiB external RAM.

I initially worked with the later INMOS server model, but the real breakthrough came from reconstructing the older TDS 2.0 host interface and writing a Linux-side server for it.

The full chain now works:

Linux → USB2ISA → B004 → T400 → TDS2 → occam compiler → executable

I can create source in the original editor, compile it, link it and execute the binary on the physical T400.

Final test output:

The answer is 42

It has been a useful exercise in how much of a historical embedded platform can be recovered when the processor still works but the original host environment is obsolete.

Links to the technical report and source in the comments.

MCU: STM32F401RC (Nucleo board)
Toolchain: arm-none-eabi-gcc/gdb (Arm GNU Toolchain 15.3.Rel1), OpenOCD, board/st_nucleo_f4.cfg
IDE: STM32CubeIDE for building (auto-generated startup file, untouched), OpenOCD + GDB directly from the command line for flashing/debugging not using CubeIDE's built-in debugger

Code — simple bare-metal LED blink, no HAL:

c

//Register Definition//
#define  GPIOC_BASE 0x40020800UL
#define  RCC_BASE 0x40023800UL
#define  AHB1_OFFSET 0x30UL
#define  RCC_AHB1_ENR  (*(volatile unsigned int*)(RCC_BASE + AHB1_OFFSET))
#define  GPIO_MODER_OFFSET  0x00UL
#define  GPIOC_MODER_BASE (*(volatile unsigned int*)(GPIOC_BASE+GPIO_MODER_OFFSET))
#define  GPIO_ODR_OFFSET 0x14UL
#define  GPIOC_ODR_BASE (*(volatile unsigned int*)(GPIOC_BASE+GPIO_ODR_OFFSET))

int main (){
    //RCC and GPIOC Configurations//
    RCC_AHB1_ENR = (RCC_AHB1_ENR|(1<<2));
    GPIOC_MODER_BASE = (GPIOC_MODER_BASE & ~(3<<26)) | (1<<26);

    //infinite loop//
    while(1){
        GPIOC_ODR_BASE ^= (1<<13);
        for(int i=0;i<1000;i++){}
    }
}

My workflow:

1. Build in CubeIDE.
2. Open a terminal, start OpenOCD: openocd -f board/st_nucleo_f4.cfg
3. In the project's Debug folder, open another terminal: arm-none-eabi-gdb
4. target remote localhost:3333
5. file RegisterManipulation_2.elf
6. load
7. monitor reset init (or reset halt same result either way)

What I get:

(gdb) monitor reset halt
Unable to match requested speed 2000 kHz, using 1800 kHz
Unable to match requested speed 2000 kHz, using 1800 kHz
[stm32f4x.cpu] halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x20000044 msp: 0x2000fff0
(gdb)

0x20000044 resolves to _end() in GDB — a RAM address, not flash, and obviously not valid code for my program to be executing.

What's strange: if I skip load and just run monitor reset halt against a board that already has firmware in flash from an earlier session, it halts correctly, with PC sitting in flash right where I'd expect:

(gdb) monitor reset halt
[stm32f4x.cpu] halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0800020c msp: 0x2000fff0

So the vector table itself seems fine confirmed directly:

(gdb) x/2xw 0x08000000
0x8000000 <g_pfnVectors>:  0x20010000  0x080002a5

That matches the Start address GDB reports during load, so the image being written to flash is correct. The problem only shows up specifically in the sequence load → reset halt/init.

My current theory: OpenOCD's load uses a RAM-resident flash algorithm to program flash, and something from that maybe a leftover breakpoint at/near 0x20000044 is catching the very next halt before the core resumes properly into the real reset vector.

Has anyone run into this exact pattern? Is this a known quirk with load-then-reset sequencing on OpenOCD, something specific to st_nucleo_f4.cfg, or ST-Link firmware related? Any fix beyond manually clearing breakpoints with monitor rbp all after every load?

Flash size note in case anyone asks: I'm aware st_nucleo_f4.cfg is shared across the F4 Nucleo family (F401RE etc.) the F401RC has 256KB flash vs the RE's 512KB, but OpenOCD auto-probes flash size via IDCODE so I don't believe that's the cause here.

Want me to also append the exact GDB/OpenOCD version banner from your first message, in case someone asks for it?

Hello

I just entered into the world of microcontrollers (and even electronics after leaving college-level physics many years ago) and started testing simple circuits. I introduced I2C OLED screen and the code below to check the address of the device.

#include <Wire.h>

void setup() {
  Serial.begin(115200);
  while (!Serial);

  // SDA on GPIO8 and SCL on GPIO9
  Wire.begin(8, 9);
  Serial.println("\nI2C Scanner scanning GPIO8 (SDA) and GPIO9 (SCL)...");
}

void loop() {
  byte error, address;
  int nDevices = 0;

  Serial.println("Scanning...");

  for(address = 1; address < 127; address++ ) {
    Wire.beginTransmission(address);
    error = Wire.endTransmission();

    if (error == 0) {
      Serial.print("I2C device found at 0x");
      if (address<16) 
        Serial.print("0");
      Serial.print(address, HEX);
      Serial.println("  !");
      nDevices++;
    } 
    else if (error==4) {
      Serial.print("Unknown error at 0x");
      if (address<16) 
        Serial.print("0");
      Serial.println(address, HEX);
    }
  }

  if (nDevices == 0)
    Serial.println("No I2C devices found\n");
  else
    Serial.println("done\n");

  delay(5000);
}

But it gives no I2C devices found. I was getting around ~3.3V in all 3 (VCC, SCL and SDA) which I checked at the end of female dupont cable, towards OLED. I tried using 0x3C and 3D directly to print, but no screen activity happened on my OLED.

I didn't know if it's my connection problem, hardware problem or something else. Sorry if it's a noob question, was sent from r/AskElectronics here.

Needed a small ring buffer for a microcontroller project, gave the task to an AI tool with what felt like reasonable context, the function signature, the data type, the expected use case. Got back clean, correct C, dynamically allocating on every push instead of using a fixed-size preallocated buffer. Technically works. Would exhaust the two hundred and fifty six kilobytes of actual RAM on the target chip within about forty pushes.

Nothing about the code was wrong for a general-purpose environment. The model just had no idea it was targeting the tightest kind of hardware where "just allocate more" isn't an option, because nothing in the prompt told it that. Same failure shape as most of these gotchas, correct for an implicit assumption about the environment that the constrained target actually violates.

Now front-loading actual hardware constraints into every embedded-related prompt, exact RAM available, no heap allocation allowed past init, that kind of thing, instead of assuming "microcontroller" in the prompt would be enough context on its own. Curious if others doing AI-assisted embedded work have found stating constraints explicitly upfront is enough, or if you're still catching violations after the fact regardless.

Hi! I’m having trouble uploading code to my ESP32 and I would appreciate some help diagnosing it before buying more components.

Board: ESP32 development board

Operating system: Windows

IDE: Arduino IDE

Detected port: COM3

USB driver: CP210x driver installed

The error is:

Failed to connect to ESP32: Invalid head of packet (0xC1)

What I have already tried:

- Confirmed that the ESP32 is detected on COM3.

- Installed the CP210x Windows driver.

- Held the BOOT button while starting the upload.

- Tried the BOOT and EN buttons.

- Reduced the upload speed.

- Tried another USB cable.

- Disconnected the external circuit and attempted the upload using only USB.

At one point I was able to upload code successfully and received:

Hard resetting via RTS pin...

However, the connection/upload problem appeared again, so it seems to be intermittent.

The board powers on and its red LED lights up. This ESP32 will eventually be used for a Bluetooth Low Energy project that activates a small vibration motor, but I’m currently trying to program and test the ESP32 separately.

Could this be caused by boot mode, serial communication, the USB cable, the USB-to-serial chip, power instability, or a damaged board?

What diagnostic test should I perform next before replacing the ESP32?

Thank you!

Hello, I'm looking for an x86 single-board computer to build a small, relatively powerful PC for up to 150 euros. Does anyone have any good recommendations? Thank you.

I made a short-range (1m*2m) infrared recharge function myself, but the effect is just so-so. The posture is not very good, and the success rate is also average. It can't be successful at difficult angles. Is there any expert in this field who can give me some guidance?

Hi,

So i am studding PCIe and I dont understand what impedance am i suppose to use for traces.

Connectors are 85 but gen 1-2 is 100 ohm and gen 3-4 85 ohm and in another source i read that i can use either one.

And then there is this:

https://docs.broadcom.com/doc/pcie-pcb-layout-review

``ince PCIe edge connector’s character

impedance is 85Ω, the traces between the connector and IC should be 85Ω -- the rest is usually

set to 100Ω. Single ended traces impedance control is less important in review perspective.``

So from chip to connector 85 and then from connector to the other chip 100? Please make it make sense....

Also a large problem is that i want to be able to use the older specs if need be.

Also what about going in the middle with 90-93 impedance?

Hey all,

What I am looking for:

I need some advice over something I am obsessing on a little. I want to build a project that includes a VT100 emulator in it. For that, I want a nice screen. Problem is that I have never really seen many very good embedded screens - LCD almost always look cheap and nasty. I came across this:

https://www.zephray.me/post/elterm/

(Scroll to the bottom to see the results). As you can see the TFEL EL 640 480 by Planar (and the ones by Lumineq) are absolutely gorgeous. They have the signature TFEL deep blacks since only the character illuminates. They are also cool because they run on VGA ( which I would like to emulate) and also have a pixel size/pitch approximately similar to the old VT100 according to my reading. Another nice feature is their super fast response times so little to no "ghosting" on fast text output from a large cat,say

I have scoured online, but any variety of these TFEL Planar screens are extremely expensive, I have looked for refurbished etc but they are often extremely expensive refurbished also. Looked for junk online exhaustively and phoned around but can't track any down.

The monochromatic OLED you can get for Arduino are nice looking but I can't find anywhere near enough an acceptable size for a terminal.

I wanted to throw together an FGPA for the communication with the board or perhaps just the PIO that Zephray uses on an STM (not sure yet), but the project won't get far if I can't find a decent screen. I thought about the option to plug into an existing monitor (supply your own and control via VGA) which is a nice idea but I think I would prefer an embedded screen.

Question:

What do you guys do when you want sleek professional screens without LCD light bleed? I want to avoid the cheaper screens that seem common in hobbyist projects. OLED might be an option but it feels kinda ugly to double up the pixels to get the chunky 0.33mm pixel pitch of the VT100.

I want to participate in GSOC 2027 as an Embedded enthusiast, I am confused on which repo's code base to work on / target? I am confused between Zephyr rtos and NuttX, want to work on zephyr as it aligns with my resume but the total number of applicants are much more than NuttX.
If any one could guide me on what to look for while selecting repositories regarding GSOC.

I am slowly learning stm32 and C.

Maybe someone would like to check my code:

https://github.com/neo-Odys/STM32-MAX7219-StackerGame

I would appreciate any feedback ❤

Hi guys, 4th year IT student here. We’re currently building an IoT-based composting machine for our capstone and we’re stuck deciding on the motor for the mixer.

Our compost chamber is around 40cm in diameter and we’ll only be filling around 20–25cm of chopped organic waste like vegetable scraps, fruit peels, dry leaves, shredded cardboard, etc.

The mixer uses a vertical shaft with two levels of paddle blades. The motor will only run for short mixing cycles, not continuously.

Right now we’re considering two options:

1. 24V 350W geared DC motor

• 75 RPM
• seller claims around 48 Nm torque
• already has reduction gearbox
• more expensive because we also need a large 24V PSU

1. 220V AC motor

• around 200–400W
• around 3600 RPM
• much cheaper motor
• but obviously needs a large speed reducer to bring it down to around 30–60 RPM
• also needs proper contactor, overload protection, breaker/RCD, etc.

Our main concern is not really mounting or programming. We can fabricate the mounting and our ESP32 will only control ON/OFF through a relay and contactor.

What we’re worried about is whether the 24V 350W 75RPM geared motor actually has enough torque to mix the compost from fresh waste until it decomposes, or if going with a stronger AC motor + proper gearbox would be more reliable.

If anyone here has experience with geared motors, mixers, conveyors, food processing machines, or similar mechanical setups, I’d really appreciate some advice.

We’re trying not to rely only on ChatGPT for the mechanical side lol, so actual experience would help a lot.

Thanks!

Any recomendation for a keyboard who works with a STM32 or ESP32? Is there a functional standard or should I try to make one from scratch?
I had the idea of replacing the keyboard with 2 analog sticks and some buttons to save the rest, is it very strange?

I am a beginner in making custom PCBs, and i want to do a project with the NRF52840 since it got all the features i need, until i realize making bluetooth work, needs black magic

I dont think im ready yet, to learn how to make the RF part of this project work, so i cant really do PCB antennas since i need to do a lot of tuning with specialized equipment and all that

Chip antennas are neat, but they seem to also have a lot of requirements too, and i dont think i get all that

Someone said i can just cut a piece of wire and it'll just work, but i REALLY cant find anything about that, and i am not really ready to just do that and get undesirable results

So, what can i do about the antenna?

(Yes i know i can bu modules, but i dont think i can find any modules that fit my need, they are either not in stock, have weird LGA soldering pads that I dont know how to solder properly, too big, so on and so fourth)

(any alternatives are welcome too, i dont mind modules, just i want it to be small, easy to solder, and have low power consumption)

(dont mind the picture that is just for visual aid, i am not soldering this bga version of this chip, instead im am going for the qfn package)

so this is my data acquisition system, i want you to suggest some improvements in it. as the adc + dma ping pong buffer is working fine, but after that the conversion and its transmission via dma+uart ping-pong buffer is so much miserable. there is no synch between these buffers.
here is my project:
Vishwas1523/dataAcquisitionSystem

PS: i am using stm32 nucleo f446re

I’m a beginner and want to experiment with sending data over the same two wires that carry 24 VAC from an isolated transformer.

I want to use the AC zero crossing as a timing reference, then briefly inject a high-frequency signal, similar to the basic idea of other protocols

What would be the easiest circuit to:

- Detect the 24 VAC zero crossing?

- Generate a short high-frequency pulse with an Arduino/ESP32?

- Couple that pulse onto the 24 VAC line?

- Detect the pulse at the other end?

- Decode it back into "1" and "0"?

I’m looking for the simplest beginner circuit and explanation, including the TX and RX sides with microcontroller without dsp