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

Счастья не будет… одно только разочарование. Всё это сказки сплошные, кроме того что оно МОЖЕТ захватывать.
Но из-за маленького размера буфера, которого едва хватает на один фрейм USB малейшая задержка или непонятный чипсет, и анализатор становится бесполезным и его хочется сначала об стенку потом в мусорку.
И во вторых, никакой наглядности процесса — пока не закончится захват ничего он на экране не покажет… а как понять когда хватит? Или вообще когда начинать захват? По понятным причинам, визуализировать захваченное сразу же в реальном времени нельзя — чуть что, контроллер USB задумался и захват сорван. Мышку пошевелил на том же контроллере где и лог.анализатор и привет — захват сорван.

В статье вопрос про i2c. Сюда же можно отнести:spi, uart, различные протоколы параллельных шин, да что там говорить — я таким анализатором TDM поток 8Mbit смотрел.

Если же вы хотите USB (2.0/3.0 и прочее) — берите лог анализатор по круче да подороже, кто мешает?
На гиктаймс 99% аудитории будет достаточно данного анализатора, а остальные 1% я думаю сами в состоянии понять и выбрать — что им купить в соответствии с их запросами.

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

Ну я и говорю, остальные 1% сами в состоянии понять и выбрать — что им купить в соответствии с их запросами.
Вообще, существуют логические анализаторы, которые не только захватят, но и разберут и красиво покажут весь обмен данными по любым более-менее популярным протоколам.

А в разрыв как-то не совсем правильно. Лучше уж тогда использовать процессор помощнее, типа STM32. Ну, или подключить параллельно на шину сдвиговые регистры. Вход на SDA, строб на SCL, а 8 выходов целиком на порт контроллера, и можно быстро забирать байты прямо из регистра IDR порта.
Железки на FPGA то уже есть и аппаратно весьма неплохо сделанные. Например DSLogic Pro (Spartan-6 + Cypress USB 2.0). Но вот софт оставляет желать лучшего
Для сбора данных по медленному такту и отправки их в uart никакого софта и сложных железок не надо.
Это всё ещё дороже китайской платы со Спартаном, к которому можно повесить ChipScope.
А потом запрогать его ещё для чего-нибудь.
Но ОК, варианты явно лучше, для всего есть свои задачи, всё лучше чем над ардуиной издеваться.
мы с Krey пробовали Bus Pirate для разбора SMBus (точнее, Krey колол PMBus-реализацию блоков питания Corsair). Bus Pirate с I2C/SMbus работает хреново, мусора летит много, и что-то, наоборот, не видно. Но что-то есть вполне осмысленное. Т.е., простите, ни в п&&ду, ни в Красную Армию такие устройства. Может, мы чего не доглядели?
Лично мне из всего BusPirate понравился только макрос сканирования I2C шины на наличие устройств.
А в целом — ну как можно на маломощном МК с подключенным UART на 115200 бод поймать хоть что-то внятное идущее на гораздо более высоких скоростях. Как помощь при обучении или простенькие одиночные посылки поймать-послать — вполне. Но для чего-то более серьезного такие устройства не подходят. Ну и работа в консоли — на любителя
А, ну раз там 115200, тогда понятно… участвовать в I2C-обмене — да (на 100k), но в *перехвате* BusPirate хватило только на то, чтобы увидеть адрес slave-устройства и убедиться, что блок питания действительно использует PMBus. Половина транзакций битая. Остальное выясняли уже подключившись другим master-устройством и прогнав софт через ".NET-дизасемблер". Хотя с этими ООП-фреймворками реверсная инженерия превращается в изучение оформленного по всем правилам исходного кода, разве что только комментариев разработчика нет:)
> существуют логические анализаторы
И осциллографы, которые декодируют кучу протоколов.
Это автомобильные, что ли?
Я имел в виду настоящие dso, типа такого:
существуют логические анализаторы, которые не только захватят, но и разберут и красиво покажут весь обмен данными по любым более-менее популярным протоколам
sigrok: разбирает кучу протоколов.
FOSS.
В качестве аппаратных интерфейсов поддерживает в том числе копеешные железяки из коммента выше.
Недавно зарелизило очень интересную разработку Analyzer2Go — PC клиент + прошивка для дешевых STM Evaluation Boards типа Nucleo и Discovery. Проект в самом начале пути, но качество (от русскоязычного, кстати) разработчика радует.
ISR(INT0_vect)
{
cli();

uart_send_char(data);

sei();

Потеряете все события на входе внешнего прерывания кроме первого, пока не выполнится uart_send_char(data). А это довольно долго. Вложенные прерывания запрещать не надо и правильная uart_send_char(data) тоже должна работать по прерываниям.
Плюсую. С таким подходом автора — и ARM можно утопить ожиданиями флагов аппаратуры в прерываниях.
Думаю, что надо было просто раскурить как следует мануал на блок TWI, а не возиться с «bit-bang'ом навыворот».
I2c это как правило 100кгц такты. UART в разы медленнее, и типичная uart_send_char(data) ждёт пока весь байт + стопы не уйдут. За это время на i2c несколько байт пролетит мимо. Но в принципе работало бы, если правильно всё организовать.
Ну почему в разы? Стандартными средствами ОСей до 115200 кБод (что теоретически позволяет успевать за стандартным I2C на 100 кГц — 100/9 к 115,2/10), немного покопавшись — можно и больше. Плюс — наверняка в передачах I2C будут разрывы на обработку данных в системе и кольцевую буферизацию в снифере сделать с флажком «извини, хозяин, — я не успел».
115200кБод это 57,6кГц же. Ну пусть не в разы, сравнимы скорости. Хотя авр и быстрее может. На 460800 обмен с компом у меня работал. В любом случае заработает снифер только если всё правильно написать с грамотным использованием прерываний и с буферами. Что автор не осилил.
115200кБод это 57,6кГц же.

Ну как-же так? 115.2 кГц… вот прям щас на осциллографе посмотрел.
Это же асинхронный uart. За один период частоты передаётся 2 бита. Настроив uart на 115200 бод на выходе данных вы получите частоту максимум в половину от скорости, это 57600Гц. А если бы был тактовый сигнал, то он был бы 115200гц. но тут, в отличие от i2c его нет. Вот же

image

Пожалуй — да.
«В каждой части света есть свои, не менее замечательные, меньшие части.»
Однако велосипед… Почему не сделать проще и лучше: берем MAX10, цепляемся к нише и заполняем FIFO, постепенно сливая данные в юарт через терминал?
Если хочется писать большое количество данных, то цепляем гиг ОЗУ (у альтеры есть готовое IP ядро для новичков) и пишем в них очень и очень долго. Можно сразу и в юарт сливать. Использование FIFO в ОЗУ позволит и записать много данных и не потерять ничего.
Это где же она дорогая? 7.5$, что собственно дешевле циклона. И стоит помнить, что в MAX10 есть внутри ПЗУ для хранения конфигурации, что экономит еще 7-10$. (Цены с digikey).
спартан без хорошего USB чипа для стриминга мало что сможет, только триггер и захват куда-то в буфер. Плюс нужна сама буферная память, то се…
В идеале, конечно, чтобы декодеры протоколов были тоже аппаратные. Но про такое слышал только в контексте MegaZoom IV ASIC для Keysight осциллографов…
Я думаю для большинства i2c хватит uart стандартных скоростей.
Это же не АЦП данные, по одному битику в спартан xc6slx9 можно полмиллиона отсчётов запихать, т.е. секунду обмена.
А если посчитать? минимально стандартизированная скорость I2C — 100кбит. Как без компрессии впихнуть всю информацию о посылках I2C (информация о фронтах, длительность, декодированная информация) в 115.2кбит? никак. 400кбит, 1мбит и выше — тем более
Скажем про 1Мбит я не знал, во вторых сведения о задержках пакетов и прочую телеметрию я пока не предлагал передавать, я естественно рассматривал вариант 100кбит.
Во вторых я пока мало знаком с i2c, только bme280 завёл на оранжпай, так, диванные рассуждения.
В третьих я слышал про более быстрые уарты, х.з. как с поддержкой скоростей компами, но на плисе можно любую скорость реализовать.
Когда заходит в прерывания, прерывания(другие) уже запрещены.
Поэтому не нужно в них писать cli(), sei();
Хм. Правильно я понял, что включить параллельно на gpio не удалось из-за недостаточной скорости обработки, а задействовать параллельно аппаратный порт из-за того, что он обязан отвечать (выставлять Ack на каждый байт), тем самым вмешиваясь в обмен?
Вообще идея вставать в разрыв не самая удачная, т.к. I2C поддерживает мультимастеринг на шине, и в неудачном случае можно с удивлением обнаружить транзакции приходящие с обеих сторон ;)
I2C и SPI во всех коммерческих анализаторах ловятся просто подключаясь к шине и слушая ее, без разрывов цепей.
Собственно, ни разу не видел анализаторов, которые требуют делать разрыв
Если память мне не изменяет, протокол I2C допускает торможение обмена путем принудительного придавливания SCL в ноль… Не уверен, что все «мастеры» это поддерживают, но по идее попробовать можно было бы: прижали SCL на время передачи в UART, потом отпустили и ловим следующий фрейм/байт.
С одной стороны, да, должно сработать. Но всё-таки для прослушивания какой-нибудь RT-системы это неприемлемо, сниффер вообще никак не должен влиять на процессы в системе.

Примерно то же касается идеи разрыва линии — I2C часто разводится в пределах одной платы, подключение сниффера часто возможно только в одной точке.
я бы взял Esp8266 вместо AVR/MEGA. Там два аппаратных i2c. Ну и вообще, железяка помощнее и будет, при том, скорее всего скетчи для arduino подойдут с мин.танцами.
Автор, спасибо за тему, конечно, но после заголовков «Начало» и «На верном пути» не хватает заголовка «Решение» с соответствующим описанием победы. Т.е. я ценю Ваши усилия по созданию анализатора, но не вижу подтверждения наличия готового продукта, с помощью которого (внимание!) была решена конкретная задача. Прототип от продукта отличается тем, что в последнем учтены все нюансы, без которых невозможно решать реальные задачи в адекватные сроки. В комментариях выше я даже упомянул изделие, которое считается продуктом, но по факту не работает (таких примеров не просто много, а очень много). А что в итоге есть у Вас — идея с исходниками, готовый прототип или полностью работающий продукт?
Идея с исходниками выложенными в открытый доступ, готовый прототип, по работоспособности удовлетворивший потребность в выполнении конкретной задачи, до этапа продукта это не дойдет, так как нет в этом потребности.
uart интерфейсу, который, к слову, работал на максимальной стабильной скорости 38 кбит/с

хм, а тактовая частота кристалла какая? и что за мега? 8,16...?

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