CYDs (and Vibe Coding)

Is this coding? It sure doesn’t seem like it, but it’s sure faster than the old way!

A working zero-shot vibe-coded Mandelbrot zoomer.
This was written entirely by GPT-OSS-20B from a single prompt, with no human-contributed code.

Since 2022 or so, we’ve learned that (since programming is at least partially a language-based task) large, multi-billion-dollar LLMs can often produce useful, working code. But we’re now getting to the point where even open-source language models that can run on consumer hardware can do useful coding work, at least if properly prepared.

I recently learned about a useful new ESP32 form factor that everybody seems to be calling the “CYD” (for “Cheap Yellow Display“.) It has all of the usual ESP32 goodies — a dual-core processor, 240MHz clock speed, WiFi, Bluetooth, and so on — plus a 320×240 resistive touchscreen display. It would make a nice modern thermostat or data readout or whatever.

When I work with new hardware or new languages, one of the first familiarization tasks I usually start with is to write a Mandelbrot viewer for it. 320×240 isn’t exactly High Definition, but with 16-bit color, it’s starting to be useful for graphical applications like this.

Instead of writing the Mandelbrot zoomer myself (I’m already familiar with Bodmer’s excellent tft_eSPI library), I decided to see how well GPT-OSS-20B would do with the task. Since local models may or may not have working Internet search capability, I decided to give it a primer. I asked GPT5.2 to write a simple demo sketch that listened for touch sensor input and then drew a green dot at that location, and also provided (in comments) syntax for other library functions. Adding this sketch into the prompt would show a local LLM how the graphics and touchscreen functions work, so they could be incorporated into new code. (After all, it’s a lot more reasonable to expect a model to know C than to be familiar with specific libraries.)

Here is the complete prompt (including Arduino skeleton sketch from GPT5.2) that I provided:

The following is an example Arduino sketch for an ESP32-based “CYD” dev board with a 320×240 pixel touchscreen display. Please create a Mandelbrot Set viewer with a touchscreen interface, using this exact board hardware setup as defined in the “BOARD-SPECIFIC CONSTANTS” section. Various methods for drawing to the screen and reading touch inputs are demonstrated and/or described in the comments. Use these functions to implement a Mandelbrot Set viewer. On reset, start with a view of the whole Set, zoomed appropriately. Once the Set is drawn and a point on the screen is touched, zoom in at a factor of 2.0 (in both x and y), centered on that point. Start with 100 iterations (settable by parameter) and increase as needed. Choose an appropriate color map that will be visible at high and low zoom levels. Use Float for the first 16 zooms, and Double thereafter. Track all position variables as type double. Thanks.

[skeleton Arduino sketch pasted into prompt; file available below]

The gpt-oss-20b model, running under Ollama with a 64k token context window, took about an hour to think about the problem. At one point, I was concerned that it was getting stuck in a loop (it went on and on for dozens of lines about “Now I need to think about X” and “Now I need to think about Y” — some of which made more sense than others. I decided to go watch some YouTube videos and wait to see what happened. After an hour or so, it finished and produced a plausible-looking sketch. I copied and pasted it into the Arduino IDE, hit Upload and waited.

It worked. I didn’t have to change anything. The touch inputs work correctly, the images are correct, and even the color map is appropriately-chosen and works at multiple zoom levels.

This is as big a change as going from machine code to assembly, or from assembly to higher-level languages. Maybe even more profound. We’re at the very least going to see the barrier to entry for writing code effectively removed, allowing anyone to code, and allowing existing engineers to focus on higher-level aspects of design.

And that’s the conservative, pessimistic view.

Posted in Arduino, C, Coding, Current Events, Digital Citizenship, Fractals, Machine Learning / Neural Networks | Leave a comment

Mini Museum: Cisco 2500 Router

“Well, that takes a lot of the mystique out of Cisco routers…”
–Frank Gentges, AK4R (upon seeing one opened up)

A Cisco 2500 router, resting on its removed cover to show the internals.

At one point, probably around the year 2000, it was said that every email (and anything else sent over the Internet) went through one or more Cisco routers. I believe it, at least given the market dominance Cisco enjoyed back in the early Internet days. No doubt, many exabytes of data have flowed through these Internet traffic-control devices.

IP routers are central to packet-switched networks. Working with routing protocols such as RIP and OSPF, they examine the addresses and subnet masks of incoming IP packets, and route those along to the next step. They would typically be paired with a CSU/DSU and connected to a 1.544 Mbit/sec T1 link (which was quite speedy for the time, but quickly got eclipsed once cable modems and fiber-to-the-home became popular. (Gigabit fiber is reasonably common in urban areas, today.)

Although the 2500 is (literally) a museum piece today — its 10BaseT Ethernet connection would be a huge bottleneck even for home Internet connections — the same important job is still being handled by thousands of similar, higher-speed devices. Packet-switched networks (of which the Internet is the poster-child example) do not create persistent electrical connections between nodes which need to communicate with each other. Instead, data is grouped into packets, which are routed node-to-node until they get to their destination.

(This particular router was pulled from service because it developed a problem with its persistent memory, and therefore won’t remember any settings. The company I was contracting for said to keep it.)

Posted in Digital, Internet, Networking, Nostalgia, System Administration, Tools | Leave a comment

Serial LED Matrix

Specialty chips like the MAX7219 can make visually-striking devices easier to work with. The ‘7219 is designed to drive an 8×8 matrix of LEDs, from a single SPI input. Additional modules can be easily added to the chain, allowing the creation of larger displays. A few helper C functions fold the pixels into the usual rectangular shape even if they’re not wired that way. With the SPI interface, updates are fast — at least several dozen Hz for four modules (32×8).

Four blue 8×8 LED modules.
(They’re blue, not pale-blue or white — but even the lowest brightness overpowers the camera.)
Each module sends excess data on to the next one.
The only limit (other than supply current, which could be supplied) is update time.

Weirdly, even though the modules are sold as (and work as) MAX7219 chips, the ICs themselves seem to have had any identifying markings removed. (The original seller photos show both Maxim-branded (now part of Analog Devices) as well as the anonymous chips.)

The product listing says it’s a MAX7219. It works like one. Why the obfuscation?

A basic Arduino sketch (tested on ESP32) is up on GitHub. I’ll probably add digits next, if there isn’t a library already out there, suitable for these. They’d make a good compass display for the Santana.

Just don’t try to take a picture of them without strong lighting…

This isn’t how it looks IRL either, but it gives you an idea of the level of blue. At low brightness.
Posted in C, Components, Electronics, Toys, User Interface Design | Tagged , | Leave a comment

Bus Prognosticator

I recently came across an “ESP32 SEPTA Bus Monitor” project that would query a SEPTA Transit API and update a large scoreboard-like display with information about the predicted arrival time of the next SEPTA bus. Since project author [grandpasquarepants] lives right next to a bus stop, this format is perfect to be able to not only see when the next bus will arrive, but share this information with other riders.

I live half a block from my bus stop. It’s too far to be in easy sight from the bus stop, but a similar clock would be a useful addition to my entryway, helping me decide whether to walk or to wait for the bus when I head out. (If it’s more than a ten-minute wait, I’ll get to work faster by walking.)

So I asked GPT5.1 to take a look at the original ESP32 SEPTA Bus Monitor site and modify the code to simply print out the information to the serial port, as a test. After adding in my WiFi credentials to the sketch, this worked quite well, and a few prompts later, I had the world’s weirdest wall clock…

The Bus Prognosticator. (Now if only there were a bus inbound…)
Eventually, a bus is inbound!

When one or more buses are inbound to the stop, the estimated time to the first bus to arrive is displayed. Sometimes there’s an incoming bus and therefore a time displayed, sometimes not. When there is, it usually counts down (bus making forward progress) but sometimes stands still (bus stuck in traffic) or even counts up (I don’t want to know.) The script can be modified to show buses in both directions; as it is, it only shows inbound buses (towards city center), since that’s all I use the bus line for.

Here’s the Github, including source code and .stl files for the wall-mount case, as shown. It seems pretty reliable, if you leave a minute or so slack. Enjoy!

Posted in 3D Printing, Arduino, C, Networking, Projects, Tools | Leave a comment