Hacker News Reader

Comment by helpfulmountain | Hacker News Reader

I think this is a wonderful idea and begins to create a foundation of data richness and interoperability for a very exciting new approach to PCB design, as I commented elsewhere in this thread

However I do want to mention that I think it might be necessary to be able to "cross-compile" to visual schematic format, and back. Or perhaps there is an open schematic tool that can be extended?

The issue is that I think electrical schematics are significantly more familiar to EE types, contain more legible information. Instead of reinventing the wheel there, it'd be nice to see a system that can switch back and forth between text and visual schematic.

How are schematics described as files currently? Is there an open standard? Can it be converted to atopile format, and back?

View on HN

I was thinking the same thing (I'm an EE by day). I think this idea is very cool, but since the dawn of time schematics and PCB layout have always been visual because you are actually building a physical thing. Its easy to see hardware bugs in schematics visually. However, it might be very hard to track it in code, unless the code is one day smart enough to find the bugs for you. You have to hold more context in your head that you cant export to your visual senses when its written as code. You cant see the actual circuit flow.

edit: just wanted to double down on this being very cool though. i dont mean to deflate this project and I'm about to design a pcb for a personal project - I might give this a go for fun. the promise is there and asthe project and feature set grows i can see it being the way forward.

We do agree. We built an early version of a viewer in the project but later moved away from it because it wasn't good enough to interact with. We might come back to it with something that is more targeted at inspecting only sections of the circuit or provide a block diagram level representation. But we don't think that just outputting a schematic the way they look today is the right solution.

You might find this a stumbling point for adoption. My first thought is this could be a good tool for me to use, but how can I send a design to someone else to get feedback on if I’m not going to expect them to also also learn how to use this or how can I get my design manufactured if the tools can’t export out the, normally very visual, layout files.

I do think that is fair. The reason that we don't have a visualizer is not that we don't want one, but rather that the value to effort ratio is quite low (and really because the effort is high, not because of low value). I'm sure we'll get there at some point. But at the moment there are more pressing issues for the people who are ok dealing with no visualization (like typing, language server, equations etc...).

I’d definitely consider not letting some basic visual schematic outputs fall too far down the priority list.

A lot of existing EE is basically just the visual diagrams and a lot of existing EE people will expect the tools to give them the visual diagrams they work with somehow… like even just including the compiled schematic as an SVG in with the compiled outputs of netlist, gerber, etc… something that other software can be used to convert to PDF without extra complexity in your tool and can be used to interoperable with the existing talent pool of EE people who have not just no idea how to use your tool… but know how to read typical style circuit diagrams.

I worked on this for a little while myself.

It wasn't so much "pc board by code" so much, but it was more a "pc board by CLI" approach.

And by that what my goal was, was to offer primitives and utility functions that would build the board up over time, but it was to be done incrementally in a Lisp REPL.

My use case scenario, was ancient AutoCAD.

Back in the day, while you could hook up a tablet or other pointing device (I'm talking pre-mouse here) to make AutoCAD drawings, a lot of it was done simply through typing in commands, in AutoLISP.

(lineto 100 100) kind of thing. And the drawing would appear on the screen over time, you'd save the data model, and manipulated with the REPL. If you wanted 10 lines:

    (dotimes (i 10) (let ((x (* i 10)) (y 100)) (line x y x (+ y 100)))

(HN does not have a paren matching editor, apologies...)

Where it broke down for me was coming up with a graphic rendition using CL.

If emacs had anything reasonable regarding graphic support (its SVG support is Not Good), I'd have done it there.

Rethinking it, it just occurred to me I could have probably gone a good way using ABCL in a Java GUI shell.

But the key point is that I think using a REPL for building up something like a circuit can actually work, actually be efficient for users, especially if it's extensible (i.e. (defun grid ...) ). Especially a hybrid (like clicking on a line pastes an identifier into the REPL).

My experiences with KiCAD drove me down that mad hole.

I have found taking a 'functional programming' like approach, where you build up your circuit from small blocks with specific functions that are easy to hold in your mind and then building up by combining those. For example instead of sticking a bunch of resistors and caps in your top level file, you can abstract them into their functions like a filter, resistor divider etc. Very curious to get your thoughts on using the tool!

I agree - also an EE - and I think it is similar to 'programming music' packages like Sonic Pi. If you are used to reading and writing standard music coding will be an odd and difficult change. Right now we have a comfort for seeing the layout and such physically, and since that is how we manufacture it this is going to be an output anyway, but there is some future world where it is all put together automatically within the requirements we specify and we have an entirely new way of designing circuit boards. Each component would come with not only a footprint but an array of basic design implementations that would mix and match with others.. autorouting on steroids of sorts.

Yeah that’s an interesting aspect. We did implement a viewer very early on. And we then removed it from the project.

What we discovered is that:

- making a visual viewer is a non trivial endeavor. It takes a lot of time but the value add is marginal for an average viewer. - people tend to spend a lot of time making the viewer look good instead of improving the circuit

We think that in the long run, a viewer could be awesome to inspect what is going on or get a general understanding of the circuit. But it’ll be difficult to justify the time spent on it early on in the project.

Worth adding, we have found much higher returns building tools to solve the problems that a visualizer would normally help you with in other ways. For example ERC checking and modular abstraction of circuits. Working at a 'block diagram' level is much more intuitive than at the net level in my experience.

We also think that there might be better and more interesting ways to view your data, for example maybe you want to just see all the power paths through your circuit, or investigate how a signal travels from your input to your adc through filters, protection etc. Often on big designs these things might be strewn across multiple sheets and a bit hard to follow.

As a novice, a viewer would be really helpful to me to understand what it's actually doing. I did bookmark this for the next project I have in mind.

I am definitely curious for feedback from people after using it for a while. I felt the same in the beginning, but after writing a fair bit of it, I rarely find myself wanting it. I could imagine for more casual or new users it could be helpful at least for the transition.

Reply on news.ycombinator.com