Введение

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

Имея некоторый неприятный опыт работы с Eagle, я могу с полной уверенностью сказать, что Kicad более удобен. Он определенно более интуитивно понятен в использовании, что повышает производительность и скорость  работы. Есть много различных комбинаций клавиш, чтобы получить максимальную отдачу от ваших кликов и добиться того, чего вы хотите.

Kicad — это проект с открытым исходным кодом. Имея желание и соответствующие навыки программирования, вы можете добавить свой собственный инструмент в программу или изменить существующие. Также нет проблем с запуском Kicada в Linux.

Компоненты пакета:

• eeschema — редактор схем,
• pcbnew — редактор печатных плат (до 16 слоев),
• gerbview — просмотрщик файлов Gerber ,
• cvpcb — приложение для назначения корпусов электронных компонентов,
• bitmap2component — приложение для создания графических элементов на плитках,
• 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

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

Создадим папку для будущей библиотеки элементов:

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

После выполнения этих команд в текущей директории появится файл , который хранит все указанные настройки.

Шаг 4. Генерация библиотеки

Ну вот мы и подошли к основному и самому простому шагу. Назовём нашу библиотеку .

Если процесс завершился без ошибок, то в текущей директории должны появиться две поддиректории:

• , содержащая кэшированные YAML-описания используемых элементов
• с библиотечными файлами, предназначенными для KiCad

Всё: самое время приступить к рисованию схемы. Инструкции по проектированию схемы и печатной платы больше напоминают известную шутку про то, как рисовать сову. Однако связано это с тем, что статья посвящена в основном процессу генерации библиотеки элементов, а подробности проектирования в KiCad сделали бы статью ещё более раздутой.

Проектирование схемы

Создадим проект KiCad в директории .

Так как наша библиотека элементов является самодостаточной, можно удалить все библиотеки KiCad’а по умолчанию, и добавить только нашу :

Рисуем схему:

А в стиле GOST схема выглядела бы так:

QEDA избавляет от необходимости такого этапа, как ассоциирование посадочных мест условным графическим обозначениям (assign component footprint), так как каждому элементу уже ассоциировано уникальное посадочное место. Иначе говоря, Cvpcb запускать не придётся.

Генерируем netlist.

Проектирование печатной платы

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

Импортируем netlist, делаем auto-spread.

Ну а дальше «рисуем остаток совы». Трассировщик из меня не очень, поэтому прошу не судить строго.

Realistic 3D:

Генерируем gerber’ы и можно отдавать в производство.

Заключение

На простейшем примере мы рассмотрели процесс разработки печатной платы, как говорится, с нуля. Признаюсь, плата до производства не дошла, однако предпроизводственный контроль прошла успешно.

Планы на будущее:

• Испытать утилиту на более сложном проекте многослойной платы и довести её до производства.
• Документировать все настройки и возможности.
• Запустить веб-сервис, облегчающий работу с утилитой.
• Развивать сервис в сторону поддержки новых функций и разных EDA.

Исходники:

• Утилита: https://github.com/qeda/qeda
• Описания элементов: https://github.com/qeda/library
• Проект : https://github.com/qeda/examples/tree/master/wifi-adapter

Руководство по созданию скриптов в KiCad

Применение скриптов позволяет автоматизировать действия, выполняемые в
KiCad, с помощью языка программирования Python.

Дополнительно можете изучить doxygen-документацию на сайте
Python Scripting
Reference.

Можете просмотреть документацию на python-модули, набрав в
своём терминале.

С помощью скриптов можно создавать:

• Плагины: это особый тип скрипта, который загружается при запуске KiCad.
  Например:

  • Мастер посадочных мест: помогает создавать посадочные места простым
    заполнением параметров. Смотрите соответствующий раздел
    ниже.

  • Считывание/сохранение файлов ‘(планируется)’: позволят пользователям
    создавать плагины для экспорта/импорта файлов прочих форматов.

  • Действия ‘(тестируется)’: позволят связывать события с запуском скрипта,
    добавлять новые элементы меню или панелей инструментов.

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

В командной строке будет показано предупреждение, что из всех приложений
пакета KiCad, скрипты поддерживаются только в Pcbnew. В будущем также
планируется поддержка скриптов и в Eeschema.

Объекты KiCad

API (аппаратно-программный интерфейс) скриптов отражает внутреннюю структуру
кода Pcbnew. Главным объектом является BOARD (печатная плата), который
содержит набор свойств, а также MODULE (посадочные места), TRACK/VIA
(дорожки/переходные отверстия), TEXTE_PCB (надписи), DIMENSION (размеры),
DRAWSEGMENT (графические линии). В свою очередь, объект MODULE содержит
объекты D_PAD (контактные площадки), EDGE (контуры) и т.д.

Обзор основного API

Всё API из Pcbnew содержится в модуле «pcbnew», написанного на языке
Python. Функция GetBoard() возвращает объект печатной платы, открытой в
данный момент в редакторе. Полезна при выполнении команд из интегрированной
командной оболочки Pcbnew или для плагинов, выполняющих различные действия.

Загрузка и сохранение платы

• LoadBoard(filename):
  загружает плату из указанного файла и возвращает объект типа BOARD, формат файла определяется по расширению.

• SaveBoard(filename,board):
  сохраняет объект типа BOARD в файл, по расширению файла определяется формат записи.

• board.Save(filename):
  то же что и предыдущее, но вызывается метод из самого объекта типа BOARD.

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

BOARD

Далее приведено описание объекта BOARD, основного объекта в pcbnew KiCad.

BOARD содержит набор списков объектов, к которым можно получить доступ с
помощью следующих методов. Они возвращают перечисляемые списки, их
содержимое можно перебирать используя синтаксис «for obj in list:»

• board.GetModules(): возвращает список объектов типа MODULE — все доступные посадочные места, найденные на печатной плате.

• board.GetDrawings(): возвращает список объектов типа BOARD_ITEMS — графические элементы печатной платы

• board.GetTracks(): возвращает список объектов типа TRACK и VIA — дорожки и переходные отверстия

• board.GetFullRatsnest(): возвращает список связей, не завершенных соединений

• board.GetNetClasses(): возвращает список классов цепей

• board.GetCurrentNetClassName(): возвращает текущий класс цепей

• board.GetViasDimensionsList(): возвращает список размеров переходных отверстий, доступных для платы

• board.GetTrackWidthList(): возвращает список значений ширины дорожек, доступных для платы

Пример проверки платы

#!/usr/bin/env python2.7
import sys
from pcbnew import *

filename=sys.argv
pcb = LoadBoard(filename)

KiCad Build Version

The KiCad version string is defined by the output of when git is available or the version string defined in CMakeModules/KiCadVersion.cmake with the value of KICAD_VERSION_EXTRA appended to the former. If the KICAD_VERSION_EXTRA variable is not defined, it is not appended to the version string. If the KICAD_VERSION_EXTRA variable is defined it is appended along with a leading ‘-‘ to the full version string as follows:

(KICAD_VERSION)

The build script automatically creates the version string information from the git repository information as follows:

(5.0.0-rc2-dev-100-g5a33f0960)
 |
 output of `git describe --dirty` if git is available.

G2 Символы (УГО)

G2.1 Терминология

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

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

Есть компоненты, которые имеют вполне четкое посадочное место (футпринт) и part номер производителя. Им может быть назначен как вполне конкретный футпринт, так и фильтр, по которому можно в процессе проектирования назначить футпринт.

Полностью описанный компонент с посадочным местом, соответствующим его part номеру, называется атомарным компонентом (atomic symbol).

Шаг 2. Прочие настройки

Мы можем выбрать предпочитаемый способ генерирования посадочных мест (pattern) микросхем: рекомендуемый производителем или по стандарту IPC-7351. По умолчанию задан рекомендуемый производителем (значения по умолчанию задавать в настройках не обязательно, но мы продублируем их для демонстрации возможностей):

Те элементы, в чьих описаниях не содержится рекомендаций производителя, рассчитываются по стандарту IPC-7351. Стандарт предусматривает три уровня плотности компоновки (density level):

• Least () — самый плотный (рекомендуется при ограниченных габаритах печатной платы)
• Nominal () — нормальный (рекомендуется в большинстве случаев)
• Most () — наименее плотная компоновка (рекомендуется для плат, рассчитанных на жёсткие условия эксплуатации)

Так как мы не ограничены в габаритах, выбираем наименее плотный вариант:

Так как предполагается паять плату вручную, зададим ещё один параметр: минимальное расстояние от края вывода элемента до противоположного края его контактной площадки.

Также есть возможность настроить следующие параметры (в скобках указаны значения по умолчанию):

• (0.05): расстояние от края контактной площадки до края маски (раскрытие маски)
• (0.2): минимальная ширина пояска маски (имеет приоритет над предыдущим параметром)
• (0.12): толщина линии в слое шелкографии
• (1.2): высота шрифта для позиционных обозначений (reference designator)

Мы оставим эти параметры по умолчанию.

Кроме этого, есть возможность задать кое-какие настройки будущих условных графических обозначений (УГО) элементов (schematic symbol):

• (‘default’): стиль начертания УГО, альтернативный вариант: ‘GOST’
• (2.5): размер ячейки сетки привязки
• (2.5): высота шрифта для позиционных обозначений (reference designator)
• (2.5): высота шрифта для наименования элемента
• (2.5): высота шрифта для обозначения выводов

Их так же трогать не будем.

Typical Plugin Structure

The support is implemented in Pcbnew by discovering Python packages and Python script files in specific directories on startup. In order for the discovery process to work, the following requirements must be met.

• The plugin must be installed in the KiCad plugins search paths as documented in . You can always discover the search path for your setup by opening the scripting console and entering the command:

    `import pcbnew; print pcbnew.PLUGIN_DIRECTORIES_SEARCH`
  

  Currently on a Linux Installation the plugins search path is

  • /usr/share/kicad/scripting/plugins/
  • ~/.kicad/scripting/plugins
  • ~/.kicad_plugins/

  On Windows

  • %KICAD_INSTALL_PATH%/share/kicad/scripting/plugins
  • %APPDATA%/Roaming/kicad/scripting/plugins

  On macOS, there is a security feature that makes it easier to add scripting plugins to the ~/Library… path than to kicad.app, but the search path is

  • /Applications/kicad/Kicad/Contents/SharedSupport/scripting/plugins
  • ~/Library/Application Support/kicad/scripting/plugins
• Alternatively a symbolic link can be created in the KiCad plugin path link to the plugin file/folder in another location of the file system. This can be useful for development.
• The plugin must be written as a simple Python script (*.py) located in the plugin search path. Note that this method is preferred for small plugins consisting of a single .py file.
• Alternatively the plugin must be implemented as a Python package conforming to the Python package standard definitions (See ). Note that this method is preferred for larger plugin projects consisting of multiple .py files and resource files such as dialogs or images.
• The Python plugin must contain a class derived from and it’s method must be called within the plugin.

The following examples demonstrate the plugin requirements.

KiCad — редактор печатных плат

После построения схемы, ее проверки с помощью теста ERC, составления списка сетей и присвоения оболочек элементов их символам, пришло время выполнить проектирование печатной платы (PCB). В KiCad за это отвечает подпрограмма PCBNEW , это третий значок слева в менеджере проектов . Как видите, создатели программы последовательно разделяют отдельные этапы, планируя повторять их циклически в каждом последующем проекте.

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

Если мы подготовили такой файл заранее (name.net), все элементы должны появиться на, однако, может быть и такое:

Этот набросок — не что иное, как все корпуса элементов были размещены друг над другом в нулевой позиции системы координат листа. Однако, поскольку мы уже знаем, что все работает, мы должны расположить наши элементы рядом друг с другом (все еще в случайном порядке). Сначала включите значок ручного режима и автоматического перемещения и установки footprint. Затем щелкните правой кнопкой мыши на черном фоне и выберите параметры « Глобальное распространение» и «Макет» в контекстном меню — разделите все элементы footprint . Теперь на нашем экране отображает что-то вроде:

И давайте теперь выключим ручной и автоматический режим перемещения и установки foorprint.

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

По моему опыту, весь процесс проектирования плитки более просто с включением дюймовой сетки (калиброванной в мил). По умолчанию для сетки задано значение 50 миль (1,27 мм), это значение основано на наиболее распространенных растровых экранах для различных элементов. Однако контур плитки будет выгоднее рисовать на метрической сетке с сеткой 1 мм. После его настройки выберите (вверху) слой Egde.Cuts и инструмент « Добавить линию или многоугольник» (значок справа), нарисуйте прямоугольник (завершите двойным щелчком мыши). Затем, логическим образом мы упорядочиваем элементы на нашей плате в последовательности, используя сочетания клавиш , и . После окончания этого этапа мы должны получить более или менее похожую картину:

Далее мы начинаем рисовать пути. Для простоты мы предполагаем, что в нашем проекте все элементы размещены на верхнем слое ( F.Cu ). Переключение между слоями путей F.Cu / B.Cu выполняется клавишей . Клавиша переносит вас в верхний слой, а — в нижний слой . Выберите верхний слой и нарисуйте первый путь (клавиша ). Конец пути отмечен двойным щелчком. Когда закончите, нажмите клавишу , и у нас будет обзор нашей печатной платы.

Мы можем отключить отображение некоторых слоев, чтобы оценить внешний вид интересующих нас элементов.

Часто выполняемое действие — «выливание» массы на всю плитку или какую-то ее область. Здесь мы реализуем это с помощью зеленого значка Add zone на правой панели инструментов, определяем, к какому слою относится область (в нашем случае это верхний слой путей), выбираем сигнал, с которым мы его соединяем (в данном случае с GND), и рисуем область, которая будет поверхностью массы. Мы получаем дополнительный прямоугольник с прикрепленными внутренними диагональными линиями. Вы также можете нажать или выберите опцию Fill Zone из контекстного меню. Если ERC не сообщает об ошибках, мы получаем следующую картину:

Если мы хотим отменить заполнение зоны, мы нажимаем последовательность — .

После окончательной редакции печатной платы, в программе реализована возможность предварительного 3D просмотра детали. Выбираем меню View — 3D Browser и спустя некоторое время наблюдаем за 3D моделью вашей платы.

S3 Общие требования к символам УГО

S3.1 Начало координат по центру компонента

Симметричные компоненты должны быть отцентрированы относительно начала координат (0, 0) в редакторе символов УГО. Для несимметричных символов УГО следует распологать его как можно ближе к началу координат, но так чтобы не сдвинуть пины компонента с сетки .

S3.2 Текстовые поля должны использовать размер текста 50mil

Все текстовые поля символа УГО должны иметь размер в . Разрешается уменьшать размер текста имен и номеров выводов до , если этого требует геометрия символа УГО.

S3.3 Обводка символа и заливка

1. Толщина линий символа УГО должна равняться ().
2. Микросхемы и другие компоненты со скрытым функционалом должны заливаться фоновым цветом.
3. Дискретные компоненты не должны заливаться фоновым цветом.

S3.4 Символы УГО со сложной функциональностью

Для символов УГО компонентов с некоторой сложной функциональностью допускается внутри тела символа рисовать функциональную схему, если она размещается в небольшом пространстве УГО.

Пример неверного символа УГО

Примеры правильного расположения выводов УГО

S3.6 Смещение позиции имени вывода

1. Смещение позиции имени вывода не должно превышать ().
2. Смещение позиции имени вывода не должно быть меньше ().
3. предпочтительное значение смещения.

S3.7 Нумерация выводов

Для микросхем, имеющих выводы отвода тепла (Exposed Pad), подключаемые к земле, нумерация начинается с числа на один больше, чем количество выводов микросхемы.

Для SOIC-8 с одним выводом теплоотвода его номер равен .

Экранируемые компоненты должны использовать в качестве номера выводов, к которым подключается экран, «SH». Монтажные выводы без электрических соединений должны получать номер вывода «MP».

S3.8 Символы УГО из нескольких частей

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

Specific System Requirements

KiCad supports major operating systems that remain supported by their developers. After the
operating systems’ respective organizations stop releasing updates for the system, KiCad will
not be specifically tested with the unsupported system. Unsupported operating systems may
continue to work with KiCad beyond this time but bugs must be reproduced on a supported operating
system before they will be addressed by KiCad.

Windows

The software prerequisites for installing KiCad on a Windows system are as follows:

Operating System	Support Status
Windows 7	Unsupported, will most likely still function
Windows 8	Unsupported, will most likely still function
Windows 8.1	10-Jan-2023
Windows Server 2012	10-Oct-2023
Windows Server 2016	10-Oct-2027
Windows Server 2019	09-Jan-2029
Windows 10	09-Jan-2029

Apple — macOS

The software prerequisites for installing on a macOS system are as follows:

Operating System	End of Support
macOS 10.12	Unsupported
macOS 10.13	Unsupported
macOS 10.14	1-Aug-2021
macOS 10.15	1-Aug-2022

GNU/Linux

The following Linux distributions have been tested and are known to be working with
KiCad version 5.1.
Issues or bugs that occur on an unsupported platform must be reproduced on an officially
supported distribution and window manager before they will be addressed by KiCad.

Note: Development versions of the next KiCad release (version 6) may not function
on some of the older distributions listed below.

Ubuntu

Operating System	End of Support
Ubuntu 16.04 (LTS)	Unsupported, will most likely still function
Ubuntu 18.04 (LTS)	1-Apr-2021
Ubuntu 18.10	Unsupported, will most likely still function
Ubuntu 19.04	Unsupported, will most likely still function
Ubuntu 19.10	Unsupported, will most likely still function
Ubuntu 20.04 (LTS)	approx May 2023

Long Term Support (LTS) releases of Ubuntu will be supported for 1 year after the next
LTS version is released (for a total of 3 years of support).

Non-LTS releases of Ubuntu will be supported while the version
is under standard support from Ubuntu.

Fedora

Operating System	End of Support
Fedora 29	Unsupported, will most likely still function
Fedora 30	Unsupported, will most likely still function
Fedora 31	approx November 2020
Fedora 32	approx May 2021

Fedora releases will be supported for as long as they are supported by the Fedora Project
(usually for 1 year after release).

Debian

Operating System	End of Support
Debian 9 (Stretch)	approx 2020
Debian 10 (Buster)	approx 2022

Debian releases will be supported for as long as they are
by Debian.

Additional Linux Considerations

Linux allows users to select their preferred window manager. There are many esoteric window
managers available for Linux and some may have unexpected behavior. KiCad officially supports
the following window managers:

• Metacity (used by GNOME 2 and GNOME flashback)

• Mutter (GNOME 3)

• KWin (KDE)

• Xfwm (used by XFCE)

• i3 (Arch Linux)

• Unity (Ubuntu prior to 18.04)

Graphical Windowing Backend

Regardless of the window manager, KiCad officially only supports the X11 backend. Users who
choose to use Wayland will have to run KiCad in the compatibility layer
XWayland.

Issues or bugs encountered while using XWayland must be reproduced under X11 before they
will be addressed by KiCad. Bugs that cannot be reproduced on X11 should be reported to
the Wayland bug tracker.

Other systems (notably Unix *BSD) may be fully functional but are not officially supported.

Simple Plugin Example

The folder structure of the simple plugin is fairly straight forward. A single Python script file is placed into a directory that is present in the KiCad plugin path.

+ ~/.kicad_plugins/ # A folder in the KiCad plugin path
    - simple_plugin.py
    - simple_plugin.png (optional)

The file contains the following.

import pcbnew
import os

class SimplePlugin(pcbnew.ActionPlugin):
    def defaults(self):
        self.name = "Plugin Name as shown in Pcbnew: Tools->External Plugins"
        self.category = "A descriptive category name"
        self.description = "A description of the plugin and what it does"
        self.show_toolbar_button = False # Optional, defaults to False
        self.icon_file_name = os.path.join(os.path.dirname(__file__), 'simple_plugin.png') # Optional, defaults to ""

    def Run(self):
        # The entry function of the plugin that is executed on user action
        print("Hello World")

SimplePlugin().register() # Instantiate and register to Pcbnew

Note that if specified must contain absolute path to the plugin icon. It must be png file, recommended size is 26×26 pixels. Alpha channel for opacity is supported. If icon is not specified a generic tool icon will be used.

only defines a default state for plugin toolbar button. Users can override it in pcbnew preferences.

KiCad Config Directory

The default KiCad configuration directory is . On Linux this is located at , on MSW, this is and on MacOS, this is . If the installation package would like to, it may specify an alternate configuration name instead of . This may be useful for versioning the configuration parameters and allowing the use of, e.g. and concurrently without losing configuration data.

This is set by specifying the KICAD_CONFIG_DIR string at compile time.

Getting the KiCad Source Code

There are several ways to get the KiCad source. If you want to build the stable version you can down load the source archive from the GitLab repository. Use tar or some other archive program to extract the source on your system. If you are using tar, use the following command:

tar -xaf kicad_src_archive.tar.xz

If you are contributing directly to the KiCad project on GitLab, you can create a local copy on your machine by using the following command:

git clone https://gitlab.com/kicad/code/kicad.git

Here is a list of source links:

Stable release archives: https://kicad-pcb.org/download/source/

Development branch: https://gitlab.com/kicad/code/kicad/tree/master

GitHub mirror: https://github.com/KiCad/kicad-source-mirror

Building KiCad on Linux

To perform a full build on Linux, run the following commands:

cd <your kicad source mirror>
mkdir -p build/release
mkdir build/debug               # Optional for debug build.
cd build/release
cmake -DCMAKE_BUILD_TYPE=Release \
      ../../
make
sudo make install

If the CMake configuration fails, determine the missing dependencies and install them on your system. By default, CMake sets the install path on Linux to /usr/local. Use the CMAKE_INSTALL_PREFIX option to specify a different install path.

Building KiCad on Windows

The preferred Windows build environment is MSYS2. The MinGW build environment is still supported but it is not recommended because the developer is responsible for building all of the dependencies from source which is a huge and frustrating undertaking. The MSYS2 project provides packages for all of the require dependencies to build KiCad. To setup the MSYS2 build environment, depending on your system download and run either the MSYS2 32-bit Installer or the MSYS2 64-bit Installer. After the installer is finished, update to the latest package versions by running the file located in the MSYS2 install path and running the command . If the msys2-runtime package is updated, close the shell and run .

Building using MSYS2

The following commands assume you are building for 64-bit Windows, and that you already have the KiCad source code in a folder called in your home directory. See below for changes if you need to build for 32-bit instead. Run from the MSYS2 install path. At the command prompt run the the following commands:

pacman -S base-devel \
          git \
          mingw-w64-x86_64-cmake \
          mingw-w64-x86_64-doxygen \
          mingw-w64-x86_64-gcc \
          mingw-w64-x86_64-python2 \
          mingw-w64-x86_64-pkg-config \
          mingw-w64-x86_64-swig \
          mingw-w64-x86_64-boost \
          mingw-w64-x86_64-cairo \
          mingw-w64-x86_64-glew \
          mingw-w64-x86_64-curl \
          mingw-w64-x86_64-wxPython \
          mingw-w64-x86_64-wxWidgets \
          mingw-w64-x86_64-toolchain \
          mingw-w64-x86_64-glm \
          mingw-w64-x86_64-oce \
          mingw-w64-x86_64-ngspice \
          mingw-w64-x86_64-zlib
cd kicad-source
mkdir -p build/release
mkdir build/debug               # Optional for debug build.
cd build/release
cmake -DCMAKE_BUILD_TYPE=Release \
      -G "MSYS Makefiles" \
      -DCMAKE_PREFIX_PATH=/mingw64 \
      -DCMAKE_INSTALL_PREFIX=/mingw64 \
      -DDEFAULT_INSTALL_PATH=/mingw64 \
      ../../
