Building an Arduino Strip Chart with AI: Agency, Attribution, and Embedded Development

This is a case study exploring the utility of AI-assisted development for an embedded project. The strip chart recorder shown in Figure 1 is the final deliverable. The project features:

Key Takeaways

  • Attribution can be lost with AI-generated code.
  • The AI assumed tremendous design agency. The Figure 1 strip chart was produced with a single, highly underspecified prompt: “Need a dual color strip chart.”
  • The AI cannot see the project in operation. The programmer must be able to identify and explain the problem before it can be fixed.
  • AI produces faster code but reduces your exposure to the underlying program. The learning is in the journey.

Author: Aaron Dahlen | MSEE | Senior Applications Engineer, DigiKey
Last update: 30 Sep 2026


Figure 1: Arduino-based strip chart recorder.

AI Attribution and Open-Source Ethics

We need to be honest about what the AI did on this project. As a general statement, it leveraged code already produced by the community. As a specific statement, it grafted itself to Adafruit’s ST7735 library. This code has a MIT license and includes this statement:

Adafruit invests time and resources providing this open source code, please support Adafruit and open-source hardware by purchasing products from Adafruit!

In recognition of that request, Figure 2 shows the Adafruit 1.8 CLR TFT shield.

Figure 2: Image of the Adafruit 1.8-inch color TFT shield.

Getting Started with Hello World!

The initial setup consists of:

  • Collecting the necessary hardware
  • Installing the software
  • Mapping the pins for the Click display
  • Writing the Hello World! program (AI-driven)

Using the GPT-6.1 Sol (Medium), the initial setup took about 15 minutes. By far, the most time-consuming task was assigning the pins to the #2 socket (right-hand side of the Click shield). This task is simplified by using my pin map as shown in Figure 3, along with the Click board’s schematic.

constexpr int TFT_CS = 8;
constexpr int TFT_DC = 16;  // Click board pin RS
constexpr int TFT_RST = 3;
constexpr int TFT_BCK = 15;  

The only other noteworthy problem was an upside-down image. One prompt to the AI identified the required ‘tft.setRotation(2);’ statement. Yes, I could have found the prompt myself in the Adafruit library. Perhaps I should have, as this would have helped me understand the structure of the API.

Figure 3: Mapping of Arduino pins to the corresponding Click socket pins.

Display Images

As a next step, I directed the AI to display an image. The results are shown in Figure 4 where a DigiKey stock image of the Click display is rendered on the physical display itself. The AI accepted the original 640 x 640 image and converted it into a 240 × 240 RGB565 image for the IPS Display 2 Click. AI constructed a ‘.h’ file containing the image. It also recommended modifications to the main ‘.ino’ sketch.

This represents another 15 minutes of work.

Tech Tip: The resulting image is relatively large from a microcontroller perspective. In fact only one uncompressed image of this size may be stored in the Arduino Minima’s program memory. However, there are compression options. Observe that the chosen image has long runs of white pixels. Run-length encoding may be used to reduce the image size. This compression exercise may be an interesting experiment to explore with AI assistance. It would be instructive to compare the level of compression against the size of the necessary decompressing algorithm and its execution time.

This is also a good time to explore the difference between a microcontroller and a microprocessor. For example, the same Click display driven by a Raspberry Pi could leverage the Pi’s microSD card to hold thousands of images. We could envision a Pi-based music player where the album covers are displayed while the song plays.

Figure 4: Color image displayed on the Click board.

Strip Chart Development

This is the exact prompt I used to generate the strip chart:

Let's shift gears:

Need a dual color strip chart.

I was surprised when the AI responded with a dual_strip_chart.ino file. This is what the AI provided to my arguably underspecified prompt:

  • Red and cyan traces scroll left; newest readings appear at the right.
  • Samples every 200 ms, showing approximately 42 seconds of history.
  • Starts with simulated signals over a 40–140 °F range.
  • Uses your existing display pins and setRotation(2).
  • The two sample buffers use 1,680 bytes of RAM.

Full disclosure, my GPT is configured to track prior conversations. Last week I used the machine to edit this thermocouple article. The AI likely inferred a temperature-based system as well as my preference for the Fahrenheit scale.

Evaluating and Refining the Result

The display flickered badly as each frame update began by clearing the display to black before redrawing the components. With minimal prompting the AI recast the program to redraw smaller regions of the display.

This introduced tearing distortion. Recall that this is caused during a frame update when components from both the old and new frames are visible. This is aggravated by the update speed of the display. For context, I observed that it took about a second to load the color image pictured in Figure 4. The distortion becomes increasingly noticeable as the strip chart scroll speed increases.

My intended application has a sample rate of once per second. The tearing distortion is hardly worth mentioning.

Parting Thoughts

Returning to ethics, I do not know the source of the AI’s solution. Perhaps the strip chart recorder is a canonical design pattern. Then again, the AI may be leaning on a very specific program from an unnamed programmer who spent days carefully crafting this solution. If that is the case, I salute your work and thank you for your attention to detail.

The grid was a nice touch.

About This Author

Aaron Dahlen, LCDR USCG (Ret.), is a Senior Applications Engineer at DigiKey in Thief River Falls. His background in electronics and industrial automation was shaped by a 27-year military career as both technician and engineer, followed by over a decade of teaching.

Dahlen holds an MSEE from Minnesota State University, Mankato. He has taught in an ABET-accredited electrical engineering program, served as coordinator of an electronic engineering technology program, and instructed military technicians in component-level repair.

Today, he has returned to his home in northern Minnesota, completing a decades-long journey that began with a search for capacitors. Read his story here.