Доброго времени суток.
Есть необходимость собрать анализатор шини I2C.

Анализатор должен собирать всю информацию о шине, т.е. все возможные временные параметры, такие как длительность единиц, длительность нолей, частота следования клока, качество старт и стоп условий, нарастание-спад уровней, время удержания акнолоджеса ведомым, возникновения коллизий на шине (хотя едвали получится, из-за специфики работы мультимастера). Так же вся собранная информация + сами данные должны передаваться в компьютер по рс-232.

Ничего сложного нет, как говорится: бери да пиши... НО
Аппаратный I2C AVR не обладает всеми нужными ф-циями, им можно только данные собирать. Следовательно нужен програмный I2C. Но сильно сомниваюсь, что програмный и2ц сможет отслеживать шину, работающую на полной скорости (до МГц или хотя бы до 400 кГц клока).

Вопрос: что посаветуйте, может стоит воспользоваться более скоростным камнем? Или может собрать часть анализатора на жесткой логике?
Может у кого был подобный проект?

Сильно зависит от точности, если хватит 10-20 сэмплов на измеряемый период, то почему нет? На какой-нибудь новой меге, на 16-20 MHz должно хватить. Если надо точнее, брать ПЛИС на 64-128 триггеров и делать на ней захват. А управлять уже все равно чем.

Пробовал сделать более простой анализатор, отлов стартов, стопов, аков, неаков, и самих байт + вывод в ком порт. На меге16 на 16 мегагерц сходу не удалось. Т.к. на 400 кГц иис нужно отловить уровень sda максимум за 20 команд, на си не получилось уложиться, попробую скоро написать на асме. может для 400 и получиться.

Уважаемый Woodoo!



У Вас скорость И2Ц превышает скорость РС-232! Вам не успеть передать трафик И2Ц в ПЭВМ при интенсивном обмене. Все-таки что Вас больше интересует : трафик на И2Ц или временные характеристики стопов, стартов, тактовых импульсов и прочего?

Можно предложить следующие подходы :

1. Интересует все. Делаем скоростной анализатор (берем готовый), например, на ПЛИС + USB, опрашиваем SDA и SCL с необходимым разрешением по времени. Анализ времянок и трафика в ПЭВМ (программу пишем).

2. Интересует трафик. Пользуемся встроенным в AVR аппаратным TWI, передаем снятый трафик по USB.

3. Интересуют времянки, но можно измерять не все сразу, а например по выбору - сначала старты, потом стопы и т.д. Тогда можно анализировать прямо в MCU, результаты скидывать через RS-232.

Сам я И2Ц не анализировал, но снимал другой протокол по варианту 1. Использовал платку с Altera EPM7064AETC + FTDI FT245ВМ.

Аппаратный не подойдёт. Там же надо адрес забивать. А если он не известен?

Посмотри мой проект PULT I2C. В исходниках. Там 2313 работает в качестве SLAVE програмным способом. Вам только прерывание надо разобрать. На 12М по-моему до 100кГц работала. Конечно переделать предётся, но посмотреть можно.

Установить бит General Call.

так General Call вроде тоже фиксированный адрес имеет-0?или я ошибаюсь?
Я делал на tiny2313 монитор квадратной на ее usi-там есть прерывание по приходу старта-очень удобно.

Согласен с Whale
Тоже была мысля сделать монитор И2Ц,кинулся на меги там только фиксированный адресс и общий,
а на тини2313 адресации нет и сам USI попроще чем TWI у мег.
По пинам можно в цикле читать длительность,а по прерыванию паковать байты,жаль только
что нет флажка или прерывания СТОП и протокол шины не привязан к частоте,можно управлять хоть тумблерами ,поэтому расчет длительности может быть только в определенных пределах.
В любом случае ,если что получится пишите мне на личку,мне тоже эта тема интересна.

Я делал подобный анализатор потока по I2C аппаратно:
74Ac74 (между стробами инвертор) - детектор start/stop
74Ac299 - преобразователь из последовательного кода в параллельный
далеее уже в параллельном виде на AtMega8515 в ней буфферизация fifo
и передача (через раз'ём програматора) в компьютер.

Направление передачи данных master<=>slave не анализировал,
но думаю это решается врезкой в SDA/SCL резисторов и установкой
быстродействующих компараторов.

Есть готовый вариант

Да господа. Но времена меняются.

Обратите внимание на регистр маски (TWAMR) для МК Atmega88. И мой проект красиво ложится на аппаратные возможности данной микрухи. Жаль что на момент написания её ещё не было. Таким образом можно (уже можно) отвечать на любой адрес и делать програмный монитор I2C. (Конечно без тайминга зато на достаточно высокой скорости).

Это конечно прекрасно, что разработчики AVR учитывают пожелания разработчиков (уж не знаю как они до них доходят), но это возвращает нас к уже состоявшемуся разговору о серьёзной непродуманности многих решений и внесении заплаток "на ходу". Что плодит множество решений при ощущении отсутствия общего подхода. А с точки зрения программиста, серьёзно усложняет написание и заимствование библиотек.
Надо непрерывно следить за новыми кристаллами. Трудно предугадать что ещё они там подкинут.

Давайте же выпьем за ATMEGA888!

Собрал вот такой
работает - очень помог (покруче бы ваще супер было бы)
Тема очь интересна
http://sterr.narod.ru/i2cmon/index.htm

Не думаю что тема очень интересна. По совершенно простой причине. Сам протокол I2C ну очень простой, очень чётко прописанный и совершенно статический. Реализация его не вызывает не малейшей проблемы. Ну если только какой нибудь мультимастер.

Иное дело какой-нибудь RS485 с несколькими соподчинёнными или USB. В таких местах нельзя остановить прогу и посмотреть. Нельзя её пройти по шагам. Протокол эффективен только в движении. Например в одном изделии возникала ошибка на 1.5Мб передаваемых данных. Как её вычислить? Для этих дел я применяю анализатор. Программы от него "выкинул" в раздел "исходники программ и библиотек". Чё то может быть и не доработано. Где-то может и не всё описано, - ну так под себя же делал. Посмотреть любую шину там - раз плюнуть. Возможно после Нового года, если освобожусь, - выложу в комплекте в виде законченного устр-ва. Почти законченного . Надо понимать, что "нижней" части универсальной не бывает. Часто приходится переписывать под конкретный случай.
Ну и всё таки это оценочное, а не измерительное устр-во.

Сразу не выложил так как мой стенд достаточно "тяжеловесный". Например у меня к процу M8515 подрублено 256K внешней памяти. Память динамическая. Можно поставить 1М. Проц поддерживает до 256 различных способов "съёма". Попробую упростить для народа. Если нужно конечно.

Проще всего конечно анализировать двухканальным цифровым осциллографом с программной опцией анализатора сериальных интерфейсов. Но жаба душит. Хотелось бы что-то попроще, с интеллектуальной детекцией неисправностей (звоны, одновременность фронтов, подвисания на шине). Изделие на базе PCF8584 хорошо для изучения протокола работающей системы, а вот если это своя собственная разработка, в принципе работающая, но раз в день зависающая намертво....
Для ловли таких глюков надо нечто на основе FPGA небольшой, чтобы быстро работало и могло хранить небольшую предисторию фатального глюка. А вход на быстрых двухпороговых компараторах, чтобы отличало хотя бы 1,0,Z состояние, а лучше и с детектором тока, чтобы понять, какой передатчик тянет линию вверх или вниз. Ну и выход на USB, с возможностью автономной работы (ожидания неисправности). А поскольку система неочень простая, то желательно кроме I2C еще и SPI, и CAN анализировать. Есть у кого-лидо идеи по поводу построения IP core такого анализатора?

Я уже давно хлопаю глазами на эту линейку,в дополнение скажу есть куча ШИМ и возможность внешнего прерывания практически от каждой ноги,что решает очень много проблем по перехвату внешних событий .Жаль инфы на русском по ним мало,на досуге сделаю себе компьютерный перевод.

А чего хлопать, я её уже применяю потихоньку. Пока правда как замену M8 так как в DebugWare работает и отлаживается великолепно. Но скоро можно и так применять. Разница в цене 0.2$ приблизительно. А все нюансы всё равно обнаруживаются когда работать по-настоящему начнёшь. А от перевода нифига в голове не остаётся. Я вот сейчас на ней интерфейсную часть делаю и по I2C отвечает, так вот - столкнулся. А в соседней ветке написано, что из проги можно фузы читать. А ты, как я вижу, здорово с ШИМами работаешь и скоро нам интересных новостей из этой области подкинешь!