Да, этот момент стоило отметить. Сама библиотека имеет собственную систему логирования с несколькими уровнями сообщений. По умолчанию включен уровень 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 пришлось исследовать самостоятельно. Поэтому решил, что материал будет полезен.
Насчет уточнения, если я правильно понимаю документацию к микросхеме, то DV формируется, когда микросхема находится в состоянии ожидания, а для этого линия SCL в течении 2 мс. должна находится в пассивном состоянии. По активному сигналу на SCL микросхема переходит в режим чтения и до его завершения сигнал DV не выставляется. Единственно, что ведущее устройство может начать читать данные, не дожидаясь завершения сигнала DV, тогда фронт SCL может оказаться между началом и концом DV. Но в этом случае, это скорее некорректная работа мастер-устройства.
Как написала vikky13, CM действительно долгое время разрабатывался в Intel, но не был публично анонсирован и задокументирован. Например, давайте возьмем официальный GPU драйвер от 2015 года, найдем там библиотеку igfxcmrt32.dll и если посмотрим список экспортируемых ей функций, то найдем упоминавшуюся в статье CreateCmDevice. Да, эта библиотека CM runtime от 2015 года. Т.е. CM ведет свою историю, как минимум, со времен Sandy Bridge / Ivy Bridge процессоров, для встроенной графики которых, этот драйвер и предназначен. Сейчас Intel вывела эту технологию в свет, предоставив кроссплатформенное решение, документацию и даже код, что не может не радовать.
Если же проводить аналогии, то CM очень похож на CUDA от Intel и похоже, что позиционируется точно также. Он не вместо OpenCL, который Intel тоже развивает, а вместе. Если необходима универсальность и переносимость, используется OpenCL, если необходимо выжать из железки максимум, тогда CM.
Аналогичным способом можно получить и весь список возможных опций DSView, которых не так много.
Насчет уточнения, если я правильно понимаю документацию к микросхеме, то DV формируется, когда микросхема находится в состоянии ожидания, а для этого линия SCL в течении 2 мс. должна находится в пассивном состоянии. По активному сигналу на SCL микросхема переходит в режим чтения и до его завершения сигнал DV не выставляется. Единственно, что ведущее устройство может начать читать данные, не дожидаясь завершения сигнала DV, тогда фронт SCL может оказаться между началом и концом DV. Но в этом случае, это скорее некорректная работа мастер-устройства.
Если же проводить аналогии, то CM очень похож на CUDA от Intel и похоже, что позиционируется точно также. Он не вместо OpenCL, который Intel тоже развивает, а вместе. Если необходима универсальность и переносимость, используется OpenCL, если необходимо выжать из железки максимум, тогда CM.