hpr-knowledge-base/hpr_transcripts/hpr4689.txt

Episode: 4689
Title: Cheap Yellow Display Project Part 8: Writing the code 
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr4689/hpr4689.mp3
Transcribed: 2026-07-31 16:16:49 (official HPR transcript)

---

This is Hacker Public Radio Episode 4689, for 2026-07-23
Today's show is entitled, "Cheap Yellow Display Project Part 8: Writing the code "
The host is Trey and the duration is 00:19:33
The flag is Clean, and the license is CC-BY-SA
The summary is "How we wrote the code to make this whole thing work"
Hello again, this is Tre. Welcome to Part 8 in my cheap yellow display project series.
If you wish to catch up on earlier episodes, you can find them on my HPR profile page,
and I'll post a link in the show notes. It is hard to believe that I started this project
and the HPR series to document it more than a year ago. Time flies. Life happens. I spent the last
eight months or so focused on work-related activities that I had to set aside the project.
And once I set it aside, it was difficult to get back to it again. The one time that I tried,
I found my son's old Windows laptop, which I had come and dared to use for this project,
was once and truly dead. We live in a different world now, though, then we were when I began this
project. Today, everything is about AI. How it is changing the world, increasing efficiencies,
and even displacing certain types of jobs. Vibescoding is transforming the way we make software,
and now everyone is a developer. Within my organization, we are all being strongly encouraged
to learn more about AI and apply it to our daily work. We are blessed to have access to a wide range
of training and to powerful tools which support the process. Several colleagues within my organization
and outside my organization have recommended Claude code for development, for organization,
for brainstorming, and for so much more, every time I turn around, you should use Claude code
for that. Now, my role in my organization is not that of a developer, so I have not had the need for
Claude code at work. There are plenty of other AI tools for me to use there. But at home, I thought
I could install Claude code at home to experiment with and to learn, and then it hit me.
I wonder if I could use Claude code to help me with my stalled, cheap yellow display project.
Hello, my name is Tray, and I'm a fraud. Okay, I don't think that I'm a fraud, but having never
used such a powerful tool to help me code, I feel a little bit like a fraud, and with Claude doing
the work for me, let's talk through the process of what we did. As I mentioned, I was unable to
use the laptop on which I had created the original GUI code, but no worries, because it was all on
GitHub, right? Right? So I began trying to install Claude code on one of my Ubuntu machines,
that failed miserably, and all the instructions I found online recommended running it on Windows.
So I transitioned to installing Claude code on a freshly built Windows 10 system,
using some old hardware, which will not support Windows 11. Surprisingly, it seems that Claude wants
to run within Ubuntu 4 Windows subsystem for Linux. Go figure.
Once I went through all the hoops for installing and setting up my basic subscription to Claude,
I got to work. I created a new directory to use for all of my project files, and another one
for Claude to write all its output files to. This way I had some protection on what it could
manipulate and what it could not. Everything I read about or heard about using Claude code
for projects like this recommended beginning by using Claude to create the project plan itself.
So my first prompt was as follows. Quote, I'm building a project using an ESP32 cheap yellow display.
The final goal is to have a device with a graphical user interface, which will allow me to store
several text messages. Each assigned to their own specific button. Then, when one of the buttons
is pressed, the message will be converted into Morse code, and the message will be sent by blinking
the onboard LED. I already have the initial design for the GUI coded into my GitHub repository.
Please construct a detailed step-by-step plan for building this application, unquote.
I wanted to keep it simple at the beginning, so even though we planned to use an
opto-isolated relay for the output, I'm starting out using just the built-in LED.
Claude asked me for the URL for my GitHub repository, and I provided it.
After thinking for a bit, it produced a project plan. I'll give you just the headers here
and some of the basic information, but you can read the full project plan in the show notes.
Cheap below display Morse code center, step-by-step build plan. What you already have.
Three, fully designed LVGL screens, send config, and keyboard. Seven send buttons with green
styling on the send green, a speed slider from 30 to 50 words per minute, and a program slot
drop down on the config screen. Text area and LVGL keyboard widget on the keyboard screen,
display driver and touch screen hardware initialized, but touch read was stubbed out.
Phase one. Fix touch screen input. Phase two. Persistent message storage. Phase three.
Config screen slot selection and speed. Phase four. Keyboard screen capture and save text.
Phase five. Morse code engine. Phase six. Non-blocking LED transmission. Phase seven.
Wire the send buttons. Phase eight. Integration and polish. Wow. That's a lot.
This was wild. Cloud determined exactly how far along in the project. I was and also alerted
me to the fact that the touch read was stubbed out. This means that the files that I uploaded
to GitHub were my original GUI files that you can hear about in episode five. HPR4532.
And they were not the ones that I finally got working properly in episode seven, which is HPR 4624.
That was my own fault. Did I mention that I don't get git? I really need to learn to properly use git.
But we have a plan broken down into eight numbered phases and they seem to address all the functionality I wanted
with a few additional things that I had not even thought about. Interestingly, even though these phases were sequentially numbered,
Cloud recommended that we approached them in a bizarre order. Phase one, then phase two, then phase seven,
partial. Then phase five, then phase six, then phase seven, full. Then phase three, then phase four, then phase eight.
All right. Let's see what we can do. The first phase is to fix the touch screen input.
Cloud took me through it, step by step, asking as it needed to read specific project files.
Finally, it wrote a new UI.ion.code file to my specified output directory for me to test.
I copied it to the correct file location, set a quick prayer compiled in the Arduino IDE and
downloaded it to my cheap yellow display. Well, that is interesting.
The display looked nothing like it was supposed to. There were vertical green bars with smaller
dashed green vertical stripes in them. I'll include a picture in the show notes so you can see exactly
what it looked like and why it was so difficult for me to describe here. And I spent the next
hour or so trying to explain what it was that I was seeing to a chatbot. That is thunder and
lightning. Very close. We'll continue recording. I spent the next hour or so trying to explain
what I was seeing to a chatbot. Cloud recommended potential fixes with either did nothing or made the
situation worse. I began questioning whether this really was a good idea. How people actually
gained efficiencies by talking to a bot and even several other life choices.
And then I had a thought. I prompted Cloud. If I were to take a picture of the screen on the
cheap yellow display and copy it to the output folder, would you be able to analyze it to better
determine what is wrong and how to fix it? Shockingly, Cloud answered in the affirmative and told
me to copy the picture to the output folder. And then it let me know when to press or then to let
it know when to proceed. Sorry, I was distracted by the clocks chiming. If you listen to any of my
previous recordings about clocks, and you heard both the kuhu clock and the shifts bell clock,
I bet you could determine exactly what time it is where I'm recording. Back to the recording.
Cloud analyzed the picture and more of the supporting files it had copied from GitHub,
asking me each time if it could access that file. It determined that my original code was written
for a flavor of LVGL version 8. And I was now using LVGL version 9.5, which was not completely
compatible. It recommended changes and then asked permission to make those changes.
File by file. h files and dot c files. Finally, I succumbed and I gave it permission to edit
all the files in the project folder without asking me for specific permission for each file each time.
Cloud was still explaining each change and showing me exactly what would be changed and asking
for permission to make the change so that I could review them. But now it was not asking additional
permission to write to each of the impacted files. Next, I compiled the code and downloaded it
to the cheap yellow display. Alright, it was a different screen but still not right.
Again, I took a picture of it and gave it to Cloud to analyze. So, Cloud paused and altered the code
to generate a specific test pattern over top of the GUI. The test pattern was supposed to cover
the entire rectangle screen. You can see the the test pattern in the show notes.
Parts of the pattern were in a square on the screen and parts were not. Another photograph
and analysis told Cloud that there was some rotation and screen size issues. We repeated this several
times. Some resulted in improvement and others did not. This is the point where I noticed something
extremely interesting. Not about Cloud specifically and not about the app. But I noticed something
interesting about myself and about the process. Previously, when I was working through some of
these challenges without Cloud, I found myself becoming more and more stressed, frustrated and angry,
until I found a solution. Then another problem would repeat the cycle. Success in the end was
great but the emotional extremes during the process were not always pleasant.
Now, I was effectively managing the project and relaying information to the resource responsible
for fixing the problems. This was a very different experience. But I also ran into another issue.
Cloud became absolutely certain that the problem revolved around the device not accurately
knowing where the four corners of the screen were. But in reality, the output of the test pattern
was rotated 90 degrees out of phase from the actual screen orientation. It took several iterations
of me insisting that the problem had to do with screen orientation and not corner coordinates.
It was interesting to experience the tool doubling down on an obvious mistake. But we finally
resolved that. Again, while it was frustrating, it was much less stressful. We proceeded to phase
2. This is the persistent message storage phase where we insured that the button labels on the
send screen were stored in the device's persistent storage so that when they were edited to contain
the messages they would send, that information would survive a reboot. I had not even thought
about this in my original ideas about this project. Next, we combined elements of phase 5, which is
the Morse code engine, phase 6, the non-blocking LED transmission, and phase 7, the wire and
send buttons all together. Building the Morse code engine was a night and area that I'd been thinking
about for a while. I already had working parts of something similar in the Arduino practice oscillator
I have referenced a few times in this series. The code for the practice oscillator may be found on
my GitHub, but it was all based on original code by J.M. Harvey 1, my only contribution being
making pin assignments variables so that the code could easily be ported to different devices.
So I was happy that we were building the Morse code engine directly. The code for it may be found
in the Morse.h file, which uses a constant character look-up table to define each character
without any specific direction for me, plot use the Paris timing methods I've already described
within episode 6 of this series. It defines timing for dot and dash and letter gap and word gap,
and all are based on a simple calculation of 1200 milliseconds divided by the number of words
per minute we wish to transmit. Along the way, we discovered that if we tried to use a delay function,
it would crash the program due to a conflict with the LVGL timer used for touch screen inputs.
Cloud altered all the delays accordingly. Then we worked on phase 6, which is the config screen
for slot selection and speed. This allowed us to actually configure the word per minute we wish to
use in addition to selecting a specific send button to configure. It also forced us to work on phase 4,
which is our keyboard screen, specifically the Capture and Save Text portions of it.
And these are used to type in the entries for each send button. At this point, I also decided
that I want to use the keyboard sent the keyboard screen to send ad hoc Morse code as we typed on it.
This was an additional thing that I added to the project plan. During this phase, we discovered
several bugs, which seemed to cause random freezes. Careful trouble shooting with the messages
output of the Arduino IDE's serial console helped us narrow down the causes and remedy them.
Finally, all the tests worked and I was able to merely pre-configure macro buttons with custom
messages and use the cheap yellow display to send Morse code for those messages to the onboard
LED at whatever rate I specified. I've noticed in my presentation of this narrative that I
repeatedly slipped into the first person plural terms we and us instead of the first person singular
terms I and me along with an impersonal it for Claude. I have unconsciously personified Claude
and recognized it as an integral part of my formerly one-person development team.
I finally configured Claude to connect to my GitHub repo and uploaded all of the files and documentation.
We additionally created a CYD-narrative Markdown file which describes in more detail all the work
that was done in this project. I still do not 100% get get but we are successfully using it.
You can find all these files on my GitHub repo where I've shared them under a GPL 3.0 license
and there's a link in the show notes. There are several additional steps I plan to complete in the
next few months. One, I will be integrating an optimized-related relay which will allow me to plug
the device into a straight key input for any amateur radio. This will require a battery power source,
a charge controller, and some more hardware. I, all right, make that Wii, Claude and I will be
modifying the code to support an audio side tone through an attached speaker when sending code.
We will add an output selection switch to the configuration page to choose any combination of
speaker, relay, and or LED as output. We will develop a downloadable firmware which I hope to
share on the cheap yellow display community. If you can think of any additional features you would
like to see integrated, please drop me an email using the email address in my HPR profile.
I may also work with a friend to attempt a 3D printed case for this entire contraption
and I will be sure to record additional episodes sharing that process.
I have learned so much throughout this project about the cheap yellow display, about ESP32,
about graphical user interfaces, about Claude code, about GitHub, and most of all about myself.
Does using AI to develop this code make me a fraud? I still, it still feels like it in some ways.
Does it make me more productive? Absolutely. I made consistent forward progress when I only had
30 to 60 minutes each day to work on it and everything discussed in this episode was completed within
less than a week. If I had been able to work on it uninterrupted, it may have taken me 3 to 5 hours.
Does using AI empower and inspire me to do more projects like this? 100%. I feel like I had
support working with me the whole way. I was less stressed overall and it had less of an impact
on the amount of and quality of time I spent with my family. I will be wrapping up this series soon
without any more six-month gaps I hope. Until next time.
You have been listening to the Hacker Public Radio podcast, at hackerpublicradio.org.
Today's show was contributed by a HPR listener like yourself.
If you ever thought of recording a podcast, then visit the HPR site to find out how easy it really is.
Hosting for HPR has been kindly provided by anhonesthost.com, the Internet Archive, rsync.net, and the HPR Community Content Delivery Network.
Unless otherwise stated, today's show is released under a Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.