Как создать своими руками контроллер

Как сделать свой микроконтроллер?

Давно хотел сделать свой микроконтроллер. Но не знаю как и с чего начать. Искал в интернете, но ничего не нашёл.

Если кто знает что, помогите. Я изучаю arduino. Уже собирал несколько схем. Подключал различные модули и т. д.

3 ответа 3

Сделать собственный микроконтроллер не так сложно, как кажется. Но для отладки точно потребуется осциллограф.

Возьмите плату ПЛИС, например, производства Terasic, и изучайте Verilog и VHDL.

Возможно, Вам будет небезынтересно ознакомиться с моими собственными статьями по этой теме.

Именно микроконтроллер у вас навряд ли получится сделать, так как МК — это процессор + периферия. А что бы сделать процессор очень рекомендую почитать Харрис и Харрис «Цифровая схемотехника и архитектура компьютера». Есть в свободном доступе, например, http://easyelectronics.ru/files/Book/digital-design-and-computer-architecture-russian-translation.pdf Книга отличная! Все дается с азов, а заканчивается она разработкой процессора с набором команд MIPS.

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

Для написания и тестирования не нужны даже платы, вся отладка должна идти на симуляторе (ModelSim, QuestaSim), только так можно выявить и исправить все ошибки.

Писать нужно синтезируемые конструкции, т.е. прогонять проект через синтизатор. Тестирование должно заключаться в том, чтобы программа откомпилированная под AVR работала точно также как на микроконтроллере. HDL позволяет её загрузить из файла в память процессора.

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

Источник

Сайт про изобретения своими руками

МозгоЧины

Сайт про изобретения своими руками

Как сделать контроллер мотора на основе МОП-транзистора

Как сделать контроллер мотора на основе МОП-транзистора

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

Данная поделка проста по конструкции, может быть использована в качестве электронного контроллера скорости (ESC), и имеет прямое и обратное управление. Спектр ее применения от робототехники, устройств дистанционного управления, портативного транспорта, до других разнообразных проектов, использующих моторы.

Поделка-контроллер состоит из минимума деталей и миниатюрна по размерам, что дает ей возможность легко помещаться в ваши мозгопроекты. Схема контроллера основана на схеме «управления большими нагрузками» из моих предыдущих проектов и содержит только один МОП-транзистор и диод. Это позволяет микроконтроллеру управлять скоростью мотора. А для возможности обратного управления я добавил DPDT реле, еще один МОП-транзистор и диодную пару для контроля смены полярности.

Думаю, что это мозгоруководство будет вам интересно!

Шаг 1: Инструменты и материалы

Как говорилось, эта поделка проста и использует минимум деталей:

• макетная плата — используйте любую вам доступную
• тонкий провод — я взял одиночный 24 калибра
• МОП-ранзистор — 2шт.- я использовал IRF510, но сгодится и любой эквивалентный, например, NTE2382
• DPDT реле 30В — на фото показана не та реле
• выпрямляющий диод — 2шт.
• штырьковые разъемы — лучше взять те, которые можно «отломать» на нужное количество штырьков.

А еще понадобятся некоторые инструменты:

• паяльник и припой
• клеевой пистолет
• изоляционные кусачки
• дремель или что-то подобное для обрезки макетной платы

Шаг 2: Компоновка деталей

На макетную плату помещаем все мозгодетали, причем таким образом, чтобы можно было легко их спаять согласно схеме при наименьших габаритах. От штырьковой полосы отделяем кусочек с 2-мя контактами и кусок с 4-мя контактами (если вы планируете припаять контакты двигателя непосредственно к плате, то 2-х штырьковый разъем не понадобится). На 2-х контактном отрезке укорачиваем штырьки с обоих сторон, а на 4-х контактном загибаем под углом 90 градусов штырьки одной стороны с помощью изоляционных кусачек, либо другого подходящего инструмента.

Шаг 3: Пайка

После того, как детали размещены на плате, проводим пайку согласно схеме представленной выше, и используем для этого любые удобные вам паяльник и припой. В качестве дорожек используйте кусочки провода, для близко стоящих контактов — не изолированные отрезки провода, а для далеко стоящих — изолированные перемычки, зачищенные с обоих концов. Омедненая макетная мозгоплата конечно лучше подойдет для наших целей, но обычная плата дешевле. Так же на этом этапе можно припаять провода мотора или как я, 2-х штырьковый разъем.

Шаг 4:Обрезка платы

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

Шаг 5: Доработка

Осталось добавить несколько штрихов и «защитить» мозгоподелку. Изоляционными кусачками обрезаем торчащие концы проводков, при этом не повреждая целостность схемы. Можно использовать для этих целей и плоскогубцы, раскачивая в стороны проводки пока они не обломятся. Затем зигзагообразными покрываем плату горячим клеем, тем самым защищаем ее от возможного замыкания и повреждений, получится должно примерно как на фото.

Шаг 6: Контроллер готов, используем его!

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

Подключение к микроконтроллеру:

• Подключаем мотор к контроллеру мотора через соответствующий разъем.
• Вставляем контроллер мотора в макетную плату.
• С помощью разноцветных проводов соединяем Vin поделки с Vin микроконтроллера, GND с GND микроконтроллера.
• Используя еще два провода соединяем контакты «speed» и «reverse» контроллера мотора с двумя контактами микроконтроллера по вашему усмотрению.
• Запрограммируйте микроконтроллер.

• Не превышайте напряжение 30В на Vin.
• Не путайте контакты.
• Если вы используете напряжение выше 15В на Vin, то подключите Vin и GND непосредственно к источнику питания, и заземлите микроконтроллер, соединив его GND и GND источника питания.
• При работе с большими мощностями на МОП-транзистор установите радиатор.
• Применяйте только двухконтактые моторы постоянного тока.На этом все, благодарю за мозговнимание!

( Специально для МозгоЧинов #DIY-MOSFET-Motor-Controller

Источник

Делаем контроллер для умного дома

Делаем контроллер для умного дома и не только.

В предыдущей статье я описывал разработку системы в целом. В этой я опишу разработку контроллера, который отвечает за опрос датчиков и модулей ввода-вывода. «Зачем изобретать велосипед?» — спросите вы. Во-первых, это интересно, во вторых, как ни странно, нет OpenSource решения для подобного контроллера, покрывающего как программную так и аппаратную часть. Статья ориентирована на людей немного разбирающихся как в электронике так и в embedded linux development.

Сделать контроллер, скажете вы, это же так сложно — нужно делать плату, писать софт, печатать корпус. Но в реалии всё чуть-чуть ещё сложнее, вот во что это вылилось для меня, но вы в принципе правы:

1. аппаратная часть контроллера

— выбор cpu платы для контроллера
— выбор IO контроллера
— выбор блока питания
— структурная схема контроллера
— разработка кросс платы для контроллера
— разработка плат для RS-485 модулей
— производство плат

2. софт для контроллера

— выбор системы сборки для ядра linux и rootfs
— структура разделов SD карты
— выбор бутлоадера и загрузка нужного rootfs
— изменения в device tree
— выбор системы сбора дебажных трейсов
— написание билдсистемы
— написание коммуникационного ядра
— написание mqtt гейтвея (дискретные/аналоговые точки контроллера -> топики mqtt)
— написание парсера гуглтаблицы и построение конфигурационного json файла для гейтвея
— написание point monitor для доступа к точкам контроллера
— монтирование readonly файловой системы

3. корпус контроллера

— какой должен быть, разъёмы, охлаждение, посадочные места под плату, закладные под клипсы для скоб на динрейку.
— конструирование и печать

Пару слов о аппаратной части.

Наверно только самые отчаянные сейчас берут отдельно процессор, память, флеш, контроллер питания, еще пару сот компонентов и начинают лепить это всё вместе. Остальные же пользуются плодами трудов других людей, так быстрее и проще. Нужно всего лишь открыть браузер и написать «одноплатный компьютер» и весь остаток дня провести в выборе нужного. Мне нужно было много последовательных портов и желательно что бы плата поддерживала -40°C до +85°C, поэтому выбор пал на BeagleBone Black(BBB). Также на ВВВ вся периферия выведена на два разъёма PBD по 46 пинов с шагом 2.54, что удобно для макетирования и разработки кросс платы. Кросс плата нужна что бы объединить все компоненты на одной плате, у меня это — cpu плата, блок питания, IO контроллер, и платы каналов RS485. Также именно кросс плату нужно крепить к корпусу и на ней стоят разъемы для подключения питания и кабеля RS485.

Так, с cpu платой разобрались, следующее что надо решить — нужно ли на кросс плату ставить Input/Output(IO) контроллер или можно и без него. Я его заложил на плату, и успешно им пока не пользуюсь. Единственное что он делает это откладывает старт BBB на 1с после подачи питания и обслуживает кнопку reset.

Блок питания для контроллера я взял уже готовый MeanWell NSD10-12S5, разрабатывать его для единичного девайса — бессмысленная затея, просто подобрал его по потреблению и всё. На ЖКИ не обращайте внимание, он есть на плате, но поддержку я не реализовал.

Пару слов о платах каналов RS485.

На кросс плату выведены 4 последовательных интерфейса BBB. Так что туда можно поставить любой тип канала который нужно, RS485, CAN, Zigbee модуль…

Мне нужны были каналы RS485, так что я сделал только их, они с автоматическим управлением приемом/передачей и с гальванической развязкой. Почему не использовать управление приёмо-передачей с ВВВ, да потому что TI официально перестали поддерживать строб для RS485 в драйвере serial устройства. Можно найти патч к драйверу, можно дописать самому, но зачем? Сделав канал самостробирующий, можно его будет ставить на любую плату, например на RaspberyPi, где никогда и не было такой поддержки, если была, то поправьте меня. Строб для драйвера rs485 формируется на attiny10, дешево и сердито.

Возвращаемся к софту.

Выбор системы сборки для ядра linux и rootfs.

Существует несколько подобного рода систем, самые популярные это Yocto и BuildRoot. Ели вам нужно разработать большой проект, если у вас много времени и желания писать рецепты, то Yocto — ваш выбор. С помощью же BuildRoot, можно собрать всё что нужно для простого запуска платы очень и очень просто, т.к. я делаю систему на Beaglebone Black (далее ВВВ) то:

1. почитать что написано здесь habr.com/ru/post/448638
2. make clean
3. make beaglebone_defconfig
4. make

Вот и всё. Теперь всё необходимое для запуска платы, лежит в папке /buildroot/output/images.

Выглядит всё очень просто и не интересно, так что можно сделать немного посложнее:

1. интегрировать buildroot в свою билдсистему, скачивать его скриптом, не забыв использовать стабильный тэг, а не брать последний develop
2. написать свой defconfig и перед сборкой buildroot подкидывать его скриптом в папку /buildroot/configs, не забываем что все дефконфиги должны заканчиваться на *_defconfig, иначе buildroot его не видит
3. копировать свой post-build.sh в board/beaglebone/post-build.sh
4. сделать prepare скрипт, который будет делать п1, п2 и п3 за вас

Как результат buildroot будет генерировать zImage и rootfs.tar

Выбор структуры разделов SD карты:

На этом, думаю, не стоит много акцентировать внимание.
Я сделал 4 раздела BOOT / ROOT_1 / ROOT_2 / DATA.
В BOOT разделе хранится всё необходимое для начальной загрузки: MLO, barebox.bin, barebox.env, am335x-boneblack.dtb, zImage, boot.txt.

ROOT_1 и ROOT_2 содержат rootfs, выбор которого вписан в файле boot.txt(см. ниже). Все эти разделы монтируются как readonly во избежания крешев файловой системы при выключении питания. DATA содержит проектные конфиги, при изменении которых нет необходимости пересобирать код.

Такая структура разделов в будущем позволит легко написать software update компоненту. Эта компонента будет перезаписывать один из разделов ROOT_1/ROOT_2, который сейчас не используется, а потом просто менять файл boot.txt, если не нужно менять ядро.

У меня было много экспериментов с бутлоадерами для BBB. Сначала я использовал, как все, U-Boot который генерирует BuildRoot. Но мне он не понравился, может быть, конечно, это дело привычки, но мне показалось что это перебор, уж очень он тяжелый и сложно конфигурируемый. Потом, я подумал что не плохо бы было стартануть систему быстро, секунды за 2-3, и подпилив X-Loader так что бы он грузил ядро, у меня это получилось, но опять же остался вопрос с конфигурированием, да и время старта для меня не критично(система на systemd грузится сама по себе медленно, даже если удалить всё не нужное).

В конце концов я остановился на barebox, его простота мне очень понравилась, плюс на сайте есть вся документация (www.barebox.org).

Например, что-бы грузить rootfs c первого или второго раздела нужно всего лишь:

1. на boot разделе сделать файл boot.txt который экспортит переменную типа «export BOOT_NUM=Х»

2. сделать два скрипта /env/boot/sdb1 /env/boot/sdb2 в которых описать параметры загрузки, например:

3. сделать скрипт /env/boot/sd в котором в зависимости от BOOT_NUM стартовать sdb1 или sdb2 скрипт

4. установить переменную boot.default

5. далее меняя BOOT_NUM в boot.txt мы будем загружать rootfs с первого или второго раздела, что в будущем можно использовать для software update.

Изменения в device tree.

Поскольку для связи с модулями я использую MODBUS RTU по RS485, то мне нужно было включить практически все существующие на ВВВ последовательные порты. Для этого надо заэнэйблить их в device tree, т.к. по умолчанию большинство из них выключены.

Правильно бы было сделать свой патч для файла am335x-bone-common.dtsi из пакета билдрута и применять его каждый раз перед его сборкой, но лень победила, и я просто вытащил все нужные файлы, поменял всё что нужно и сбилдил руками.

Т.к. это делается один раз, то можно и так:

1. Создаем папку с файлами необходимые для сборки:

2. В файле am335x-bone-common.dtsi нужно правильно настроить пины и заэнейблить драйверы портов:

3. Далее немного магии, и готовый файл am335x-boneblack.dtb лежит в этом же каталоге:

b. запускаем препроцессор:

c. запускаем сам компилятор:

4. am335x-boneblack.dtb нужно положить на boot раздел рядом с ядром и в скрипте запуска для barebox добавить следующую строчку — » global.bootm.oftree=/boot/am335x-boneblack.dtb «

Выбор системы сбора дебажных трейсов.

Как известно систем без багов не бывает, как и анализа многопоточной системы без трейсов. Очень удобно если эти трейсы не выводятся просто в консоль, а собираются чем-то специально для этого созданным, да так что бы можно было сортировать их по процессам, применять фильтры и т.д. И я как раз знаю одну неплохую систему, которую легко собрать как под host так и под target. Это DLT, если вы никогда не слышали об этом, то это не беда, все пробелы в знаниях можно легко покрыть прочитав at.projects.genivi.org/wiki/display/PROJ/Diagnostic+Log+and+Trace.
Данная система состоит из dlt-daemon и dlt-viewer. Как и понятно из названия dlt-daemon запускается на таргете, а dlt-viewer на хосте. Плюс к этому всему, к своему бинарнику, с которого мы хотим собирать трейсы, нужно прилинковать dlt либу.

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

Зачем писать билдсистему, ведь можно всё скачать с репозиториев, сбилдить руками, собрать на основе этого rootfs и вуалля, контроллер работает. Но повторить такой трюк через месяц будет сложнее, а через два — так вообще невозможно. Опять придётся вспоминать что, куда положить, что сбилдить и как запустить. Поэтому потратив немало времени сначала, вы экономите его потом, плюс вы получаете возможность удобно билдить под host и target. Билдсистема состоит из набора скриптов, которые сначала подготавливают host для билда, скачивают сторонние компоненты, такие как buildroot, mosquitto, DLT daemon, с их репозиториев, билдят их, раскладывают по своим местам. А уж потом можно запускать билд вашего проекта. Если билд под host, сделать не сложно, то с билдом под таргет всегда нужно повозиться, и лучше что бы это делал скрипт.

Buildroot можно сконфигурировать так что бы он вызывал post-build скрипт после того как он сформирует rootfs, которая будет лежать в buildroot/output/target. Это даёт отличную возможность вам положить туда всё то, что вам нужно. И тогда, образ файловой системы уже будет содержать всё необходимое для запуска вашей системы.

Рецепт примерно такой:

1. надо скопировать свои бинарники куда-то в buildroot/output/target, например в /opt/bin
2. если есть конфиги, то с ними сделать то же самое, только в /opt/etc
3. скопировать сторонние бинарники, для меня это mosquitto, DLT daemon, их либы и конфиги
4. Что бы при загрузке контроллера система стартанула сама — нужно скопировать ваши systemd сервисы, лучше их объединить в свой target и заэнэйблить его сделав симлинку в multi-user.
5. скопировать модифицированный fstab(зачем, расскажу позже)

После этого вам достаточно распаковать buildroot/output/images/rootfs.tar на нужный раздел SD карты и включить питание.

Написание коммуникационного ядра.

Концепция этого стара как сам modbus.

У каждого устройства ввода-вывода в modbus сети есть регистры(16 bit), доступные на чтение, чтение/запись, в которых хранятся данные и через которые идет управление этими устройствами. У контроллера, в свою очередь, есть массивы дискретных(статус и byte значение) и аналоговых точек(статус и float значение), в которых он и хранит состояние всех параметров.

Так вот, задача коммуникационного ядра проста — собрать данные с устройств ввода-дывода по протоколу modbus, замапить их на точки контроллера и предоставить доступ к этим точкам для верхнего уровня. А если вам надо чем-то управлять, то всё в другую сторону — логическое устройство(об этом позже) должно быть подписано на точку контроллера и запись в эту точку инициирует трансляцию этого параметра в физическое устройство вода-вывода.

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

Также я решил разделить логические устройства на две группы:

1. Стандартные (модули Овен дискретного ввода/вывода), для которых заранее известны номера modbus регистров с данными, и достаточно только определить точки контроллера куда сохранить эти данные.
2. Пользовательские устройства, для них надо самостоятельно описывать маппинг modbus регистров на точки контроллера.

Из всего выше сказанного логично иметь какой-то конфигуратор для контроллера, будь то просто json конфиг или самописная тула генерирующая бинарный конфиг, подходит что угодно. У меня второй вариант, потому что были идеи писать коммуникационное ядро так, что бы его можно было легко запускать не только на линукс борде но и на Ардуине с FreeRtos, меняя PAL уровень в софте.

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

Такой конфигурационный файл, содержащий все необходимые данные по конструированию modbus сети, позволяет не модифицировать исходный код для проекта если надо добавить/удалить/изменить устройства ввода-вывода, достаточно изменить параметры в конфигураторе и сохранить их в конфиг файл.

При старте коммуникационное ядро разбирает конфиг и создает на его базе списки логических устройств для каждого rs485 порта контроллера, после этого создаются потоки на каждый порт и начинается циклический опрос физических устройств.

Написание mqtt гейтвея.

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

Т.к. параметров у меня довольно много, то постоянно возникали путаницы в файле конфигурации гейтвея, где был прописан маппинг точек контроллера на mqtt топики гейтвея. Помогла гугл таблица, и написание csv парсера этой таблицы в конфигурационный json файл для гейтвея.

Написание point monitor.

Иногда очень полезно посмотреть что же сейчас происходит с точками контроллера, для этого я написал небольшое приложение который подключается непосредственно к коммуникационному ядру и считывает состояние дискретных и аналоговых точек. У меня довольно-таки туго с UI так что кое-как смог накидать приложение на QML, оно со скрипом заработало, можно считать точку, можно её записать, а мне большего и не надо.

Монтирование readonly файловой системы.

Обычно этому мало кто уделяет внимание, и даже в продакшен проектах можно встретить устройства в которых партишен с rootfs доступен на запись. Это рано или поздно приводит к крешу любой, даже самой устойчивой файловой системы. Т.к. контроллер может быть выключен в любой время, то это лишь вопрос времени/случая когда это произойдет. Что бы минимизировать эту вероятность надо немного повозиться с fstab и перед сборкой образа rootfs, положить его туда, как было описано выше. В fstab, во-первых, надо примонтировать файловую систему как readonly а во вторых всё что может меняться замапить в tmpfs.

Мой fstab таков, у вас он может отличатся:

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

Рисуем в FreeCAD, генерим gcode в Cura и получаем корпус, не забыв сделать посадочные места под плату, вырезы под разъёмы и охлаждение и закладные для клипс на din рейку.

Ну вот и всё, теперь у нас есть плата, софт на SD карте и корпус. Берем напильник(не шучу) и соединяем всё вместе, подключаем питание, кабели RS485 и всё начинает работать. А вы говорили сложно, сложно…

Источник