Live data from Hacker News

I designed my LED matrix PCB with code

docs.tscircuit.com

11–20 of 68 posts

Re: I designed my LED matrix PCB with code

#12
post #9

Earlier 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

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.

Re: I designed my LED matrix PCB with code

#13
post #8

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…

(tscircuit maintainer here) It might be easier to think of tscircuit as an electronics CAD kernel. We're MIT licensed and web-compatible, so we would make a great foundation for people building new EDA tools or people who would like to generate electronics (think domain-specific tools, e.g. a website that allows you to quickly build a custom keyboard)

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

#14

Earlier 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.

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 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

#15

Earlier 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…

> 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.

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

#19
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.

Re: I designed my LED matrix PCB with code

#20
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.

Post reply on HN