Библиотеки компонентов для KiCAD, Как сделать и где взять ? Опции

[viknn]

Генератор eeschema-библиотек от А.Колодкина

Прикрепленные файлы

 kicad_libgen.zip ( 112.47 килобайт ) Кол-во скачиваний: 557
 KiCAD_libgen.pdf ( 136.44 килобайт ) Кол-во скачиваний: 970

 

[viknn]

Текущий сборник gost-библиотек на ftp://ftp.kicad.ru/pub/kicad/library/

[valber]

Генератор eeschema-библиотек от А.Колодкина

Ну существует этих генераторов , не мало

** Создаем УГО online
http://kicad.rohrbacher.net/quicklib.php
** Генерируем УГО из XML
https://github.com/AdharLabs/Kicad-tools/tree/master/libgen
** Создаем УГО с помощью list2kc
https://github.com/nekromant/list2kc

Сейчас статью про это пишу.

[tema-electric]

Если бы KiCAD работал как торрент-клиент, чтобы можно было через него библиотеки раздавать и искать у других пользователей...

[AVL]

Текущий сборник gost-библиотек на ftp://ftp.kicad.ru/pub/kicad/library/

Пока не изучал что это за библиотеки, но считаю есть смысл поместить их и другие ГОСТ-библиотеки в хранилище lp:~kicad-gost-committers/kicad/library
Есть возражения против этого?

[AVL]

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

Потенциальное хранилище lp:~kicad-gost-committers/kicad/library будет независимо от lp:~kicad-gost-committers/kicad/kicad точно также как и от lp:~kicad-gost-committers/kicad/doc. Независимы с точки зрения хранилищ. А с точки зрения "подгружаться безусловно" не совсем понимаю о чем речь. Если речь о штатных библиотеках, которые обычно устанавливаются при установке дистрибутива KiCad, так это определяет тот человек, который собирает этот дистрибутив. Откуда библиотеки возьмет, те и попадут в дистрибутив.

Варианты могут быть, например, такими:
1) lp:~kicad-gost-committers/kicad/library в виде ответвления от lp:~kicad-lib-committers/kicad/library с добавлением отдельных директорий ГОСТ-библиотек
2) прямо в lp:~kicad-lib-committers/kicad/library добавить отдельные директории ГОСТ-библиотек (пока не знаю как отреагирует команда kicad-lib-committers)
3) полностью независимый lp:~kicad-gost-committers/kicad/library
4) полностью независимый lp:~kicad-lib-gost-committers/kicad/library (создать отдельную команду kicad-lib-gost-committers со своими правами, хотя мне лично больше нравится вариант с командой kicad-gost-committers и для библиотек и для кода. Это если сравнивать только с пунктом 3)

[AVL]

Варианты могут быть, например, такими:
1) lp:~kicad-gost-committers/kicad/library в виде ответвления от lp:~kicad-lib-committers/kicad/library с добавлением отдельных директорий ГОСТ-библиотек
2) прямо в lp:~kicad-lib-committers/kicad/library добавить отдельные директории ГОСТ-библиотек (пока не знаю как отреагирует команда kicad-lib-committers)
3) полностью независимый lp:~kicad-gost-committers/kicad/library
4) полностью независимый lp:~kicad-lib-gost-committers/kicad/library (создать отдельную команду kicad-lib-gost-committers со своими правами, хотя мне лично больше нравится вариант с командой kicad-gost-committers и для библиотек и для кода. Это если сравнивать только с пунктом 3)

Прошу по возможности каждого указать какой вариант больше нравится.
Я отдаю предпочтение варианту №1 из указанных 4-х.

[mobidev]

Прошу по возможности каждого указать какой вариант больше нравится.
Я отдаю предпочтение варианту №1 из указанных 4-х.

Да, наверно вариант № 1 оптимальный, по крайней мере мне так тоже кажется, можно будет спокойно иметь
в одном флаконе и свежую ветку основных библиотек буржуинов и спокойно добавлять наши ГОСТовские.

Сообщение отредактировал mobidev - Jun 1 2013, 09:02

[Сергей Борщ]

Поскольку я пользуюсь только своими библиотеками, то мне совершенно все равно. Единственное, что меня беспокоит - чтобы не приходилось постоянно выкачивать совершенно ненужные мне библиотеки при обновлении исходников.

[IgorKossak]

Сергей Борщ, +1.
Основной напряг с библиотеками возникает только когда начинаешь работать в KiCAD. Потом, по мере наработки багажа, отвлекаешься на них всё меньше. Тем более, что в общедоступных библиотеках, как правило, нужных элементов процентов на 5, да и те приходится дорабатывать.
Единственную пользу в общедоступных библиотеках я бы видел в виде паттернов для PCB и в соответствующих им 3D моделях. К тому же, их многообразие на порядки меньше, чем у схемных элементов.

[AVL]

Поскольку я пользуюсь только своими библиотеками, то мне совершенно все равно. Единственное, что меня беспокоит - чтобы не приходилось постоянно выкачивать совершенно ненужные мне библиотеки при обновлении исходников.

Как я уже говорил, хранилище исходников программы и хранилище библиотек - это 2 независимых хранилища.
При выкачивании хранилища lp:~kicad-gost-committers/kicad/kicad хранилище библиотек, например, lp:~kicad-gost-committers/kicad/library не будет выкачиваться автоматически.
lp:~kicad-gost-committers/kicad/library нужно выкачивать отдельно и по желанию.
При подготовке дистрибутива принимается отдельное решение какую именно библиотеку поместить в дистрибутив. Либо дистрибутив с библиотеками - это вообще может быть отдельный дистрибутив.

Сергей Борщ, +1.
Основной напряг с библиотеками возникает только когда начинаешь работать в KiCAD. Потом, по мере наработки багажа, отвлекаешься на них всё меньше. Тем более, что в общедоступных библиотеках, как правило, нужных элементов процентов на 5, да и те приходится дорабатывать.
Единственную пользу в общедоступных библиотеках я бы видел в виде паттернов для PCB и в соответствующих им 3D моделях. К тому же, их многообразие на порядки меньше, чем у схемных элементов.

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

[Сергей Борщ]

При выкачивании хранилища lp:~kicad-gost-committers/kicad/kicad хранилище библиотек, например, lp:~kicad-gost-committers/kicad/library не будет выкачиваться автоматически.

Отлично. Только это меня и беспокоило - я совсем слаб в bazaar, поэтому смутил путь с общим "корнем".

[IgorKossak]

На сколько понимаю, имеется разрозненность библиотек в Инете, и большинство из них сырые, недоделанные. Нужно собрать все в одном месте (в хранилище), навести порядок, провести ревизию, устранить ошибки и т.д. В результате должна получиться максимально полная ГОСТ-библиотека компонентов, пригодная для каждого разработчика. Данную работу есть смысл выполнять общими усилиями.

Дело не столько в сырости библиотек (я имею в виду пока только схемные УГО), сколько в различных толкованиях изображений, допускаемых ГОСТом. И если на простые УГО типа дискретных элементов и несложных МС всё более-менее устаканилось, то в случае сложных микроконтроллеров я, например, не встречал ещё ни одного устраивающего меня варианта. Хотя, те варианты, что есть, тоже имеют право на жизнь и не противоречат ГОСТу. Здесь многое зависит от традиций и вкусов. Кто-то любит гигантские изображения со всеми выводами, даже четырёхсторонние, кто-то любит скрывать выводы питания. Кто-то любит делать многоэлементные гетерогенные компоненты. Кто-то указывает все возможные функции выводов, а кто-то только основные или по умолчанию. Вариантов здесь может быть множество, всем не угодишь. Поэтому результирующая свалка может быть огромной, а её полезность для данного конкретного разработчика - стремящейся к нулю, чем дальше - тем больше.
Кроме того, время разработки УГО для нового компонента (кои появляются чуть ли не каждый день, в отличие от типов корпусов) сопоставимо с временем поиска (и проверки) в общедоступной библиотеке.
PS. Недавно озаботился новым проектом на STM32F407Z. Сделал как обычно УГО со всеми функциями для выводов и сгруппировал по портам ввода\вывода. Положил этот УГО на схему и ужаснулся тому, что он занял половину площади листа. Пришлось переделать УГО под данный конкретный проект, в котором сгруппировал выводы пофункционально (Ethernet, USB, UART, ...) и указал только нужные функции (и номера портов). Жить стало значительно легче, площадь УГО уменьшилась втрое, читабельность увеличилась. Но пострадала переносимость. Для другого проекта придётся другой УГО делать. Ну и как бы мне помогла общественная библиотека?

[AVL]

Дело не столько в сырости библиотек (я имею в виду пока только схемные УГО), сколько в различных толкованиях изображений, допускаемых ГОСТом. И если на простые УГО типа дискретных элементов и несложных МС всё более-менее устаканилось, то в случае сложных микроконтроллеров я, например, не встречал ещё ни одного устраивающего меня варианта. Хотя, те варианты, что есть, тоже имеют право на жизнь и не противоречат ГОСТу. Здесь многое зависит от традиций и вкусов. Кто-то любит гигантские изображения со всеми выводами, даже четырёхсторонние, кто-то любит скрывать выводы питания. Кто-то любит делать многоэлементные гетерогенные компоненты. Кто-то указывает все возможные функции выводов, а кто-то только основные или по умолчанию. Вариантов здесь может быть множество, всем не угодишь. Поэтому результирующая свалка может быть огромной, а её полезность для данного конкретного разработчика - стремящейся к нулю, чем дальше - тем больше.
Кроме того, время разработки УГО для нового компонента (кои появляются чуть ли не каждый день, в отличие от типов корпусов) сопоставимо с временем поиска (и проверки) в общедоступной библиотеке.
PS. Недавно озаботился новым проектом на STM32F407Z. Сделал как обычно УГО со всеми функциями для выводов и сгруппировал по портам ввода\вывода. Положил этот УГО на схему и ужаснулся тому, что он занял половину площади листа. Пришлось переделать УГО под данный конкретный проект, в котором сгруппировал выводы пофункционально (Ethernet, USB, UART, ...) и указал только нужные функции (и номера портов). Жить стало значительно легче, площадь УГО уменьшилась втрое, читабельность увеличилась. Но пострадала переносимость. Для другого проекта придётся другой УГО делать. Ну и как бы мне помогла общественная библиотека?

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

Сообщение отредактировал AVL - Jun 2 2013, 14:39

[IgorKossak]

А вот УГО дискретных компонентов можно унифицировать и иметь отработанную библиотеку: транзисторы, диоды, резисторы и т.д.
Также можно попытаться все-таки выбрать какой-то наиболее универсальный вариант УГО для микросхем дискретной логики и тоже сделать отработанную библиотеку.

Именно об этом я и говорил. И такие библиотеки должны быть маленькими и их должно быть не много.