Перейти к содержанию
    

Всем привет!

 

Случилось так, что пришлось познакомиться с KiCad поближе. До этого был длительный опыт использования разных пакетов (начиная с ДОСовых OrCAD и Tango PCB, виндовый OrCAD, Protel'ы разных вариантов и заканчивая Altium'ом). Первое знакомство с KiCad'ом повергло в ступор. Собственно, посмотреть в его сторону сподвигло желание иметь нативный пакет электронной САПР в среде Linux, соответствующий духу последнего. Но столкнувшись с бедностью и даже, не побоюсь этого слова, убогостью функциональных возможностей, сильно засомневался. Изрядным плюсом было то, что пакет реально шустрый - быстро грузится, не тормозит в работе. Дальнейшее знакомство показало, что есть ещё один просто мегаплюс - текстовые документированные (хотя и не в полной мере) форматы файлов.

 

Забегая вперёд, хочется сказать, что этот пост (и тема) не о том, каков путь очередного осваивающего пакет пользователя, а о том, как довести (или хотя бы приблизить) пакет до более-менее юзабельного состояния (потому что то, что, как говорится, "из коробки", почти не пригодно для эффективной работы, моё мнение). Примеры из личного опыта тут только для полноты контекста, чтобы было понятнее. Ну, и возможно кому-то из начинающих осваивать KiCad пригодится аналогичный опыт.

 

Первое, с чем пришлось столкнуться - перенос библиотек и проектов. Сразу скажу, что тут получилась полная неудача. Делалось по маршруту Altium->PCAD->KiCad. Уж не знаю, то ли Altium горбато экспортирует, то ли плагин pcad2kicad работает не вполне корректно, но ничего путного не вышло. Помучавшись некоторое время, решил плюнуть на имеющееся проекты - пусть живут под виртуалкой в старом альтиуме. А вот c библиотеками уже так не сделать.

 

Библиотеки

 

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

 

Стало очевидным следующее: собственно все символы компонентов можно поделить на две группы:

 

* символы, которые сложно (или бессмысленно) описать алгоритмически, а проще нарисовать;

* символы, которые легко описать алгоритмически.

 

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

 

Вторая группа - микросхемы и разъёмы. И вот тут начинают рулить генераторы. С разъёмами всё совсем просто: мы используем УГО разъёмов преимущественно в виде таблицы со столбцами "Цепь", "Конт". Создавать и хранить отдельную библиотеку для этого оказалось избыточным - куда проще сгенерировать компоненты разъёмов (какие нужны) прямо "по месту" в проекте и сунуть их в библиотеку проекта. Всё, что для этого нужно - это указать количество выводов разъёма и опционально задать его ширину (см. ниже). Т.е. и описания-то символа никакого не требуется.

 

С микросхемами посложнее - всё-таки тут есть некое разнообразие. При изучении вопроса обратил внимание на этот пост, по ссылке из которого описывается искомый подход. Даже пытались это дело использовать, но кое-что не устроило, а подправить под свои хотелки оказалось для нас сложным, т.к. нет знакомства с платформой, которая там использовалась (Node.js). Да и формат описания показался несколько сложным. Но сама идея классная. В итоге был написан собственный генератор на языке Python, который из текстового описания на YAML генерирует схемные символы.

 

Собственно, саму библиотеку и формат описания можно посмотреть тут. Ограничения генератора УГО микросхем:

 

* позволят создавать УГО только ГОСТовского вида - расположение выводов только по бокам;

* тип выводов - passive (не придумалось веских оснований делать иначе).

 

Там же по ссылке ниже есть пара примеров описания и результат работы генератора.

 

Описываемый подход позволяет помимо собственно генерации компонентов автоматизировать создание библиотек. По факту всё получилось как при сборке программы: YAML-описания - это исходные файлы, *.cmp файлы - это что-то вроде объектных файлов (продуктов компилятора), которые потом "линкуются" в главную цель - библиотеку. В приведённой библиотеке представлена структура файлов и каталогов, а также сборочный скрипт на основе утилиты scons. Чтобы внести изменения в библиотеки, достаточно отредактировать YAML-описание компонента и запустить scons - при этом будут сгенерированы только компоненты, описание которых изменилось, и пересобрана соответствующая библиотека.

 

Оказалось, что пользоваться настолько просто и легко, что такая структура библиотеки у нас живёт в каждом проекте. Т.е. есть общая для всех проектов библиотека (пути к ней прописаны в свойствах проекта по умолчанию), а есть локальная в каждом проекте - в ней "живут" разъёмы, используемые в проекте, и специфичные для проекта компоненты или версии компонентов. На версиях компонентов хочется остановиться подробнее. В процессе изучения попался пост от уважаемого IgorKossak:

 

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

 

Цитированный текст зацепил прямо за живое - сам неоднократно сталкивался с подобным. Но перерисовывать компоненты под проект обычно было "в лом" - куча движений мышью, требующих определённой точности т.д.. А подход, основанный на текстовых описаниях компонентов и сборке библиотек, прямо-таки отлично ложится на реализацию идеи. Суть: в основной библиотеке хранятся полные версии компонентов, а в проекте, если тот или иной компонент изрядно избыточен (или даже просто "конфигурация" его внешнего вида не очень красиво выглядит на схеме), то файл с описанием этого компонента копируются в локальную библиотеку проекта, там это описание быстро правится в текстовом редакторе (лучше в "программерском") методом удаления лишнего текста и/или переноса текстовых кусков в нужные места - в общем, работа как при редактировании исходных текстов программ, потом запускается сборка, несколько секунд и получается библиотека с кастомизированным компонентом для проекта.

 

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

 

Инструментарий

 

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

 

Менеджер компонентов редактора схем

 

Ну, и наконец ещё один инструмент. При начале работы в схемном редакторе был неприятно удивлён абсолютным отсутствием средств для группового редактирования. После работы в том же Altium'е это было ощущение полной беспомощности. Основное, чего не хватало - это возможности быстро и эффективно работать со свойствами компонентов. Например, задать посадочные (да, там есть специальная программа для этого - CvPcb, но это очень на любителя и кроме того это не решает проблемы в целом. За годы работы в электронных САПР выработался подход, при котором у каждого компонента создаётся определённый набор свойств, причём, свойства не валятся в кучу, а каждое задаётся отдельно. Например, резисторов и конденсаторов есть свойства, обозначающие номинал и допуск (отклонение от номинала), у конденсаторов - тип диэлектрика, и т.д. Записывать всё это одним свойством очень негибко и неудобно.

 

Намного удобнее задавать все параметры компонента отдельными свойствами и иметь возможность создавать композитные свойства - состоящие из значений других свойств компонента по заданному [простому] формату. Это позволяет легко и эффективно управлять и внешним видом схемы, и содержимым, передаваемым в редактор печатных плат (сформировав значение встроенного свойства Value), и подготовкой данных для генерации перечня элементов.

 

В общем, в результате было написано приложение для управления свойствами компонентов. Это GUI приложение, написанное с использованием фреймворка PyQt5, работает оно с файлами eeschema. Не скрою, большое влияние при разработке приложения оказал изрядный опыт работы в Altium Designer и хотя развитие этой САПР идёт "не туда" (моё мнение, но достаточно посмотреть на эволюцию этой программы за последние несколько лет, т.ч. расстаюсь без особого сожаления), некоторые инструменты и подходы там реализованы очень эффективно - имеются в виду способы выделения объектов через Find Similar Objects и Inspector. Поэтому тот, кто имел опыт работы с AD, без труда заметит общие черты.

 

Собственно сама программа находится в том же репозитории (запускаемый файл - scmgr.py), что и остальные инструменты, русскоязычное описание доступно на wiki странице проекта.

 

 

Напоследок хочется отметить ещё одно классное следствие используемого в KiCad'е подхода - текстовых форматов файлов, а именно - возможность эффективно использовать системы управления версиями (мы используем git) для хранения проектов и библиотек. Помимо компактных комитов существует нативная возможность легко найти некоторые отличия между версиями. Конечно, графические изменения тут так просто будет не оследить, но редактирование компонентов сразу видно в diff'ах (хоть текстовых, хоть в двухпанельных). Для того, чтобы не испортить картину, менеджер компонентов работает с файлами *.sch "аккуратно" - не меняет их структуру. Т.е. все изменения сразу видны diff'ом.

 

P.S. Все инструменты достаточно "молодые", вполне могут быть "детские болезни". Поэтому в случае использования проверяйте результат. Приложение менеджера компонентов бекапит исходный файл, но всё равно лучше покамест делать резервные копии перед использованием.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

русскоязычное описание доступно на wiki странице проекта.

Шикарно! Обязательно попробую. А то CvPcb - очень неудобная программа.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Приятно видеть новые плюшки для нашего родного KiCad!

Странно, что в сам KiCad основная группа разрабтчиков это до сих пор не внесла.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Приятно видеть новые плюшки для нашего родного KiCad!

Вы попробуйте сначала, а то может рано радуетесь (может там кривизна и горбатость). :)

 

Странно, что в сам KiCad основная группа разрабтчиков это до сих пор не внесла.

