Conversation

Notices

1. Embed this notice
   Piotr Esden-Tempski (esden@chaos.social)'s status on Saturday, 17-May-2025 11:18:28 JST Piotr Esden-Tempski

   Updated my STM32 KiCad Symbol generator! It now generates the modern library format and uses alternate pin functions feature. I decided not to include the "all features listed" strings as I did in the past. (I might add them later as a dedicated alternate function.) This results in more compact symbols. Because it is my personal preference I keep the GPIO pin name in every alt-function. Give it a try, let me know what you think. #kicad #stm32 #opensource #mcu https://github.com/esden/stm32-kicad-lib

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Saturday, 17-May-2025 11:18:27 JST ✧✦Catherine✦✧

     in reply to

     @esden I really like the more compact symbols, the upstream policy feels like it results in less readable/usable schematics

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Saturday, 17-May-2025 21:50:41 JST ✧✦Catherine✦✧

     in reply to

     • cpresser

     @cccpresser @esden a few years ago I did an upstream-first approach with #glasgowinterfaceexplorer and it was really exhausting, i don't blame anyone obviously but it's also hard to justify the effort now that when i have even less to spare...

   • Embed this notice
     cpresser (cccpresser@chaos.social)'s status on Saturday, 17-May-2025 21:50:43 JST cpresser

     in reply to

     • ✧✦Catherine✦✧

     @esden @whitequark and quite important addition: upstream accepts maintainers.
     On boarding does work quite well an quick.

   • Embed this notice
     cpresser (cccpresser@chaos.social)'s status on Saturday, 17-May-2025 21:50:44 JST cpresser

     in reply to

     • ✧✦Catherine✦✧

     @esden @whitequark upstream accepts patches :)

     I am not involved in the stm32 libs and generators at all, so I am not sure what decisions were taken why.
     But we sure love feedback. It sometimes just takes really long for a maintainer to pick it up.

   • Embed this notice
     Piotr Esden-Tempski (esden@chaos.social)'s status on Saturday, 17-May-2025 21:50:46 JST Piotr Esden-Tempski

     in reply to

     • ✧✦Catherine✦✧

     @whitequark I agree, having only the intended function listed is better for readability. (I like also seeing the Port name too) I think they might have changed the policy at some point? Now the official symbols are so compact that only the GPIO name fits. (see pin 2 in the screenshot) Also they don't offer modularized symbols only the monolyths. (my generator creates both variants) I am sure I can continue improving my symbols to make the resulting schematic easier to read.

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Saturday, 17-May-2025 22:13:56 JST ✧✦Catherine✦✧

     in reply to

     • cpresser

     @cccpresser @esden fwiw I would have probably joined as a maintainer but I have no formal EE background and I've concluded that as a result of that I wouldn't be capable of decisionmaking that feels right to the rest of the KLC maintenance team

   • Embed this notice
     cpresser (cccpresser@chaos.social)'s status on Saturday, 17-May-2025 22:13:57 JST cpresser

     in reply to

     • ✧✦Catherine✦✧

     @whitequark @esden fair enough. The experience for contributors was not great and still can be improved.

     Early in the pandemic we were only about two active people.
     That is now way better! But still, some MRs will stay open for months without any activity.

     So we are looking to grow the team even more. And perhaps get rid of the backlog.

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Saturday, 17-May-2025 22:14:37 JST ✧✦Catherine✦✧

     in reply to

     • Lukas

     @karotte @esden I really should try Horizon EDA

   • Embed this notice
     Lukas (karotte@chaos.social)'s status on Saturday, 17-May-2025 22:14:38 JST Lukas

     in reply to

     • ✧✦Catherine✦✧

     @esden @whitequark

     FWIW, Horizon EDA handles this by making symbols expandable in width to accommodate longer pin names resulting from alternate functions: https://blog.horizon-eda.org/progress/2021/01/28/progress-2021-01.html#symbol-expand-preview

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Saturday, 17-May-2025 23:22:33 JST ✧✦Catherine✦✧

     in reply to

     • cpresser

     @cccpresser @esden I'm making this inference from the number of times I got told to refer to some obscure-to-me IPC standard in response to me making a decision in a footprint that seemed reasonable and fairly obvious; presumably people learn these things somewhere that I never have

   • Embed this notice
     cpresser (cccpresser@chaos.social)'s status on Saturday, 17-May-2025 23:22:35 JST cpresser

     in reply to

     • ✧✦Catherine✦✧

     @whitequark @esden While it might feel like that is a relevant to join the librarians team, it is not.
     I never finished my degree, and I don't know about everybody in the team. Some are still in their formal education.

     The important qualities we are looking for is communicating well and cursed knowledge of electronics. Programming an git skills are somewhat required, but not mandatory.

     You probably know this already, vendors don't care about standards, we just manage that mess. That's the job.

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Saturday, 17-May-2025 23:48:46 JST ✧✦Catherine✦✧

     in reply to

     • cpresser

     @cccpresser @esden oh I have access to a lot of standards, that's usually not the issue, it's mostly just the overwhelming amount of stuff to deal with. I might try contributing again, sounds like things improved since ~2018

   • Embed this notice
     cpresser (cccpresser@chaos.social)'s status on Saturday, 17-May-2025 23:48:48 JST cpresser

     in reply to

     • ✧✦Catherine✦✧

     @whitequark @esden while IPC is the industry standard, it is not common knowledge even for experienced EEs.
     Only a few people I know have actually read any of it.

     So for the librarians, we do training on the job.
     And we make mistakes, lots of them.
     But with reviews only a few bad ones make it into the release.

   • Embed this notice
     cpresser (cccpresser@chaos.social)'s status on Saturday, 17-May-2025 23:48:49 JST cpresser

     in reply to

     • ✧✦Catherine✦✧

     @whitequark @esden we try to put everything from the IPC7352 into KLC.
     It's quite shitty that the document itself is not publicly accessible.
     We now have a wiki as well, with best practices and explanation why the KLC rules are the way they are.

     I had the same experience as you when I started contributing. Rules that I neither understood nor could fully access.

     And we improving the KLC, but also need to take care of legacy stuff, migration paths and existing inconsistencys.
     Its a pain :)