"Vibe coding" Spin with Gemini

Jeff Haas · 2025-04-25 07:06

I've been working with LLMs out there in my regular work, and since the Open House is coming, I thought it might be fun to try working with Spin and seeing what one of them can do. Since Spin has been out a long time and the OBEX is up on GitHub, I figured that everything in it has been absorbed. On the other hand, I've also found that projects not using common web languages run into all kinds of problems pretty quickly.

My demo idea was to use an ultrasonic distance sensor, and a strip of Neopixels. The Neopixels start out all lit up, and as you move your hand closer to the sensor, they turn off - kind of a manually controlled bar graph.

First I tried Claude. Ugh, it had a hard time getting Spin right. Eventually it got late and I gave up.

A couple of nights later I tried Google's Gemini in Google AI Studio. It also struggled, but was much better about understanding its errors and fixing them. I started with having it read the ultrasonic sensor and display the distance. It had to fix three bugs, like this one:

Error: Expected a constant, unary operator, or "("
On this line: US_PER_TICK = 1_000_000 / clkfreq

It did it pretty fast and then the code worked - the ultrasonic sensor shows the distance on the PST.

So it was onto the Neopixels. It struggled with getting it right - until I gave it the current version of jm_ws2812b.spin from the Obex by pasting it into the chat. Then it analyzed it and did a new version of the Neopixels, and got it right.

Finally I asked to combine the two:

Use the Ultrasonic sensor to read the distance and light up the string of 8 Neopixel LEDs. The ultrasonic sensor should read a hand at 1 meter, and light up the entire string of Neopixels. As you move your hand closer to the ultrasonic sensor, the Neopixels follow it and turn off from the farthest point. So the effect is that the line of lit Neopixels gets shorter as you move your hand closer to the ultrasonic sensor.

And it got that right.

This is currently sitting on my desk and is fun to play with. Anyone want me to bring it to the Open House?

mpark · 2025-04-26 00:59

@"Jeff Haas" said:
This is currently sitting on my desk and is fun to play with. Anyone want me to bring it to the Open House?

Yes! I haven't exactly welcomed our AI overlords, but I'd like to see what you've done

macrobeak · 2025-04-29 01:03

I liked this part;
"So it was onto the Neopixels. It struggled with getting it right - until I gave it the current version of jm_ws2812b.spin from the Obex by pasting it into the chat. Then it analyzed it and did a new version of the Neopixels, and got it right."

The AI just needed some jm_ code to put it right!

JonnyMac · 2025-04-29 01:55

The AI just needed some jm_ code to put it right!

Jeff Haas · 2025-05-05 19:37

Follow-up to my talk at Propeller Day...

I picked up a Laser PING in the giveaway bin (version A, the old one) and decided to see how quickly I could get Google Gemini to convert the code from an ultrasonic sensor to the PING code.

It took very little time. I followed my own tips! (See the next post.)

These were the prompts:

This is working code for the Parallax Propeller 1 in SPIN. It uses an ultrasonic sensor to light Neopixels as the user's hand gets closer:

[Pasted working code]

This is a library for the Parallax PING sensor:

[Pasted the PING library for Spin]

And this is how you address the library:

[Pasted the demo code from the Ping download]

Now convert the first version of the code that uses the Ultrasonic sensor, to use the Parallax PING sensor.

Note that all of the above was done as one big prompt, before I hit CTRL - Enter to make Gemini read it and go to work.

It came back with code that added a reference to a method that doesn't exist in Jon's driver. Whoops! Here was my next prompt:

I forgot one library - this is the Neopixel library the original code used:

[Pasted jm_ws2812b.spin]

However...then Gemini replied:

The previously generated code using the PING))) sensor is already compatible with the jm_ws2812b.spin library you just provided. No further modifications are needed based on this library's details. The key elements (initialization, color format, update call) are correctly implemented.

So I said:

Examine the original code again. It works. The change you made to add ws.start is incorrect.

Then it said:

You are absolutely right! My apologies. My mistake was assuming a more common driver pattern where the main code explicitly triggers the data transmission. Thank you for pointing out the error.

It updated the code. And the code worked.

Total time: About 6 minutes.

Jeff Haas · 2025-05-05 19:42

Tips for working with LLMs:

You guide the LLM through the process of helping you code.
- Do NOT do “one-shot” code on a microcontroller.
- Give it an instruction and then test the result.
Know your fundamentals. You should be familiar with the parts of the project before starting.
- In this project, I already knew how an ultrasonic sensor worked, and how to control Neopixels.
Plan the project in steps.
Build the project in pieces.
- I originally had it do the ultrasonic code, tested it; then the Neopixel code, tested it; and then put the two together.
Feed clear information back to the AI when you get an error message.
- Copy the error message, paste it into the chat, and copy the line the error refers to.
Provide specific code you want used, such as a library.
- As above, give it the code you want it to use.

evanh · 2025-05-06 02:28

And also pay the actual electricity costs. Once the real costs are transferred, plus some profit, people aren't going to be so enamoured I don't think.

Honestly though, all that work to coax an unreliable output seems more like a burden than a benefit.

I guess that's what I've been saying all along though. Unless the LLM has already been fed all the examples you're wanting it to regurgitate, then it won't be any use.

"Vibe coding" Spin with Gemini

Comments