Да вот и мне странно. Ведь тот же редактор схем только тогда отличается от примитивного векторного редактора, когда в нём есть развитые средства для работы с объектами (компонентами, цепями...). Но eeschema в этом плане совсем пустой. Мало этого, даже самые примитивные редакторы поддерживают устоявшуюся парадигму "выделил -> применил к выделенному действие". Но тут даже такого понятия, как выделение, нету. :( А пакет-то с 1992 года начался и до сих пор функциональность на уровне paint. Я вот не догоняю, неужели самим авторам удобно так работать? Или они свойствами совсем не пользуется?..

 

У меня типовой компонент выглядит примерно так:

post-1343-1479990875_thumb.png

 

Т.е. компонент несёт внутри себя все необходимые данные. И с помощью менеджера компонентов это достигается вообще без усилий (минут за 5-10) для всех элементов схемы (несколько сотен). Совершенно согласен с вами, что такого рода инструменты просто обязаны быть в составе схемного редактора.

 

Кстати, в соседней ветке кинули ссылку на доработку eeschema, фича добавляет табличное представление компонентов с их свойствами (наподобие как в OrCAD Capture), что позволяет оперативно их просматривать и редактировать в т.ч. и групповым, насколько правильно я понял (там есть ссылка на видеоролик), способом. Будем ждать, что включат в основной код.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вы попробуйте сначала, а то может рано радуетесь (может там кривизна и горбатость). :)

Попробовал. Вещь простая, удобная и крайне полезная. Разве только добавить установку размеров шрифтов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Попробовал. Вещь простая, удобная и крайне полезная. Разве только добавить установку размеров шрифтов.

Вы о каком инструменте говорите?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

icgen + merge-lib

Так вы можете в icgen.py исправить значение в строке (она там в начале)

 

FONT_SIZE = 100 # mils

 

на то, которое надо. И пересобрать. Или вам нужно разные размеры шрифта для разных компонентов?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Так вы можете в icgen.py исправить значение в строке (она там в начале)

Ну да, так и сделал.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну да, так и сделал.

 

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

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

 

С шагом же (vertical spacing - это не только шаг пинов, это общий шаг разметки по вертикали - группы и разделители групп тоже от него зависят) ситуация немного иная - вполне может захотеться разместить выводы пореже - например, хочется сделать символ таким, чтобы элементы внешней "обвязки" красиво ложились на выводы компонента. Конечно, можно и мелким шагом разметить, но это может оказаться менее удобным.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Брал таблицу из PDF файла, с помощью http://tabula.technology/

потом городил примерно такое

with open('tabula-vs1053.csv') as f:
    txt=f.readlines()
deltay=100
Y=0
for x in txt:
    z=x.replace('\n','').split(',')
    #strip name spaces
    z[0]=z[0].replace(' / ','/')
    print 'X', z[0], z[1],0,Y, 300, 'R', 40,40, 0, 0, 'P'
    Y+=deltay

и далее уже пины вставлял в текст либы, потом расставлял их на УГО элемента вручную

 

формат таблицы, разумеется, от доки к доке меняется. Но профит остается: вероятность ошибок в разы меньше

Изменено пользователем _Pasha

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для создания УГО использовал KiPart.

Есть интересная возможность для выводов питания, которые все равно объединяются кикадом:

post-20394-1496891130_thumb.png

Очень экономит место на листе.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А есть подобный набор утилит/плагинов не на питоне?

Если уж не на С, то хотя бы на С++… Чтобы хоть понятно было, что там где что делает, и куда изменения при необходимости вносить!

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Стал изменять значения, упало, и больше не открывает эту схему, с таким выводом

$ ~/KiCAD_prj/kicad-tools-master/scmgr.py RS232.sch
Qt Version: 5.9.1
QApplication: invalid style override passed, ignoring it.
Traceback (most recent call last):
  File "/home/op3op3/KiCAD_prj/kicad-tools-master/scmgr.py", line 817, in <module>
    mwin = MainWindow()
  File "/home/op3op3/KiCAD_prj/kicad-tools-master/scmgr.py", line 394, in __init__
    self.initUI()
  File "/home/op3op3/KiCAD_prj/kicad-tools-master/scmgr.py", line 712, in initUI
    self.CmpTable.load_file(fname)
  File "/home/op3op3/KiCAD_prj/kicad-tools-master/scmgr/cmptable.py", line 120, in load_file
    self.CmpDict = CmpMgr.load_file(fname)
  File "/home/op3op3/KiCAD_prj/kicad-tools-master/scmgr/cmpmgr.py", line 385, in load_file
    cmp_dict = self.create_cmp_dict( rcls, ipl )
  File "/home/op3op3/KiCAD_prj/kicad-tools-master/scmgr/cmpmgr.py", line 400, in create_cmp_dict
    for ip in ipl:
TypeError: 'NoneType' object is not iterable

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...