I designed my LED matrix PCB with code
11–20 of 68 posts
Re: I designed my LED matrix PCB with code
#12Earlier quoted context omitted.
Honestly? I want a footprint editor with constraint-based modeling. The datasheets often show measurements like the horizontal distance between the leftmost side of the left-row pads and the rightmost side of the right-most pad, and the distance between the rightmost side of the left-row pads and the leftmost side of the right-row pads. Converting that into the stuff you need to enter in the editor (width of pad, dis…
tscircuit maintainer here, we actually do support constraint-based modeling for footprints, although we don't use it often because we also support "short string" footprints which are often faster https://docs.tscircuit.com/footprints/constraint
Also, for resistors, is there a chance for PTCs and NTCs? And would benefit IMHO from a variant="[zener, schottky, photo]" plus associated parameters for them.
Re: I designed my LED matrix PCB with code
#13I'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…
FWIW In this case I think this board called out to freerouting for the routing. Companies have reached out to us with autorouting APIs, so we'll support different vendors and hopefully allow enough constraint-specification for people to get good results. Autorouting is important for reusability, even if it's routing between manually-routed sections (e.g. fanouts)
Re: I designed my LED matrix PCB with code
#14Earlier quoted context omitted.
tscircuit maintainer here, we actually do support constraint-based modeling for footprints, although we don't use it often because we also support "short string" footprints which are often faster https://docs.tscircuit.com/footprints/constraint
What I'm missing is something like , just for generic connectors - say, . Also, for resistors, is there a chance for PTCs and NTCs? And would benefit IMHO from a variant="[zener, schottky, photo]" plus associated parameters for them.
Yes diodes should have variants, I was surprised this wasn't already in the spec and created an issue to add it: https://github.com/tscircuit/props/issues/211
Yes we would support PTCs and NTCs for resistors, in general anything that helps with simulation, part selection, design intent, functionality, placement or appearance is in scope.
Re: I designed my LED matrix PCB with code
#15Earlier quoted context omitted.
What I'm missing is something like , just for generic connectors - say, . Also, for resistors, is there a chance for PTCs and NTCs? And would benefit IMHO from a variant="[zener, schottky, photo]" plus associated parameters for them.
We think that intuitive element names should be added to the tscircuit spec, even if they're redundant/there are multiple ways to do something. Right now you would probably use a (very general purpose), but is a great proposal for an element. Yes diodes should have variants, I was surprised this wasn't already in the spec and created an issue to add it: https://github.com/tscircuit/props/issues/211 Yes we would suppo…
Definitely makes sense, the question IMHO is what is the best way to interface with existing parts libraries. Making up individual names for each of the probably hundreds of thousands of connector types is going to be a looot of work.
And then, to add insult to injury, for some connectors there are so many different sub-variants as well. RJ45 with and without magnetics (I see inductors and (auto)transformers aren't present at the moment either) and LEDs, USB-C with some connectors being flush with the PCB and others that are designed to be placed in a PCB cutout... or PCIe connectors which can be had in physically closed and cutout variants (aka, an x1 socket that accepts x4/8/16 cards).
I hate connectors, in case it isn't apparent :'D
> Yes diodes should have variants, I was surprised this wasn't already in the spec and created an issue to add it
Thanks!
Re: I designed my LED matrix PCB with code
#16I 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
Re: I designed my LED matrix PCB with code
#17Re: I designed my LED matrix PCB with code
#18Re: I designed my LED matrix PCB with code
#19As 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.
Re: I designed my LED matrix PCB with code
#20I 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.