Программирование ATMEL в BASCOM. |
Привет, Гость! Войдите или зарегистрируйтесь.
Вы здесь » Программирование ATMEL в BASCOM. » Связь проводная и бесп-ная, интерфейсы, протоколы » Устойчивость I2C к сбоям?
Привествую товарищи! Подскажите есть реализации I2C устойчивого к неиправности что бы зависнуть не могло?
Пока что все баскомовские варианты виснут при отсутвии устройства. SPI вот так не делает например.
Кажись надо свою функцию писать тогда и будет известно что неполадка на линии уже. Неужел ипридётся?
Или может косяк в другом?
Отредактировано RadioHAM-433 (2020-02-19 06:46:36)
Покопался тут в своих развалах по этому вопросу... 
Источник не помню:
Данная шина предусматривает возможность иметь сразу несколько ведущих, предоставляя все необходимые средства для определения коллизий, а также арбитраж, позволяющий предотвратить повреждение данных в том случае, если два или большее количество ведущих начинает одновременно передавать информацию.
.....
В микросхемах используется специальный встроенный фильтр, который достаточно эффективно подавляет всплески и обеспечивает максимальную целостность данных.
Предельно возможное количество микросхем, которые могут быть подсоединены к одной шине, ограничивается только ее предельно возможной емкостью, составляющей 400 пФ.
Фрагмент перевода из даташита на ATMega8:
Когда ведомый осознает, что к нему обращаются, он должен ответить, установив LOW на линии SDA в девятом цикле SCL (ACK). Если адресованное ведомое устройство занято или по какой-либо другой причине не может обслуживать запрос ведущего устройства, линия SDA должна быть оставлена высоко в такте ACK. Затем мастер может передать условие остановки или повторное условие запуска для инициирования новой передачи.
Отсюда можно (думаю) сделать вывод, что вопрос с конфликтами решен аппаратно производителями чипов.
Можно программно отслеживать состояние ножки SDA при соответствующем состоянии SCL (см. выше) и, если ведомый не выставляет там ожидаемый "0", то считать, что ведомый сдох или отсутствует (логика, как в 1-Wire).
Только надо будет после чтения восстановить бит TWCR.TWEN, который после чтения пина может "свалиться", т.к. меняется способ использования пина...
Не претендую на "истину в первой инстанции", это мои выводы...
А можно по русси? Если это по русси то ответ на вопрос отличный от моего!
Внимание обращаюсь к русски или знающим русский по крайней мере! Есть ли способ без написания функции работы с I2C програмно избежать зависания при неполадках на шине?
Отредактировано RadioHAM-433 (2020-02-19 08:03:19)
По русски: всё должно работать и виснуть ничего не должно. В Баскоме есть обработчик ошибок при работе с I2C (Err).
Протокол/шина весьма надежная, рассчитана работать в составе внутренней части схемы. Если вы решили "сэкономить" и использовать её как например RS-485 на приличном удалении (сопли), то это ошибка.
Виснет скорее всего по другой причине (плохое питание/помехи..) и возможно проблема с внешней периферией/чипами, но сам МК не должен виснуть. Если всё таки это происходит, то о проблеме можно сообщить Марку (на офф форум). Или как вариант придумать механизм обхода этого обработчика через стэк (запомнить на входе значения PC, затем на выходе его руками восстанавливать, если повиснет через период времени (правда тут есть одна проблема с запоминанием переменных, придется все регистры сохранять перед каждым входом/выходом). 
ps: возможно виснуть может тогда, когда вместе с I2C используется Timer, который как раз используется для внутренних нужд.
Отредактировано RDW (2020-02-22 13:02:57)
В общем попробуйте поиграться с опцией "Err" и понаблюдать за результатами.
Использован програмный так уже сложилось в данной реализации.
Но я не спорю о надёжности данной шины но вот в Bascom программная реализация оказалась увы... Меня инетересует как это в Bascom всё работает а пока что оно себя показало нет устройства и всё зависло всё надёжность кончилась, то есть неполадка на шине и всё. По SPI похер было на отсутвующее устройство, при записи вообще SPI пофиг что там, даже при чтении отсутвии устройва вообще прочиталось все байты 255 и всё.
Зависает программа после обращения в I2C а не шина или что там могло бы зависнуть что бы ради чего я стал писать бы. Зависнуть неподлюченное или сдозшее устройство как ради такого точно бы не стал.
Хотя при стартовой инициализации зависает когда прерывания еще не включались.
Я видел что отписывались что Bascom реализация I2C такая удогая что работает лишь иногда.
Так о таймере по подробнее можно? Может который еще не запущен? Но Timer1 на mega328 используется для измерения времени, после ухода в обработку приёма таймер останавливается, да и его нельзя трогать никак нельзя!
Тут всё достаточно неоднозначно, после приёма данных с аппарата опрос датчика проиходит при отключенных прерываниях уже, при отсутвии сигнала просто датчик опрашивается для измерения температуры и давления, для отображения их. Это опрос датчика BMP280 на ПДУ для измерения высота аппарата относительно ПДУ. Прерывания не много время тянут там снимаеся время с таймера принимается бит и всё, частота прерываний без сигнала ~20кГц.
Но вообще используются прерывания, да именно по причине прерываний в таких решениях только синхронные шины, асинхронные типа 1wire сбоят, приоритет прерываниям. Зы даже Uart колбасит, потому по Uart общение при отключенной приёме. Но SPI всё чётко! Да там можно это подключить на SPI но всё же надо с I2C разобраться.
Данные на экран выводятся каждую секунду по SPI MAX7456.
Это 1-я версия ПДУ надо всё тут отладить что бы во 2-й уже сразу определиться что где будет.
UART вообще не используется!
Для обмена данными между МК который работет в реальном времени у меня есть протокол полностью фоновый данные передаются синхронно с подтверждением, принял следующий такт. Фоновый потому что не ограничивает время ожидания, данные передаются когда есть такт функции, тут всё хорошо если время есть скорость получается высокая. То есть принял поставил что принял, другой обнаружил что принято передаёт следующий байт/бит зависит от разрядности. UART тут работать не будет нормально.
Да я код добавил а датчик еще не подключался из-за его отсутвия еще. Возможно правда проблема в том что таймеры еще все стоят при конфигурации датчика и там же сразу виснет.
1wire при отсутвии устройка выдаёт ошибку но никаких сбоев в программе не было еще!
Отредактировано RadioHAM-433 (2020-02-23 04:00:37)
Зависает программа после обращения в I2C а не шина или что там могло бы зависнуть что бы ради чего я стал писать бы.
Все правильно. Программа работает с регистрами модуля TWI, а не с шиной.
Поэтому:
1. Проверьте, не возникают ли объявленные прерывания в процессе работы с I2C ?
2. Отключение аппаратного модуля TWI произойдет так же при выполнении PORTC = ххх (применительно к Mega328). При использовании TWI с этим портом надо обращаться "побитно", минуя ножки SCL/SDA.
3. Собственно работы самого таймера в МК можно не опасаться, аппаратно они с модулем TWI не завязаны, но их прерывания... См. п.1...
Если такое случится, то потребуется повторная инициализация аппаратного модуля TWI, о чем я уже упоминал ранее.
Программа обращается к нему, а он (модуль) отключен...
Это применимо ко всем синхронным аппаратным интерфейсам, а так же к программным (1-Wire, например).
Это примерно, как выполнить Enable INT0 и безуспешно ожидать его события, не выполнив Enable Interrupts...
PS. Просто последнее время озадачился I2C-slave, посему рою эту тему "по-взрослому"
Я всё понял правильно значит что программный I2C убогий по само небалйся и работает он иногда. Так что програмного I2C в Bascom нету ни кому не советую использовать это уродство! Конечно независать при неответе устройства он не может.
Точно програмисты писали ни чё не скажешь, только настоящий програмист может сделать что при отстувии ответа устройства будет зависать.
Программа обращается к нему, а он (модуль) отключен...
Так а никто не гарантирует что всегда всё будет подключено, какой чип и всё полетит куда далеко и жестко и после такого полёта мало что останется если что останется найдётся 
! И полетит не потому что даже вся шина встанет (а если на I2C единственное устройство барометр без которого можно обойтись легко) а потому что зависнет прогрмма когда какой то чип не ответит! Уже на этом всё будет кончено на мягкое приземление рассчитывать как то...
Вот как известно стало SPI естественно отказоустойчивый он не может зависнуть как при записи вообще нет подтверждения, при чтении тоже будет читать чё та даже если там нет ни чё.
Зы так сложилось что я как таковую отладочную плату не сделал. Ща попробую на псевдоотладочной что будет с аппаратным I2C при отсутвии устройсва. Если так же то или писать свою функцию или не использовать I2C. Но в принципе потому програмный I2C Basom и не использовали наверное по этой причине.
Очень хорошо что сейчас вся прелесть всплыла.
Отредактировано RadioHAM-433 (2020-02-23 06:34:24)
Я всё понял правильно значит что программный I2C убогий по само небалйся и работает он иногда.
Начнем с того, что упора именно на программный I2C изначально не было.
Далее... Почему вот тут Сканер устройств подключенных по шине i2c ничего не зависает, пока ищется адрес ?
Остальных - как бы нет...
Из практики...
В ходе сотворения и отладки одного устройства довольно долго не подключал к плате BME280, пока отлаживал другие моменты. На I2C он - единственный. Ничего не зависало.
Вы задаете вопрос, ничего не прилагая, кроме "зависает" и "не работает", при этом прямо таки требуете адекватный ответ, практически обвиняя других в некомпетенции...
- Исхитрись ка мне добыть "то чего не может быть" ! (с) Л.Филатов
Ладно это всё ниочём, я вашего языка не понимаю, Вы моего глупый разговор!
Далее... Почему вот тут Сканер устройств подключенных по шине i2c ничего не зависает, пока ищется адрес ?
Потому это совсем другое кино, где не играют в домино!
ы задаете вопрос, ничего не прилагая,
Не прилагая приложение это так очевидно! А чё можно приложить то? Куда приложить и зачем вот вопрос? Что это даст, кто ж поймёт то. А тот кто в теме тот поймёт. Тема тут достаточно сложная зависание програмного I2C при отсутвии устройства.
Отредактировано RadioHAM-433 (2020-02-23 06:46:28)
Зря вы сразу "в штыки"...
Ладно это всё ниочём, я вашего языка не понимаю
А на каком языке тогда общаться ?
Сами же пишете:
Так а никто не гарантирует что всегда всё будет подключено, какой чип п***а и всё полетит куда далеко и жестко и после такого полёта мало что останется если что останется найдётся ! И полетит не потому что даже вся шина встанет (а если на I2C единственное устройство барометр без которого можно обойтись легко) а потому что зависнет прогрмма когда какой то чип не ответит!
При использовании аппаратного I2C зависания МК не произойдет. Проверено практически и не раз.
Идеология I2С это предусматривает.
В случае выхода из строя одного из Ведомых - он просто не будет откликаться Мастеру.
Единственный случай - замыкание шины на "корпус", но так чипы I2C не сдохнут по конструктивным причинам.
Работу программного I2C обсуждать не буду, т.к. еще ни разу не использовал.
Тема тут достаточно сложная зависание програмного I2C при отсутвии устройства.
Наконец-то появились уточнения...
Не прилагая приложение это так очевидно! А чё можно приложить то? Куда приложить и зачем вот вопрос?
Листинг программы или зависающего фрагмента...
Что это даст, кто ж поймёт то. А тот кто в теме тот поймёт.
Если все равно никто не поймет - тогда не утруждайтесь с листингом, а из тех, "кто в теме" - телепатов тут нет, чтоб увидеть, что вы там наваракосили...
Наконец-то появились уточнения...
Неа не появились уточнения, это всеголишь повторения повторений. Появились они лишь в моём 2-м сообщение.
Работу программного I2C обсуждать не буду, т.к. еще ни разу не использовал.
Вот с того бы и следовало бы начать и закончить. А лучше не начинать и заканчивать не надо.
Зачем начитать то что надо заканчивать, а если заканчивать то зачем начинать?
При использовании аппаратного I2C зависания МК не произойдет. Проверено практически и не раз.
Это кино где уже сыграли в домино.
что вы там наваракосили...
Это точно не комне! Это у разработчиков Bascom надо спрашивать. Но явно постарались.
Отредактировано RadioHAM-433 (2020-02-23 07:56:46)
Неа не появились уточнения, это всеголишь повторения повторений. Появились они лишь в моём 2-м сообщение.
А ничего, между "первым" сообщением и, как вы говорите, "повторением" - трое суток прошло ?
На этом и завершим...
У меня программный I2C. Как написал ранее RDW, с помощью проверки ERROR я контролирую и DS3231, и BME280 на одной шине. Если какого то устройства нет, то на дисплей выдаётся соответствующее сообщение. Таймер 0 используется для динамической индикации. Ещё опрашивается DS18B20. И всё работает! У топикстартера скорее всего проблема в неправильном построении архитектуры программы.
И ещё, за использование мата заблокировал на три дня.
У меня программный I2C.
Если я правильно понимаю архитектуру, то программный I2С позволяет назначить произвольные ножки для SCL и SDA и не подключать библиотеку, которая привязана к аппаратному, но физически в работе все равно используются регистры модуля TWI в МК.
Если это так, то программный I2C по устойчивости протокола не отличается от аппаратного.
Зачем программному I2C использовать регистры TWI?
Что при использовании аппаратного, что программного I2C все равно применяются операторы:
I2cstart
I2rwbyte...
I2cwbyte...
I2cstop
Программа же (программист) не заморачивается с аппаратным (лог. уровни, длительности и т.п.) выполнением протокола, это за него делает компилятор.
На физическом уровне, насколько я разгрыз эту архитектуру МК, в обоих случаях работает модуль TWI в МК.
А его работа строится на группе регистров TWхх.
Если неправ - готов признать...
На физическом уровне, насколько я разгрыз эту архитектуру МК, в обоих случаях работает модуль TWI в МК.А его работа строится на группе регистров TWхх.
Просто интересно как вы себе представляете использование аппаратного I2C в виде программного?
То что команды одинаковые еще не значит что используется аппаратный I2C. Для его использования нужно подключить библиотеку i2c_twi.lbx. 
Из справки.
To use the hardware I2C routines and not the Software I2C routines you need to use the $lib "i2c_twi.lbx"
аппаратный I2C. Для его использования нужно подключить библиотеку i2c_twi.lbx.
А вы уверены, что это необходимо? И что дает эта библиотека? Сколько раз использовал аппаратный И2С, без этой библиотеки. Все работало нормально. Это не подколка, хочу просто понять.
Просто интересно как вы себе представляете использование аппаратного I2C в виде программного? То что команды одинаковые еще не значит что используется аппаратный I2C. Для его использования нужно подключить библиотеку i2c_twi.lbx.
Тут не я должен объяснения придумывать, а М.А. комментировать свое детище...
Подключение библиотеки, возможно, как-то оптимизирует конечный код.
Возможно, без библиотеки компилятор обращается к регистрам TWхх по их адресу в памяти, а с ней - по их "имени"...
Ну, как варианты объяснения "разницы"...
И, таки повторяю - ни разу не видел, чтоб при использовании программного I2C кто-то заморачивался в теле программы реализацией протокола I2C, кроме как операторами Bascom.
Но ведь он реализуется на указанных ножках МК.
Какой "невидимый суслик" этим занимается ?
Уверен - "модуль TWI" в МК... Других объяснений не вижу.
Сколько раз использовал аппаратный И2С, без этой библиотеки.
Использование "аппаратных" ножек МК без библиотеки - это программный режим.
Только ножки - "родные"...
В подкрепление своих размышлений.
Вот скрин из ДШ PCF8574
Даже здесь присутствует схема контроля и управления шиной I2C.
Возможно даже, что в этой схеме какой-нибудь супер-мини-МК присутствует...
В МК этот модуль с более широкой функциональностью.
А операторы Bascom... К ним привязываться, думаю, не стоит.
Задача компилятора - преобразовать понятное нам (человеку) написание в команды, понятные МК.
Операторы 1-Wire - заставляют формировать на указанной ножке протокол 1-Wire...
Операторы I2C - вызывают ресурсы модуля TWI...
А вот аппаратные различия реализации "программного или аппаратного" - это, думаю, только разработчик объяснить сможет...
Возможно, без библиотеки компилятор обращается к регистрам TWхх по их адресу в памяти, а с ней - по их "имени"...
То есть МК можно передать имя регистра и получить результат? 
Или все таки у каждого регистра свой адрес и на уровне МК имен регистров нет?
Программный I2C как и программные 1Wire, USART и т. д., реализованы методом задержек и записью/чтением портов. Или по вашему мнению в программном USART используются регистры аппаратного USART? 
А вы уверены, что это необходимо?
Об i2c_twi.lbx написано в справке.
https://avrhelp.mcselec.com/index.html?i2c_twi.htm
https://avrhelp.mcselec.com/index.html? … otocol.htm
https://avrhelp.mcselec.com/index.html?config_twi.htm
Какой "невидимый суслик" этим занимается ? Уверен - "модуль TWI" в МК... Других объяснений не вижу.
Почему не допускаете что протокол I2C можно реализовать только программными средствами (задержки и чтение/запись портов)?
Для баскома есть программный USB так что будем считать что в ATmega8 имеется недокументированный аппаратный USB, существование кторого разработчики скрывают от нас?
Операторы 1-Wire - заставляют формировать на указанной ножке протокол 1-Wire...
Операторы I2C - вызывают ресурсы модуля TWI...
А какие ресурсы вызывают операторы 1Wire. Или 1Wire возможно реализовать программно, а I2C ну никак нельзя?
Пётр, я не вкурю, к чему вы ведёте ?
Вы - местный гуру, я это признаю, но это не говорит о том, что я должен безоговорочно принимать сказанное вами.
Вы или не понимаете, о чем говорю я, или я недостаточно точно изъясняюсь...
То есть МК можно передать имя регистра и получить результат?
Я выразил предположение, а вы его приняли за главное и смеётесь...
Если знаете что-то больше - скажите, если не жалко.
Пётр, я не вкурю, к чему вы ведёте ?
К тому что программная реализация не использует аппаратные модули. Откуда такое предположение что программный I2C может использовать регистры аппаратного TWI? Это же нелогично. Программный I2C должен работать на всех МК в т. ч. не имеющих модуля TWI. А если он использует его регистры, то какой же это программный I2C? Это аппаратный I2C.
Вы или не понимаете, о чем говорю я
Вы пишите
Если я правильно понимаю архитектуру, то программный I2С позволяет назначить произвольные ножки для SCL и SDA и не подключать библиотеку, которая привязана к аппаратному, но физически в работе все равно используются регистры модуля TWI в МК.
Как это иначе понимать кроме как "программный I2C использует аппаратный модуль TWI". А TWI это одно из названий I2C. Если I2C использует TWI это аппаратный I2C.
Я выразил предположение, а вы его приняли за главное и смеётесь...
Я не смеюсь. Это просто смайлики...
К тому что программная реализация не использует аппаратные модули.
Откуда такая уверенность (Справка не в счет) ?
Программный I2C должен работать на всех МК в т. ч. не имеющих модуля TWI. А если он использует его регистры, то какой же это программный I2C? Это аппаратный I2C.
Следовательно, программный I2C эмулирует аппаратный "модуль TWI", все его регистры и их зависимость.
Если это так, то это не "есть гуд", т.к. отнимает аппаратные и временнЫе ресурсы МК.
При небольших проектах это незаметно.
Вот так и найдем истину.
PS. Кстати, протокол I2С в AVR "замешан" не на задержках, а на прерываниях...
Отредактировано Nord (2020-02-24 00:30:29)
Откуда такое предположение что программный I2C может использовать регистры аппаратного TWI? Это же нелогично.
Наоборот (ИМХО)...
Перенаправление пинов + использование аппаратного модуля TWI - очень даже логичное решение для реализации программного I2C на базе имеющихся аппаратных средств.
Для пользователя это незаметно, он использует заявленные ресурсы, а всё отрабатывает компилятор.
Я бы (на месте разработчика компилятора) так поступил.
Следовательно, программный I2C эмулирует аппаратный "модуль TWI", все его регистры и их зависимость.
Откуда такие предположения? Зачем это нужно? Намного проще программно реализовать протокол I2C чем эмулировать работу аппаратного модуля.
I2C не такой сложный и его описание легко можно найти в сети. https://ru.wikipedia.org/wiki/I²C
Кстати, протокол I2С в AVR "замешан" не на задержках, а на прерываниях...
Прерываниях от чего?
Перенаправление пинов + использование аппаратного модуля TWI - очень даже логичное решение для реализации программного I2C на базе имеющихся аппаратных средств.
С чего вы решили что аппаратный модуль I2C в поддерживает переназначение выводов?
Как быть если в МК нет аппаратного I2C? Программный работать не будет? Не кажется что это нелогично?
Прежде чем дальше строить неизвестно на чем основанные предположения откройте файл i2c.lib находящийся в папке LIB баскома. Там вы увидите и "работу с регистрами TWI" и "прерывания вместо задержек" и другие ваши самые смелые предположения.
Вы здесь » Программирование ATMEL в BASCOM. » Связь проводная и бесп-ная, интерфейсы, протоколы » Устойчивость I2C к сбоям?