Швейцарский нож для embedded разработчика.

Швейцарский нож для embedded разработчика.

Разработка embedded устройств — это моя работа и хобби. За все время, проведенное за этим занятием, у меня накопилось много «поделок» и «недоделок» различных инструментов для отладки и тестирования: USB-UART преобразователи, JTAG адаптеры, разного рода программаторы и т.д. Рассматривая весь этот «зоопарк» устройств, мы (я и несколько моих друзей) задумались, а можно ли сделать одно многофункциональное устройство, которое выполняло бы функции всех этих инструментов отладки. Сделать что-то аналогичное швейцарскому армейскому ножу для embedded разработки.

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

«Классическими» инструментами при отладке и тестировании embedded устройств всегда были осциллограф и мультиметр (паяльник и прочие инструменты «разрушающего» тестирования в данной статье я упоминать не буду). Но с помощью только этой «классики», отлаживать устройства довольно неудобно и требует особого творческого подхода. Поэтому для перенаправления творческой энергии в другое — более «мирное» русло, были придуманы различные устройства для облегчения процесса отладки. Некоторые из этих устройств необходимы буквально всем разработчикам (например, программаторы), некоторые нужны для углубленной отладки (отладчики, логические анализаторы), некоторые могут применяться для комплексного тестирования (преобразователи интерфейсов и различные отладочные платы).
Идея заключается в создании лабораторного прибора (назовем его Fibell MultiTool), в котором:
  • реализовано максимальное количество отладочных функций
  • реализован интерпретатор языка сценариев
  • логика работы отладочных функций пишется на языке сценариев (в виде пользовательских скриптов)

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

Такое решение имеет несколько преимуществ:
  1. Все «в одном флаконе».
    Один прибор всегда удобнее использовать, чем набор устройств.
  2. Независимость от ПК.
    Прибор имеет минимальные зависимости от программного обеспечения на ПК.
  3. Быстрый отклик.
    Выполнение пользовательских скриптов на приборе позволяет обеспечить быстрый отклик на сигналы отлаживаемой системы. Это повышает скорость обмена и эффективность тестирования и отладки.
  4. Постоянное время выполнения скриптов.
    Длительность выполнения скриптов не зависят от загруженности ПК.
  5. Интеграция функций.
    Возможность совместной синхронизированной работы нескольких отладочных функций. Например, остановка/запуск сканирования сигналов логическим анализатором с помощью «breakpoint» в GDB и т.д.

Набор функций отладки.
После долгих обсуждений и споров был определен минимальный набор функции, которые должен поддерживать
Fibell MultiTool:
  1. ISP Программаторы — Протоколы ISP Atmel, JTAG, ICSP PIC.
    Было решено реализовать только функции внутрисхемного программирования и отказаться от функции программирования отдельных микросхем, так как это приводит к усложнению конструкции прибора (добавлению разъемов под разные socket-ы микросхем, дополнительные уровни напряжения питания и тд.)
  2. Отладчик — JTAG/SWD dongle для OpenOCD.
    OpenOCD — открытый проект отладочного сервера для GDB отладчика (openocd.sourceforge.net). Схему отладки можно описать как: целевое устройство + Fibell_MultiTool(JTAG/SWD dongle) + OpenOCD + GDB. Задача JTAG/SWD dongl-а передавать данные между целевым устройством и OpenOCD/GDB.
  3. Логический анализатор — 8 входов/24Мгц.
    Реализация уже «стандартного» в DIY среде анализатора (типа Salea Logic) на базе SUMP/Logic Sniffer(sump.org).
  4. Преобразователи интерфейсов. — Интерфейсы RS232, RS485, UART, I2C, SPI, 1Wire, USB-VCOM.
    Для работы с интерфейсами выбрана модель «drivers-pipes», похожая на «pipe» подсистему в Linux. То есть между интерфейсами и виртуальными устройствами (такими как shell, файл и т.д.) можно организовывать каналы обмена данными, что позволяет разрабатывать гибкую систему протоколирования или подстроить работу прибора под конкретную задачу.

Aрхетиктура Fibell MultiTool.
Архитектура прибора построена на нескольких основных концепциях:
  1. Использование языка сценариев для написания логики работы устройства.
  2. Использование модели drivers-pipes для обмена данными внутри устройства.
  3. Реализация только «цифровой» части всех интерфейсов.
  4. Использование специальных плат расширения для реализации «аналоговой» части всех интерфейсов.
  5. Логический анализатор выполнен на отдельном микроконтроллере для получения максимальной производительности.


