DS 0 28 февраля, 2009 Опубликовано 28 февраля, 2009 · Жалоба Покажите обработчик прерываний на меге. И инфу о том кто мастер, какая скорость какие пулапы итд... Вот так повисает. Мастер - mega128. С прерыванием и прочим все нормально - проблема именно в становлении раком модуля в 48. На первой - нормальный цикл. На последней картинке - попытка recovery. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
singlskv 0 28 февраля, 2009 Опубликовано 28 февраля, 2009 · Жалоба Вот так повисает. Мастер - mega128. С прерыванием и прочим все нормально - проблема именно в становлении раком модуля в 48. На первой - нормальный цикл. На последней картинке - попытка recovery. Картинки странные конечно, но если бы слейв подвисал с удержанием SCL то на последней картинке (попытка recovery) тактирования не было бы совсем, а оно там есть... так что еще не факт что слейв SCL держит не видя Ваш код могу только предложить добавить на слейве если чего не хватает: BYTE twsr=TWSR & 0xF8; // Статус с учетом маски допустимых состояний switch (twsr) // Разбор состояний i2c { .............. <-- обрабатываемые состояния .............. .............. case (I2C_BUS_ERROR): // 0x00 ---- ошибка на шине ------------ TWCR; TWCR=(1<<TWINT)|(1<<TWSTO)|(1<<TWEA)|(1<<TWEN); return; case (I2C_RECV_ARB_LOST_ADR_ACK): // 0x68 ---- Arbitration lost & General Calls case (I2C_RECV_GC_ADR_ACK): // 0x70 case (I2C_RECV_ARB_LOST_GC_ADR_ACK)://0x78 case (I2C_RECV_GC_DATA_ACK): // 0x90 TWCR; TWCR=(1<<TWINT)|(1<<TWEN); // отвечаем NAK return; case (I2C_RECV_DATA_STOP): // 0xA0 ---- конец приема -------------- case (I2C_RECV_DATA_NACK): // 0x88 ---- если отвечали NAK --------- case (I2C_RECV_GC_DATA_NACK): // 0x98 case (I2C_SEND_DATA_NACK): // 0xC0 ---- конец передачи пакета ----- case (I2C_SEND_LAST_DATA_ACK): // 0xC8 default: // недопустимое состояние TWCR; TWCR=(1<<TWINT)|(1<<TWEA)|(1<<TWEN); } Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DS 0 28 февраля, 2009 Опубликовано 28 февраля, 2009 · Жалоба Картинки странные конечно, но если бы слейв подвисал с удержанием SCL то на последней картинке (попытка recovery) тактирования не было бы совсем, а оно там есть... так что еще не факт что слейв SCL держит не видя Ваш код могу только предложить добавить на слейве если чего не хватает: Слэйв держит, но выходы ATmeg имеют ограничение по току в режиме TWI, поэтому нога в стандартном режиме его перебарывает. Как только выход переходит в 3 состояние, "слабый" выход устанавливает шину в 0. Если отключить разъем от модуля, шина оживает. В тиньке, кстати, ограничения по току нет, там такое КЗ на осциллограмме хорошо видно. В обработчике, если что-то происходит не в очередь, или статус не соответствует ожидаемому, сразу выполняется STOP. Хотя, конечно, вариант "сам дурак" не исключен, только не из-за того, что забыли какие-то состояния обработать, а из-за какой-то более хитрой программной ошибки. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
singlskv 0 28 февраля, 2009 Опубликовано 28 февраля, 2009 · Жалоба Слэйв держит, но выходы ATmeg имеют ограничение по току в режиме TWI, поэтому нога в стандартном режиме его перебарывает. Как только выход переходит в 3 состояние, "слабый" выход устанавливает шину в 0. Если отключить разъем от модуля, шина оживает. У меня были сомнения по картине N3 что там перетягивание на шине, но какое-то слабое перетягивание... Но если нет сомнения что держит слейв, то нужно все-таки по состояниям twi разбираться. В обработчике, если что-то происходит не в очередь, или статус не соответствует ожидаемому, сразу выполняется STOP. Хотя, конечно, вариант "сам дурак" не исключен, только не в лоб, а из-за какой-то более хитрой программной ошибки. STOP нужен только если пришло состояние I2C_BUS_ERROR я на своей реализации проверял закороткой SCL и SDA, все восстанавливалось. STOP в смысле TWCR=(1<<TWINT)|(1<<TWSTO)|(1<<TWEA)|(1<<TWEN); конечно Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DS 0 1 марта, 2009 Опубликовано 1 марта, 2009 · Жалоба А не может ли вызывать завис изменение режима SPI в момент работы модуля TWI ? Я обнаружил, что после изменения режима SPI первый байт передается рваным - сначала 4 или 5 бит, потом пауза различной длины, потом оставшиеся 3 бита. Я хотел попользоваться изменением скорости SPI "на лету", да видать нельзя. Только вот в datasheet не нашел ничего про такое ограничение. Может, невнимательно смотрел ? После того, как я перестал трогать SPCR, перестал виснуть TWI (т.е. пока не повис за тот промежуток времени, за который раньше вис с гарантией). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
defunct 0 1 марта, 2009 Опубликовано 1 марта, 2009 · Жалоба А не может ли вызывать завис изменение режима SPI в момент работы модуля TWI ? Не должно, но если наблюдается корреляция между изменением режима SPI и подвисанием TWI, то причина может быть в несвоевременной реакции на TWI прерывание. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DS 0 1 марта, 2009 Опубликовано 1 марта, 2009 · Жалоба Не должно, но если наблюдается корреляция между изменением режима SPI и подвисанием TWI, то причина может быть в несвоевременной реакции на TWI прерывание. Да похоже, что именно с совпадением во времени промежутка между out spcr и out spdr и приходом пакета на TWI. Где-нибудь в документации отражено, что первый байт, переданный по SPI после смены режима, искажается ? Я не нашел. А это факт, я на осциллографе это пронаблюдал и экспериментировал, как и что меняется при разных сменах режима. Несвоевременную реакцию я тоже моделировал задержками до секунд, и в начале, и в середине пакета - не сбивается. Сейчас работает без сбоев - отличие только в отсутствии команд out spcr в программе. Реакция на TWI даже несколько замедлилась - раньше я переключал spi между 2.5 Мгц и 10 Мгц, что позволяло сэкономить время,на которое прерывания необходимо запрещать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DS 0 1 марта, 2009 Опубликовано 1 марта, 2009 · Жалоба Вот код, который вызывает неадекватное поведение 48 ldi r31, $2e out ddrb,r31 ldi r31,$14 out portb,r31 ldi r31, $f out ddrc, r31 ldi r31, $0 out portc, r31 ldi r31, $b out ddrd,r31 ldi r31,$fb out portd,r31 ldi r25, 1 out SPSR, r25 ldi r25, $50 bbb: out spcr, r25 cbi portd, 3 out SPDR, r25 nop nop nop nop nop nop nop nop nop nop in r1, SPSR sbi portd, 3 clr r16 bb: dec r16 brne bb rjmp bbb А вот осциллограммы - синий - PD3, желтый - PB5 (SCK). Дергать именно PD3 - важно, при замене на что-нибудь другое все нормально работает. Важна также задержка от записи SPDR до чтения SPSR и минимальная длительность после чтения SPSR - при загрузке в r16 числа, меньшего 64, сбоев нет. Частота такта 20 Мгц. Кадры на осциллографе сняты в произвольный момент времени - форма сбоев непостоянна. Какие будут комментарии ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DS 0 1 марта, 2009 Опубликовано 1 марта, 2009 · Жалоба Блин, классическое "сам дурак" - Наводки в шлейфике программирования от AVreal (15 cм) на тактовый генератор, приводящие к его сбою. Для получения нужной для сбоя амлитуды как раз не хватало в момент переключения SPI дергануть ногой PD3, расположенной рядышком с выводами генератора. Так и рождаются нездоровые сенсации. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SapegoAL 0 1 марта, 2009 Опубликовано 1 марта, 2009 · Жалоба Так и рождаются нездоровые сенсации. :) Так попало в благодатную почву. Здесь уже несколько раз проскакивали сообщения про "зависания" TWI в слэйве. У меня, к примеру, всё прекрасно работает, причём годами, причём паралельно 24c512 сидят и обмен идёт очень плотный. Правда скорость не очень высокая. Отличный интерфейс выдумали филипы. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
