141–150 of 300 posts
`import Y from X` is a terrible language design decision, established by the JavaScript ecosystem. It should be along the lines of `import X.Y` or `from X import Y` so that autocomplete tools can assist you.
Very nice! The state of electronics tooling has long been extremely bad - 99% of people who put a regulator into their schematic will want an appropriate input and output capacitor as the datasheet demands. 99% of people who put a microcontroller will want a crystal and a programming port and a reset pin pull-up. It's only because of closed source tools stuck in the stone age that the state of the art is to copy out…
Yeah, trying to learn KiCad is worse than learning Blender. If JLCPcb made a simple online editor that sourced from available parts and integrated directly with their store they'd be running out of banks to put their money into.
`import Y from X` is a terrible language design decision, established by the JavaScript ecosystem. It should be along the lines of `import X.Y` or `from X import Y` so that autocomplete tools can assist you.
`import Y from X` is a terrible language design decision, established by the JavaScript ecosystem. It should be along the lines of `import X.Y` or `from X import Y` so that autocomplete tools can assist you.
One small thing regarding the imports: If you plan to have some rich autocomplete functionality (which helps dicoverability of packages) it is better to have the source of something first and the imported stuff afterwards. Python - which you seem to draw inspiration from - does this as well:
from xy import z
I'll try this out, it looks very promising!
Earlier quoted context omitted.
look at OpenSCAD, it's a scripting language to generate models. I used this a lot to generate subpieces and build off of that. easy as saying Bolt("M5", 1.5) or something
As a regular OpenSCAD user, I wouldn't bring it up as a good solution for anything. It exists, you can solve problems with it, but it isn't a good design. It should just be a library in a real language.
The last thing I want to worry about is having malware in an M5 bolt.
Finally I can just install some package and have a spec-compliant ESP32 circuit which I don't have to copy from somewhere else. This is great. One small thing regarding the imports: If you plan to have some rich autocomplete functionality (which helps dicoverability of packages) it is better to have the source of something first and the imported stuff afterwards. Python - which you seem to draw inspiration from - doe…
Did you see the ESP32 in the package registry? https://packages.atopile.io
I think KiCAD gets a lot of things right. Some of the broken things:
parts management (There is no central repo, a la LVFS, where I can get a part/pinout/3d model to easily import)
export process (feels kludgey, although some manufactures take the native KiCAD files)
multiple users, same project -- it's hard to put artifacts into git and merge changes.
I see this solving the last issue, perhaps the second as well. Commercially, I think it is worth pursing the first.
Other thoughts:
When I spec parts for certain types of designs, I need a whole lot more than just tolerance. e.g, for a mlcc capacitor, I need to spec dielectric, voltage, tolerance, ESR, sometimes leakage. For resistors, inductors, and other jellybean parts, similar metrics apply. Specing active "common" parts (like bjt/fet, diodes, etc) has even more parameters to consider.
I would also love the ability to take a design and drop it into SPICE for simulation.
Congrats on the launch! Couple of quick questions: Are there any initiatives or resources planned for educational institutions to adopt atopile? Outside of GitHub, are there specific areas or tasks where you’re seeking community or volunteer contributions? Thanks!