Архитектуру прибора Fibell MultiTool можно представить в виде модели drivers-pipes. Все модули прибора представлены как драйвера (drivers), которые могут соединяться между собой в каналы (pipes) по определенным правилам. Для каждого интерфейса прибора (UART, SPI и тд.) реализован свой драйвер. Shell, файловая система и другие программные модули реализованы как виртуальные устройства со своими драйверами. Таким образом, создавая каналы между драйверами, можно сконфигурировать прибор под разные цели.
Например, вы можете соединить в pipe драйвера UART/RS232 и USB-VCOM интерфейсов и получите стандартный USB-RS232 преобразователь интерфейсов, а можете соединить драйвера JTAG и USB-COM и получить JTAG донгл для OpenOCD.
Однако интерфейсы UART, I2C, SPI, GPIO — это только интерфейсы физического уровня и для передачи данных по ним часто необходимо реализовать специальные протоколы обмена, для I2C это могут быть I2C EEPROM или SMBus, для UART/RS485 — ModBus и ProfiBus и тд. Поэтому для реализации специальных протоколов обмена или любой другой пользовательской логики в прибор был добавлен интерпретатор языка сценариев. Из всех возможных вариантов был выбран язык Lua (проект eLua).
Lua выбран по нескольким причинам:
  1. Существует реализация Lua для embedded проектов. (проект eLua)
  2. eLua предлагает полнофункциональную реализацию Lua.
  3. Lua считается одним из самых быстрых языков сценариев.
  4. Достаточно не большой объем используемой памяти для работы Lua интерпретатора.


Пользовательские скрипты на языке Lua могут обмениваться данными со специальными Lua-драйверами, которые являются частью общей drivers-pipes модели. Таким образом, например, объединяя в pipe драйвер I2C интерфейса и Lua-драйвер/скрипт, можно получить возможность управлять I2C интерфейсом и реализовать алгоритм чтения I2C EEPROM.

Функциональная схема Fibell MultiTool.
Fibell MultiTool построен на двух модулях- CPU и CoCPU. На CPU выполняются основные алгоритмы работы устройства, а на СoCPU выполняется алгоритм работы логического анализатора. Модули связанны между собой по внутренней I2C шине.
Устройство имеет четыре коммуникационных порта для связи с целевой системой (Port1, Port2, Port3, Port4):
  • Port1 — разъем GPIO и цифровой части UART интерфейсов.
    На этот разъем могут подключаются платы расширения с аналоговой частью UART интерфейсов (например RS232, RS485, LIN и тд.).
  • Port2 — дублирует Port1.
    Разъем выведен на переднюю панель прибора для удобства подключения сигналов Port1 к логическому анализатору.
  • Port3 — разъем JTAG, I2C, SPI, 1Wire, GPIO интерфейсов.
  • Port4 — разъем логического анализатора.

Для хранения скриптов, конфигураций и других данных, Fibell MultiTool поддерживает работу с SD-дисками.
Для связи с компьютером используется USB 2.0 HS протокол. При подключении к ПК прибор распознается как четыре USB-устройсва:
  • USB disk — внешний SD диск.
  • VCOM1 — виртуальный COM порт 1
  • VCOM2 — виртуальный COM порт 2
  • Cypress — специальный драйвер логического анализатора


Интерфейс для ПК и общее состояние разработки.
Как и весь прибор, интерфейс для ПК в разработке. Пока для тестирования и отладки мы используем отдельные утилиты (ZeroBranе Studio -для Lua, TerraTerm — для shell и тд.)
В планах создание интегрированной среды для отладки скриптов, конфигурирования устройства и тд. Также в планах создание системы обновления прошивки прибора и реализация SUMP анализатора на Cypress микросхеме и еще много чего другого.
На данный момент был создан первый вариант Fibell MultiTool без анализатора и с USB 2.0 FS.

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


  • +2
  • 01 февраля 2014, 12:03
  • trapper

Комментарии (38)

RSS свернуть / развернуть
Автор, вы когда-либо слышали о Bus Pirate?
Штука даже поболее функциональна вышенаписанной. Недостаток — ограниченная скорость. Можете назвать характеристики вашего устройства? Число замеров лог.анализатора, максимальные скорости портов ввода-вывода?
«Модули связанны между собой по внутренней I2C шине.» — вот это настораживает. Т.е. пропускная способность любого интерфейса равна 400 кБод?
Китайские чудо-коробки имеют осциллограф (10 МГц 8-бит). Не спорю что качество у него плохое, но выручал много раз. Так же имеют ШИМ, полезный при отладке систем с сервомашинками или диммерами.
Хотите сделать швейцарский нож? Сделайте настоящий Victorinox, а не «предмет, внешне напоминающий...». Поставьте там АЦП, мелкую ПЛИСку с ОЗУ для осциллографа/ЛА, добавьте защиту входов и аналоговые части для RS232 — RS485, питание с защитой по току 3.3 и 5 В хотя бы на 250 мА. Чтобы я доставал прибор из кармана и не думал «эх, а переходник дома остался». Пусть дороже, но вы должны быть чем-то лучше десятков подобных плат.
И да, напоминаю что настоящие швейцарские ножи имеют пожизненную гарантию.
0
Спасибо за развернутый комментарий.

“Число замеров лог.анализатора” – 24Мгц. 8 бит,

“максимальные скорости портов ввода-вывода” – не очень понимаю параметр, если просто дрыгать ножкой из Lua скрипта – то порядка 75 mks один “дрыг”. Но честно говоря я не думаю что это самое полезное использование

Да конечно я слышал и про Bus Pirate и про FT232 и даже про Versaloon.
Как вы правильно заметили проблема Bus Pirate скорость — мало того что он обрабатывает данные на ПК так еще и весь обмен идет через COM специальными ESC последовательностями(если я не ошибаюсь). Для прошивки и даже отладки (хоть и очень медленной) но вполне сойдет, но для тестирования работоспособности системы, ИМХО слабовато.

По поводу анализатора — I2C шина необходима только для управления, данные в ПК он посылает через USB 2.0 HS как нормальный китаец. (Я даже на рисунке USB хаб нарисовал, но в тексте об этом забыл упомянуть). Идея анализатора — сделать архитектуру полностью аналогичную Salea Logic/USB Вee, чтобы товарищи которые «не парятся» по поводу авторских прав могли запустить эти анализаторы, конечно исключительно в демонстрационных целях.

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

Про вечную гарантию не знал… просто ассоциация понравилась.
0
А сколько памяти в ЛА? Насчет ограниченной скорости: если вся периферия висит на I2C, то это значит что и SPI, и JTAG ограничены скоростью шины. А если будет насколько активных устройств на шине? 400 кбод SPI это откровенно слабо.
Насчет защиты. Не утверждаю, что надо делать ее по MIL-STD с опторазвязкой, но я буду этим прибором тыкать в неведомые девайсы с неведомыми уровнями, переполюсовкой и черт знает чем еще. Сделайте так чтобы прибор прожил дольше одного неверного подключения. Вы уже потратили кучу времени и средств для написания нетривиального софта, добавление парочки защитных диодов, восстанавливаемого предохранителя, АЦП и ШИМ-выходов цену кардинально не изменит.
0
По ЛА пока нечего сказать (я сам туда пока Salea Logic прошиваю ;) ) разработка SUMP ЛА пока “в проекте”.

Вся периферия не висит на I2С вас по-видимому ввела в заблуждения “общая шина” к Port3 на рисунке. Я имел в виду, что Port 3 это конструктивно один разъем, который можно использовать для JTAG | I2C | SPI, переконфигурируя прибор. А так, все эти интерфейсы — это аппаратные интерфейсы микроконтроллера модуля CPU, которые специальными драйверами интегрируются в общую систему.

Конечно, простая защита “от дурака” будет на всех выходах прибора. Но серьезные (а поэтому не часто необходимые ) защиты и развязки, предполагается делать на плате расширения. При этом я рассматриваю плату расширения, как неотъемлемую часть прибора, сейчас не предполагается что она будет “hot plug” (на последнем рисунке она видна справа, такие DEGSON клемники для RS-485/UART/RS232 интерфейсов).

