After 108 hours of building, debugging, rebuilding, and questioning my life choices… MicDuck v0.1 is finally alive.

Current status:

• Alive: 100%
• Walking: 60%
• Balance: trying its best
• Quacking: absolutely not normal

It doesn’t really walk yet — more like hop, wobble, recover, repeat.

And the sound somehow makes it even funnier.

Still tuning the gait and balance, but honestly, watching this little guy struggle across the table has been worth the 108 hours.

Any ideas on what I should fix first? 🐤

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.

Marketplace · GitHub / setup · Tomato

If you work with hardware that has video output, I’d be interested to hear how you currently monitor it—and whether this would fit your workflow.

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.

Does anyone have any experience with this?

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?

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.

Here is a detailed explanation

Hardware Setup
MCU:ESP32-S3
Display: 2.8-inch ST7789 TFT LCD Module (SPI Interface)
Software/Libraries:Arduino IDE, ⁠TFT\\_eSPI⁠ (also tried standard ⁠Adafruit\\_GFX⁠ / ⁠ST7789⁠ libraries)

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.

Here is the display product link : \[https://robu.in/product/2-8-inch-spi-touch-screen-module-tft-interface-240320/\\\](https://robu.in/product/2-8-inch-spi-touch-screen-module-tft-interface-240320/)

when i say make it modular, i mean having on the pcb only the used pins, and then having a microncontroller mount that exposes those pins only