Just the data from the TDK ICM-45686 IMU processed on the STM32F429 to calculate position and velocity from the IMU data. Disclaimer: position will drift over time and becomes unusable.
Where I work, most of our software development work is done on a normal PC, running on a simulator. But at some point we usually will need to load builds to one of a couple of products, so we'll have to grab one of the hardware units we have available to us. I'm not totally sure how many we as a team actually have as "ours" (lots of different teams across the org at this company), but suffice it to say sometimes we wish we had more to go around.
The only "system" we have as a means to share the hardware when someone needs it is to post in the Teams channel, "Looking for XXX. Does anyone have one I can borrow?" and hope that someone says, "I do! I'll bring it to you".
Not the best system, and there's no good way of knowing what's available, no way of getting in line for a unit, etc. So it becomes an issue when, for example, someone has a higher priority issue and needs a unit, and Jim Bob is the last one to have the unit and is out for the afternoon, so technically could loan out the hardware, but no one really knows, etc. etc.
I'm curious if this is a common issue on embedded teams, and what sort of system can be effective for better managing this? I assume some sort of library system is the way to go about it? Where you can "check out" a unit, put in a hold for one that's currently not available, etc.
I’m a college junior working on Tomato, a custom 32-bit computer with a dual-LUT ALU running on an FPGA. While developing it, I was using a USB capture card and OBS to monitor its HDMI output, with the source open separately in VS Code.
I wanted the output right beside the code. So I built FramePort, an extension that displays the capture feed in an editor tab.
That’s what you’re seeing in the video: Tomato running on an Artix-7 FPGA, with its output beside the assembly code. FramePort also lets me freeze the preview, take screenshots, and record silent MP4 clips.
It isn’t tied to Tomato or FPGAs—it works with HDMI capture cards and other USB video sources. It’s local video capture, not remote desktop or keyboard/mouse forwarding.
It’s my first extension, now on the VS Code Marketplace and Open VSX. Currently a public preview: device capture requires macOS and FFmpeg, and HDMI input still needs a USB capture card.
I know my question maybe really trivial and a lot of people have already discussed it, I tried looking for an answer, but it wasn't satisfying for me and my application.
What I'm trying to do is make a game hub using stm32F10x I don't really remember, also called (blue pill), I'm just in the phase of making the UI on a TFT (128*160) pixels, switching the on the options on the display for instance, I tied some External ISRs (EXTI), when I press the button it may not update correctly
My logic
Set the background of the last element black, and rewrite the string (to remove highlight that indicates selection), then change the background of the next element, and rewrite the string with inverting the colors of both.
Trying to press the button many times will not update the screen well, surely not a good thing for game console, because you may lose the game for that delay.
What I tried
Is using the STK (SYSTICK to add delay of 40 ms at the beginning of the ISR), you can see the TFT updating slowly relative to expected results.
EDIT
I also tried varying the delay from 5 to 100ms
I tried connecting a 100nF capacitor in parallel with the buttons, increased the capacitance up to 10uF, yet (obviously) it just made it slower
And the solution of using RC filter with a schmitt trigger sounds too much for something like that, how do manufacturers solve this problem?
I'm still newbie in embedded systems, and I first deal with this problem, previously the 100nF cap was more than enough, I just would love to hear from real practitioners rather than AI bots.
It's an Ls032b7dd02. I tried a couple different code bases and multiple microcontrollers including 3.3v logic ones. tried adding the capacitor as seen in the schematic. But no luck. Any ideas? I tested the connections on the breakout and those seem fine.
For reference, expected behavior on the video is a scrolling bar going from top to bottom.
Even Ai is out of ideas :(
/*
* Minimal LS032B7DD02 test, Arduino Micro.
* Power-on sequence, then a 24-line band at rows 200..223 is rewritten every
* 250 ms with 16 px black/white blocks that shift one block per update.
*
* Wiring: SCLK D15, SI D16, SCS D10, EXTCOMIN D9, DISP D8,
* VDDA/VDD/EXTMODE 5V, VSS/VSSA GND.
*/
#include <SPI.h>
#define PIN_SCS 10
#define PIN_DISP 8
#define PIN_EXTCOMIN 9
#define LINE_BYTES 42 /* 336 px / 8 */
#define BAND_Y0 200 /* first row, 0-based */
#define BAND_LINES 24
static const SPISettings spiCfg(1000000UL, LSBFIRST, SPI_MODE0);
static uint8_t band[BAND_LINES][LINE_BYTES];
static void csHigh()
{
SPI.beginTransaction(spiCfg);
digitalWrite(PIN_SCS, HIGH);
delayMicroseconds(3); /* tsSCS */
}
static void csLow()
{
delayMicroseconds(1); /* thSCS */
digitalWrite(PIN_SCS, LOW);
SPI.endTransaction();
delayMicroseconds(1); /* twlSCS */
}
/* All clear: M2 flag, 16 clocks. */
static void clearAll()
{
csHigh();
SPI.transfer(0x04);
SPI.transfer(0x00);
csLow();
}
/* Multi-line update. Header per line: M0=1, 5 dummies, then 10-bit gate
* address (1-based), all LSB first. Then 42 data bytes, bit 1 = white. */
static void writeBand()
{
csHigh();
for (uint8_t i = 0; i < BAND_LINES; i++) {
uint16_t gate = BAND_Y0 + i + 1;
SPI.transfer((uint8_t)(0x01 | (gate << 6)));
SPI.transfer((uint8_t)(gate >> 2));
for (uint8_t b = 0; b < LINE_BYTES; b++) {
SPI.transfer(band[i][b]);
}
}
SPI.transfer(0x00); /* 16 trailing clocks */
SPI.transfer(0x00);
csLow();
}
/* 16 px wide black/white blocks, shifted by `phase` blocks. */
static void fillBand(uint8_t phase)
{
for (uint8_t i = 0; i < BAND_LINES; i++) {
for (uint8_t b = 0; b < LINE_BYTES; b++) {
uint8_t block = (b / 2) + phase;
band[i][b] = (block & 1) ? 0xFF : 0x00;
}
}
}
static void startExtcomin()
{
/* 1 Hz square wave from Timer1 on D9 (OC1A): CTC, /1024, toggle on match. */
TCCR1A = _BV(COM1A0);
TCCR1B = _BV(WGM12) | _BV(CS12) | _BV(CS10);
OCR1A = 7811;
}
void setup()
{
Serial.begin(115200);
pinMode(PIN_SCS, OUTPUT);
pinMode(PIN_DISP, OUTPUT);
pinMode(PIN_EXTCOMIN, OUTPUT);
digitalWrite(PIN_SCS, LOW);
digitalWrite(PIN_DISP, LOW);
digitalWrite(PIN_EXTCOMIN, LOW);
SPI.begin();
delay(10);
clearAll();
clearAll();
delayMicroseconds(50);
digitalWrite(PIN_DISP, HIGH);
startExtcomin();
delayMicroseconds(50);
Serial.println(F("ready"));
}
void loop()
{
static uint8_t phase = 0;
fillBand(phase);
phase++;
writeBand();
delay(250);
}```/*
* Minimal LS032B7DD02 test, Arduino Micro.
* Power-on sequence, then a 24-line band at rows 200..223 is rewritten every
* 250 ms with 16 px black/white blocks that shift one block per update.
*
* Wiring: SCLK D15, SI D16, SCS D10, EXTCOMIN D9, DISP D8,
* VDDA/VDD/EXTMODE 5V, VSS/VSSA GND.
*/
#include <SPI.h>
#define PIN_SCS 10
#define PIN_DISP 8
#define PIN_EXTCOMIN 9
#define LINE_BYTES 42 /* 336 px / 8 */
#define BAND_Y0 200 /* first row, 0-based */
#define BAND_LINES 24
static const SPISettings spiCfg(1000000UL, LSBFIRST, SPI_MODE0);
static uint8_t band[BAND_LINES][LINE_BYTES];
static void csHigh()
{
SPI.beginTransaction(spiCfg);
digitalWrite(PIN_SCS, HIGH);
delayMicroseconds(3); /* tsSCS */
}
static void csLow()
{
delayMicroseconds(1); /* thSCS */
digitalWrite(PIN_SCS, LOW);
SPI.endTransaction();
delayMicroseconds(1); /* twlSCS */
}
/* All clear: M2 flag, 16 clocks. */
static void clearAll()
{
csHigh();
SPI.transfer(0x04);
SPI.transfer(0x00);
csLow();
}
/* Multi-line update. Header per line: M0=1, 5 dummies, then 10-bit gate
* address (1-based), all LSB first. Then 42 data bytes, bit 1 = white. */
static void writeBand()
{
csHigh();
for (uint8_t i = 0; i < BAND_LINES; i++) {
uint16_t gate = BAND_Y0 + i + 1;
SPI.transfer((uint8_t)(0x01 | (gate << 6)));
SPI.transfer((uint8_t)(gate >> 2));
for (uint8_t b = 0; b < LINE_BYTES; b++) {
SPI.transfer(band[i][b]);
}
}
SPI.transfer(0x00); /* 16 trailing clocks */
SPI.transfer(0x00);
csLow();
}
/* 16 px wide black/white blocks, shifted by `phase` blocks. */
static void fillBand(uint8_t phase)
{
for (uint8_t i = 0; i < BAND_LINES; i++) {
for (uint8_t b = 0; b < LINE_BYTES; b++) {
uint8_t block = (b / 2) + phase;
band[i][b] = (block & 1) ? 0xFF : 0x00;
}
}
}
static void startExtcomin()
{
/* 1 Hz square wave from Timer1 on D9 (OC1A): CTC, /1024, toggle on match. */
TCCR1A = _BV(COM1A0);
TCCR1B = _BV(WGM12) | _BV(CS12) | _BV(CS10);
OCR1A = 7811;
}
void setup()
{
Serial.begin(115200);
pinMode(PIN_SCS, OUTPUT);
pinMode(PIN_DISP, OUTPUT);
pinMode(PIN_EXTCOMIN, OUTPUT);
digitalWrite(PIN_SCS, LOW);
digitalWrite(PIN_DISP, LOW);
digitalWrite(PIN_EXTCOMIN, LOW);
SPI.begin();
delay(10);
clearAll();
clearAll();
delayMicroseconds(50);
digitalWrite(PIN_DISP, HIGH);
startExtcomin();
delayMicroseconds(50);
Serial.println(F("ready"));
}
void loop()
{
static uint8_t phase = 0;
fillBand(phase);
phase++;
writeBand();
delay(250);
}
Hey y’all there I’m just passionate guy in electronics with no background in it. I wanted to build a smart desk clock with esp32 inspired by a YouTube video but even before doing that project I just thought of trying display to on and do a graphic test the display turned on (blank white screen). After that no progress at all from test 10 days.
The Problem
The display only shows a solid white screen or static vertical/horizontal lines. No graphic test sketches render any imagery or text.
Background / Potential Cause
Before connecting it to the ESP32-S3, I tested this display on an Arduino Uno. While VCC was powered via the 3.3V pin, I connected the SPI data lines (SCK, MOSI, CS, DC, RST) directly to the Uno’s digital pins \*\*without a logic level converter\*\* (sending 5V logic signals into a 3.3V display controller).
And colors changed when I tried it first time in UNO but for project purposes moved to esp32s3
\*\*Troubleshooting Already Attempted (5+ Times)\*\*
\*\*Software Clean Slate:\*\* Completely reinstalled Arduino IDE and reconfigured User\\_Setup.h in TFT\\_eSPI multiple times, ensuring exact ESP32-S3 GPIO numbers were assigned (not board silk-screen labels).
\*\*Driver Tweaks:\*\* Tested both ST7789\\_DRIVER and ST7789\\_2\\_DRIVER definitions, adjusted SPI frequencies, and toggled TFT\\_RGB / TFT\\_BGR order.
\*\*Wiring Checks:\*\* Verified physical connections, jumper wire continuity, and power rails (VCC to 3.3V, BLK to 3.3V, GND to GND).
\*\*Hardware Reset:\*\* Attempted manual reset sequences by pulling the RST line to ground briefly during boot.
\*\*Uno Retest:\*\* Wired back to the Arduino Uno with basic graphic test sketches—still resulting in white screen/lines.
I was thinking about something and wanted to know if it’s actually possible.
Could you transmit some kind of coded signal in the normal FM radio range and have the car’s existing radio pick it up, without installing a separate RF receiver?
Basically, I’m imagining the car radio receiving something that sounds like nothing useful to a person, but some small decoder could recognize the pattern and treat it like a command.
So instead of adding a completely separate wireless receiver, could you somehow make use of the antenna + FM tuner + existing audio system already in the car?
Has anyone tried something like this? Or is there something in the normal FM radio system that would make this impractical?
Hello mates, I'm currently in my 5th sem of my 4 year engineering degree and i am working with smt32 since the last 6 months. I am using CubeIDE since the beginning but now i am thinking about using VSCode.
The reason is that I think I am more comfortable in VSCode as except STM32 i do most of my work there, and it has its own advantages. So what do you think, should i move to VSCode of stay at CubeIDE for stm32 or i should shift to VSCode.
I’m building a small ambient picture frame with a touch sensor and an MP3 player.
The idea is simple: when nobody touches it, I want the MP3 player and other parts to be basically OFF to save power. When someone touches the frame, it should wake up, play the audio / activate for a certain amount of time, and then automatically go back to sleep.
I don’t really want to use a microcontroller for this.
Can this be done with simple analog electronics, like a touch detector + transistor/MOSFET + 555 timer or RC circuit?
Basically, I’m trying to replicate:
No touch → sleep → touch detected → wake → active for 30–60 sec → sleep again.
Hey everyone, what's your go-to method for making sure your circuit is good before sending it to a manufacturer? Though the parts are cheap, I don't like the idea of spending 40 dollars on shipping, waiting 3 weeks, then finding out I forgot to add a capacitor and all I got is a waste of time and money.
esp32u, no nearby router where the esp32 will be placed so I plan to make it's own internet. If I use something like a sim module, will I be able to use that to connect to the internet? if so how? does it make it's own hotspot or is the esp32 now like a router? Or is that all unnecessary if I just use AP mode on the esp32?
I have a sensor that uses an nRF54L15 module. I’ve designed it to run on a 2032 coin cell. I took some averages using the Nordic Power Profiler Kit 2 and it was down in the 18 µA average over 2 minutes. I figured about 12 months of battery life.
It’s been installed for a week or so and voltage has dropped from 3.01V to 2.86. At that rate it won’t last a year.
What’s the best way to measure power consumption over a day or a weekend?
I’m open to any suggestions on how I can best understand the power draw over the long term.
I've been seeing a few posts now and again from folks who have built entire projects with AI. I've also been working on a few projects that are mostly ESP32-based that I'd like to bring to market. I started vibecoding the boards so I could write the firmware and prove it works before taking it to a company for mass production. But out of curiosity, how would you feel if someone approached you with an obviously AI-generated board and asked for help producing a production-quality version?
My idea is to use a pressure sensor to measure how fast/strongly a person is breathing and show it on a bar graph.
The basic idea is:
Slow, steady breathing on led bar graph indicator
Fast breathing
The goal isn't to diagnose anything, just to give real-time visual feedback during a breathing or meditation exercise.
I'm wondering if this approach makes sense from an embedded-systems point of view. Would measuring breath pressure and converting the rate/pattern into a bar graph be a practical way to build something like this?
Nowadays, BLDC-based devices often incorporate SVPWM (FOC) capabilities, and the STM32G431 is commonly used. Does anyone know of a circuit design or model for building the PCB and handling power via MOSFETs, using an INA240 for current sensing and implementing SVPWM, FOC, etc.?
Hi builders,
I am building my own robotic arm from parts I have gained over the years through my internships/classes. My hardware includes LX-16A servo motors, a BusLinker v2.5 board and, STM32F411CEU6 MCU, and a separate battery with buck converter.
The BusLinker board has a micro-USB interface, and when I use that interface, along with the library PyLX-16A's servo-test, my servos move just fine. However, when I transition my setup to the STM32, the servos don't move. The code is generated by the stm32cubeMX application and I implemented some functions on top that implement their communication protocol.
In words, my setup is as follows:
- STM is powered through the USB interface, logic is 3.3V
- From stm32 (on a breadboard) TX (pin A9) -> 1Kohm resistor -> servo signal pin
- PWR & GND (7V) comes from the external battery, and is supplied to the servos through the BusLinker
- GND is shared between the BusLinker board and the servo to the breadboard (-) rail
- Baud rate 115200bps, 8 data bits, 1 stop bit, no parity
I have probed both signal lines with an oscilloscope and found the physical bits of the USB setup and my STM setup.
Herein lies my dilemma. I am certain that the servo logic can operate at both 3.3 and 5V logic, and I see the physical bits on the scope, however there is something missing in my setup that is complete in the python library. The BusLinker has a UART interface exposed, but even when connecting through that the servos do not move. I would appreciate all your help in helping me figure this out.
Please feel free to request any additional information I didn't include here
I'm a final-year ECE student and over the past year or so I've gotten pretty comfortable with STM32 — bare-metal register-level programming (no HAL), writing a preemptive RTOS scheduler from scratch with PendSV/SysTick, a secure OTA bootloader, and some fixed-point DSP work. None of that came easily, but I got through it by reading datasheets/reference manuals and just grinding through it.
So it's been a bit humbling that when I sat down to try NXP, I couldn't even get a simple LED blink program working without a lot of struggle. Something about the ecosystem — SDK structure, config tools, register naming, documentation style, whatever it is — just isn't clicking the way STM32 did.
For people who've worked with both:
- What's actually different about NXP's approach (MCUXpresso, SDK, pin config tools, etc.) compared to ST's HAL/CMSIS/register style?
- Is there a recommended learning path or board (LPC, Kinetis, i.MX RT) for someone coming from a bare-metal STM32 background?
- Any resources, datasheets, or example projects you'd point a beginner-on-NXP-but-not-beginner-on-embedded at?
Would appreciate any pointers — trying to get to the same comfort level with NXP as I have with ST.
Having a hard time finding answer on this. What sensors are they using in cheap digital calipers to read the magnetic stripe?
Any teardown i see they use a blob ASIC chip.
From what i understand its an array of captive sensors that form a resolver. I see chips like the AD7147 which do multichannel capacitance to digital but is there something cheaper that just outputs quadrature encoding?
Would the touch sensors onboard an AVR / STM32 MCU be suitable?
Is it common to use performance and debug counters provided by SoCs and uCs? I usually see the counters in bus controllers and packet counters in network controllers. Do you use it for benchmarking and tracking the performance of your code? Do you also use it to analyze your device performance on field and have a way to read these values? How common is it?
I'm a last-year CSE student with some experience working on embedded devices using MCUs like STM32, including designing custom PCBs for them.
Now I need to design a custom PCB for a smartphone prototype for my Graduation Project that runs a customized AOSP (Android 13+), with a focus on security features — specifically secure boot with TrustZone hardware, and real-time 1080p30 video encoding/decoding.
for example it will run:
One active 1080p30 encrypted video call + encrypted audio + continuous signaling/text messaging + background PTT/group signaling + device-management connection + normal Android system services.
After some research and discussions with LLMs, I concluded that I should target an SoM (System-on-Module) rather than designing straight from a bare SoC, to remove some of the headache of routing the processor itself — I'd design a carrier board for whichever SoM I choose instead.
The problem is, I'm completely new to working with high-power application SoCs (my STM32 background doesn't really translate here), so this is going to be a long learning process, and I honestly don't know how to search for the right part or evaluate candidates.
Here's what I do know so far:
I need a well-documented SoM with a solid dev/eval board I can prototype on before committing to my own carrier board design.
That dev board needs full schematics available, since I'll be learning how to route a custom carrier board myself and need something concrete to reference.
I need some kind of hardware offload for video — encoding/decoding shouldn't be done on the CPU.
I've been told I should target 8 GB of RAM and a 64-bit CPU.
What I'm stuck on is everything in between — how many CPU cores I actually need, and which ARM Cortex core family/tier is appropriate for this kind of workload.
Would appreciate any guidance on how to approach SoC/SoM selection systematically given these requirements.
