Вы не вошли. Пожалуйста, войдите или зарегистрируйтесь.
Страницы 1
Чтобы отправить ответ, вы должны войти или зарегистрироваться
День добрый.
Столкнулся с проблемой по шине I2C.
Самая простая диаграмма на шину выбрасывает только адрес. Данные отсутствуют.
Что я делаю не так?
1.cfd 942 б, скачивался 355 раз, последний раз 2018-08-21
показания осцилографа
IMG_6820.JPG 79.62 кб, скачивался 356 раз, последний раз 2018-08-21
Slave-устройство к линии подключено?
Никак нет 2 резистора и все. Так я вроде данные в шину кидаю.
Стандарт I2C требует, после передачи каждого байта I2C посылки, включая первый байт адреса, при отсутствии подтверждения приема со стороны slave (ACK) прекратить передачу.
Спасибо, ступил я 
.
достал ответный контроллер.
Маюсь дальше.
1. Регистр длинны передачи I2C если он нулевой, то по идее должен отправляться только адрес. Адрес получается битый(на картинке 3 адрес).
2. Сильно не ясен смысл сдвига адреса, описанный как обязательный в документации <1. Адрес х22 и отправляет х22. Может поправили, но не вычистили в документации?
IMG_6904.JPG 66.2 кб, скачивался 329 раз, последний раз 2018-08-29
Ближе
IMG_6905.JPG 64.06 кб, скачивался 327 раз, последний раз 2018-08-29
достал ответный контроллер.
Маюсь дальше.
1. Регистр длинны передачи I2C если он нулевой, то по идее должен отправляться только адрес. Адрес получается битый(на картинке 3 адрес).
2. Сильно не ясен смысл сдвига адреса, описанный как обязательный в документации <1. Адрес х22 и отправляет х22. Может поправили, но не вычистили в документации?
1. Все правильно. Исходя из чего определяется, что адрес битый? Из того, что ведомый не ответил? Учтена ли особенность задания адреса ведомого (сдвиг влево на 1 бит)? Какой должен быть адрес?
2. Смысл в особенности адресации устройств i2c: она 7-битная и адресом являются старшие 7 бит - отсюда и сдвиг адреса на 1 бит влево. Можно, конечно, было вынести это в драйвер, но было решено оставить в таком виде. Т.о. если адрес ведомого устройства 0x22, то в регистр адреса i2c следует записать: 0x22 << 1 = 0x44.
Вот диаграмма
Наддув_3.cfd 6.61 кб, скачивался 354 раз, последний раз 2018-08-29
Без ответного контроллера перебираем ему адреса.
IMG_6907.JPG 65.89 кб, скачивался 355 раз, последний раз 2018-08-29
Третий адрес вместо C2 не имеет клоков.
IMG_6905.JPG 64.06 кб, скачивался 352 раз, последний раз 2018-08-29
В диаграмме, при значении сети "Счетчик I2C" равном 2 (как раз 3й адрес), длина приема равна 0 (установлено константой в регистр) и длина передачи равна 0 (устанавливается блоком №8). Т.е. по команде пользователя контроллер ничего не принимает и ничего не передает.
Допустимые режимы работы драйвера приведены в соответствующем разделе wiki.
Не забывайте про сдвиг влево! Иначе адреса ведомых будут некорректные и получить от них данные будет невозможно.
Тут ясность есть. Но имхо:
- длина принимаемого >0. Длинна передаваемого =0 . Адрес, принимаем.
- длина принимаемого =0. Длинна передаваемого >0 . Адрес, передаем.
- длина принимаемого =0. Длинна передаваемого =0 . Адрес? Передаем только адрес. А адреса нет. На шине какой то артефакт. Не было бы артефакта я бы понял. Но я не понимаю почему не уходит адрес.
Просто шину пользуем для режима управления экраном на TM1637.
- длина принимаемого =0. Длинна передаваемого =0.
Такого режима вообще не рассматривается в описании нашего драйвера I2C.
- длина принимаемого >0. Длинна передаваемого =0 . Мастер передает адрес и принимает данные.
- длина принимаемого =0. Длинна передаваемого >0 . Мастер передает адрес и передает данные.
- длина принимаемого >0. Длинна передаваемого >0 . Мастер передает адрес, передает данные, получает данные.
Если мастер ничего не передает и не ожидает получить, то он и адрес не передает.
В остальных случаях, кроме случая 3, адрес передается. И это Вас не смутило. Сделайте передачу 1 байта, как в остальных случаях.
Скажите, какова цель этих экспериментов? Для чего нужен только адрес? В работе с дисплеем в него нужно либо что-то передавать для отображения, либо что-то считывать (статус и т.п.). В обоих случаях либо длина приема, либо длина передачи не будут равны 0.
У TM1637 протокол отличается от стандартного I2C. Вы определитесь что именно вы хотите с ним сделать. Посылки состоящие всего из одного байта (адреса в спецификации I2C илм 'Command' в терминах вашего устройства), без изменения нами драйвера у вас врядли получится отправлять. Потому как у нас все таки драйвер I2C а не ТM1637. Но так ли это необходимо ли при работе с вашим дисплеем?
Попытка была работать по диаграмме с фиксированным адресом.
Что бы дешифратор цифры в сегменты имел постоянное место в адресной посылке.
Соотвественно команды начала записи и контроля дисплея оказались однобайтовые.
Думал с 0 длинной прокатит, а не получается. Может с SPI вариантом попробовать, благо он на руках.
2018-08-30_16-56-34.jpg 43.42 кб, скачивался 326 раз, последний раз 2018-08-30
В результате результат получен через ардуино.
Canny бросает по UART данные на Ардуинку 328, а она управляет дисплеем.
В результате диаграмма проще, провод на дисплей идет 1 , а не 2.
И овцы целы и волки сыты. И времени завтрачено 15 минут а не 2 недели .
И возможностей по экрану в разы больше.
TM1637 и TM1638 таким образом отлично работают.
Если кому нужен будет код обращайтесь.
Спасибо за отчет!
Рады Вашим успехам!
Альтернативное решение для TM1637: https://forum.canny.ru/viewtopic.php?id=531
Страницы 1
Чтобы отправить ответ, вы должны войти или зарегистрироваться