Как стать автором
Обновить

Комментарии 11

Доходчиво, спасибо! Как-то попытался на скорую руку и усталую голову переделать под свои нужды готовый декодер (как и советуют), быстро утонул в кортежах с непонятными цифрами и ушел обрабатывать экспортированный бинарник «дедовским способом» на голом Python.
Маленькое уточнение: что если между передним и задним фронтами SDO DV окажется фронт SCL (например мы начали захват посреди отправки данных)? В ожидание заднего фронта DV напрашивается дополнительное условие SCL: ‘e’ по ИЛИ и возврат в начальное состояние.

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

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

Так я и предлагаю обнаружить и пропустить некорректные случаи (изменение SCL во время DV импульса). Довольно частые в практике ситуации: в захват попали переходные процессы при инициализации пинов, либо начали захват посреди пакета, декодеры подхватывают этот мусор и «плывут».

С этим согласен. Возможно, даже стоит добавить отдельную аннотацию на подобные случаи, как это сделано в некоторых стандартных декодерах.
А я в своём декодере даже фильтровал сигналы, если они короче некоторого порога. Просто DSL если фронт пологий начинает осцеллировать на переходном процессе на максимальной частоте (практически в 1 сэмпл). У Saleae (16ти канальная версия с ПЛИС) такого не замечал.
image
image
А вот как при написании ошибки отлаживать? Бывает очепятался или совсем чушь спорол, а оно тупо не запускается без визгов и обид. Как понять что ей не нравится?
Да, этот момент стоило отметить. Сама библиотека имеет собственную систему логирования с несколькими уровнями сообщений. По умолчанию включен уровень SRD_LOG_WARN(2), а все сообщения пишутся в stderr. Но если запустить DSView на Windows из командной строки, то логи не отображаются, видимо приложение создает собственную консоль. При этом, перенаправление стандартных потоков продолжает работать. Например, если убрать свойство 'license' для пустого декодера, запустить DSView с уровнем логирования SRD_LOG_INFO(3) и перенаправлением вывода, то получим:
>DSView.exe -l3 2> log.txt
>cat log.txt
srd: Failed to load decoder empty: no 'license' attribute

Аналогичным способом можно получить и весь список возможных опций DSView, которых не так много.
DSView.exe -h > help.txt
>DSView.exe -h > help.txt
>cat help.txt
Usage:
  DSView [OPTION…] [FILE] — A GUI for instruments of DreamSourceLab
Help Options:
  -l, --loglevel        Set libsigrok/libsigrokdecode loglevel
  -V, --version         Show release version
  -h, -?, --help        Show help option

Очень подробно и понятно, спасибо.
Блин, буквально на днях адаптировал свой декодер, написанный давно под «api_version = 2» и переставший работать на новой версии под «api_version = 3». Отлаживать научился через put прямо на график, если нет ошибок в синтаксисе.

В статье упущен важный момент: в какую папку класть декодер?
По умолчанию sigrok ищет декодеры в двух папках:

  • Для всех пользователей, если вы собирали sigrok самостоятельно: в папке /usr/local/share/libsigrokdecode/decoders/

  • Для всех пользователей, если вы ставили sigrok из репозитория: в папке /usr/share/libsigrokdecode/decoders/

  • Для конкретного пользователя: в папке /home/$USER/.local/share/libsigrokdecode/decoders

Добавлю свои 5 копеек по поводу отладки.

  1. Для отладки, как верно было выше замечено, надо установить режим отладки с помощью параметра командной строки (-l[0;5]) и перенаправить вывод stderr в файл. То же самое можно сделать в интерфейсе - справа вверху есть меню Help, внутри Log Options. Логирование в файл, настроенное через интерфейс в винде пишет в файл, находящийся в "%USERPROFILE%\AppData\Roaming\DreamSourceLab\DSView\dsview.log". Оба варианта (запись лога через stderr и настроенная через интерфейс) могут работать параллельно. В файл будут писаться логи самого DSView, а так же исключения python.

  2. В набор модулей для встроенного в DSView python входит модуль logging, который можно использовать для вывода отладочных сообщений внутри скрипта. Модуль стандартный, очень гибкий, описание есть в питонячей документации. Настраиваете модуль на запись в файл и выводите все что нужно. logging можно настроить так, чтобы отлаживать одновременно несколько декодеров, каждый в свой файл.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории