viknn 0 1 апреля, 2013 Опубликовано 1 апреля, 2013 · Жалоба Генератор eeschema-библиотек от А.Колодкина kicad_libgen.zip KiCAD_libgen.pdf Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
viknn 0 2 апреля, 2013 Опубликовано 2 апреля, 2013 · Жалоба Текущий сборник gost-библиотек на ftp://ftp.kicad.ru/pub/kicad/library/ Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
valber 0 2 апреля, 2013 Опубликовано 2 апреля, 2013 · Жалоба Генератор 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 0 17 мая, 2013 Опубликовано 17 мая, 2013 · Жалоба Если бы KiCAD работал как торрент-клиент, чтобы можно было через него библиотеки раздавать и искать у других пользователей... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AVL 0 28 мая, 2013 Опубликовано 28 мая, 2013 · Жалоба Текущий сборник gost-библиотек на ftp://ftp.kicad.ru/pub/kicad/library/ Пока не изучал что это за библиотеки, но считаю есть смысл поместить их и другие ГОСТ-библиотеки в хранилище lp:~kicad-gost-committers/kicad/library Есть возражения против этого? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AVL 0 28 мая, 2013 Опубликовано 28 мая, 2013 · Жалоба Если эти библиотеки будут подгружаться безусловно при переключении на эту ветку - возражаю. Библиотеки - вещь несколько перпендикулярная к проекту. Думаю, для них стоит сделать совершенно отдельный и независимый репозиторий. Потенциальное хранилище 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 0 1 июня, 2013 Опубликовано 1 июня, 2013 · Жалоба Варианты могут быть, например, такими: 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 0 1 июня, 2013 Опубликовано 1 июня, 2013 (изменено) · Жалоба Прошу по возможности каждого указать какой вариант больше нравится. Я отдаю предпочтение варианту №1 из указанных 4-х. Да, наверно вариант № 1 оптимальный, по крайней мере мне так тоже кажется, можно будет спокойно иметь в одном флаконе и свежую ветку основных библиотек буржуинов и спокойно добавлять наши ГОСТовские. Изменено 1 июня, 2013 пользователем mobidev Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 136 1 июня, 2013 Опубликовано 1 июня, 2013 · Жалоба Поскольку я пользуюсь только своими библиотеками, то мне совершенно все равно. Единственное, что меня беспокоит - чтобы не приходилось постоянно выкачивать совершенно ненужные мне библиотеки при обновлении исходников. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
IgorKossak 0 1 июня, 2013 Опубликовано 1 июня, 2013 · Жалоба Сергей Борщ, +1. Основной напряг с библиотеками возникает только когда начинаешь работать в KiCAD. Потом, по мере наработки багажа, отвлекаешься на них всё меньше. Тем более, что в общедоступных библиотеках, как правило, нужных элементов процентов на 5, да и те приходится дорабатывать. Единственную пользу в общедоступных библиотеках я бы видел в виде паттернов для PCB и в соответствующих им 3D моделях. К тому же, их многообразие на порядки меньше, чем у схемных элементов. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AVL 0 1 июня, 2013 Опубликовано 1 июня, 2013 · Жалоба Поскольку я пользуюсь только своими библиотеками, то мне совершенно все равно. Единственное, что меня беспокоит - чтобы не приходилось постоянно выкачивать совершенно ненужные мне библиотеки при обновлении исходников. Как я уже говорил, хранилище исходников программы и хранилище библиотек - это 2 независимых хранилища. При выкачивании хранилища lp:~kicad-gost-committers/kicad/kicad хранилище библиотек, например, lp:~kicad-gost-committers/kicad/library не будет выкачиваться автоматически. lp:~kicad-gost-committers/kicad/library нужно выкачивать отдельно и по желанию. При подготовке дистрибутива принимается отдельное решение какую именно библиотеку поместить в дистрибутив. Либо дистрибутив с библиотеками - это вообще может быть отдельный дистрибутив. Сергей Борщ, +1. Основной напряг с библиотеками возникает только когда начинаешь работать в KiCAD. Потом, по мере наработки багажа, отвлекаешься на них всё меньше. Тем более, что в общедоступных библиотеках, как правило, нужных элементов процентов на 5, да и те приходится дорабатывать. Единственную пользу в общедоступных библиотеках я бы видел в виде паттернов для PCB и в соответствующих им 3D моделях. К тому же, их многообразие на порядки меньше, чем у схемных элементов. Преимущество хранилища как раз в том, чтобы можно было различным людям удобно и упорядоченно корректировать, улучшать библиотеки. В моем понимании, ГОСТ-библиотеки могут иметь (в идеале) только одно единственно возможное представление. И по идее любой сможет использовать такие библиотеки для любых проектов. На сколько понимаю, имеется разрозненность библиотек в Инете, и большинство из них сырые, недоделанные. Нужно собрать все в одном месте (в хранилище), навести порядок, провести ревизию, устранить ошибки и т.д. В результате должна получиться максимально полная ГОСТ-библиотека компонентов, пригодная для каждого разработчика. Данную работу есть смысл выполнять общими усилиями. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 136 1 июня, 2013 Опубликовано 1 июня, 2013 · Жалоба При выкачивании хранилища lp:~kicad-gost-committers/kicad/kicad хранилище библиотек, например, lp:~kicad-gost-committers/kicad/library не будет выкачиваться автоматически.Отлично. Только это меня и беспокоило - я совсем слаб в bazaar, поэтому смутил путь с общим "корнем". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
IgorKossak 0 2 июня, 2013 Опубликовано 2 июня, 2013 · Жалоба На сколько понимаю, имеется разрозненность библиотек в Инете, и большинство из них сырые, недоделанные. Нужно собрать все в одном месте (в хранилище), навести порядок, провести ревизию, устранить ошибки и т.д. В результате должна получиться максимально полная ГОСТ-библиотека компонентов, пригодная для каждого разработчика. Данную работу есть смысл выполнять общими усилиями. Дело не столько в сырости библиотек (я имею в виду пока только схемные УГО), сколько в различных толкованиях изображений, допускаемых ГОСТом. И если на простые УГО типа дискретных элементов и несложных МС всё более-менее устаканилось, то в случае сложных микроконтроллеров я, например, не встречал ещё ни одного устраивающего меня варианта. Хотя, те варианты, что есть, тоже имеют право на жизнь и не противоречат ГОСТу. Здесь многое зависит от традиций и вкусов. Кто-то любит гигантские изображения со всеми выводами, даже четырёхсторонние, кто-то любит скрывать выводы питания. Кто-то любит делать многоэлементные гетерогенные компоненты. Кто-то указывает все возможные функции выводов, а кто-то только основные или по умолчанию. Вариантов здесь может быть множество, всем не угодишь. Поэтому результирующая свалка может быть огромной, а её полезность для данного конкретного разработчика - стремящейся к нулю, чем дальше - тем больше. Кроме того, время разработки УГО для нового компонента (кои появляются чуть ли не каждый день, в отличие от типов корпусов) сопоставимо с временем поиска (и проверки) в общедоступной библиотеке. PS. Недавно озаботился новым проектом на STM32F407Z. Сделал как обычно УГО со всеми функциями для выводов и сгруппировал по портам ввода\вывода. Положил этот УГО на схему и ужаснулся тому, что он занял половину площади листа. Пришлось переделать УГО под данный конкретный проект, в котором сгруппировал выводы пофункционально (Ethernet, USB, UART, ...) и указал только нужные функции (и номера портов). Жить стало значительно легче, площадь УГО уменьшилась втрое, читабельность увеличилась. Но пострадала переносимость. Для другого проекта придётся другой УГО делать. Ну и как бы мне помогла общественная библиотека? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AVL 0 2 июня, 2013 Опубликовано 2 июня, 2013 (изменено) · Жалоба Дело не столько в сырости библиотек (я имею в виду пока только схемные УГО), сколько в различных толкованиях изображений, допускаемых ГОСТом. И если на простые УГО типа дискретных элементов и несложных МС всё более-менее устаканилось, то в случае сложных микроконтроллеров я, например, не встречал ещё ни одного устраивающего меня варианта. Хотя, те варианты, что есть, тоже имеют право на жизнь и не противоречат ГОСТу. Здесь многое зависит от традиций и вкусов. Кто-то любит гигантские изображения со всеми выводами, даже четырёхсторонние, кто-то любит скрывать выводы питания. Кто-то любит делать многоэлементные гетерогенные компоненты. Кто-то указывает все возможные функции выводов, а кто-то только основные или по умолчанию. Вариантов здесь может быть множество, всем не угодишь. Поэтому результирующая свалка может быть огромной, а её полезность для данного конкретного разработчика - стремящейся к нулю, чем дальше - тем больше. Кроме того, время разработки УГО для нового компонента (кои появляются чуть ли не каждый день, в отличие от типов корпусов) сопоставимо с временем поиска (и проверки) в общедоступной библиотеке. PS. Недавно озаботился новым проектом на STM32F407Z. Сделал как обычно УГО со всеми функциями для выводов и сгруппировал по портам ввода\вывода. Положил этот УГО на схему и ужаснулся тому, что он занял половину площади листа. Пришлось переделать УГО под данный конкретный проект, в котором сгруппировал выводы пофункционально (Ethernet, USB, UART, ...) и указал только нужные функции (и номера портов). Жить стало значительно легче, площадь УГО уменьшилась втрое, читабельность увеличилась. Но пострадала переносимость. Для другого проекта придётся другой УГО делать. Ну и как бы мне помогла общественная библиотека? Да, насчет чипов согласен. Наверно для чипов есть смысл использовать генераторы УГО. В случае ГОСТ, какие-то ГОСТ-генераторы УГО. Я пока не имел дело с ними. А вот УГО дискретных компонентов можно унифицировать и иметь отработанную библиотеку: транзисторы, диоды, резисторы и т.д. Также можно попытаться все-таки выбрать какой-то наиболее универсальный вариант УГО для микросхем дискретной логики и тоже сделать отработанную библиотеку. По крайней мере будем иметь базис. На самом деле чипы тоже можно представить в каком-то одном варианте. Кто-то возьмет и будет использовать как есть. Кто-то другой не будет использовать готовое УГО чипа, а либо сгенерирует его согласно своим критериям, либо разработает его сам без генерации. Изменено 2 июня, 2013 пользователем AVL Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
IgorKossak 0 2 июня, 2013 Опубликовано 2 июня, 2013 · Жалоба А вот УГО дискретных компонентов можно унифицировать и иметь отработанную библиотеку: транзисторы, диоды, резисторы и т.д. Также можно попытаться все-таки выбрать какой-то наиболее универсальный вариант УГО для микросхем дискретной логики и тоже сделать отработанную библиотеку. Именно об этом я и говорил. И такие библиотеки должны быть маленькими и их должно быть не много. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться