8051 программный I2C. Не взлетело :(.

[Shuspano]

Добрый день.
Недавно решил сделать программный I2C для микроконтроллера STC89C52RC. Поковырялся в тырнете, работающих сразу примеров не нашел. Погрустил, почитал DiHalt-а, поковырялся в разных чужих листингах, и решил написать еще один.
И вроде даже написал. Для начала традиционно взял EEPROM AT24C32N (меньше не нашлось). Программа состоит из двух частей, первая пишет в микросхему байт по нулевому адресу, вторая часть читает его оттуда, и показывает на полосковом светодиодном индикаторе. Но заработало не очень. Первая часть программы работает нормально, байт пишется - в этом я убедился, прочитав микруху программатором. Читает и показывает тоже нормально - байт, записанный программатором или первой частю программы - читается. Но все вместе это не работает.
Я решил узнать где происходит затык, для этого я использовал светодиод на контакте P1.0 , строчку зажигания которого размещал в разных частях программы. После какой инструкции не зажигался - там и затык. Оказалось что после перехода к чтению, и отправки аппаратного адреса микрухи, подпрограмма отправки стоит и ждет нуля на линии SDA, который микросхема не выдает. Если пропустить ACK - выдает невесть что.
Чё с этим делать - не знаю. Всю циклограмму обращения к микрухе проверил на соответствие даташиту пошагово и побайтно, раз 5. Есть ощущение что микросхема криво инициализирована, потому не выставляет готовность. Но если неправильно, почему тогда части программы работают правильно. Что я сделал не так?

[ARV]

шашек в руки я не брал давно... но когда разбирался, то написал i2c-мастера на ассемблере за пару часов. где-то валяется даже код...
но в гугле этого кода - как у дяди кота Матроскина гуталина!
вот например: https://github.com/ExploreEmbedded/8051 ... 0-libfiles - там есть файлики и для i2c, и выглядят правильными...

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

[Shuspano]

ARV писал(а):

шашек в руки я не брал давно... но когда разбирался, то написал i2c-мастера на ассемблере за пару часов. где-то валяется даже код...
но в гугле этого кода - как у дяди кота Матроскина гуталина!
вот например: https://github.com/ExploreEmbedded/8051 ... 0-libfiles - там есть файлики и для i2c, и выглядят правильными...

Ну, попытка разобраться с С у меня не особо задалась. Мне бы ассемблер, а весь доступный в гугле ассемблер я уже попробовал.

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

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

[BOB51]

Есть вроде такое (программный I2С на ассемблере)...
Надо в архивах порыться...

Воть вроде раскопалось:

Новая папка.zip

(6.27 KiB) Скачиваний: 171

Однако относительно DS1307 чтение по предварительно заданному адресу там хотя и работает, но организованно не по фэншую.

В принципе причина обнаружена и исправлена, но не в данных файликах - все лапы не дойдут стары тексты исправить.

[ARV]

после перехода к чтению, и отправки аппаратного адреса микрухи

а не тут ли собачка-то порылась? написано "переход к чтению И отправка адреса" в то время как именно в байте адреса содержится бит чтения/записи, и перейти к чтению ДО или ВМЕСТО отправки адреса попросту нельзя.

Добавлено after 1 minute 51 second:
кстати, еще: после "записи" надо выдать STOP в шину и подождать, пока микросхема обновит страничку - мгновенно переходить к чтению нельзя, как я припоминаю, во всяком случае, к чтению из той же самой странички... могу ошибаться...

[BOB51]

Скорее та же "затыковка", что и у меня была (причина появления "изврата")...
Посылаем адрес устройства , затем адрес данных (чтение по произвольному адресу)...и...
Если алгоритм проверки АСК используется после передачи адреса данных имеем проблему - в случае когда на краю байта возвращаемых данных первым на выход стоит нулик.
Я под Си ту ошибку подправил и замечание в конспектики записал..., а до асмовских заготовок лапы не дошли...

[ARV]

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

[Shuspano]

Ну как бы после окончания записи идет условие STOP, то бишь завершаю работу с микросхемой. Все прежде переданные туда данные стали недействительные. В следующей части программы, где происходит чтение, я инициализирую микросхему (INIT и START), передаю аппаратный адрес с битом ЗАПИСИ, как того требует даташЫт (и тут затык происходит), и передаю старшие и младшие байты адреса. Далее, не завершая работу с микросхемой, снова выставляю условие START, после чего, передаю аппаратный адрес микрухи с битом ЧТЕНИЕ. После отправки адресов, если ACK прошел, сразу вызываю цикл чтения. Прочитав байт, отвечаю NAK и STOP, и все, досвидонья. Эта циклограмма составлена на основании даташита епромки.
По тдельности все это работает, не работает когда вместе. Значит, микруха "портится" (может зависает, может не проходит STOP) при записи.

Вложения

rndread.PNG

(21.18 KiB) Скачиваний: 158

[BOB51]

Передача байта ...
затем в "хвосте"
Полная проверка АСК ->
ждем нуль,
подтверждаем стробом и
ждем освобождения шины слэйвом - т.е 1 на SDA.

НО... при передаче байта с R/W=1 следующая операция со стороны слэйва не прием, а передача того, что мы заказали.
И не факт, что первый бит заказанного равен 1.
Слейв то сразу же после строба выставил на SDA первый битик заказанного нами байта.
Посему в "хвосте" алгоритма проверки необходимо учитывать, что ответной 1 в этом случае ( R/W=1 ) мы можем и не дождаться.
Тогда как в общем случае (при передаче байта с R/W=0) ожидание ответной 1 по завершении АСК ОБЯЗАТЕЛЬНО.

[Shuspano]

все, разобрался. Видимо, после STOP записи микруха не сразу освобождается, а я ее почти сразу снова инициализирую на чтение. Несколько "нупиков" после STOP исправили ситуацию. МК быстрее епромки.

[BOB51]

Вот потому и делается контроль 1 в полном фрагменте программки передачи с R/W=0.
Прежде чем послать очередной (командный или данных) байт ждем готовности слэйва.

В то же время этот "полный контроль" подложит свинтуса при передаче командного байта с R/W=1.
Посему или две прожки передачи в зависимости от назначения или "универсальный хвост" с единой подпрограммой передачи байта.
Кому чего понятнее - так и делаем.
Воть как-то так...

[ARV]

Видимо, после STOP записи микруха не сразу освобождается

все временнЫе параметры микросхемы указаны в даташите. "несколько нупиков" - это путь к следующей ошибке. сделайте сразу правильно - разве это трудно?

[Shuspano]

В любом случае, других средств кроме нупов у меня нет. Не буду же я заводить таймер из-за нескольких микросекунд.

[ARV]

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

[Shuspano]

Четко написано 4,7 мкс. Ну это пять машинных циклов.
Кстати, вопрос. Пишет микруха очень медленно. Написано что 20 мс. И вот когда она запишет, мне от нее ждать ACK, или молотить пустой цикл и тупить 20 мс?
20 мс это очень долго. Это, прикидочно, ~10 000 инструкций. И вот, если линию SDA перевесить на один из INT-ов, завести прерывание, и пока она, допустим пишет, заниматься чем-то другим. Интересно, так можно?

[ARV]

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

Добавлено after 3 minutes 49 seconds:
кстати, все микросхемы памяти и2ц пишут не только побайтно, но и постранично, т.е. сразу по несколько байт, а время тратится при этом то же самое. так что вам выгоднее использовать страничную запись, если надо писать много данных. если страница 32 байта, то за те же 20 мс вы их сразу и запишите, а побайтно потратите в 32 раза большевремени!

[Shuspano]

Если вообще говорить, мне не очень нужен этот епром, мне нужен рабочий I2C Решил использовать в учебно-тренировочных целях, вроде не такая сложная.
Все равно, было интересно. Но если понадобится епром, возьму чего нибудь типа AT25020, там SPI, работа с ней не намного сложнее чем с 74HC595, и она быстрее, чем МК может шевелить ногами, там о задержках (кроме записи) не надо думать.

[BOB51]

Помимо стандартных значений имеют место и отклонения, вызванные схемотехникой... Там шинка в клубок свернулась... там обратный проводок "не туда" лишний ток пустил...
Лучше таки проверять завершение активности слэйва по факту, а не по жестко заданному интервалу.

Это именно протокола программного обмена касается.
А уж далее отлаженную библиотечку примитива можно цеплять к конкретной мелкосхемке - как та мелкосхемка работает - это уже следующий уровень прожки.