По поводу вывода ШИМ-сигналов, спасибо за идею, я думаю их можно добавить вот про АЦП надо подумать… все таки общая идея — это отладка «цифровой части», а «аналоговую» часть предполагалось оставить осциллографу
0
ADC стоит копеечные копейки, как и DAC. А эти вещи резко расширяют диапазон прибора: осциллограф, вольтметр, генератор сигнала. Я бы сделал 2 исполнения прибора: один для цифровой электроники и МК, а второй для автомобильной, промышленной электроники итд: с защитой, RS422/485/232, CAN и разъемами крупными.
0
Насколько я помню, применяемый в USBee (а ЛА-часть сего девайса — это он и есть) АЦП не столь уж копеечный.

Алсо, вопрос к автору: какой МК используется в качестве основы девайса? «CoCPU» — понятно, что CY7C68013. Алсо, что мешало весь девайс сделать на нем?
0
Микроконтроллер для основы девайса – STM32F417IET6
Сейчас планирую попробовать STM32F439IIT6, так как у STM32F417IET6 какая-то “органическая” несовместимость с USB3300. Мне их так и не удалось вместе запустить. А на STM32F439IIT6/USB3300 уже даже evaluation board иметься.
Выбрал по нескольким причинам:
— Нужна скорость и память для работы с Lua. Конечно первый вариант был на STM32F103 и он тоже работает, но памяти на более-менее сложные скрипты уже не хватало.
— Для Cortex-M3 (M4) есть поддержка в eLua проекте.
— Нужен многоногий и “многоинтерфейсный” chip для одновременной работы максимального количества интерфейсов.
— Ну и главное :). C Cypress я пока еще не работал, использование его как coCPU было только из соображений совместимости с USBee/Salea Logic.
0
В СТМ-ке есть приличные ЦАП и АЦП, надо лишь придумать как гнать данные в Кипарис согласно спецификации USBeeAX или придумать свой осциллограф. С ЦАПом вообще всё очень просто: добавить пару таблиц в прошивку и готов генератор сигналов.
0
Я предпочту прибор, предназначенный для какой то конкретной задачи, будь то программатор или лог. анализатор. Функцииональность таких сборных солянок обычно не дотягивает до функциональности узкоспециализированного устройства.
+1
  • avatar
  • Bonio
  • 01 февраля 2014, 14:14
Это закрытый проект или схемы/исходники будут открыты для повторения/доработки?
0
  • avatar
  • Vga
  • 01 февраля 2014, 17:28
На данный момент проект разрабатывается как “закрытый” (по крайней мере для firmware прибора). Однако если команде не хватит энергии и энтузиазма, чтобы довести дела до конца, тогда мы опубликуем исходники.
0
Что у вас за команда, где посмотреть?
0
Команда — я и два моих друга, которые, по мере своей занятости и лени :), поддерживают проект.
Подробности в “личке”…. хочется оставить топик, так сказать, “в техническом русле”.
0
Лично для меня самая интересная часть это интеграция интерпретатора Lua во FreeRTOS. Думаю многие будут благодарны за отдельную статью об этом, да загрузке скриптов из SD.
0
Да, у меня есть такая идея взять eLua, PICOC, и какой-нибудь Python-on-a-chip и устроить их соревнование в FreeRtos среде. … но пока нет времени для реализации такого проекта.
0
Есть ещё один прибор — мультитул. Проект на Кикстартере. Проект открытый, может что из него вам пригодится.
0
Рассматривали уже здесь. Это игрушка, не годится для чего-либо серьезного. Посмотрите сколько памяти у этого «ЛА» и «осциллографа».
0
У DSO Nano — столько же, и вполне хватает. И, кстати, еще совсем недавно большие цифровые осциллографы имели сравнимый объем памяти — порядка 16к сэмплов.
Для карманного «всегда с собой» прибора характеристики вполне неплохи.
0
А что за корпус используется?
0
  • avatar
  • x893
  • 02 февраля 2014, 15:11
Корпус вот такой Z-91
0
А можно 16 бит 400MHz логический анализатор с записью в память только изменений?
Мне по работе нужно иногда отснифать параллельный протокол на скорости 12 MHz по 11-проводной шине, который передаёт только 20 байт и редко. Покупать тяжелый Л/А для этого и пускать винду для софта нет ни малейшего желания, а все китайцы этого не могут.
0
  • avatar
  • dekar
  • 04 февраля 2014, 14:18
На данный момент, мы хотим сделать довольно простой логический анализатор, чтобы «пощупать» SUMP/Logic Sniffer. До такой «крутизны» — 16бит и 400MHz нам пока далеко.
0
Скажите, а как связаны 12МГц таргета и 400МГц анализатора?
0
Ну давай смотреть:
1) для корректной обработки периодических сигналов надо иметь сэмпл-рейт больше, чем 2хнесущую.
2) для непериодических сигналов надо делить каждый фрейм на фазу ниспадающей несущей (falling edge), фазу удержания внизу (clock down), рост несущей (rising edge) и удержание ввержу(clock up). Это минимум 4 частоты — 48MHz
3) для определения глюков и отлова расхождения по фазе надо ещё делить на 16 (смотри описание функционирования USART модуля в stm32, там расписано, как) получаем 192MHz.
Да, 400 я сказал с запасом. 200 хватает. Но только при записи актов изменения — иначе никакого буфера не хватит искать сигналы с частотой раз в 2 секунды и записывать их последовательность.
0
USART — странича 747 документа RM0008
www.st.com/web/en/resource/technical/document/reference_manual/CD00171190.pdf
0
400 МГц ЛА это дорогое удовольствие. Сделать его нормально можно только на плисине с продвинутой логикой портов. У меня был фирменный 32-канальник на 500 МГц, и он врал как сивый мерин. Понятно что хорошая плисина + ОЗУ + быстрые буфера портов будут стоить денег.
0
400МГц это слишком конечно.
1) Найквист Котельников критерий: соглашусь
2) и 3) противоречат друг другу. При чем тут UART? Если сигналы в линии синфазны, то где клок? И пункт 3 отпадает. Если явно клока нету, его выделяют из (фазы) данных. Если же это просто набор слабосвязанных линий (?) то почему они в одном интерфейсе.

Учитывая, что вольтаж и способ передачи данных неизвестны, это еще *20 вариантов. Чем передается бит? Вольты, амперы, направление тока? По скольким проводам, один или дифф пара.?

Для начала нужно знать тип интерфейса однозначно. Затем брать буфер для этого типа интерфейса и подключать к логике захвата клока (если клок есть). И только после этого отдавать плисине. В итоге эта задача решится гораздо проще. Частотой порядка 4 тактовых. Таким способом мне удавалось оцифровать 80+ МГц информации.
0
если сигналы синфазны, то зачем они нужны? Как правило, если есть сигналы, которые надо снифать, то эти сигналы идут с 2-х разных устройств. Если устройства 2, одно ведущее, а другое ведомое — это разве слабосвязанные линии? Но ловить глюки, связанные с неуспеванием одного из них, уже надо. Сейчас делаю это осциллографом. Страдаю безмерно.
Судя по вопросу про USART чукча не читатель. Жаль, там красиво описан механизм дешевого измерения таймингов, рекомендую ознакомиться.
Отцифровать и дебажить — разные действия.
0
Насыапал на голову пепел и ушёл.
0
согласен. Плисина — 1000р, буфера — 150р, ОЗУ — 200р.
Сумма — 1350р.
0
Разработка хорошей платы и запрограммирование плисины — несколько сот Кр. Нечего себя обманывать, ЛА выше 100 МГц и ниже 150 долларов хорошим быть не может.
0
это не так. С нынешней элементной базой и техпроцессами самая сложная часть — щупы.
0
А дураки из HP и Agilentа-то не знают! Сделайте хотя бы 32-х канальник на 250 МГц, тогда поменяете мнение. С нормальной синхронизацией каналов и вменяемым входным импедансом и чувствительностью.
0
щупы…

Нет, я серьёзно. ПЛИС ко мне приедет завтра. Буфера на полочке, а CST Microwave Studio лежит в загашнике. Если поможешь с проектированием щупов — сделаем.
0
При всём моём уважении к самоделкам, я питаю нездоровую страсть к качественной измерительной технике с пломбами поверки, и мой работодатель ее удовлетворяет. Что касается щупов, предлагаю купить б/у шлейф от старенького HP — стоит немного, и не надо морочиться с придумыванием своего крепления. Но особой магии я там не видел, обычная лента с землёй через одну. А вот гнездо уже согласованно.
0
ок. Параметры для Microwave Studio есть?
0
на самом деле проблемы с согласованием начинаются где-то с 0.5 GHz — 200 MHz должно хватить. Работают же линии связи с флеш-памятью в мобильниках.
0
На шлейфы и аппаратуру от HP хорошая документация, не знаю какие именно параметры нужны, и с Microwave studio никогда не работал.
0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.