Вот напоролись тут на следующую проблему. Имеется экран от Newhaven Display с емкостным тачем, основанном на чипе FT5306 от FocalTech. Он отказался работать по I2C в линуксе от TI, поставляемом вместе с стартер китом для AM3359. В процессе разбора полетов выяснилось, что чип немного туповат, и транзакция чтения его регистров на шине I2C вида S Addr|W REG S Addr|R Data P выдает обратно значение адреса регистра REG вместо данных Data. А все потому, что ARM слишком быстро шуршит сигналами, видимо чип (у него внутри 8051 на самом деле) не успевает обработать прерывание у себя там и выставить правильные данные в регистре передачи своего I2C-кора. Когда я переподключил дисплей к микроконтроллеру и стал медленнее сигналы дергать, то все там нормально читается.

В итоге имею такой вопрос. Можно ли научить линукс как-то притормаживать операцию чтения данных после выдачи первой части команды с номером регистра? И если можно, то как? Суть в том, что транзакция на шине состоит из двух частей, и драйвер вызывает ее одним вызовом I2C SMBUS API. Можно наверное попробовать это запатчить в яре, но мне эта идея не очень нравится, так как, по-хорошему, задержка нужна только для вполне конкретного типа i2c клиента, причем я еще даже не знаю точно какая она есть на самом деле. Известно пока, что 100 мкс мало, а 1000 мкс - достаточно. Может быть, можно как-то разбить само операцию на две более примитивные, но неделимые, и между ними вставить задержку? Тогда такой вызов можно будет перенести именно в драйвер для FT5306, и задержка будет только у него.

Еще замечено, что для чипа FT5406 такой задержки нет, и тач на дисплеях большего размера работает нормально.

у вашего чипа питание 3в3?
пуллапы на шине i2c присутствуют? номиналы?
смотрите на той шине, где подключен тач? у этого АРМа 3 шины i2c аппаратные..
что выводится при
ls /dev/i2c*
и
i2cdetect -y -r N (где N - номер шины с тачем)



это может быть, если шина настроена на 400кГц, а контроллер тача умеет не более 100..
мастер i2c в АРМ можно придушить на нужную скорость, вне зависимости от тактовой самого АРМа


можно отсадить тач на отдельную i2c-gpio шину и общаться с нужной скорость
можно поставить i2c мультиплексор
можно выделить отдельную аппаратную шину под этот упрямый чип, раз он так нужен
для отладки железа можно соединить тач и кит на 3359 на любые контакты и сэмулировать i2c обычныи пинодрыгством (наверняка вы такое делали на обычном микроконтроллере)

Jury093

Так я ж говорю, все делалось на штатном TI-ном стартер-ките. Поэтому:
1) питание и резисторы там есть и соответствуют параметрам FT5306
2) скорость шины пробовали и 400 и 100 кГц, но в обоих случаях не успевает.
3) Поменять шины i2c мы не можем, у нас уже к этой штатный разъемчик для экрана припаян Да и смысла нет
4) Осциллографом смотрели времянки, никаких серьезных косяков в сигналах там нет, даже пуллапы вытягивают сигналы до 3В, прежде чем они снова проседают.

Душить проблему скоростью не хочется, так как тач не мышка, у него на порядок больший объем регистров с данными, особенно при мультитаче.
Естественно, что не хотелось бы увеличивать загрузку шины, и ограничиться точечным воздействием на код.

Даже более конкретно могу спросить.

Вот сейчас, насколько я вижу, чтение регистров в драйвере FT5x06 делается вызовом i2c_transfer, состоящем из двух сообщений. Одно на запись, второе на чтение. Что если я разобью один i2c_transfer на i2c_master_send и i2c_master_recv, поставлю задержку между ними? По идее должно получиться именно оно, с той лишь разницей, что это будет не
S Addr|W REG S Addr|R Data P
а
S Addr|W REG P ... S Addr|R Data P

насколько чревато то, что будет один лишний STOP? С точки зрения протокола I2C?

ок. я спросил "широкополосно", мало ли у вас тривиальная ошибка..

а 10/50кГц не пробовали? чисто узнать о работоспособности для штатного режима..


я бы не стал пока трогать ветку i2c шины ядра, а поковырял драйвер. возможно ваша версия еще сырая и может не работать на платформе ам335х. никакого криминала в исправлениях драйверов нет - это нормальный процесс. т.к. драйвера пишут люди под свое железо.. более того, даже если вы полностью перепишете и получите работоспособную версию, то вам спасибо скажут

если ваш STOP не нарушит работу драйвера и логику обмена, то смело вставляйте. в мане на чип тача должны быть диаграммы протокола - "кто сказал старт" "какой адрес" "будет NAK" и тыпы.. я обычно туда подсматриваю..

Так я про драйвер и написал - махнуть i2c_transfer на пару senv/recv. По идее это должно работать, так как адрес регистра вообще должен записываться в накапливающий регистр, и только в фазе данных инкрементироваться. Так что лишний стоп не должен мешать. Просто теоретически шину могут отдать другому устройству после STOP, если ее не захватить монопольно на время своих операций.

С мануалом у них интересно. В даташите на дисплей вообще ничего нет, кроме распиновки шлейфа. Но есть application note, вот такой:
http://www.newhavendisplay.com/app_notes/F...6_registers.pdf
Но только согласно этому документу там вообще нет разницы между 5306 и 5406, все должно работать на ура на 400кГц. А вот...

попробуйте. страшного тут ничего нет, в худшем случае словите таймауты по i2c шине - мастер ам335х их умеет разруливать, в отличие от, например, Марвела..


аппнота шикарная, все расписано и разрисованно.. правда слов про 100/400 (normal/fast) я не увидел, может бегло смотрел может они в даташите..
видел вот такое упоминание:
2.2.2 ROW_ADDR
Please delay for more than 100us, then read the raw data
возможно драйвер это не учитывает..

вот тут девайс с таким же тачем:
http://wiki.opennet.ru/Zenithink_C71
у них вроде все работает, внизу растут линки - может там поискать исходники драйвера или ядра и посмотреть в чем затык..

Опс, похоже проблема все же не в задержках. Задержку вставили, но по-прежнему не работает. А вот ели шлейф контроллера передернуть при запущенном ките, то начинает работать. Похоже, у этого контроллера есть какие-то свои тараканы, и они не описаны в даташите...

Сейчас рабочая гипотеза, что если на старте FT5306 сигналы /INT и /WAKE не притянуты к питанию, то он не заводится. На ките они подключены к GPIO без пуллапов. А линукс или U-Boot начинает ими рулить со значительной задержкой после старта. Когда передергиваем при уже запущенном всем, то работает.

не, гипотезы хороши в астрономии - в случае электроники все должно быть однозначно..
тащим даташит, читаем:

3.5 POWER ON/Reset/Wake Sequence
The GPIO such as Wake, INT and I2C should be pulled down to be low before powering on. The signal of waking up should be set
to be high after powering on. INT signal will be sent to the host after initializing all parameters and then start to report points to the
host.


попробуйте на контакты WAKE и INT навесить резистор 10/100к на gnd.. и в момент инита системы выставить сигнал WAKE в "1", если есть проводок до АРМа.. если нет, то RC цепочку для теста запуска..

Так вот я и говорю, что оно странно, не работает так, как это написано. Ну и потом, надо смотреть не только в даташит, а еще и в схему подключения этого чипа для конкретного дисплея. Там у некоторых моделей WAKE наружу торчит, а у некоторых - RESET. В нашем варианте вроде WAKE. Во всяком случае так на шлейфе написано.

По факту работает вариант, когда на WAKE сидит pull-up на 10К. Если его нет, то после включения питания чип уходит в несознанку. И мигание WAKE-ом ему после этого не помогает. Если же ему передернуть питание, когда WAKE с самого начала стоит в 1 (GPIO), то все работает.

если с резистором все работает, то оставьте как есть и углубляйтесь в софт..
заодно попробуйте в суппорт FocalTech написать, может чго полезного ответят..
еще поставщика дисплея можно попытать на предмет "состав сигналов в шлейфе нашего контроллера тача и правильная комбинация начальных уровней"

Да собственно софт уже обкатали на другом дисплее, у которого чип FT5406. Нам просто надо запроектировать два прибора, с несколько разными по размеру дисплеями: 4.3" и 7". И вот 7" заработал сам собой как-только мы правильный драйвер нашли, а 4.3" - ни в какую. Вот с резистором нашли беду, и вообще вроде все заработало, теперь все довольные к выходным

если кому интересно будет, то вот ветка на форуме производителя дисплеев - Newhaven Display.
http://www.newhavendisplay.com/NHD_forum/i...topic,82.0.html