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

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

Описание проекта

Кратко опишу все требования, которые я выдвигал к разрабатываемому устройству:

• Наличие цифровых входов\выходов

• Интерфейсы CAN, RS-485, UART, SPI, I2C

• Генератор ШИМ

• Компактность

• Возможность подключать модули расширения для увеличения функционала устройства.

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

В процессе разработки также пришла идея реализовать режим терминала, превращающая устройство в универсальный преобразователь интерфейсов. Программы и железо, которые я использовал, не всегда устраивали меня — например, софт CAN анализатора от microchip не запоминал введенные пользовательские команды и каждый раз их приходилось вводить заново, а в COM терминалах не хватало возможности переключить ввод между hex и ASCII (не добавляя каждый раз символ $, а просто поставить галочку и печатать). Мысль о возможности сделать свой открытый терминал, в который можно будет добавлять все, что душе угодно, захватила меня не меньше, чем идея сделать контроллер для стендов.

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

Прошёл год с моей предыдущей публикации о первой версии и за это время я значительно переосмыслил концепцию устройства, которым бы пользовался на регулярной основе в процессе разработки и отладки новой электроники. Изначально я делал проект автономным и всё управление происходило через сенсорный дисплей от компании DWIN, но с увеличением объема функционала стало ясно, что дисплей и микроконтроллер не справятся с нагрузкой. Поэтому все управление было перенесено на компьютер, а сам девайс только выполняет команды, полученные от ПК.

Схемотехника и корпус

Мультитул представляет из себя небольшую плату в пластиковом корпусе, на борту у него:

• Микроконтроллере stm32g4

• Выходы: 2 x PWM, 4 x цифровых выхода, 2 x входа

• Интерфейсы: CAN, RS-485, UART, 2 х SPI, I2C

• Разъем для взаимодействия с ПК - USB Type-C 

• Выходной разъем PBD30R

Выходным разъемом выбрана PBD с шагом 2.54 мм для удобства — можно взять PLS и сделать на нем нужный кабель, или же взять угловой PLD, макетку и сделать простую плату расширения — разъемы эти часто есть под рукой.

Корпус напечатан на 3д принтере из PETG, состоит из двух половинок и соединяется с помощью винтов М3 и вплавляемых гаек. На корпусе располагается прозрачная пластиковая наклейка, на которой написано название прибора и расположение выводов. Ранее я делал надписи на корпусе печатными, но сейчас габариты корпуса настолько маленькие, что от этого варианта я отказался сразу же. Наклейки же позволяют делать на них пометки, что актуально в случае модуля, который может быть запаян в разных конфигурациях (например разные адреса I2C).

Отдельно упомяну модули расширения — это схожие по размеру и габаритам с Лучом устройства, которые подключаются к главному модулю и увеличивают его возможности. На данный момент я изготовил только один модуль — расширитель портов ввода‑вывода. Модули сделаны сквозными, чтобы иметь возможность подключать несколько штук друг за другом, в том числе и разных (конечно если они используют разные интерфейсы). В данном случае оба модуля используют I2C шину, но имеют разные адреса — на плате можно запаять перемычки для разных конфигураций, а на наклейке отметить, в какую именно конфигурацию запаян данный модуль. 

ПО

Рассмотрим для начала программу, которая задает алгоритм действий: 

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

Самое интересное здесь — прием сообщения, он организован как прием диапазона данных. Это сделано для того, чтобы можно было проверять корректность диапазона измерения какого‑либо параметра, например, как в примере ниже — захват частоты или значение измеренного напряжения (параметр может плавать, и можно проверить, что он не выходит за диапазон). Дополнительно указывается время в мс, сколько ждать прихода сообщения. 

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

В центре можно увидеть сформированный алгоритм. Тут команды уже представлены в виде json строк, которые будут отправлены на контроллер. При желании команды можно подправить вручную. Список действий можно сохранить и загрузить из обычного.txt файла.

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

