Pull to refresh

Comments 49

Счастья не будет… одно только разочарование. Всё это сказки сплошные, кроме того что оно МОЖЕТ захватывать.
Но из-за маленького размера буфера, которого едва хватает на один фрейм 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-дизасемблер". Хотя с этими ООП-фреймворками реверсная инженерия превращается в изучение оформленного по всем правилам исходного кода, разве что только комментариев разработчика нет:)
> существуют логические анализаторы
И осциллографы, которые декодируют кучу протоколов.
UFO just landed and posted this here
Это автомобильные, что ли?
Я имел в виду настоящие dso, типа такого:
UFO just landed and posted this here
существуют логические анализаторы, которые не только захватят, но и разберут и красиво покажут весь обмен данными по любым более-менее популярным протоколам
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 в ОЗУ позволит и записать много данных и не потерять ничего.
Макс10 пока ещё дороговат )
Плата с 3-им Спартаном ~20$ с 6-м ~25$ это дорого?
Это где же она дорогая? 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 аппаратно использовать для мониторинга/сниффинга. они начинают влезать в разговор. и «старый мастер» может не понять такой шутки и обидеться. (у меня так и получалось изредка, шина вставала)

тиньки могут, там twi урезан, но мне не подошли.

для сниффинга скорости атмеги не хватает, если шина загружена. по-хорошему только вариант сбор в память — выгрузка всего с потерей данных во время выгрузки.

итого — бардак ) потом уже с из китайчины дешевый логический анализатор пришел — просто день и ночь ))))

а с non-intrusive мониторингом в итоге: вложенные прерывания и отлов только конкретного события. отлично работает. думаю так же и сниффить можно пробовать.

//i2c part
#define SCL_PIN PD2  //INT0
#define SDA_PIN PD3  //INT1

#define TRIGGER_EVENT 1
volatile uint8_t i2c_trigger = 0;

register volatile uint8_t bits_to_read    asm("r5");
register volatile uint8_t bits_value      asm("r6");
register volatile uint8_t bytes_to_read   asm("r7");
register volatile uint8_t current_bits    asm("r8");

#define BUFFER_SIZE 3       // maximum size of buffer for message: i had to sniff only a packet of 3 bytes: address+data+data
volatile uint8_t i2c_cmd_buffer[BUFFER_SIZE];

void setup() {
    i2c_cmd_buffer[0] = 0;
    i2c_cmd_buffer[1] = 0;
    i2c_cmd_buffer[2] = 0;
  
    // sda/scl 
    DDRD &= ~(_BV(DDD2)|_BV(DDD3));             // PD2 and PD3 pins as INPUT
  
    EICRA |= _BV(ISC00)|_BV(ISC01)|_BV(ISC10);  // set INT0 to trigger on RISING
                                                // set INT1 to trigger on ANY logic change
    EIMSK |= _BV(INT1);                         // only enable INT1. INT0 (SCL) won't be enabled until we see a START
    sei();                                      // turn on interrupts
}


void loop() {
    if (i2c_trigger) {
      cli();
      //do something here. 
      //we have just noticed specific message on i2c bus

      i2c_trigger = 0;
      sei();
    }
}


ISR (INT0_vect) { // SCL interrupt code here. SCL RISE. Read bits from SDA
    if (bits_to_read-- > 0 ) {
      bits_value <<= 1;
      if(PIND & _BV(PD3)) {
        bits_value |= 1;
      }
    } else { //ack/nack
      if (bytes_to_read < BUFFER_SIZE) {
        i2c_cmd_buffer[bytes_to_read++] = bits_value;
      }
      bits_to_read = 8;
      bits_value = 0;
    }
}

ISR (INT1_vect) { // SDA interrupt code here. SDA CHANGE
    if (!(PIND & _BV(PD2))) 
        return; // clk is low
        
    if (PIND & _BV(PD3)) {
        // SDA is rising. its a STOP condition
        // disable interrupt for SCL rising
        EIMSK &= ~_BV(INT0);

        //stop condition. we've finally got message we was waiting for. set flag.
        i2c_trigger = (i2c_cmd_buffer[0] == 0x4e && i2c_cmd_buffer[1] == 0x99) ? TRIGGER_EVENT : 0;

    } else {                       
        // SDA is falling. its a START condition
        // enable interrupt for SCL rising
        EIMSK |= _BV(INT0);

        bits_to_read = 8;
        bits_value = 0;
        bytes_to_read = 0;
   }
}




а мониторинг делал в итоге
Если память мне не изменяет, протокол I2C допускает торможение обмена путем принудительного придавливания SCL в ноль… Не уверен, что все «мастеры» это поддерживают, но по идее попробовать можно было бы: прижали SCL на время передачи в UART, потом отпустили и ловим следующий фрейм/байт.
С одной стороны, да, должно сработать. Но всё-таки для прослушивания какой-нибудь RT-системы это неприемлемо, сниффер вообще никак не должен влиять на процессы в системе.

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

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

atmega8 от внутренней RC-цепочки.
Sign up to leave a comment.

Articles