3 ms·
Hey - I ordered a board yesterday. I used Opus 5, Astra, and Sol at points to QC the board, and offer power routing advice. (The MCU is a brand new one, and poo
by the__alchemist 9d ago
Hey - I ordered a board yesterday. I used Opus 5, Astra, and Sol at points to QC the board, and offer power routing advice. (The MCU is a brand new one, and poorly documented unless they send you an NDA and the full docs).
Those models were not capable of even schematic editing or building. (I didn't bother with routing or placement). They made gross errors all over the schematic; changed the known-working parts and net routing I'd copy+pasted from previous boards, changed I2C to SPI for no reason, and generally produced an unusable, unreadable result. Overlapping symbols and labels etc.
- Neywiny 9d agoWhat do you mean by power routing for an MCU? Like they wanted to fatten the traces or what?
- the__alchemist 9d agoIt's an Atmosic Atm3430e, which includes RF energy harvesting. So, I'm using 3 power sources depending on the application: Coin cell, USB, and RF, with a 1v8 net for sensors. Its power pin routing has some particulars that are poorly documented, and there are no publicly available reference designs. There are a few design docs which help, but leave open questions. So, I used LLMs to help me figure out which pins to connect to which. They did not seem capable of actually doing the work directly, but they answered my questions. We will see how correctly in a few weeks... Also used LLMs to try to figure out how to flash/debug it. The setup I normally use (Tac-Connect ST-Link 6 pin + Probe-rs) won't work here; it's cortex-m, but their official guides indicate they want you do use a Segger J-Link, which I'm not ready to pay for at this point. It is a very expensive thing. So I'm going to try an NXP MCU-Link Pro. The St-Linkv3 I've been using will likely not work.
- Neywiny 9d ago?? I found the schematic here https://atmosic.com/products_kit_atmevk-3430e-yqn/ https://atmosic.com/products_kit_atmevk-3430e-yqn/ Is this not it? They even have the .pcb file if you download the full board doc which I believe is everything you need. This is a lot more than I thought you'd have to work with given your description. Full schematic, user guides, datasheet
- the__alchemist 9d agoHoly shit, I don't know how I missed that. Ty! I must have been only looking at the bare parts docs and not the DK.
- Neywiny 9d agoLol all good. Please use this instead of slopping up something that'll let the smoke out
- HerAnt 9d agoThis is amazing for people who don't know anything about it, while it's exactly the opposite for those who do
- johnboiles 9d agoWhat PCB software did you give it? I'm having great success with Fusion (formerly known as Eagle) and others seem to be doing great with KiCad.
- the__alchemist 9d agoKiCad 10
- tonyarkles 9d ago> changed I2C to SPI for no reason Heh, tongue firmly in cheek: there's a good reason to change from I2C to SPI. I2C's pretty shit in comparison :D More seriously, I've had interesting mixed results. I had a hobby-maybe-commercialize-next-year Christmas lighting project that I started in March (if I start in March, this will definitely be ready for Christmas!) and got 90% of the way there... and then life got busy and it's sat there untouched with the holiday season coming up again quicker than I'd like. I threw Fable at it first to assess what's done, not done, look for schematic mistakes/improvements (it rightfully pointed out that the cheap LDO I was using was near its limits and suggested a better part). Opus did a reasonable job of swapping out the LDO, putting reasonable values on all of the pull-ups/pull-downs, etc. Some of the labels did end up in slightly weird places and needed some manual correction. It also did a decent job of floor planning on the PCB side, but pretty much refused to do any routing other than power traces. I've installed https://github.com/drandyhaas/KiCadRoutingTools https://github.com/drandyhaas/KiCadRoutingTools this morning after seeing this article last night... we'll see how this goes. My first manual attempt at running the router did decent but it failed a bunch of DRC spacing rules and insisted on via-in-pad to make it all work. That's, I think, a side effect of Opus's floor planning. It's interesting to play around with to see what's good and not.
- the__alchemist 9d agoI should try that lib! (Same one mentioned in the article?) I should also give layout/routing a try. My thought was, schematic design, from the perspective of what LLMs are good at, seems like the much more appropriate/easy tasks, so if it's failing at the basics there... I think I also experienced some consternation at patterns I've seen in real PCBs like a section dedicated to bypass caps that have no context of what pins they go to. (e.g. power connected to ground). And I gave it a board that had a mixed of components/routing that I have used successfully one or many times, and parts that I am unsure about/don't know how to use and wire. Me seeing it make substantial changes to the known-working parts (My stake-in-the-ground), I got very nervous!
- tonyarkles 9d agoYeah it's the one mentioned in the article. I've tried FreeRouting or whatever it's called before and had... ok results... but it's a pain in the ass to set up. This KiCadRoutingTools code was super easy to set up in comparison. Edit: actually, one interesting thing to consider about routing vs. schematic design: my general experience with LLMs is that things work best when there's a feedback loop. On the schematic side, there isn't really much of a feedback loop; nothing will tell you that you've e.g. flipped the + and - terminals of your Opamp. On the layout side, you've got the ratsnest and DRC to tell you whether you're winning or not. That might be the key to making LLM-based routing work. Opus refused to hand-route my whole board yesterday but is currently using the KCRT tools to do the routing and things seem to be progressing well.