make install

For 32-bit builds, run and change to in the package names and change the paths in the cmake configuration from to .

For debug builds, run the cmake command with from the folder.

S4 Требования к выводам символов УГО

S4.1 Общие требования к выводам

1. Следует использовать сетку () при размещении выводов (IEC-60617).
2. Длина вывода должна быть не менее ()
   • Длина вывода может быть увеличена с шагом ()
   • Длина вывода определяется количеством символов в номере вывода. Если 2 символа — длина , 3 — и т.д.
   • Длина вывода не должна превышать ().
   • Более короткие выводы разрешены для дискретных компонентов, таких как резисторы, конденсаторы и т.д.
   • Все выводы символа УГО должны быть одной длины.
3. Номера выводов должны быть уникальными. Недопустимо, чтобы два вывода имели один и тот же номер.

S4.2 Группировать выводы следует по функциям

Конечно, только там где это возможно, лучше следовать этому правилу, нежели группировать их по расположению на посадочном месте компонента.

1. Пример выводов одной функциональности:
   • , , ,
   • ,
2. Нумерация портов должна следовать сверху вниз.
3. Выводы положительного питания размещаются сверху символа УГО
4. Выводы отрицательного питания и земли размещаются снизу символа УГО
5. Входы / Выводы контроля / Логики должны располагаться слева
6. Выходы / Выводы управления / Драйверы должны располагаться справа

S4.3 Правила размещения выводов

Многие символы УГО имеют посадочные места, в которых несколько физических пинов подключены к одной логической цепи (к примеру ). В таких случаях желательно, чтобы пользователь в схеме подключал только один вывод и он автоматически бы соединялся со всеми физическими пинами на плате.

Сделать это можно разместив выводы одной цепи в одной и той же позиции в символе УГО. Каким условиям должны соответствовать выводы, чтобы быть объединены в одной позиции:

1. Выводы не должны быть типа , т.к. такие выводы никогда не должны соединяться на плате.
2. Выводы питания должны быть размещены таким образом, если только в даташите не сказано, что каждый вывод питания должен иметь свои развязывающие конденсаторы.
3. Выводы должны быть логически соединены в символе УГО.
4. Выводы должны иметь одно и то же имя.
5. Выводы должны иметь один и тот же электрический тип.
6. Один вывод из стека должен быть видимым (все остальные делаются невидимыми).

S4.4 Электрический тип вывода

Электрический тип вывода должен быть установлен так, чтобы совпадать с соответствующей функцией

1. Питание и земля устанавливаются как () и () соответственно.
2. Логические выводы устанавливаются в соответствии с рекомендациями даташита на компонент.
3. Выводы с программируемой функциональностью должны быть установлены как ().
4. Выводы с инверсией следует устанавливать с использование символа инверсии и чертой над именем вывода.

S4.5 Выводы, не подключаемые к посадочному месту могут быть опущены в символе УГО

Условия:

1. Выводы могут быть проигнорированы в символе УГО, если они никогда не будут подключены в схеме ни при каких условиях.
2. Не подключенные выводы делают символ УГО неоправданно большим и плохо читаемым.
3. Если выводы маркируются по даташиту как (Not Connected), но сказано, что они должны быть подтянуты к питанию или земле, то такие выводы должны быть размещены на символе УГО.
4. Также фильтр посадочного места компонента должен содержать информацию о количестве выводов компонента

В противном случае выводы делаются скрытыми и не могут исключены из символа УГО.

S4.6 Скрытые выводы

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

Исключения

1. Выводы питания, которые связаны с глобальными метками символов питания.
2. Выводы, которые не предназначены для подключения в схеме. В этом случае тип вывода также должен быть установлен в (). Подключаемый конец такого вывода следует разместить внутри графического обозначения символа, как показано на скриншоте ниже.
3. Невидимые выводы могут группироваться как было описано в пункте S4.2.

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