Данное ПО я написал на C# еще в начале года, но в будущем я планирую перенести его на QT C++, на котором написан терминал, в угоду мультиплатформенности. 

Собственно терминал:

Как я писал ранее, пока поддерживает UART, CAN и RS-485. Позволяет отображать сообщения в hex и ASCII формате, задавать скорость общения и хранить пользовательские сообщения. Я довольно долго не мог выбрать, сделать под каждый интерфейс свое окно отображения или единое окошко для всего, но выбрал второй вариант, только поле слева содержит разные кнопки в зависимости от интерфейса. Чего в этой программе пока нет, так это работы с ошибками на линиях, периодической отправки сообщения и возможности отправить файл. Думаю, в ближайшее время все это добавлю.

Работа в качестве тестера

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

Первым делом настраиваю RS-485, затем провожу два теста. В первом я меняю состояние вывода DOUT4 и проверяю, что испытуемый фиксирует изменения. Во втором тесте я задаю ШИМ сигнал и запрашиваю значение частоты с точностью в 1% (подал 100 Гц — удовлетворительным результатом в ответе будет значение от 0×63 до 0×65). В самом конце запрашиваю, какое напряжение питания измерил прибор (проверка, что 12В). 

Запустив тестирование на полностью исправном приборе я получаю следующий ответ:

Отлично, все проверяется. Теперь попробуем нарушить целостность устройства, вынув провод RS-485. Выходят ошибки всех проверок ответов:

Каждая строка содержит информацию о номере действия, которое пошло не так, как хотелось бы, и тип действия. 

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

Данный проект находится на этапе опытного образца, из функционала умеет пока только работать по CAN, щелкать релюшками и проверять состояние своих входов. В этом тесте воспользуемся двумя модулями ввода-вывода, один из них сконфигурирован полностью как вход, второй полностью как выход.

Тест будет состоять из двух частей: в первой части «луч» посылает команду — замкни реле, а после проверяет, замкнулось ли (тест выходов), во втором же подает на входы платы сигнал и опрашивает по CAN, изменилось ли их состояние. 

Тест выдал две ошибки — плата считала со своих входов значение, отличное от того, что подали. Все дело в том, что 4 входа из 12 открываются напряжением 24В, а модуль DIO выдает максимум 5В. В будущем нужно будет заложить возможность использовать более высокое напряжение в модулях, либо сделать отдельный модуль с большим напряжением. Тестирование же реле прошло как по маслу.

По итогу «луч» может работать как тестер, и время написания кода в данных случаях было минимальным. Но прибор требует некоторых доработок или же новых модулей расширения для работы с более высоким напряжением как минимум.

Выводы

Поработав с устройством и модулями к нему, я получил удовлетворение от того, что прибор стал похож на то, что я хотел. Аппарат действительно может выполнять те цели, для которых я изначально его задумывал — на нем можно быстро накидать алгоритм, сделать кабель на pls, подключить и протестировать прототип. Следующую версию устройства я смогу проверять уже на предыдущей. Теперь хочется большего + исправить некоторые недочеты:

• Механика: уже после сборки дополнительных модулей я понял, что вариант с угловыми двойными разъемами не очень удобный — в длину 30 их не так уж и много на рынке, из частей собрать не получится, так как точки соединения дают дополнительную ширину, а самое главное, они немного разные по высоте. Решение этой задачи простое — нужно паять не боковой разъем, а обычный разъем сбоку, как на картинке:

• Изменения буду вносить и в 3д модели — корпус должен быть единообразным для модулей и базового луча, хочется отойти от вплавляемых гаек — точность попадания у меня хромала и толщину пластика для них нужно закладывать побольше, а вплавляемые гайки М2 вообще не держались в корпусе. Думаю просто перейти на закладные гайки.

• ПО требует доработки, особенно список системных команд — хочется добавить возможность заводить переменные для цикла, чтобы сократить объем алгоритма. Софт для написания порядка действий я думаю перенесу на QT, потихоньку перехожу на линукс и задумываюсь об мультиплатформенности.

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