правильная организация библиотек kicad

У одного символа может быть несколько футпринтов, одному футпринту могут соответствовать несколько символов.

Как у тебя дела обстоят спустя год? Разобрался:)

фигово. Завел репозиторий, на каждый компонент (символ, футпринт, 3д-модель) — своя ветка. Когда рисую какую-нить поделку — сливаю необходимые ветви.

Говно все это. До DbLib альтиумовских тут срать и срать.

Странно, видимо так и не договорился ты с ним. У меня локально одна глобальная библиотека с тремя папками components, models, package3d лежит и проблем никаких нет. А в том, что модель, компонент и футпринт не привязаны друг к другу - весьма огромный плюс зачастую. Может попробуешь на свежую голову еще раз?

еще раз. У альтиума тоже символ, футпринт и 3д-модель не привязаны друг к другу. Но есть сущность, которая их объединяет (DbLib, IntLib — кому как нравится. DbLib может вообще представлять собой линк на csv-файл, в котором прописано, какому партнамберу что соответствует).

Когда ты идешь на тот же digikey — тебе надо знать partnumber, а не мифические связки из названий символа и футпринта.

Другой пример — у меня в альтиуме есть библиотека для резисторов и конденсаторов для поверхностного монтажа. В partnumber забиты данные про номинал, размер и точность (типа RES-1k-0402-5%). И это удобнее, чем держать в голове весь ряд E96.

Понимаешь, одно дело — поделка с десятком разных типов компонентов, их можно и в голове держать. Когда их количество измеряется сотнями — волей-неволей захочешь, чтобы BOM требовал минимально редактирования.

Ты требуешь от кикада быть альтиумом и вести себя как альтиум. Не будет этого, он другой. И BOM-лист там по-другому используется. Это всё равно, что от убунты требовать быть вендой и вести себя как венда. Если нужен альтиум, пользуйся им, если хочешь пользоваться кикадом, нужно просто немного переключить мозги с привычного.

я иногда смотрю, что они с кодом творят. В общем, пока что складывается ощущение, что они движутся в никуда. Разрозненные форматы хранения данных (зачем-то для футпринтов — s-exp, для символов — текстовый велосипед), непродуманный API (который еще и ломают в два счета — а на него у меня свои «инструменты» привязаны). Питон у них — тема для отдельного баттхерта. Зачем они вообще его в таком виде туда завезли — мне непонятно. Ничего с его помощью сделать нельзя.

Вот не покидает меня ощущение, что пишут его лебедь, рак и щука.

На самом деле, когда я переползал на кикад, то первое на что я обратил внимание - это его достаточность для практически любого проекта. Да, есть некоторые сложности, но и сталкиваешься с ними не то что не каждый день, а раз в пятилетку. Во всем остальном кикад скорее подкупает тем, что в нем вполне все можно под себя сделать. Тот же вом-лист вполне может тебе выдавать и партнамбер и даже группировать по нему лист, вопрос в содержании этой информации в посадочных местах. Да, в альтиуме это сделали за тебя, а кикад требует чтоб это сделал ты. Собственно вся проблема только в этом по сути, других нет. Понимаю, не хочется заморачиваться, но опять же, есть куча очень неплохо переработанных библиотек не из кикадовского гита, никто не запрещает их использовать. Сейчас я лично привык к кикаду и понял основную проблему любого софта - привычка юзера, зачастую перерастающая в синдром утенка. Как уже сказали, нужно было просто переключить мозги и поиграться с софтом немного, все становится на свои места.

я иногда смотрю, что они с кодом творят.

Да в общем-то в порядок приводят. Иногда почему-то окольными путями, это да, но в целом картина выстраивается приближающейся к логике.

складывается ощущение, что они движутся в никуда.

У меня лично другое ощущение: они стремятся к максимальной кастомизации пользователем своего инструмента. Как говорится, добро пожаловать в мир открытого софта. Много не сделано не из-за лени разработчиков, а для того чтобы пользователь допилил это сам. И именно это самое классное, что кикадовцы не ведут меня к чему-то конкретному, по сути загоняя в рамки, а скорее дают велосипед, руль и педали крути сам куда хочешь. Пока им это удается.

непродуманный API (который еще и ломают в два счета — а на него у меня свои «инструменты» привязаны)

Было дело. Но согласись, что проблемы возникают все-таки реже. Так что я скорее вижу в этом движение в сторону именно стабильности, а не ломкости.

Питон у них — тема для отдельного баттхерта. Зачем они вообще его в таком виде туда завезли — мне непонятно. Ничего с его помощью сделать нельзя.

Не совсем тебя понял. А что именно не получается и в каком таком «не таком» виде там питон? Можешь пример какой-нибудь привести?

Да, гитхаб — это полный трешняк. К счастью, все можно скачать и локально использовать, что я и сделал.

Но все равно, лучше по максимуму футпринты и элементы хранить в директории с проектом, потому как в следующей версии может оказаться, что в "стандартных" футпринтах и либах чего-то не хватает. И опять придется рисовать... Уже напарывался на такой косяк.

А жестко связать компонент с футпринтом у тебя не получится: ведь многие вещи идут в куче разных исполнений. Особенно пассивка всякая.

Насчет 3D-моделей — на кой черт оно тебе нужно?

Зато все хранится в текстовых файлах, и ты спокойно можешь нужный функционал добавить хоть баш-скриптами!

Кстати, fped с новым способом хранения футпринтов не работает, это печально.

Насчет 3D-моделей — на кой черт оно тебе нужно?

Часто при дизайне корпуса нужно экспортировать 3D-модель платы (иногда даже с правильной высотой всех конденсаторов), чтобы посмотреть, как она входит, а если не входит, что нужно сточить и где резать отверстия для портов.

Насчет 3D-моделей — на кой черт оно тебе нужно?

Для дизайна устройства. Проектируя корпуснужно понимать что там как будет сидеть. Особенно если корпус особо выпендрежный и платы приходится делать многоэтажными. Бывало у меня такое. Для домашних поделий оно не нужно конечно, а даже при мелкой серии уже понимание нужно иметь, а при крупняке и подавно.

Да, гитхаб — это полный трешняк.

Да он собственно как свалка и задумывался. Первым делом выкачиваешь/генеришь то, что тебе нужно, а потом только заглядываешь периодически, не появилось ли чего интересного.

Но все равно, лучше по максимуму футпринты и элементы хранить в директории с проектом, потому как в следующей версии может оказаться, что в «стандартных» футпринтах и либах чего-то не хватает.

Черти когда собрал себе библиотеку и так и таскаю с компа на комп или на серваке держу. На гитхаб хожу раз в трехлетку поглазеть нет ли чего нового. Прямо с проектом держать библиотеку не нужно, достаточно одной глобальной. Главное сохранять бэкапить на будущее.

для меня ценность python api представлял бы, если бы на нем можно было писать интерактивные скрипты для работы с печатной платой, если бы все действия, которые я могу сделать через гуй, я мог бы выполнить и из скрипта. А получается какая-то фигня.

Например, мне хочется выполнить какие-то действия над текущим выделением, а через api к selection manager'у никак подлезть не получается — тупо не реализовано. А крестовый код, как я уже отметил, они регулярно ломают.

если бы все действия, которые я могу сделать через гуй, я мог бы выполнить и из скрипта. А получается какая-то фигня.

Да, здесь я с тобой соглашусь. Пока что, увы, все так. Просто не каждый день я стремлюсь автоматизировать трассировку плат или что-то еще, ручная трассировка как-то скорее вопрос душевного спокойствия.
С другой стороны сделай все-таки скидку для софта, который сильно младше того же альтиума, так еще и разрабатывается по сути на голом энтузиазме. Мне лично хочется верить, что кикадовцы все-таки смогут довести его до ума. На сайте они кстати весьма серьезную задачу перед собой продекларировали. Хотят полноценно встать в один ряд с альтиумом. Будем посмотреть)