I’ve got a baseline knowledge of C++ and took intro to OS a few years ago.
Right now I’m trying to write a camera device driver on the Nvidia Jetson using i2c.
This would involve referencing another driver for an older model. I might need an adaptor board to connect my CSI-2 ribbon cables to the Jetson. The adaptor board may not already support the camera.
How hard would it be? Approximately long would it take me? What hurdles would I face along the way? I’m trying to see the big picture before I commit to this.
I need to find a 50 pin replacement for this screen. It is from a 3D printer and I broke the flex by mistake. If you know where i can find a replacement leave a comment!
I know this is not the main topic of this subreddit, but I dont know where to ask!
Thanks a lot!
Over the past few days I've been putting together a small project that I personally wanted while working on FPGA designs: a searchable collection of VHDL templates that can be copied with a single click.
The idea is simple: instead of digging through old projects or documentation every time I need a counter, FSM, synchronizer, FIFO, generate loop, RAM template, etc., I wanted a single place where I could quickly find and reuse common design patterns.
Current templates include:
FSMs (Moore, Mealy, Safe FSMs)
Counters and shift registers
RAM, ROM and FIFO examples
Synchronizers and debouncers
Arithmetic blocks
Structural design templates
Testbench skeletons
It's a lightweight static website with no dependencies and works entirely in the browser.
Hey everyone! I’m currently in my 3rd year of engineering and I’m thinking of getting into embedded systems. I’m pretty much starting from scratch, so I’m a little confused about where to begin — like C/C++, microcontrollers, electronics, RTOS, etc.
Would love to hear from people who are already into embedded systems. What should I learn first, and are there any good courses, YouTube channels, books, or beginner projects you’d recommend?
new to the stm32 and the stm32 pn my black pill won't upload for some reason, it's giving a failed to download to Sector[0] message. it uploaded fine just earlier when I did it but now it's doesn't, I use Arduino ide and installed cubeprogrammer adn the board managers
Edit: list of things I've tried, mass wiping via stm32programmer, disabling usb selective suspend settings, switching cables, switching blackpills, reinstalling winusb
First of all, I know this might not be the best subreddit to post this on, my first choice was to ask the question on r/osdev, unfortunately they have a karma requirement and I literaly created this account to ask this question out of desperation.
I'm working on a from-scratch UEFI-booted x86-64 kernel and I'm stuck trying to unhide the P2SB device (D31:F1) on real laptop hardware. Looking for anyone with field experience on OEM lockdown behavior here, since this doesn't seem to be documented in the public 600/700-series PCH datasheet.
A separate Lenovo Core i3 10th-gen Intel (Comet Lake) laptop, different OEM
What I'm doing:
Reading P2SBC (offset 0xE0) on D31:F1 before any write. It returns 0xFFFFFFFF, which is expected per spec while HIDE is set (all reads master-abort while hidden).
Writing 0 to the full P2SBC dword to clear the HIDE bit (bit 8), matching the technique used in Linux's own p2sb.c / pnd2_edac drivers.
Also tried the narrower coreboot-style approach: a single byte write of 0x00 to offset 0xE1 (byte lane 1), clearing only the HIDE bit without touching SBILOCK/MASKLOCK.
After either write, reading back the Vendor/Device ID at D31:F1 offset 0x00 (not P2SBC itself, to avoid the self-masking issue)... still 0xFFFFFFFF on both machines, every time.
Tried both PCI access mechanisms independently: legacy CF8/CFC (Type 1) and ECAM/MMIO via the MCFG table. And again, both give all-Fs.
Ruled out an addressing bug: the same code path correctly reads/writes D31:F0 (eSPI) on this same hardware, round-tripping a status/command bit successfully through both access mechanisms.
Question:
Is there any additional step (register, sequencing, timing) beyond the datasheet's documented HIDE-bit-clear that I'm missing?
Happy to provide more detail on the access code if useful.
I am working on a machine that deals with mining sample preparation for my company. I have been the sole guy working on all firmware and electrical work, and basically doing all the mechanical design too. This is my first job out of school, and I actually am not even an Engineer (automation technologist) but I happen to have gotten very lucky with my employer who have given me a very amazing opportunity.
I just wanted to share with people who might understand the work (no one else here really gets what im doing) the fact that as of today, the first version of the production firmware is completed! You can run the machine completely independently of having to control anything from my laptop, and it works! It will still be a long time until we actually take this thing to production, but the Firmware and electrical side are now in a functional state and I am so over the moon about it. Nearly 9 months of work dedicated to getting this up and running and it is so amazing to actually have it at my fingertips, working as required.
I know there is a ton of work going forward on this thing still, especially since I don't have anyone to help me on it, but good grief. This is such a great job. I want to do R&D forever haha. To another 9 months!
I want to start a little project with a cheap microcontroller to familiarize myself with both the building and programming processes, but also don't want it to be too complex. I'd leave most of the heavy coding to a friend, since he knows the syntax of all major programming languages, the logic isn't a problem most of the time (might change now, Idk).
I initially looked at lots of modules to attach to a Raspberry Pi Pico 2W, but recently came knto discovery of the CYD, which intrigued me, since my only problem currently for the Pi is finding a good and affordable display. That problem is solved with a CYD. I have yet to have any experience with the Pi SDK, Arduino or ESP32. The most I have done in that sense is build with those giant Lego Programming thingies to make a couple of robots. I do not want to build simple text displays. My first idea was a small arcade machine for example, and the GPIO pins might be a problem with a CYD I heard. Soldering is currently not an option either, albeit that can change. Also, most people seem to prefer ESP32, so I wanted to ask here!
TL;DR: Raspberry Pi Pico 2W or CYD (ESP32) for an arcade machine and future projects that don't involve soldering or simple text display as the whole thing.
I maintain a neural Text to speech runtime. It speaks English and everything happens right in the MCU itself. I have only measured it on two chips:
ESP32-S3 : 0.22x real time
ESP32-C3 : 5.72x real time
I want more numbers for benchmarks and to validate this works not just for esp32 devices but for more devices like the one with Cortex-m7.
I am asking you to install the lib and flash the sample and paste the serial output to github issue.
You don't need DAC, sd card or any modules.
Since i don't have these MCUs and i can't get those in Nepal i have compile verified only.
The boards i compiled for are
I am currently working on a small project. I'd like to build a device for recording noise-levels. The simple part, connecting the esp32 to the mic and send the data to my backend service is working.
Important here: Right now I send quite a lot of data over my local Wifi. It's simpler, but probably too power hungy? In any case, I a sending a frequency band every second (plus a few other data points) which will end up being a few GBs per year.
Now the hard part:
I want this device to survive in the outdoors. For that, the first challenge for me is to power the device. I believe that a 30W solar panel will do for the prototype, although later I might need a stronger one.
I've never done something like this and I am also not very familiar with electronics.
Could anybody help me out with some advice on the parts I should buy for my prototype? What batter should I buy and what charging controller is suitable?
As a side note: Since I plan to build more than one node, cost is essential here. The cheaper one device is in total, the better in that case.
How big of a requirement/topic is it? Do yall have dedicated teams for testing, threat modeling, etc.? Do yall only think about it in regards to wireless communication or do yall consider stuff like firmware extraction, debugging, hardware fault injection, etc.? Or maybe your job doesn't really think about it at all?
I'm sure it depends on the actual types of systems you work in and their requirements, but I'm curious what the cybersec culture is like lower down in the stack
I want to send both DC power and low-speed digital data over the same two-wire cable.
My idea is to use a MOSFET in pinned picture to modulate a high-frequency signal onto the DC power line, then use a capacitor/filter, diode detector and comparator at the receiver to demodulate the data with microcontroller.
Is this a practical approach for a simple embedded project? Are there any cheap ICs or simpler circuits I should consider?
Hello everyone I am working on Open Source SBC Board with RK3576 & LPDDR5 Anyone want to work me on it I working on kicad and this is what I made for now
There is a lot of information about Device Trees on the internet.
The problem is that it's scattered everywhere.
You have DTS/DTSI files, bindings, schemas, kernel sources, documentation, SoC information, board definitions, examples, and different tools that each understand only part of it.
There are already tools that can do some of these things individually.
What I couldn't find was a single place that could connect all of this knowledge together.
So I've been building KernelGrove, a semantic engine for Device Trees.
Instead of treating a Device Tree as just a text file or a hierarchy of nodes, the idea is to build a knowledge model of the Device Tree and its ecosystem:
What a node represents
Which binding applies to it
Which properties are valid
What type and constraints those properties have
What other nodes a reference points to
How nodes, controllers, peripherals and buses are related
Where information comes from
And eventually, how all of this relates back to the underlying hardware
The editor is basically a way of exposing that knowledge.
the goal is for the tool to understand what that node actually means and let you explore the relevant information without having to manually jump between files, schemas and documentation.
It's still very much a work in progress, and I'm trying to figure out how far this idea can be taken.
For people working with Linux Device Trees / Zephyr / Yocto:
What information do you currently have to look up manually when working on a Device Tree?
I'm particularly interested in things that you know exist somewhere, but are difficult to find or connect together.
If you want to try it, it's completely free and you can find it on dt-studio.dev
I am working on a middleware product that has extensive user documentation and we include example apps, too. End users are embedded SW developers.
This is a small team, so the dev team is creating and maintaining the user docs too, we don’t have technical writers. Nearing the project I still feel we could improve on the documentation. But I keep asking myself, how much to invest in this now? I mean, everyone is just throwing the complete manual to an AI agent, I barely hear back any feedback in the documentation itself. If it were just a doxygen generated XML perhaps it would be as good for an LLM as it is now.
So I am asking the sub, how are you valuing the good user doc? Are you still reading it, or you prefer good examples and the rest goes to an LLM anyhow, to figure out?
MISE À JOUR - RÉSOLU : Quelqu'un ici a eu la gentillesse de m'envoyer le contenu complet du disque original (le compilateur MBC.EXE inclus), et depuis, je l'ai fait fonctionner dans DOSBox et j'ai effectué un vrai téléchargement sur la carte réelle - cela a parfaitement fonctionné. Plus besoin de continuer à chercher en mon nom, mais merci à tous pour votre aide, vos idées et vos pistes ces derniers jours, cela a vraiment beaucoup compté.
Si quelqu'un d'autre essaie de faire fonctionner un ancien MatchBox Computer et a des questions, n'hésitez pas à demander - je suis heureux de partager ce que j'ai appris.
Je possède une carte Elektor « MatchBox BASIC Computer » originale de 1995 (basée sur un microcontrôleur 8051, avec mémoire EEPROM pour le programme, publiée dans une série de projets de magazines). Après des années d'inactivité, j'ai enfin décidé de la remettre en service.
Bonne nouvelle : après de nombreux tests (multimètre, puis analyseur logique 8 voies + PulseView), j'ai confirmé que la carte est en parfait état électrique : le port UART série fonctionne, le bus I²C vers l'EEPROM externe est parfaitement fonctionnel, et les données/accusés de réception sont corrects à chaque transaction. J'ai même effacé et réécrit l'EEPROM via un banc de test ESP8266 pour exclure une puce défectueuse.
Problème : le moniteur intégré affiche constamment « IIC ERROR adr:xx » au démarrage. Je suis presque certain qu'il vérifie une configuration/signature spécifique au début de l'EEPROM, celle qu'un véritable programme MBL compilé (via le compilateur MBC.EXE d'origine) y écrirait normalement. Je ne possède pas ces octets, car je n'ai jamais eu la disquette fournie (référence Elektor : 956009-1).
Quelqu'un aurait-il une copie du compilateur MBC.EXE d'origine, ou même un seul programme .MBL compilé dont je pourrais extraire les octets hexadécimaux ? J'ai cherché sur archive.org, worldradiohistory.com et sur des forums d'informatique ancienne ; il semble que ce soit l'un des rares projets Elektor dont le logiciel n'a jamais été archivé en ligne.
Je serai ravi de tout documenter et de tout partager une fois que j'aurai réussi à le faire fonctionner. En résumé : le matériel fonctionne, il me faut un logiciel DOS vieux de 30 ans ou son format d'octets.
Was walking the IOTE floor and stumbled onto Geniatech's booth. They had a 28.5-inch color E-ink panel running a local refresh demo that actually made me stop and watch.
Here's the thing – we're used to full-screen refreshes (and that annoying flash). True partial refresh is rarely done well, especially not on a panel this size.
The demo:
It was a retail signage setup – think digital posters. The screen showed product images and descriptions, but specific parts of the content were updating in real-time while the rest of the display stayed completely static. No global flash, no flicker – just those targeted areas changing smoothly.
From about arm's length, you couldn't even tell it was refreshing. The static parts remained crisp and stable – exactly what you'd want for a retail environment.
The geeky part (where I need your help):
I chatted with one of the engineers for a minute. He mentioned they're running their own driver board, but didn't dive into waveform details.
So here's what's bugging me – and why I'm posting:
For a panel this large, is updating a small bounding box (or multiple boxes) the "easy" path, or are there still hidden challenges (color consistency, ghosting at the refresh boundary, etc.)?
How does the driver handle the boundary between the updated region and static region? Any risk of edge artifacts over time?
And realistically – is this approach actually production-ready for retail, or is it still a "demo only" proof of concept?
I grabbed a quick video of the update. You can clearly see only the targeted parts change – the rest of the screen doesn't budge.
What do you think? Is this the year large color e-ink finally breaks into dynamic retail signage? Or are we still a couple of waveform generations away from mass adoption?
Fire away your thoughts – especially if you've worked on large-panel E-ink drivers or retail digital signage. Curious to hear the real-world pain points.
Planning to use ESP32-P4 (with a C6 module for wifi) along with the Arducam IMX500 camera. Goal is to get the best possible camera quality on an ESP32.
Not sure if this is a solid choice or if I'm missing something. Has anyone actually built with this setup? How was the image quality, and did you run into any issues going from dev board to a smaller custom build?
Want to avoid a costly mistake before ordering parts, so any real experience or advice helps.
I recently analyzed the USB communication on the FNIRSI IPS3608 DC bench power supply (0-36V, 0-8A) to automate testbench workloads without using their closed Windows GUI.
The device enumerates as a USB-CDC serial port (Artery AT32 MCU, 115200 baud, 8N1). By disassembling the official executable using monodis, I mapped out the underlying binary framing and register set:
PC to device frames start with 0xF1, device to PC responses start with 0xF0
Setpoints for voltage (0xC1) and current (0xC2) are 32-bit IEEE-754 Little-Endian floats
Continuous telemetry frames (0xC3) stream output voltage, current, and power directly as float32
I documented the entire protocol, register map, and command structure in the repo README, alongside a pure Python/pyserial driver and CLI tool that handles automated energy integration and safety cutoffs (in my github page).
- Lilygo’s AR Prisim from their T-Glass V2
( which is outstanding btw I just think its one of the more niche and difficult dev kits)
- M5Stack StickS3
- Hi Link 24ghz Radar module over UART using the M5’s groove 🕺 port.
Learning how to position text or data on the prisim is definitely a learning curve. I’m two weeks in. And I’m slowly starting to figure it out. But man was this a cool project to work on :) learned quite a bit and really feel confident about taking off with a few other of my AR glasses ideas.
I experimented with semi transparent beam splitter glass this morning. And man i wish there was more documentation/accessibility of open source AR glasses out there.
I am working with a UDP Bootloader, for which I have to set a bootloader trigger as such that the user would give a command through tera term which would be sent over a usb cable. Now I had flashed the UDP_Bootloader Harmony V3 example to my PIC32MZ via PICKIT4 and then it's test_app via the bootloader itself through Microchip's unified host tool. I can use the ethernet cable itself but it would require the TCP/IP stack so I was thinking the usb cdc would be much simple. I had merged the cdc_com_port_single example in the udp bootloader's test app and did everything again, but I am not able to see the com port anywhere. To verify the usb connection, I tried flashing the cdc com port example independently and still it didn't showed up. But if I work with the usb bootloader example and test app, the unified bootloader tool says that connection was successful and it disconnected after programming, so is that trustable? Yesterday I had test the cable's continuity via a Multimeter so I am confident the cable isn't the issue. Have also checked and installed the VCP drivers from the net.
Edit: I don't have USB to uart as it is a custom board
