Файлы fp lib table не содержат библиотек с именем
В данной статье мы посмотрим, что такое статические и динамические библиотеки. Местоположение библиотек по умолчанию. Определение используемых библиотек. Загрузка библиотек.
Библиотеки это набор функций, которые могут использоваться в различных программах. Библиотеки могут быть статические (библиотека привязывается к определенной программе или софт содержит данную библиотеку в своем теле.) и динамическими (библиотеки грузятся в оперативную память и используются). Плюсы первого варианта нет проблемы совместимости, т. к. софт уже в себе содержит библиотеку, библиотека всегда с собой. Но при этом программы становятся большие по размеры и т.к каждая может загружать свои библиотеки, а иногда и одинаковые. Второй вариант значительно лучше, сами программы по своему размеру меньше. Библиотека загружается один раз в оперативку. И следующая программа, которой необходимы такие же функции, берет и использует эти данные.
По умолчанию библиотеки в Linux находятся в двух папках. Это корневая папка /lib в ней находятся библиотеки, которые используют программы, расположенные в корневой папке /bin.
И есть вторая папка /usr/lib . В ней находятся библиотеки, которые используют программы расположенные /usr/bin . Пути к библиотекам указаны файле /etc/ld.so.conf . Данный файл можно просмотреть стандартным способом, через утилиту cat.
Видим, что написано включить все библиотеки, которые расположены по пути, указанном в файле. Те которые оканчиваются на .conf . Он просто включает в себя все настройки, которые находятся в конфигурационных файлах, в данной директории. Переходим в данную директорию.
В данной директории мы можем видеть 2 файла конфигурации, в зависимости от версии и наполнения операционной системы их может быть и больше. Ну и соответственно в конфигурационных файлах находятся пути к директориям, где лежат необходимые для работы библиотеки. Если мы ставим какое, то свое программное обеспечение, которому необходимы дополнительные библиотеки, не идущие в составе дистрибутива linux, то в данной директории может создаться свой конфигурационный файл. Например: если мы используем систему виртуализации VMware , то к каждой VM устанавливаем VMware tools то данное программное обеспечение создаст свой конфигурационный файл с путями для своих библиотек.
Переходим в директорию cd /etc/ и отсортируем так, чтобы в результатах все, что содержит ld.
Видим 3 основных конфигурационных файла. ld.so.conf - это файл конфигурации в котором написано откуда брать дополнительные библиотеки. Директория ls.so.conf.d в которой находятся дополнительные конфигурационные файлы и ld.so.cache это кэш библиотек. Он у нас выстраивается каждый раз для того, чтобы программы при необходимости при запросе библиотек не копались в файлах, а сразу брали из загруженного в оперативную память кэша. Т.е. если мы вносим какие-то изменения в файл конфигурации, добавляем какие-то конфигурационные файлы нам необходимо обновить этот кэш. Кэш обновляется командой ldconfig . Этого, собственно, достаточно, чтобы прогрузить все библиотеки в кэш.
Давайте посмотрим, как, определить какими библиотеками пользуется какая программа.
Для этого мы будем использовать команду ldd и путь к бинарному файлу. Например: Программа ls которая используется для вывода списка файлов в каталоге. Она находится в каталоге /bin/ls .
В результате получим мы следующее:
Мы видим, какие so использует данная программа и соответственно ссылки на них, где они расположены, собственно, so - это наши библиотеки в данном случае.
Возможно добавление библиотек вручную, это может потребоваться если мы ставим совершенно стороннее программное обеспечение, которое очень трудно взаимодействует с Linux или устаревшее. Т.е. которое само не может создать конфигурационный файл и разнести библиотеки в системные директории Linux. Если мы хотим сделать это вручную, тогда нам необходим тот самый файл /etc/ld.so.conf . В данный файл мы можем дописать путь к файлу конфигурации библиотек тех, которые нам нужны. Либо есть более легкий вариант с использованием переменной export LD_LIBRARY_PATH и указать путь к тем особенным библиотекам, которые будет использовать наша " особенная " программа. Обычно все стороннее программное обеспечение устанавливается в папку /opt. Итоговый вариант будет выглядеть как: export LD_LIBRARY_PATH=/opt/soft/lib и когда пройдет экспорт, у нас попробует погрузится из этого пути библиотека, но перед этим необходимо не забыть сделать ldconfig .
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Open with Desktop
- View raw
- Copy raw contents Copy raw contents
Copy raw contents
Copy raw contents
Installation of the software
The installation procedure is described in the KiCad documentation.
Modifying the default configuration
A default configuration file kicad.pro is provided in kicad/share/template . This file is used as the initial configuration for all new projects.
This configuration file can be modified to change the libraries to be loaded.
Launch Pcbnew using kicad or directly. On Windows it is in C:\kicad\bin\pcbnew.exe and on Linux you can run /usr/local/kicad/bin/kicad or /usr/local/kicad/bin/pcbnew if the binaries are located in /usr/local/kicad/bin .
Select Preferences - Libs and Dir.
Edit as required.
Save the modified configuration (Save Cfg) to kicad/share/template/kicad.pro .
Managing Footprint Libraries
As of release 4.0, Pcbnew organises the footprint libraries using files called "footprint library tables". A footprint library table contains descriptions of some number of individual footprint libraries, along with a "nickname" for each library, which is used to refer to that library when referencing a footprint.
There are several kinds of library supported by Pcbnew, each of which is supported by a "plugin":
KiCad - native KiCad footprint libraries stored on a local filesystem in the .pretty format (folders containing .kicad_mod files)
Github - native KiCad footprint libraries in the .pretty format, stored online as a Github repository
Legacy - old-style KiCad footprint libraries (.mod files)
Eagle - Eagle footprint libraries (folders containing .fp files)
Geda-PCB - Geda PCB libraries
You can write only KiCad .pretty footprint library folders on your local disk (and the .kicad_mod files inside these folders).
All other formats are read only.
It is allowed to have footprints with the same name in different libraries. The footprint will be stored as a combination of library and footprint name, ensuring that the correct footprint is loaded from the appropriate library.
There are two footprint library tables: the global one and the project one.
Global Footprint Library Table
The global footprint library table contains the list of libraries that are always available regardless of the currently loaded project file. The table is saved in the file fp-lib-table in the user’s home folder. The location of this folder is dependent on the operating system.
Project Specific Footprint Library Table
The project specific footprint library table contains the list of libraries that are available specifically for the currently loaded project file. The project specific footprint library table can only be edited when it is loaded along with the project board file. If no project file is loaded or there is no footprint library table file in the project path, an empty table is created which can be edited and later saved along with the board file.
When entries are defined in the project specific table, an `fp-lib-table file `containing the entries will be written into the folder of the currently open PCB.
The first time CvPcb or Pcbnew is run and the global footprint table file fp-lib-table is not found in the user’s home folder, Pcbnew will attempt to copy the default footprint table file fp_global_table stored in the system’s KiCad template folder to the file fp-lib-table in the user’s home folder. If fp_global_table cannot be found, an empty footprint library table will be created in the user’s home folder. If this happens, the user can either copy fp_global_table manually or configure the table by hand.
The default footprint library table includes all of the standard footprint libraries that are installed as part of KiCad.
There are also sample fp-lib-table files in the official KiCad library repository that you can use as your own starting point:
All KiCad libraries via Github: fp-lib-table.for-github
All KiCad libraries, assuming they are on your disk already (you will need to download them if you do not already have them): fp-lib-table.for-pretty
Standard Eagle libraries (for Eagle 6.4.0) fp-lib-table.for-eagle-6.4.0
The first thing to do when configuring KiCad do is to modify this table (add/remove entries) according to your work and the libraries you need for your projects.
Adding Table Entries using the Libraries Manager
The library table manager is accessible by:
The image below shows the footprint library table editing dialog which can be opened by invoking the "Footprint Libraries Manager" entry from the "Preferences" menu.
In order to use a footprint library, it must first be added to either the global table or the project specific table. The project specific table is only applicable when a board file is open.
Each library table entry has a nickname. This must be unique within that table. The nickname does not have to be related in any way to the actual library file name or path.
There are some rules for valid library table entries:
The colon : character cannot be used anywhere in the nickname.
Each library entry must have a valid path and/or file name depending on the type of library. Paths can be defined as absolute, relative, or by environment variable substitution (see below)
The appropriate plug in type must be selected in order for the library to be properly read.
There is also a description field to add a description of the library entry. The option field contains special options that are plugin-specific and is generally blank.
Although you cannot have duplicate library nicknames in the same table, you can have duplicate library nicknames in both the global and project specific footprint library table. The project specific table entry will take precedence over the global table entry when duplicated names occur.
Environment Variable Substitution
One of the most powerful features of the footprint library table is environment variable substitution. This allows you to define custom paths to where your libraries are stored in environment variables.
Environment variable substitution is supported by using the syntax $ in the footprint library path.
There are some default variables that KiCad defines:
$KISYSMOD : This points to where the default footprint libraries that were installed along with KiCad are located. You can override $KISYSMOD by defining it yourself which allows you to substitute your own libraries in place of the default KiCad footprint libraries.
When a board file is loaded, $KPRJMOD is defined using that board’s path. This allows you to refer to libraries in the project path without having to repeat the absolute path to the library in the project specific footprint library table.
Adding Table Entries using the Library Wizard
There is an interactive wizard that can assist you adding libraries to your library tables. It is accessible from the menu:
It can also be launched from the library manager, using the "Append With Wizard" button.
Here, the local libraries option is selected.
Here, the remote libraries option is selected.
The wizard will then lead you though the steps to adding a library, which will depend on the type of library you are adding. The process for each type will be explained below.
After a set of libraries is selected, the next page validates the choice:
If some selected libraries are incorrect (not supported, not a footprint library …) they will be flagged as ``INVALID''.
The last choice is the footprint library table to populate either:
the global table, or
the project specific table
Adding Existing Local Libraries
You might have local libraries already on your computer. For example:
Previously downloaded KiCad pretty directories
Legacy KiCad .mod files from older installations
Geda or Eagle libraries
These can be added with the "Files on my computer" option. You will be asked for the directory of the library to add and the format:
If you don’t select the format, the wizard will try to guess the right format.
Adding Libraries from Github
The wizard can also add libraries from Github with the "Github repository" option.
You need to specify the Github account that contains the repositories you want to add.
You may choose to save a local copy. If you do not save a local copy, the library will be a Github library, and will resync on every library reload. If you do save a local copy, the library will be a KiCad (pretty) library and will not automatically update in future.
The next page will load a list of .pretty repositories found on that Github account. You can choose any number to add to the library.
After confirmation,if you opted to save a copy, the footprints will be downloaded to the specified local location now. If you are using the Github plugin (no local copy), the footprints are loaded from Github when needed.
Using the KiCad plugin
The KiCad plugin deals with native KiCad libraries that exist on your computer (or some accessible filesystem).
It is used for pre-installed libraries that are installed along with KiCad, as well as other KiCad libraries, either from the official KiCad library collection, 3rd party libraries or your own curated libraries.
Installing KiCad plugin libraries
The Footprint Library Wizard can help you install libraries already on disk or on Github. However, for libraries on disk, you need to put them there yourself in the first place.
A KiCad library is a directory that contains some number of .kicad_mod files.
This is often done by unpacking an archive file, copying a directory from another location, or cloning a version-controlled repository.
The KiCad plugin does not specify any kind of version control, but Git is very commonly used to track changes to libraries, which can be critical to ensuring library data is safely recorded and backed up.
It is easy to track changes and contribute with the offical KiCad Github libraries. This is done using the Git version control software. If you want to contribute back, you’ll have to fork the repos on Github so you can send pull requests. If you just want to update libraries when needed, you don’t need to do that, you can clone the offical KiCad libraries directly and pull as needed.
Using the GitHub Plugin
The GitHub plugin is a special plugin that provides an interface for read-only access to a remote GitHub repository consisting of .pretty footprints and optionally provides "Copy-On-Write" (COW) support for editing footprints read from the GitHub repo and saving them locally.
You will not be told if a remote repository changed since your last use of it. Be cautious when using footprint directly from Github.
To add a GitHub entry to the footprint library table the "Library Path" in the footprint library table entry must be set to a valid GitHub URL.
Typically GitHub URLs take the form:
The "Plugin Type" must be set to "Github".
The table below shows a footprint library table entry with the default options (no COW support):
Liftoff’s GH footprints
To enable the "Copy-On-Write" feature the option allow_pretty_writing_to_this_dir must be added to the "Options" setting of the footprint library table entry. This option is the "Library Path" for local storage of modified copies of footprints read from the GitHub repo. The footprints saved to this path are combined with the read-only part of the GitHub repository to create the footprint library. If this option is missing, then the GitHub library is read-only. If the option is present for a GitHub library, then any writes to this hybrid library will go to the local *.pretty directory.
The github.com resident portion of this hybrid COW library is always read-only, meaning you cannot delete anything or modify any footprint in the specified GitHub repository directly. The aggregate library type remains "Github" in all further discussions, but it consists of both the local read/write portion and the remote read-only portion.
The table below shows a footprint library table entry with the COW option given. Note the use of the environment variable $ as an example only. The github.pretty directory is located in $/pretty/path . Anytime you use the option allow_pretty_writing_to_this_dir , you will need to create that directory manually in advance and it must end with the extension .pretty .
Liftoff’s GH footprints
Footprint loads will always give precedence to the local footprints found in the path given by the option allow_pretty_writing_to_this_dir . Once you have saved a footprint to the COW library’s local directory by doing a footprint save in the Footprint Editor, no GitHub updates will be seen when loading a footprint with the same name as one for which you’ve saved locally.
Always keep a separate local .pretty directory for each GitHub library, never combine them by referring to the same directory more than once. Also, do not use the same COW ( .pretty ) directory in a footprint library table entry. This would likely create a mess. The value of the option allow_pretty_writing_to_this_dir will expand any environment variable using the $<> notation to create the path in the same way as the "Library Path" setting.
Using Copy-On-Write to share footprints
Caching Github requests
The Github plugin can be slow, as it must download all the libraries from the Internet before they can be used.
Footprint libraries can be defined either globally or specifically to the currently loaded project. Footprint libraries defined in the user’s global table are always available and are stored in the fp-lib-table file in the user’s home folder. Global footprint libraries can always be accessed even when there is no project net list file opened. The project specific footprint table is active only for the currently open net list file. The project specific footprint library table is saved in the file fp-lib-table in the path of the currently open board file. You are free to define libraries in either table.
There are advantages and disadvantages to each method:
You can define all of your libraries in the global table which means they will always be available when you need them.
The disadvantage of this is that you may have to search through a lot of libraries to find the footprint you are looking for.
You can define all your libraries on a project specific basis.
The advantage of this is that you only need to define the libraries you actually need for the project which cuts down on searching.
The disadvantage is that you always have to remember to add each footprint library that you need for every project.
You can also define footprint libraries both globally and project specifically.
One usage pattern would be to define your most commonly used libraries globally and the library only required for the project in the project specific library table. There is no restriction on how you define your libraries.
Modifying footprints in a PCB project
When a footprint is added to a PCB, the entire footprint is copied into the PCB file (.kicad_pcb). This means changes to the footprint in the library do not automatically affect the PCB.
This also means that you can individually edit footprints on the PCB without affecting other instances of the same footprint (either on the same PCB or on other PCBs).
However, if you modify the library footprint, the next time you place an instance, it will not match existing footprints of the same name.
Какое-то время назад я опубликовал статью-презентацию об инструменте под названием QEDA. Если кратко, то это утилита для облегчения процесса создания библиотеки электронных элементов.
Были сделаны полезные выводы, проведена дальнейшая работа, проект развивался. Появился интерфейс коммандной строки (CLI). На сегодняшний день можно говорить о некотором milestone: проект достиг версии 0.1.
В этот статье я рассмотрю типичный рабочий процесс по созданию платы в среде KiCad и использованием утилиты QEDA.
Предупреждение: будут картинки и, как следствие, трафик.
Кратко напомню, что для работы надо установить Node.js, а затем запустить в консоли (в *nix может потребоваться sudo ):
Ну и конечно же нам потребуется KiCad EDA, который также необходимо установить.
Описанная ниже разработка ведётся в Ubuntu Linux, но в общем случае (вероятно, с некоторыми поправками) возможна в любой ОС.
Устройство представляет собой адаптер для подключения Wi-Fi модуля ESP-07 к автопилоту Pixhawk.
Собственно это и есть центральная часть нашего повествования.
Если всё установилось без ошибок, то в системе должна была появиться новая утилита коммандной строки. Проверим, что это так — запустим в консоли:
Если вы видите что-то вроде.
… значит мы можем продолжать.
Для начала выберем папку для будущего проекта. В моём случае это будет директория wifi-adapter .
Шаг 4. Генерация библиотеки
Ну вот мы и подошли к основному и самому простому шагу. Назовём нашу библиотеку wa .
Если процесс завершился без ошибок, то в текущей директории lib должны появиться две поддиректории:
- library , содержащая кэшированные YAML-описания используемых элементов
- kicad с библиотечными файлами, предназначенными для KiCad
Всё: самое время приступить к рисованию схемы. Инструкции по проектированию схемы и печатной платы больше напоминают известную шутку про то, как рисовать сову. Однако связано это с тем, что статья посвящена в основном процессу генерации библиотеки элементов, а подробности проектирования в KiCad сделали бы статью ещё более раздутой.
Создадим проект KiCad в директории wifi-adapter/board .
Так как наша библиотека элементов является самодостаточной, можно удалить все библиотеки KiCad'а по умолчанию, и добавить только нашу wa :
А в стиле GOST схема выглядела бы так:
QEDA избавляет от необходимости такого этапа, как ассоциирование посадочных мест условным графическим обозначениям (assign component footprint), так как каждому элементу уже ассоциировано уникальное посадочное место. Иначе говоря, Cvpcb запускать не придётся.
Для начала так же сообщаем редактору, что надо черпать посадочные места из нашей свежеиспечённой библиотеки wa . Для этого в директории проекта создаём файл fp-lib-table со следующим содержимым:
Импортируем netlist, делаем auto-spread.
Ну а дальше "рисуем остаток совы". Трассировщик из меня не очень, поэтому прошу не судить строго.
Генерируем gerber'ы и можно отдавать в производство.
На простейшем примере мы рассмотрели процесс разработки печатной платы, как говорится, с нуля. Признаюсь, плата до производства не дошла, однако предпроизводственный контроль прошла успешно.
В предыдущей части был приведен способ, с помощью которого, можно сократить количество кода при использовании классов-помощников и классов из других пространств имен.
В данной статье речь пойдет о том, как можно реализовать размещение элементов библиотеки по файлам. Также будут затронуты вопросы подключения элементов библиотеки в пользовательском коде, и, конечно же, как «рабочие» пространства имен могут помочь в реализации библиотеки.
Подходы, применяемые при организации файлов библиотеки
Для начала определимся, что речь пойдет о библиотеках, весь код которых поставляется в виде заголовочных файлов. При создании структуры файлов в таких библиотеках придерживаются ряда правил. Не все из них можно назвать «стандартными», но применение представленных правил в существующих библиотеках не такое и редкое явление.
1) Заголовочные файлы библиотеки обычно размещают в отдельной папке.
Название папки содержит имя библиотеки или пространства имен, используемого в библиотеке. Это позволяет в пользовательском коде «документировать» использование библиотеки:
2) Файлы, содержащие «пользовательские» типы, и файлы, предоставляющие детали реализации, желательно размещать в разных папках.
Под «пользовательскими» типами понимаются типы, определяемые библиотекой и предоставляемые пользователю для использования в своем коде.
Применение данного правила со стороны разработчика библиотеки позволяет пользователю библиотеки легко определить файлы, которые ему необходимы для включения в своем проекте без чтения сопутствующей документации.
Для примера, некоторые библиотеки boost размещают файлы реализации во вложенной папке detail.
3) Для каждого класса библиотеки нередко создается отдельный файл с одноименным названием.
Такой подход позволяет пользователю библиотеки легко разобраться в ее структуре, а разработчику предоставляет простоту навигации по классам в своей библиотеке.
4) Файлы библиотеки должны быть самодостаточными.
Подробней об этом правиле можно почитать в книге «Стандарты программирования на C++» Г.Саттера и А.Александреску (правило 23).
Описание тестовой библиотеки
Далее предположим, что нам необходимо реализовать некоторую библиотеку SomeLib. Эта библиотека должна предоставлять пользователю классы A_1, A_2 и A_3, реализующие некоторый функционал. Зеленой областью на рисунке представлена сама библиотека, красной — пространство имен, а синими — классы, предоставляемые пользователю.
Пусть библиотека SomeLib имеет зависимость от библиотеки STL и содержит «невидимые» пользователю вспомогательные классы I_1 и I_2, которые на рисунке представлены оранжевым цветом. Стрелками указаны зависимости классов от других. Например, класс A_1 зависит от классов list, vector и I_1. Под зависимостями класса в данном случае понимается использование им других классов при описании своих данных, функций-членов или реализации этих функций.
Предположим, что библиотека поставляется в виде заголовочных файлов и в качестве одного из файлов содержит config.hpp, описывающий некоторые «управляющие» структуры.
Реализация тестовой библиотеки с использованием представленных правил
При реализации библиотеки воспользуемся стандартным подходом, описанным в предыдущей части. Пользовательские классы будем размещать в пространстве имен библиотеки some_lib, а служебные классы во вложенном пространстве имен impl.
Библиотека будет размещаться в папке some_lib. В этой папке будут файлы A_*.hpp, описывающие «пользовательские» типы. Файлы I_*.hpp, содержащие служебные классы, будем размещать во вложенной папке impl.
Теперь можно приступить к реализации. Пропустим описание процесса кодирования и сразу перейдем к результатам.
Файл some_lib/impl/config.hpp
Файл some_lib/impl/I_1.hpp
Файл some_lib/impl/I_2.hpp
Файл some_lib/A_1.hpp
Файл some_lib/A_2.hpp
Файл some_lib/A_3.hpp
Пользователь теперь может использовать нашу библиотеку, подключив один или несколько заголовочных файлов.
Замечания по реализации тестовой библиотеки
Наша библиотека содержит относительно простую схему связей между элементами. Во что выливается разработчику библиотеки реализация более сложных зависимостей представить нетрудно.
Стоит отметить еще один интересный момент. При включении только одного заголовочного файла some_lib/A_3.hpp пользователь фактически подключает больше половины библиотеки (если быть более точным, то 4/6 исходных файлов).
А если теперь задаться вопросом: действительно ли, так необходимо реализовывать для пользователя библиотеки возможность подключения отдельных ее элементов?
Предположим, что ответ на этот вопрос «Нет». Вот здесь-то и начинается самое интересное…
Реализация тестовой библиотеки, использующей единственную точку подключения
Пользователю для подключения библиотеки теперь необходима всего одна строчка кода:
Теперь остановимся на моментах реализации, которые может применить разработчик библиотеки:
1) Поскольку имеется только одна точка подключения библиотеки (файл some_lib/include.hpp), разработчик библиотеки может избавиться от всех «стражей» включения, кроме одного — в файле подключения всей библиотеки.
2) Каждый файл «пользовательского» класса или класса-элемента реализации теперь не обязан содержать включения файлов, содержащих зависимые элементы.
3) Применение «рабочих» пространств имен позволяет избавиться от задания пространств имен в каждом файле.
Поскольку файл для подключения библиотеки пользователем только один, то можно пересмотреть структуру файлов библиотеки.
Реализация библиотеки теперь может выглядеть следующим образом:
Файл some_lib/include.hpp
Файл some_lib/private/config.hpp
Файл some_lib/private/I_1.hpp
Файл some_lib/private/I_2.hpp
Файл some_lib/public/A_1.hpp
Файл some_lib/public/A_2.hpp
Файл some_lib/public/A_3.hpp
Заключение
Описывать достоинства и недостатки представленного подхода к реализации, думаю, нет смысла — код сам говорит за себя. Каждый разработчик самостоятельно решит какую схему при реализации кода библиотеки он для себя выберет, взвесив при этом все «за» и «против».
А если внимательно присмотреться к представленной схеме, то есть ощущение чего-то знакомого. Но об этом не сейчас…
В предыдущей статье я, несколько опрометчиво, написал, что далее мы займемся созданием собственного компонента. Совершенно упустив из вида, что у читателей KiCad может быть еще не установлен или не настроен.
Поэтому сегодня речь пойдет о том, где можно получить KiCad, где найти документацию (на русском языке), где найти помощь от сообщества (а вот тут уже на английском), где найти готовые библиотеки компонентов. И как это все устроено.
KiCad может работать под управлением всех основных классических ОС: Windows, Linux, MacOS. При желании можно собрать KiCad самостоятельно из исходных текстов, они полностью открыты и доступны. Во многих дистрибутивах Linux KiCad можно найти в основных или дополнительных репозиториях или установить через flatpak.
Последняя стабильная версия на данный момент (18 августа 2021 года) 5.1.10, которая выпущена 3 мая 2021 года.
Внимание! Ни данная статья, ни все последующие, не являются заменой официальной документации. Это не фрагменты официальной документации, а лишь некоторые дополнения, основанные на собственном опыте, которые поясняют новичкам некоторые моменты и помогают разобраться. Читать официальную документацию ОБЯЗАТЕЛЬНО! Я буду в статьях лишь ссылаться на нее, а не повторять там описанное.
Шаг 3. Добавление элементов
Так как описания использованных элементов уже содержатся в репозитории элементов, нам необходимо лишь их перечислить. Однако для заинтересованных лиц ссылки на описания использованных элементов приведены в спойлере ниже.
Если нужного элемента не оказалось в репозитории, необходимо создать поддиректорию library и добавить туда описание элемента в формате YAML.
Добавим ещё символы питания и земли:
Официальный сайт
Сайт англоязычный, но некоторые разделы помощи и документации есть и на русском языке. Сайт достаточно простой и логичный. Тем не менее, я дам и прямые ссылки на основные разделы
При скачивании (во всяком случае, для Windows и MacOS) вам будут предлагать "оказать финансовую помощь". Это нововведение, которое многим не очень нравится. Платить совсем не обязательно, это не требование, а просьба/предложение. KiCad был и остается свободно распространяемым, причем и в исходных текстах. На всякий случай вот прямые ссылки на загружаемые файлы (без просьб "дать денег")
Это ссылки на последнюю версию 5.1.10. Ссылки официальные.
https://docs.kicad.org/ Раздел (точнее, отдельный сайт) с документацией. Кроме руководств по входящим в KiCad программам есть и "Быстрый старт", который кратко описывает основные моменты и позволяет понять, хотя бы, "куда здесь нажимать". Качество документации это отдельный вопрос. Безусловно, до уровня документации на коммерческие системы документация KiCad не дотягивает. Часть информации может быть устаревшей, встречаются и ошибки.
Небольшое отступление. Поскольку часть интерфейса программ может быть не переведена, или в документации часть информации устарела, могут возникать разночтения. Поэтому я рекомендую, во всяком случае, на первое время, скачать и русскоязычный, и англоязычный вариант документации.
https://www.kicad.org/libraries/download/ Раздел, в котором можно найти библиотеки готовых компонентов и шаблонов. Можно скачивать отдельные библиотеки или полный комплект. Сторонников ЕСКД могу расстроить, библиотеки "не по ГОСТу". Кроме того, в них можно найти далеко не все реально существующие компоненты.
Шаг 2. Прочие настройки
Мы можем выбрать предпочитаемый способ генерирования посадочных мест (pattern) микросхем: рекомендуемый производителем или по стандарту IPC-7351. По умолчанию задан рекомендуемый производителем (значения по умолчанию задавать в настройках не обязательно, но мы продублируем их для демонстрации возможностей):
Те элементы, в чьих описаниях не содержится рекомендаций производителя, рассчитываются по стандарту IPC-7351. Стандарт предусматривает три уровня плотности компоновки (density level):
- Least ( L ) — самый плотный (рекомендуется при ограниченных габаритах печатной платы)
- Nominal ( N ) — нормальный (рекомендуется в большинстве случаев)
- Most ( M ) — наименее плотная компоновка (рекомендуется для плат, рассчитанных на жёсткие условия эксплуатации)
Так как мы не ограничены в габаритах, выбираем наименее плотный вариант:
Так как предполагается паять плату вручную, зададим ещё один параметр: минимальное расстояние от края вывода элемента до противоположного края его контактной площадки.
Также есть возможность настроить следующие параметры (в скобках указаны значения по умолчанию):
- pattern.clearance.padToMask (0.05): расстояние от края контактной площадки до края маски (раскрытие маски)
- pattern.minimum.maskWidth (0.2): минимальная ширина пояска маски (имеет приоритет над предыдущим параметром)
- pattern.lineWidth.silkscreen (0.12): толщина линии в слое шелкографии
- pattern.fontSize.refDes (1.2): высота шрифта для позиционных обозначений (reference designator)
Мы оставим эти параметры по умолчанию.
Кроме этого, есть возможность задать кое-какие настройки будущих условных графических обозначений (УГО) элементов (schematic symbol):
- symbol.style ('default'): стиль начертания УГО, альтернативный вариант: 'GOST'
- symbol.gridSize (2.5): размер ячейки сетки привязки
- symbol.fontSize.refDes (2.5): высота шрифта для позиционных обозначений (reference designator)
- symbol.fontSize.name (2.5): высота шрифта для наименования элемента
- symbol.fontSize.pin (2.5): высота шрифта для обозначения выводов
Их так же трогать не будем.
Основные программные компоненты KiCad
KiCad это целостная система, но она состоит из отдельных компонентов, которые могут использоваться и по отдельности. Я не буду перечислять абсолютно все компоненты, назову лишь самые основные и полезные.
Установка
Установка проста. В Windows и MacOS запустите скачанный файл и выберите нужные для установки компоненты KiCad. Новичкам рекомендуется оставить набор по умолчанию.
В Linux воспользуйтесь менеджером пакетов добавив, при необходимости, нужный репозиторий. Или используйте flatpak. В Gentoo или Arch придется собирать KiCad из исходных текстов.
В конечном итоге вы получите установленную работоспособную систему. Если библиотеки электронных компонентов в вашей системе не установились вместе с KiCad, или вы отказались от их установки, скачайте необходимые вручную.
В дальнейшем я буду предполагать, что у вас есть установленный KiCad.
Шаг 1. Выбор производителя печатных плат
В моём случае я буду создавать библиотеку элементов с учетом требований конкретного производителя. Конечно, некоторые параметры можно подкрутить в процессе трассировки в EDA, но здесь я покажу, как учитывать производственные возможности на самом первом этапе.
Итак, для примера возьмём OSH Park. Из существенных для нас являются требования по:
- минимальному расстоянию между проводниками: 6 mil (0.2 mm) minimum spacing
- минимальному диаметру отверстия: 13 mil (0.4 mm) minimum drill size
- минимальной ширине ободка металлизированного отвестия: 7 mil (0.2 mm) minimum annular ring
В скобках я указал значения, преобразованные к метрической системе и округлённые в большую сторону до десятых.
Создадим папку для будущей библиотеки элементов:
Теперь используя консольную команду qeda пропишем вышеупомянутые ограничения. Повторюсь, что пока команды не документированы, так что пока буду пояснять их по месту.
После выполнения этих команд в текущей директории появится файл .qeda.yaml , который хранит все указанные настройки.
Читайте также: