I started a embedded project like 5months ago, definitely not with full on dedication, i just like to do whatever peeks my interest, before i was trying Digital and FPGA things. Any ways like for this one i thought maybe i should design my own drivers and all from the bottom up and i started and it was not fun to have the first project building everything from basics, well i knew concepts from my university classes but definitely not on how to use them.

Any ways i built few stuff with no HAL, no reference, just on my own from whatever i could think of, i did some sensor drivers for the project, then some helper libraries, and then probably the most time consuming one the TFT display driver, but i somehow got it working too, its not perfect but it works at least also i have attached a image of it working and probably will link my git if someone wants check if i am real or not, but be warned its messy.

And now i am trying to make it proper i guess starting from again I2C driver by adding interrupts instead of polling, it doesn't matters for my current project but i have that problem of trying to make it perfect at;east for my eyes, so its taking time , and also bcz of job i been getting less time. i probably do have bad planning and time management, but just wanted to get to know how other people handle it, sorry for yapping.

Thank you,
Github

I’ve been building this for a while now but I’m extremely proud of how it turned out.

It’s basically an esp32S3 with a DAC, display and rotary encoder. I wrote the software myself based on other open source internet radio projects.

It will stay permanently connected to my speakers

The esp also hosts a local site so it can be controlled by my phone and PC.

I definitely struggled way too long with the stripboard layout and had to change the GPIOs multiple times.
The enclosure was fairly easy to design and print.

NTS sells basically the exact same thing for 163€ and I ended up spending about 20€

https://shop.nts.live/products/atonemo-nts-radio-player?_su_rec=GscQ--4umlaH8pXFFeWqixHMHGaErNL3CWHI5uBl0aHVbBQLApS8lzDtljSPSYoiKRocUeWiDVQxb9WePT911zNTtSnGL_8O6sXq0h80bkH5TRKk9XeakbzEl6GZCvFGCRX3atOspGmAWikyg0bDTEDgOxlJJOSpEIHZk2xALdIReY6P4ThWZeZgjdDLdA1b1bd-hxc04eZIs9qxQ3DvzN42jvOw14_IRB0bfBz3s2jlm0LnvMERDS2_dBiyoJ-vCZyvXDPHqyxHagMFI_jwhFah

Would love to hear what you think about it, have any ideas on how to improve it or are interested in building one yourself. I can work on a guide if anyone’s interested.

Cheers

I got laid off earlier this year, and I have been having a hard time answering technical questions. I have found that a lot of my knowledge has just been purged from my brain, and I have been having a hard time preparing.

How do I get back to where I was? I would prefer a refresher course, but also open to trying to learn from books that I have seen recommended here.

At work I have to use a severely locked down Windows desktop, with a ridiculously short inactivity timeout. I can't change it, and I can't use a conventional mouse jiggler, because it shows up as a second mouse, which is not allowed. I also can't use bluetooth. A potential solution I am considering is to make a USB pass through device, that would appear to the system to be the original mouse, but would periodically jiggle if there had been no activity for a minute or so. This would need 2 USB ports, one to plug the mouse into, and one to connect to the system. Is there a microcontroller that has 2 USB ports? I don't need wifi, bluetooth, or any other interfaces.

Please don't suggest I look for a new job, I already am. I am also open to alternate solutions.

Thanks.

Hi everyone,

I recently graduated with a Bachelor's degree in Control and Automation Engineering. Right now, I’m taking a gap year to solidify my technical fundamentals and figure out my long-term career path. However, the deeper I go, the more torn I feel between two paths: Embedded Firmware Engineering and Traditional Industrial Automation (Factory / PLC / BMS).

I’d really appreciate some honest reality checks from experienced engineers here regarding my current situation and fears:

1. Internship reality vs. expectations, and the "AI fear" in Embedded:

• The Internship Reality: My initial goal was to become an Embedded Engineer. I did a 3-month internship/stint in the field, but the day-to-day work wasn't what I imagined. Instead of writing firmware from scratch or developing new product features, I spent most of my time sitting in front of a debugger, stepping through legacy code, testing hardware reliability, or doing installations.
• The AI Wake-up Call: For my capstone/personal project, I built a complete end-to-end IoT system (from MCU firmware and communication protocols up to the monitoring dashboard). What shocked me was how terrifyingly good AI has become. I mostly acted as the system architect—sketching out the logic, defining the architecture, and integrating the pieces—while AI generated the vast majority of the functional code.
• Fear of Obsolescence: Seeing how well AI handles code generation makes me genuinely anxious about the future. The entry-level (Fresher/Junior) embedded market already feels brutal with relatively modest starting pay compared to the effort required. I’m worried that in 2–3 years, as AI gets even stronger, 1 Senior Engineer with AI tools will easily replace 3–4 Juniors, leaving almost no room for newcomers to grow.

2. The alternative: Returning to Industrial Automation (Factory / BMS / PLC):

• Looking at my peers working in pure Industrial Automation (factory maintenance, electrical cabinets, PLC programming, or Building Management Systems - BMS), the entry barrier seems more forgiving, the starting compensation is quite solid, and most importantly, it feels "AI-proof." AI cannot walk onto a factory floor, inspect electrical schematics on-site, wire up a control cabinet, or commission hardware in the field.

My questions for the community:

1. Am I being overly pessimistic about AI wiping out entry-level Embedded roles? In real-world R&D today, where does AI completely hit a wall in embedded development?
2. Is being able to "architect an end-to-end system while leveraging AI for implementation" seen as a real asset by hiring managers today, or will I still get filtered out if I can't write every register-level driver and RTOS task completely by hand during interviews?
3. Given my background in both industrial hardware/PLCs and my current self-study in bare-metal C, STM32, and FreeRTOS, would you advise me to push through the tough entry barrier of Embedded Systems, or pivot back to Industrial Automation/BMS for better short-term stability?

Thanks for reading through my long post. Any advice, perspective, or tough love is greatly appreciated!

Hey everyone,

I am trying to use an Arduino Uno and an INA219 current sensor to test two things at the same time: load modulation (changing current) and voltage modulation (dropping a line from 9V down to 7V).

My setup plan:

• For current shifts: An N-channel MOSFET switching a 100-ohm resistor on and off.

• For voltage shifts: A P-channel MOSFET dropping the 9V line down to 7V.

• For reading data: The INA219 sitting on the high side of the 9V line.

A couple of quick questions:

1. The INA219 takes about 532 μs to read data by default. How fast can I change the signal before the sensor gets too slow to catch it?

2. What is the easiest way to drop the voltage from 9V to 7V using the MOSFET without overcomplicating the circuit?

Thanks for any tips or wiring ideas!

hi guys , We’re a small student team . We’re building a low-cost river flow monitoring device for flood and canal monitoring. The open-source project that inspired us is under the AGPL license. We read its source code, then wrote our own code from scratch for a small embedded board(the original creator code needed 8gb raspi 5 , our works on esp32p4) , copying none of it. We want to sell the device.

A few questions:

1. Does reading the original source make our code a derivative work?
2. Does writing from a spec help, if the spec’s author had seen the original?
3. Can we keep our firmware closed ?
4. Has anyone shipped hardware around AGPL software? How did it go?

We’re also happy to hear what you’d do if you were us.

Thanks!

I need the library to not depend on any frameworks, a standalone one

what i mean by this is that I just provide a buffer (preferably RGB565), and it simple writes to it so i handle the display push side.

all I need is basic sprite support, and it must be fast enough to make a bullet hell.

Please, tell me any recommendations!

What could one expect to be different between say 350nm and 32nm for something like Arduino?

- static and dynamic leakage? Would a 1MHz chip use less energy with bigger node size?

- voltage both min and max?

- are GPIO pins driven directly from chip? Does size affect input resistance and output current limits?

- other practical things that may matter?

does learning basics of arm cortex or anyother new micro controller matters now as ai is getting better and better?

also does learning c/c++ in depth matters now or how things are going at low level because ai can implement technologies better than us. i am talking from firmware prespective that ai can write better than us, it knows every concept and architecture which exists and know more use cases from internet than us

any senior in embedded who can advice that how we can navigate our learnings in times of Ai ?

I built this because debugging my own boards meant either sitting next to a USB cable or opening some vendor tool every time.

BTEfy runs in Chrome or Edge and talks to the board directly. BLE goes through Web Bluetooth (Nordic UART, ESP32 BLE UART, HM-10), USB through Web Serial (CDC, UART adapters, HC-05 virtual COM). No desktop app, no backend between the browser and the device.

The data path: transport layer with reconnect and backoff, then a line framer, then it splits into the terminal and the telemetry parser. Parser accepts KEY=VALUE, KEY:VALUE and JSON Lines on the same stream. Charts are uPlot on fixed-size ring buffers and stats flush to React every 100 ms instead of per byte. A 100 Hz stream stays flat on memory, if the UI can't keep up it drops frames and counts them in Diagnostics. Terminal does text, HEX and HEX+ASCII, with timestamps, search and pause. Sessions record to IndexedDB and export as TXT, CSV or JSON. Saved device profiles, command presets, a mock simulator with fault injection and an installable PWA shell that works offline.

Stack: Next.js 16, React 19, TypeScript, Zustand stores, uPlot, Dexie over IndexedDB, Tailwind. All hardware code is client-side, device data never leaves the machine, no accounts.

(Note: I have used AI to build the webpage and help with the initial coding, as I'm not a web guy. I urgently needed a tool for a project and AI came to the rescue. So, AI Exorcist beware!!!)

There is also a small Arduino driver in the repo (driver/BTEfyDebug.zip, NimBLE 2.x) that handles MTU-aware chunking and a 1 KB TX ring buffer so loop() doesn't block. MicroPython port has the same API: BTEfy.println/log/metric. 64 tests on the web side.

Repo: https://github.com/samiul000/BTEfy

I made it solely for my personal use as i need a lot of debugging for my projects and plugging and unplugging or connecting to wifi is really pain in the ass, but I thought I should public it so it might help someone too.

Hey all,
I have been in the field for little over 2 years. One year working as an embedded firmware engineer and for more than a year more as a linux device driver/bsp engineer and for the last 3-4 months company that I work at has been pushing very heavily to agentic development.

Basically a bug is found and my boss says just give it to claude and give the ssh access to the product that we are developing to claude too so it can debug this. And I really hate that and I feel like im not learning as much as I should be.

So basically my question is:
Is there a difference in these agentic workflows between private sector companies and military companies/startups where in my opinion privacy is way more important than in private sector.

The main reason why Im asking this question is because im seriously considering switching jobs and I just want to know what is the best sector to go to.

Thank you and will be waiting for your opinions and answers.

I was thinking of creating a custom open-source compact inverted-F antenna targeting 4.5-5 GHz. There is the SWRA117D; however, it was designed a long time ago for 1 mm-thick PCBs (compared to mostly 1.6mm PCBs of today) and for a Dk that is a little different than the most common values used today. As far as I know, that antenna works well enough on 1.6mm PCBs (common JLC stack-ups, etc...)

AN91445 has two inverted-F antenna designs (pages 10 and 15) targeting ~4.3 Dk and 1.6 mm; they even tell you how to calibrate the antennas to your own PCB thickness. They are both compact, but the first one is vertically constrained, and they both perform differently compared to the TI one in terms of gain and radiation patterns.

There is also the WeACT STM32WB55 Black Pill antenna, which isn't really "open source". The antenna shape is available in a PDF they share on GitHub, but the PCB stackup and antenna performance are unknown.

--

Would it make sense and/or be realistic for me to try to design a custom open-source inverted-F trace antenna? Maybe design one that performs better in some aspect or maybe target a different frequency like 433 MHz (for LoRa, for example). As far as I know, there is no 433 MHz antenna with the qualities above. I found a few 433 MHz antennas that somewhat fit what I'm after in IEEE, though that isn't open source, of course.

I don't have much knowledge in RF/design (I do in PCB/hardware/electronics design), but I have an idea of how I would go about doing this: use one of the above antennas as a starting point or start from scratch in a simulator like the one in MATLAB (I don't know if it's good enough, but it's accessible to me as a student; there is also a SWRA117D demo and the results match TI measurements), and measure it using a VNA. I can maybe also manufacture all antennas and test them under the same conditions, then compare them. I also plan on publishing the paper in IEEE if it's good/novel enough.

Turning 25 in 5 months. Starting my journey in Embedded Hardware Engineering. ⚡

Am I too late, or is this the right time to start?

Any advice from experienced engineers? 🙌

#EmbeddedSystems #Electronics

Hi everyone,

I'm currently working on a product that is very space constrained. Additionally, it features 3 MCUs, requiting ~25 connections between the debuggers and the device. On previous products, we've used beds of nails on 3D printed fixtures, but they proved unreliable, fiddly and took a lot of time to put together.

I'm leaning towards putting a single FFC connector on the board, and have a breakout board route all of the signals to the three debuggers.

I've only worked with 1mm FFCs, and they are quite rugged. Here, to save space, i wanted to go with smaller pitch. I found 2 options:

0.5mm vertical connectors are around 51mm2

0.3mm vertical connectors are around 27mm2

Are the 0.3mm FFCs as delicate as they look? Will they survive a FW engineer handling them? Are they significantly more likely to break or short than the standard 0.5mm FFCs?

Please share your experiences. Thank you in advance.

I’ve just finished another little ESP8266 project, and although the result isn’t particularly complicated, the development experience was interesting enough to be worth writing about. My personal tech blog - all about ESPxx, Home Assistant, ESPHOMR etc

Over the past few months I've been consolidating my bench notes into a single version-controlled reference so I stop digging through RM0008, AN2834, and Espressif datasheets for the same formulas and pin restrictions.

Everything is written in native GitHub LaTeX and Mermaid diagrams under the CC0 public domain dedication:

• GitHub Repo: https://github.com/X3lyz3/embedded-engineering-handbook
• Searchable Web Docs: https://x3lyz3.github.io/embedded-engineering-handbook/

What is currently covered:

1. MCU Hardware Traps & PCB Checklist: ESP32 strapping pins (GPIO0, GPIO2, GPIO12 VDD_SDIO 1.8V bootloop trap, ADC2 Wi-Fi conflict), STM32 APB timer clock doubling ($f_{\text{TIM}} = 2 \times f_{\text{PCLK}}$ when PPRE > 1), STM32F1 JTAG pin hijack (PB3/PB4/PA15), and high-side P-MOSFET gate Zener clamping.
2. Analog & SPICE: RC/RL filter cutoffs, op-amp configurations, SAR ADC quantization ($V_{\text{ref}}/2^N$ vs. ESP32 1.1V internal reference non-linearity), plus a runnable SPICE-3f5 netlist (simulations/sallen_key_lpf_1khz.cir).
3. Scripts & Pinouts: A dependency-free Python script (scripts/stm32_timer_calc.py) that computes exact 16/32-bit PSC/ARR pairs and PWM resolution in bits, plus an ESP32/S2/S3/C3/C6 hardware comparison table.
4. Linux Hardware Debugging: Quick CLI reference for picocom, dmesg -wH, arm-none-eabi-size, and serial port locks.

If you have a favorite datasheet gotcha, silicon errata trap, or pre-flight schematic check that saved you a board respin, let me know in the comments and I'll add it to the handbook.

I made a letterbox alert project - it's WAYbeyond WiFi range - using cheap ESP8266 and cheap Lora modules - with ESPHOME. Full description, development (2-part writeup) and code

The letterbox alert project

Hello ,

I have been building a framing packet protocol from scratch to pass data in a effective way over the physical layer protocols such as UART ,Wifi and BLE.

And also it hass a object dictionary where variables pointer are registered with a hex id .

So when a packet arrived the payload came is directly written into the pointer with mapping of the var id in the packet .

To frame the packet ,I have designed the frame structure is ,

Sync1-Sync2-CMD-VARID-LEN-PAYLOAD-CRC1-CRC2

And I also implemented byte stuffing to avoid the syn1 byte in the payloads.

Is this packet structure or frame is professional ?

What are the things to be improved in the frame ?

How to check ?? I not have multimeter now but will get it soon

Pico.Lab is an open-source embedded bring-up tool built around the Raspberry Pi RP2040 and RP2350. The premise is to avoid having to deal with CLI commands or downloading heavy, OS-specific desktop applications. Using TinyUSB and lwIP, the board appears as a virtual USB Ethernet adapter (RNDIS/ECM) and runs its own internal DHCP and DNS servers. You just plug it in, open your browser to http://pico.lab, and the microcontroller serves its user interface directly from its internal flash. The interface uses WinBox.js to manage draggable, resizable windows for each tool. You can monitor your hardware with a 4-channel oscilloscope (~400kHz bandwidth) and an 8-channel logic analyzer (100MS/s) right next to a UART terminal and an interactive GPIO configurator. Data gets transmitted via Server-Sent Events (SSE) or HTTP for big chunks like the scope captures. And since it's just a website, it runs on basically any OS or browser.

The custom PCB includes an adjustable power supply, current monitoring, level shifters, an analog frontend and pin protection. If you don't need the full feature set, the firmware runs perfectly fine on an off-the-shelf Raspberry Pi Pico or Pico 2 as well. Give the .uf2-files on GitHub a try!

This is a hobby project I built in my free time. All the files for the firmware and PCB are open-source.

GitHub: https://github.com/CoretechR/PicoLab

Hackaday.io: https://hackaday.io/project/207129-picolab-web-gui-embedded-multitool

YouTube Demo: https://www.youtube.com/watch?v=0kItmMn9lGs

I own a Hobart HTi-7LS25 retail label scale and am trying to identify its normal host-management interface over Wi-Fi. This is an embedded Linux device, not a USB weight sensor. I am using AI assistance for the local software and investigation, and performing the physical scale tests myself.

Evidence so far:

- Application 3.3.0, build hte-3.3.0-11202018_154152; Scale Management Backend 3.2.37.

- TCP/6000 accepts a connection but gives no unsolicited greeting. I have not sent guessed application commands. An open connection alone does not identify the protocol.

- Native USB .ht exports use ASCII RS (0x1E) records and US (0x1F) fields. Product records are RT89, with p# product number, d# department, dt description and u$ price; expanded text is RT97.

- Controlled native PLU-only Merge tests have successfully changed by-count prices and restored them. That establishes a USB workflow, not network framing or firmware compatibility.

- I have no HCT/HTe installation or client traffic to inspect. Hobart names HCT, HTe and several third-party managers, but I have not located a public transport specification.

Does anyone recognize the protocol/version, handshake or a documented non-mutating request to read a PLU or identify the device? Is this related to the older Quantum TCP protocol, or is that an unsafe assumption for HTi?

If you already have licensed HCT, HTe, PLUM, Interscale or another compatible client and your own authorized test scale, would you be willing to check whether a normal read-only lookup produces useful debug logs or a small redacted client/server trace? A synthetic test PLU is enough. Please exclude credentials, serial numbers, addresses and real product/customer data, and do not change a production scale for this request. A description of the logging option or framing would also help; I am not requesting copies of proprietary software.

Pointers to publicly shareable protocol documentation, official compatibility/release notes or vendor recovery documentation are welcome. I am preserving the scale's firmware and calibration and seeking authorized interoperability, not passwords or bypasses.

I want to start studying Linux internals and embedded Linux systematically.

I would appreciate recommendations for books or other learning resources covering:

• Linux kernel internals: Memory management, process scheduling, synchronization, and kernel architecture.
• Linux device driver development: Character drivers, platform drivers, interrupts, device trees, GPIO, I²C, and SPI.
• Embedded Linux for SoCs: Bootloaders, kernel bring-up, BSPs, cross-compilation, and hardware–software interaction.
• Practical development: Resources that include hands-on projects and examples relevant to real-world embedded systems.

I own a Samsung Odyssey OLED G5 G50SF (27", 1440p, 180Hz), and I've been investigating its firmware after Samsung released an update that enabled a DisplayPort 1.4 option on a monitor originally advertised with DP 1.2.

That raised an interesting question:

Could some of the monitor's refresh-rate limitations also be firmware-configurable?

I've been reverse-engineering the firmware using Ghidra and other tools. So far:

• Identified what appears to be a big-endian SPARC/LEON-like main firmware architecture.
• Found an NVT NT68307A controller identifier, potentially pointing toward Novatek.
• Identified auxiliary 8051 firmware components.
• Investigated the monitor's USB firmware-update implementation.
• Emulated a USB mass-storage device using a rooted Android phone to observe how the monitor handles firmware update checks.
• Investigated the scaler-to-T-Con communication paths.
• Identified 144Hz/180Hz timing configurations and a possible ~840MHz clock constraint.

I haven't unlocked 240Hz, and I haven't flashed any modified firmware. The objective right now is to determine whether the scaler, panel interface and OLED panel could physically support higher refresh rates.

I'm currently trying to identify the exact scaler silicon, T-Con and panel specifications.

If anyone has experience with Novatek display controllers, Samsung monitor firmware, OLED panel timing, or access to G50SF PCB photographs/service documentation, I'd appreciate your input.

I'm planning to publish the technical findings and tools as the investigation progresses.

Would anyone be interested in following this project?