DI HALT

Мелкосерийка. Используется FT2232D. Ручной монтаж. На последней партии микрух возникает странный глюк. На каждом пятом-седьмом изделии глючит FTDI микруха. Глюки каждый раз разные, но общая черта у них есть. Пример. Соединяем Rx и Tx у каждого канала. Шлем посылку, например: 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 А обратно возвращается что то вида: 1234567890 1234567890 1234567890 1234567890 1234567890 12345щ7890 1234567890 1234567890 1234567890 1234567890 1234567890 12345щ7890 1234567890 1234567890 1234567890 1234567890 1234567890 12345щ7890 1234567890 1234567890 1234567890 1234567890 1234567890 12345щ7890 1234567890 1234567890 1234567890 1234567890 1234567890 12345щ7890 1234567890 1234567890 1234567890 1234567890 1234567890 12345щ7890 1234567890 1234567890 1234567890 1234567890 Т.е. искажается один какой-либо байт. Причем это не зависит ни от бодрейта, ни от скорости. Можно слать хоть по байту в день, но гарантированно в том месте будет сбой. Словно там конечный автомат. Перекидываешь микруху - либо бага в другом байте, либо все ок. При этом второй канал обычно ведет себя молодцом. Работает битбанг и по MPSSE всякие адаптеры работают. Глючит то один, то другой канал. Рандомно, в зависимости от экземпляра микрухи. Вот что это за хрень? FTDI приторговывает отбраковкой? Или проблемы монтажа (перегрев, статика)? З.Ы. Серия микрух 4209 и 3310

Один из способов получить инвайт на хабр - написать пост в песочницу. Если он понравится, вас пропустят. Ну или выпросить у кого нибудь инвайт. Правда просто так мало кто даст, т.к. заработать инвайт это весьма сложно (надо написать пост с +200 чтоль рейтингом)

У меня сайты стоят на разных совершенно движках. И счетчик по каждому естественно свой, данные все считаются раздельно для каждого сайта. шо эт? Показатель отказов это же процент пользователей не ушедших дальше страницы входа. Собственно при средней глубине входа в 4 страницы на посещение он и должен быть низким. По крайней мере лог ключевых фраз поисковых запросов и результат входа это подтверждает. По запросам вида "Метод лазерного уютюга" показатель отказа 0% По запросам аля "gradient helsinki" у меня 100% Ну и по остальным плавает согласно тому есть инфа на странице или нет. В результате получается те самые 2% Или вы имели ввиду какой то другой параметр?

Какой то голимый у вас анализатор. И на основании чего интересно он данные берет? Я как то больше доверяю гугль аналитиксу, яндекс метрике, а также статистике Яндекс.Директа. Там рост посещаемости идет линейно. На корневом сайте он за год увеличился вдвое 6к до 12к. А показатель отказов по гугль аналитиксу не превышает 2.18% в среднем за год.

О своем конешн :) Сообщество EasyElectronics

Честно говоря, на рейтинги поисковиков как то пофигу. Все эти пузомерки они больше для рекламодателей. Куда важней поисковый траффик. Вот сейчас он, по мере индексации сообщества, стабильно растет на +100 уников в месяц. Т.е. за три месяца поисковый траф дорос до ~300 уникальных посетителей в сутки. Это не считая прямых заходов и заходов с ссылок. Тут прирост не такой агрессивный, но свои 3-3.5к уникльных посетителей в день сообщество we.ee уже имеет. Ну и активность посетителей высокая. За три месяца существования написано: ~180 тематических постов и под 230 постов полуоффтопных (личные блоги), оставлено под 7340 комментов.

Можно еще число попыток сделать ограниченным. Хотя времени на попытку опроса уходит мизер.

Ну я на рестарт и запрограммировал в случае адрес фейла. Думаю 20мс вполне хватит.

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

Да я проще - сейчас засинхроню оба МК один от другого. В общем, сейчас все более менее правдоподобно. ОДин МК продул сразу арбитраж еще на уровне адреса слейва. Видимо неудачно ткнулся в период. Второй МК спокойно записал байт в еепромку. Первый, сразу же по окончании работы второго тоже пытался в еепромку сунуться, дал старт и SLA, но получил NACK и отпал. Видать еепромка долго жует. 08 18 28 28 28 победитель 08 38 08 20 проигравший. 20 код отсутствия ответа на адрес слейва.

Гы. Прикольно. Ресеты четко синхронно. Разница там видна, но на пределе чувствительности осциллографа. Фуз биты в обоих контроллерах бит в бит. Код одинаковый, прям один и тот же хекс загрузил в оба. А второй стартует позже первого на 40мс. Это внутренний RC так долго раскачивается? О_о

Похоже тут прокладка виновата :) У меня контроллеры стартуют с интервалом в 40мс оказывается. И вторая пачка тоже проходит ,сама по себе, независимо от первой. И на одном захвате осцила они не влезают. Решил поглядеть полную картину за 500мс и увидел это. Не то оптимизатор так изза одного байта шалит, не то SUT биты по разному стоят. Сейчас разбирусь.

Стоп. Первый сценарий тут не катит. Он для того случая, когда мои оба мастера шлют абсолютно идентичные посылки. Да, они не поймут ,что пишут синхронно, но это и не важно - т.к. все пройдет корректно. Там есть и второй сценарий, он как раз мой: 2.Два или более ведущих обращаются к одному и тому же ведомому с различными _данными_ или различными типами обмена (чтение/запись). В этом случае распределение приоритетов произойдет во время передачи битов _данных_ или бита направления. Ведущий, потерявший приоритет, может либо переключиться в режим неадресованного ведомого, либо дождаться освобождения шины и сформировать состояние СТАРТ для ее захвата. Т.е. на этапе передачи данных и происходит косяк.

Обана, т.е. после передачи адреса Slave может начаться любой бардак и никто это не отследит? Т.е. получается принимают такой вариант как маловероятный и забивают.

Итак, ситуевина. Есть шина i2c на ней висят два мастера и одна еепромка. Мастеры одновременно (ресеты обьединены) начинают ломиться в еепромку на запись. Но в разные адреса. М1 ломится в 0А по адресу страницы 00 0F и пишет туда байт 'B' M2 ломится в 0А по адресу страницы 00 FF и пишет туда байт 'B' Исходя из правил арбитража М2 арбитраж должна проиграть и свалить с поляны. Однако, что происходит на самом деле: Итак, осциллограммка для привлечения внимания. Красный квадратик отмечает место, где идет конфлик уровней. Как видим, запись прошла в ЕЕПРОМ по адресу 00 0F - Еепром подтверждает это. Что же о процессе думают два контроллера? Я писал в буфер лог работы конечного автомата прерывания TWI (тупо TWSR) и выдавал потом в уарт. Получил такую картину: М1: 08 18 28 28 28 M2: 08 18 28 28 28 Расшифровка если кто не помнит: 08 - передан СТАРТ 18 - Передан адрес девайса и получен АСК 28 - передан первый байт (00) и получен АСК 28 - передан второй байт (0F vs FF) и получен ACK 28 - передан последний байт 'B' и получен АСК - дальше будет стоп. Хотя по логике шины должно быть так М1: 08 18 28 28 28 M2: 08 18 28 38 ...........08 18 28 28 28 38 - проигрыш арбитража и старт(опционально) после освобождения шины Почему М2 продолжил передачу, хотя пролажал арбитраж на целой тетраде? Аппаратный глюк контроллера? И как с этим жить? З.Ы. Пример сугубо учебно демонстрационный и не стоит задавать вопросы "зачем нужно много мастеров, да еще в таком синхроне". UPD ах да, по одиночке они спокойно пишут каждая в свой адрес. А вот когда вместе, то вот такое вот садомазо.