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

Чаще всего, когда речь заходит о стендах тестирования электронных устройств, мы представляем массовое производство. Там подобные стенды не просто правило хорошего тона, а острая необходимость. И это правильный подход! На эту тему есть пара интересных статей: «Как выглядит тестирование электроники Flipper Zero», «Серийное производство электроники в России. Автоматизация тестирования».

На многопоточных производствах обычно используют готовые решения для тестирования и отладки устройств, такие как PCBA Test, Semco Machine Corporation или INGUN. Для первичной отладки оборудования готовые решения могут не подойти: у них большие габариты (стенд может занимать треть стола Embedded-разработчика), компоненты таких стендов труднодоступны для модификации.

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

В этой статье мы поделимся опытом создания стендов для отладки.

TL,DR: gerbmerge+pdf merge+non-kicad interactivebom позволяет нам эффективно склеивать очень похожие, но при этом разные по форме и нюансам платы электронных блоков управления ДВС. Другие новости про rusEFI, до сих пор ищем единомышленников :)

В статье от 2014 года https://habr.com/ru/post/244737/ рассказ об открытом электронном блоке управления двигателями внутреннего сгорания rusEFI остановился на плате Frankenso. За четыре года мы продали 100 юнитов rusEFI, потом за последние 12 месяцев мы продали ещё 100 более современных юнитов, многому научились - но всё равно продолжаем пытаться понять, чего же именно мы хотим. Сейчас мы смещаем фокус с универсальности на устройства для конкретных семейств автомобилей с конкретными разъёмами и схожими распиновками ЭБУ, этим мы в том числе мечтаем привлекать программистов, которым не комфортно паять.

Давайте для начала я расскажу про Hellen https://github.com/andreika-git/hellen-one - это наш инструментарий разработки семейства модульных, склеенных из кусочков похожих, но всё-таки разных плат под конкретные проводки конкретных автомобилей.

Примерно год назад стало понятно, что универсальные блоки слишком сложны в поддержке: возможность управлять практически любым бензиновым двигателем с почти любыми оригинальными датчиками и формами сигналов ДПКВ/ДПРВ достигается только за счёт огромных усилий по поддержке нашей очень небольшой командой экспертов. При этом результат механически и электрически обычно выглядит всё равно очень плачевно. И со своей стороны мы устали сильно много допаивать руками после изготовления платы сервисом JLCPCB. Вместо большого универсального https://rusefi.com/s/proteus и маленького универсального https://rusefi.com/s/microrusefi ЭБУ мы решили сделать пару десятков ЭБУ под конкретные распиновки конкретных популярных автомобилей, изначально оптимизированных именно под JLCPCB каталог компонентов. Не хотелось разрабатывать и поддерживать много плат под конкретные автомобили ручным копированием блоков схемы и блоков трассировки. Наше решение: Hellen One Framework, это набор скриптов для склеивания gerber, PDF схем, описаний монтажа и HTML просмотрщика плат.

Делимся с вами расшифровкой и записью эфира .

Компьютерный стол у меня появился на два года раньше компьютера, в 2004 году. Это был обычный стол, у которого даже были полки для монитора и клавиатуры. За ним я научился всему, а спустя 17 лет он всё так же стоит у моих родителей.

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

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

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

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

Особенность таких параметров заключается в том, что их нельзя писать просто так в одно и то же место EEPROM, вы просто израсходуете все циклы записи EEPROM. Например, если, необходимо писать время работы один раз в 1 минуту, то нетрудно посчитать, что с EEPROM в 1 000 000 циклов записей, вы загубите его меньше чем за 2 года. А что такое 2 года, если обычное измерительное устройство имеет время поверки 3 и даже 5 лет.

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

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

Разбираемся с «чёрными ящиками» и c тем, какими они бывают сегодня

• Вы работаете со сторонним ПО, разработчики которого просто не раскрывают код.
• Вы взаимодействуете с API, внутренняя логика которого абстрагирована.
• У вас нет необходимых полномочий для доступа к Git-репозиторию.
• Даже система с полным доступом может де-факто стать «чёрным ящиком» из-за своей сложности.
• Сотрудник, обладавший всеми ключами и знаниями, внезапно уволился/пропал/умер.
• Легаси-система состоит из .dll, которая «всегда работала» на сервере, и не была подключена к системе контроля версий. Чтобы просто посмотреть на код, её нужно декомпилировать, если это возможно, конечно.

То, чего не может быть: почему наши глаза не дружат с компьютером?

Сложная завязка

Предыстория...

Исследование

Заказывая много оценочных плат из Китая, я и подумать не мог что всюду будет брак, недоработки и подделка. Всё это ужасно путало в изучении, поэтому было принято делать свою оценочную плату с блэкджеком и светодиодами!

Как я реализовал удаленное управление и мониторинг, для программируемого реле ПР200, используя разные сервисы (Telegram Bot, HomeKit) протоколы (Modbus RTU, Modbus TCP, mqtt) и ESP32.