Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Hi HN, I am making progress working on Circuitscript, a language based on python to describe electronic schematics: https://circuitscript.net/. A basic IDE (called the Bench) to try Circuitscript is available online: https://bench.circuitscript.net/

In the last month, I have added support for more ERC rules (pin type compatibility checks), added initial support for net classes and also cleaned up the language a little (backslash line continuation, similar to python).

Recently, I just completed a 161-LED charlieplexed array design that uses nested for-loops to simplify the array design. It is currently in production and I plan to write a blog post soon to document this design.

As always, the motivation for creating Circuitscript is to describe schematics in terms of code rather than graphical UIs after using different CAD packages extensively (Allegro, Altium, KiCad) for work in the past. I wanted to spend more time thinking about the design itself rather than fiddling around with GUIs. With code, the design intentions become explicit and reviewable.

Feedback welcome, especially from anyone else frustrated with graphical schematic tools! If you have a KiCad design that you would like to convert to Circuitscript, please reach out to me as well and I will help you to do so as I am trying to challenge/test the limits of Circuitscript.

 help



Hey, I took a look at your project, I'm not someone who deals with schematics or KiCad but I'm still interested in these kind of things. I read the motivations in the docs and understood why would someone try to create a new language after looking at SKiDL, but still feels like it could've been simply a python library/package instead of having to do the work of creating a new language and having to deal with the language and interpreter/compiler. I'm sure a more object oriented approach would have made it a better experience to script schematics, specially with all the tooling Python has (such as `uv` to manage project, `ruff` to lint and format, etc). Regarding your language, just wondering why does led and supply need quotation marks but resistors and capacitors that some not only include numbers such as (10k) don't need to. It feels unnecessary to make that difference, specially for a script that tried to be simpler

Hi! Thank you for taking a look at circuitscript! Before creating circuitscript, I did consider using the SKiDL package as a circuit design tool, however even though I am familiar with python, the syntax for things like connecting pins was very strange (using the += operator). Moreover many of the existing code to schematics, including SKiDL, forces the designer to give up the actual layout of the schematic itself. As a electronics designer in my day job, a well organized schematic is very important to understand the overall design. It does not only show connections, but is also a map of the system. A poorly drawn map complicates system understanding and troubleshooting.

I'm not sure how an object oriented approach would make things easier for schematic generation. The objects (components) themselves do not undergo much data interactions/manipulations. Maybe if you have some examples, this would be helpful for me to understand. As much as possible I am leaning towards a more functional approach, where inputs, data transformations and outputs are more defined.

With a new language, I could decide features that I wanted and more importantly, include more circuit specific features (branch/join/parallel statements). Of course, a python library would be able to produce the same data representation that circuitscript ultimately generates, but one aim of circuitscript is to make it much easier to do so.

The standard lib provides led, supply, res and cap as component functions (basically normal functions that return a component). For LED and supply, they take strings as parameters, this defines the led color and the name of the supply net respectively. Res and cap take a number parameter like 1k, 1u, 100n, etc. Such number expressions are very common in schematics and CAD packages, so this is a important feature to support (python equivalent of using 1e3, 1e-6, etc.).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: