Посмотрел даташит на этот чип -
http://www.mcielectronics.cl/website_MCI/static/documents/Datasheet_TM1637.pdf (я с ним не работал), это больше на SPI похоже (только half duplex), чем на i2c, что и объясняет, почему в библиотеках не используют аппаратный i2c.
Но опять же, от SPI его отличает этот самый АСК - который на аппаратном SPI будет запаристо так генерить:
Посмотреть вложение 6492
В итоге - просто на любые пины и вешают поэтому, софтварно дёргая..
И судя по коду:
Код:
bitDelay();
uint8_t ack = digitalRead(Datapin);
if (ack == 0)
{
pinMode(Datapin,OUTPUT);
digitalWrite(Datapin,LOW);
}
bitDelay();
pinMode(Datapin,OUTPUT);
bitDelay();
вот эти самые bitDelay() сильно зависят от железа на котором работает прошивка, предполагаю, что на 8-битной атмеге задержка больше для записи\чтения и поэтому все работает .. можно собственно попробовать изменить задержку в
Код:
void TM1637::bitDelay(void)
{
delayMicroseconds(50);
}
И по поводу i2c - я запускал его без проблем на USDK от pvvx, у него и примеры работы есть хорошие, сканер у вас выдаёт все адреса видимо из-за того, что этот дисплей не i2c и его выход лочится при какой то комбинации, да, кст, подтяжки к питанию для i2c не забыли ? и пробовали ли заведомо рабочий датчик\дисплей именно i2c-шный подключать - сканер так же не определяет его?