April 25th, 2025

I Designed My LED Matrix PCB with Code Instead of Traditional EDA Tools

The tutorial explains how to build a 3x5 LED matrix with a Raspberry Pi Pico, featuring WiFi control, individual LED management, and a web interface for remote operation and monitoring.

Read original articleLink Icon
FrustrationSkepticismInterest
I Designed My LED Matrix PCB with Code Instead of Traditional EDA Tools

This tutorial outlines the process of building a 3x5 LED matrix controlled by a Raspberry Pi Pico using the tscircuit platform. The LED matrix can serve various purposes, including signage, data visualization, and interactive notifications. Key requirements for the matrix include WiFi control, a grid-based layout, and individual LED control for brightness and color. The matrix connects to the Pico microcontroller via a data chain, utilizing WS2812B IC LEDs for simplified wiring and serial communication. The tutorial details the steps for importing the necessary components, chaining LEDs, and connecting the Pico to the matrix. A grid function is employed to create the matrix layout efficiently. The PCB layout is also discussed, specifying the physical positions of components. Finally, the LED matrix can be controlled through a web interface that allows users to interact with individual LEDs and monitor the matrix state via REST API endpoints. The complete implementation, including the web interface and code for the Pico W, is available in the LED Matrix Server repository.

- The tutorial provides a step-by-step guide to building a 3x5 LED matrix with a Raspberry Pi Pico.

- WS2812B IC LEDs are used for their ease of wiring and individual control capabilities.

- The matrix can be controlled remotely via a web interface and REST API.

- The PCB layout and fabrication files can be ordered through JLCPCB.

- Practical applications include signage, data visualization, and notification systems.

AI: What people are saying
The comments reflect a mix of opinions on the tutorial about building a WiFi-controlled LED matrix with a Raspberry Pi Pico, particularly focusing on the challenges and limitations of current PCB design tools.
  • Several commenters express dissatisfaction with the routing quality and overall effectiveness of the tools discussed, suggesting they complicate rather than simplify the design process.
  • There is a recurring theme of frustration with code duplication and maintainability issues in the examples provided, indicating a need for better abstraction and API support.
  • Some users share their own experiences with alternative methods and tools, highlighting the potential for automation but also the limitations of current solutions.
  • Comments reflect skepticism about the future of "circuits as code" and the integration of AI in PCB design, with some believing traditional methods remain superior.
  • Several users mention the therapeutic nature of manual design processes, contrasting it with the frustrations of automated tools.
Link Icon 14 comments
By @synapsomorphy - about 9 hours
Atopile is another thing in the circuits-as-code space: https://github.com/atopile/atopile

As a half EE/half SWE I think there are significant benefits to circuits as code but I'm not impressed with this one. Atopile has a narrower focus (autorouters are really really hard) and doesn't use as many buzzwords. Like why on earth does a "web first approach" matter at all for hardware development?

But also, GUI tools are getting better, Kicad 9 had a lot of changes that made templating / reusing blocks easier. And it works fine if not great with version control.

I don't see circuit-as-code taking off with humans anytime soon, it's much better but not enough better to convince EEs many of which don't code much or at all. But I can see it becoming much more common as LLMs get better at complex circuits.

By @Neywiny - about 9 hours
Wish I could comment on the routing like others but the render is stuck at 96.2% for me. Nothing else on the page shows it on my phone so I assume that's the problem. (And of course nothing in the log of error tabs).

I think just looking at the first code example you can already see the problem. A lot of duplication and hand written or auto generated code. I thought the point was to define it in the code. Put an array of pin functions. For loop the footprint. That kinda thing. This looks like a mess to get started with and even worse is at higher point count parts it looks like it'll balloon in maintainability. Altium has very solid footprint generators with a nice menu. This looks like it's missing an overarching API for creating these long lists of parameters. Doesn't feel like the juice is worth the squeeze on this one. If it's a simple schematic, just do it by hand. If it's complicated, this feels harder to wrangle.

Another example of weird code is the previousLedName. Like like really that variable isn't used and the first term of the && should be that indeed check. But even more so, it should be an if statement not rely on remembering short circuiting (lazy evaluation) tricks. Because that's what you mean. You mean if it's not the first one, connect to the previous one. So, the code should say that. I find it hard to believe such a high level language would prevent it.

I think the pin label lists don't make sense. They're maps where the value is an array where the first element is the key? Why is this not just a list of pin numbers to names or a map of they're not contiguous whole numbers?

And then the icing on the cake: you still have to define where in XY everything is.

So really, in thinking about this, this looks more like a file format than a tool. And maybe that's fine. But I'll stick to the native formats of the tools.

By @alnwlsn - about 7 hours
A lot of deserved criticism in the comments here tonight, but more generally, I have to ask - what's the deal with all these code/text to CAD/PCB things?

There's a half dozen of them in any category, they are all different, they all seem to struggle badly with anything outside of simple examples, none of them appear to consider how things fit together in the real world, you almost never see any of them used for anything more complicated than a keyboard layout or an LED matrix, they all have reinvented the wheel instead of using industry standard formats, and they all talk about the "difficulty of using traditional tools" as though placing each XY point in space in your head is easier than dragging things around the screen like in MS Paint. You also never see any serious hardware people use them. Every one wants to do it all from keyboard to finished product instead of being satisfied as a intermediate tool that does one thing well.

But, they all have very polished documentation, they come with examples, they have nice looking websites, and it's obvious someone put a decent amount of thought into making them. It's not like they are useless either. Making a big grid of things? It's nice to be able to write an algorithm to do that instead of entering them by hand.

I brought this up in that post about the LLM to CAD thing the other day. It's like people keep saying "hardware is hard" but then keep trying to solve it like they would work on software problems.

By @sgnelson - about 9 hours
SVG PCB is a similiar concept. The nice thing is that it allows both code and gui manipulation of the design.

https://leomcelroy.com/svg-pcb-website/#/home

By @crote - about 10 hours
I'm genuinely surprised by how awful the resulting PCB is. A trivial LED matrix like this is pretty much the best-case scenario for tooling like this. Not being able to handle this is a pretty damning - although a decent bunch of the blame should probably be placed on whatever third-party autorouter they are calling out to.

Even with better results, the big issue with tools like these is that they simply don't match with the kind of development style that's needed for the problems at hand. You see the same issue with those drag-and-drop visual programming languages, or scripted modeling like OpenSCAD: they end up making fairly trivial details slightly easier, while significantly complicating the meat-and-potatoes. Nobody cares about a neat little part placement for-loop if it generates a living hell of autorouted spaghetti you can't possibly interpret and fix manually.

In reality the low-hanging fruit has already been covered by existing tooling. Automatically generating symbols and footprints from textual descriptions is routine practice, and software like KiCad already has a reasonably usable scripting API and a well-documented file format. A lack of code-based code-based EDA hasn't stopped projects like Ergogen[0] from popping up. The main limitation for additional automation is a lack of reliable input data, and user-side tooling can't fix that.

[0]: https://docs.ergogen.xyz/

By @imrishabh18 - about 12 hours
I built a WiFi-controlled RGB LED matrix using tscircuit, a library that lets you design PCBs with JavaScript instead of traditional CAD tools.
By @whartung - about 10 hours
I took a stab at something like this. My intent was that you’d be sitting at a Common Lisp REPL, and start entering commands.

As you did this, a graphical window would show your components and traces. I considered similar to a legacy AutoCAD, way back before pointing devices were commonplace.

I had a whole simple dialect to easily identify traces, which you would continuously split with points, then nudge them around or anchor next to other points.

I honestly felt, especially for the small board project I was working on that writing this from scratch would have been faster than fighting KiCAD or any of the similar tools.

But I was stymied with finding a good way to get graphics out of CL on my Mac. I even considered doing it all in SVG with some kind of auto reloading file, and just rewriting it each time.

Obviously I did not put a lot of effort into it, had enough friction to move on to something else.

By @zjorzzzey - about 9 hours
Interesting, reminds me of a project my colleague has just been working on: using KiCad + python to auto-place LEDs at specific coordinates on a PCB. Instead of positioning them as a regular matrix, the LED locations are derived from the shape of a racing circuit: https://ledsrace.at/zandvoort (routing and non-LED part of the layout was still done manually)

I don't think 100% auto-placement/routing will be able to take over manual layout, but there is definitely lots of potential for further automation!

By @boznz - about 10 hours
I guess it kind of works, but why would you? I find it quite therapeutic designing PCCB's. My last try at getting AI to draw a circuit diagram was actually quite hilarious: https://rodyne.com/?attachment_id=1753
By @0xFF0123 - about 9 hours
By @mschuster91 - about 11 hours
If I understand this correctly, in the end, JS/TS is being used only as a template language (similar to React, Lit, ...) to render out XML that is then picked up by a router and rendered out into something a PCB fab shop can use?

Nice idea.

By @convolvatron - about 10 hours
i scaned the article but didn't see this. declarative netlist is probably ultimately the right thing. but one place where I got alot of leverage was writing generators for footprints. its so much nicer to say 'this pad is 0.8 x 0.3" and i'd like two rows of them separated by 4mm with a 1mm pitch than to draw little rectangles with the mouse and getting them all to line up. i dont know if more professional tools do this, but integrating that into kicad made me much happier about the whole process.
By @bogantech - about 10 hours
Horrendous routing
By @mystified5016 - about 9 hours
Slightly tangential, but what's the state of the art in auto routing and placement these days? I haven't tried any since I used EAGLE a few years ago.

I know routing is one of those really hard problems, and for a long time they were all pretty bad at even moderately complex or constrained designs. Have things gotten better recently with the rise of machine learning? (Specifically not 'AI')