хочу просто понять.
Ну компилятор баскома не глупый, сейчас он умеет сам переключать либы в зависимости от использования внешней периферии, а принудительное указание используется для нестандартных решений.
Программирование ATMEL в BASCOM. |
Привет, Гость! Войдите или зарегистрируйтесь.
Вы здесь » Программирование ATMEL в BASCOM. » Связь проводная и бесп-ная, интерфейсы, протоколы » Устойчивость I2C к сбоям?
хочу просто понять.
Ну компилятор баскома не глупый, сейчас он умеет сам переключать либы в зависимости от использования внешней периферии, а принудительное указание используется для нестандартных решений.
компилятор баскома не глупый
Ага. Подключаю вышеупомянутую библиотеку, получаю ошибку "Library not found", хотя в папке LIB она присутствует.
Библиотека нашлась. Попробовал перекомпиллировать часы на Меге 8. Код уменьшился на 1 процент. Дальше попробовал приемник на Тиньке 2313. Код увеличился на 1 процент, и выскочила ошибка.
Error : 202 Line : 9 .EQU not found, probably using functions that are not supported by the selected chip [TWCR] , in File : C:\PROGRAM FILES (X86)\MCS ELECTRONICS\BASCOM-AVR\LIB\I2C_TWI.LBX
Получается что тинька не поддерживается этой библиотекой, или не поддерживает эту библиотеку. Или что я сделал не так? Код рабочий, приемник на даче уже несколько лет трудится.
Откуда такие предположения? Зачем это нужно?
Ну раз уж зашел разговор про то, как на самом деле реализуется программный I2C, ото отчего бы не поразмышлять. 
Nord написал(а):Перенаправление пинов + использование аппаратного модуля TWI - очень даже логичное решение для реализации программного I2C на базе имеющихся аппаратных средств.
С чего вы решили что аппаратный модуль I2C в поддерживает переназначение выводов?
Я не сказал про использование аппаратного I2C, я сказал про аппаратные средства МК. 
"Штатные" ножки I2C расположены в общем доступе шины МК.
Что мешает вместо них указать другие ? 
Ладно, это все полемика.
В любом случае - компилятор - т.н. "черный ящик" и что внутри, знает только разработчик.
Мы видим только результаты работы этого ЧЯ... 
Nord написал(а):Кстати, протокол I2С в AVR "замешан" не на задержках, а на прерываниях...
Прерываниях от чего?
Цитата из ДШ ATbanned28:
Блок управления
Блок управления наблюдает за шиной TWI и генерирует отклики в соответствии с установками регистра управления TWI (TWCR). Если на шине TWI возникает событие, которое требует внимания со стороны программы, то устанавливается флаг прерывания TWINT.
А этих "событий" - не так уж и мало и все они описаны в таблицах ДШ... 
Получается что тинька не поддерживается этой библиотекой, или не поддерживает эту библиотеку. Или что я сделал не так?
Раскопайте ДШ на Тиньку, выясните, как обзывается регистр, который в Меге называется TWCR, замените в библиотеке "TWCR > найденное", сохраните библиотеку под новым именем.
Только не получится... 
Нет в ATTiny2313 ни одного регистра I2C, т.к. нет в нем этого аппаратного модуля...
Ножки есть, а модуля нет... 
Отредактировано Nord (2020-02-24 17:18:56)
Ножки есть, а модуля нет...
И смысл в этих библиотеках. Прежде чем применить, нужно выяснить, поддерживается ли она контроллером. Не, мы лучше по старинке, ручками. 
И смысл в этих библиотеках. Прежде чем применить, нужно выяснить, поддерживается ли она контроллером.
Смысл в них есть. Стабильность работы выше (ИМХО).
А выяснять ничего не надо - достаточно запомнить, что аппаратный I2C в ATTiny отсутствует... 
Получается что тинька не поддерживается этой библиотекой
В ATtiny2313 есть аппаратный TWI?
Я не сказал про использование аппаратного I2C, я сказал про аппаратные средства МК.
Нет вы написали про аппаратный I2C, упомянув TWI.
Перенаправление пинов + использование аппаратного модуля TWI - очень даже логичное решение для реализации программного I2C на базе имеющихся аппаратных средств.
Как такое можно было придумать - "реализация программного I2C аппаратными средствами"? Вообще отличаете программные реализации интерфейсов и аппаратные? В чем по вашему между ними отличие?
"Штатные" ножки I2C расположены в общем доступе шины МК.Что мешает вместо них указать другие ?
Только для программного I2C. Попробуйте переназначить выводы аппаратного I2C.
Расскажите что получится.
В любом случае - компилятор - т.н. "черный ящик" и что внутри, знает только разработчик.
Библиотеки открыты. Они на асме но все равно в общем можно понять как они работают.
Цитата из ДШ ATbanned28:
Только для аппаратного I2C. Упоминание TWI ведь не просто так. Попробуйте получить прерывание от программного I2C.
Расскажите что получится.
Раскопайте ДШ на Тиньку, выясните, как обзывается регистр, который в Меге называется TWCR
Его там нет, но есть USI. 
А выяснять ничего не надо - достаточно запомнить, что аппаратный I2C в ATTiny отсутствует...
Он есть в ATtiny2313. https://avrhelp.mcselec.com/config_usi.htm
Надо выкладывать проверенную информацию иначе вы вводите других в заблуждение.
Nord написал(а):А выяснять ничего не надо - достаточно запомнить, что аппаратный I2C в ATTiny отсутствует...
Он есть в ATtiny2313. https://avrhelp.mcselec.com/config_usi.htmНадо выкладывать проверенную информацию иначе вы вводите других в заблуждение.
Я все верно написал - I2C в ATTiny нет. USI есть.
Это, как в линейке ATMega48...328 нет регистра GIFR, а есть EIFR... 
Я же уже писал:
Раскопайте ДШ на Тиньку...
Только не получится...
Вот последняя фраза неполная получилась, тут каюсь... 
Надо бы было "Только не получится быстро" 
Отредактировано Nord (2020-02-25 13:56:34)
После
Config Usi = Twimaster , Mode = Normal
библиотека $lib "i2c_twi.lbx" подключилась нормально. Выводы SDA и SCL только аппаратные. На другие ноги не перекидываются. Правда код вырос на 2 процента.
Я все верно написал - I2C в ATTiny нет. USI есть.
Тогда следуя этой логике в ATmega нет I2C, а есть TWI.
То есть в AVRах вообще нет аппаратного I2C, а в место него "заменители". 
За что бан и где в последнем сообщенгие мат?
А проблема то решилась кофликт портов UART "был включен" то есть он не использовался а строка конфига была и всё, такая досадная мелочь.
А Err это вообще ниочем, просто там будет 1 если устройство не ответило, ни как на работоспособность не влияет, это чисто для инфы об ошибке.
Да уж тут баталии разгорелись!
О чём вообще спор? Аппаратный принимает и отправляет биты, а прогрмма уже только с байтами работает это даёт возможность работать на гораздо более высоких скоростях. Тут дело не размере кода. Аппаратные интерфейся для того и сделали что бы снять нагрузку с ядра! А если бы еще и буфер был тогда бы можно было пакетами работать и не надо было функции висеть пока работа закончится.
Что мешает вместо них указать другие ?
Указыть не чего не мешает, но вот как сигнал направить на модуль! Так же как и PWM и внешние прерывания. Нет в данных чипах переключателей портов. Да и это лишнее, лишняя переферия которая будет характеристики ухудшать переключатели это ёмкость, сопротивление, да и значительное усложнение кристалла, который уже разработан.
Вы что на машиные коды пишите?
Но вообще то задача языка высокого уровня свести код программы до текста в независимости от там чего либо аппаратной платформы и прочего!
Отредактировано RadioHAM-433 (2020-02-27 02:46:12)
А проблема то решилась кофликт портов UART "был включен" то есть он не использовался а строка конфига была и всё, такая досадная мелочь.
Если только это был программный UART и были назначены те же ножки, что и для I2C.
Тогда, возможно, будут накладки...
На практике - И снова часики
Часы и датчик на аппаратном I2C, дисплей - на аппаратном UART.
Все трое весело работают... 
А Err это вообще ниочем, просто там будет 1 если устройство не ответило, ни как на работоспособность не влияет, это чисто для инфы об ошибке.
Если бы "Err это вообще ниочем" было, его бы не использовали вообще. 
Err = 1 будет:
- при отсутствии устройства на шине...
- при обращении по адресу АА, тогда как адрес устройства будет ВВ...
- при выходе устройства из строя
Err = 0 будет:
- при правильной работе шины и устройств
- при замыкании линии SDA на "корпус"
Аппаратный принимает и отправляет биты, а прогрмма уже только с байтами работает это даёт возможность работать на гораздо более высоких скоростях.
Любой последовательный интерфейс принимает и отправляет побитно, в байты эти биты складываются...
Вы что на машиные коды пишите?
Компилятор ЯВУ на выходе дает набор машинных команд - машинный код. 
Это, как думать по-русски, а мысли записывать на листочек по-английски... 
Если только это был программный UART и были назначены те же ножки, что и для I2C.
Тогда, возможно, будут накладки...
Нет UART как раз аппаратный, программный UART еще ни разу не приходилось использовать, и был конфликт портов. UART вообще там использоваться проводной не планировался там беспроводной интерфейс. Зы если бы он использовался то бы эти порты ни под что другое не могли бы быть использованы xDDDDDD. Зы для мелких МК у меня ИК канал правда на 8Кб занимает 70-80% то есть как бы ни чё кроме интерфейса уже на таком МК не будет, там самое простое. Но по проводу можно около 50% там нет шифрования, формат данных логический там загрузчик много занимает.
Часы и датчик на аппаратном I2C, дисплей - на аппаратном UART.
Все трое весело работают...
Но и чё?
Я вообще внутренние протоколы только синхронные использую, любой более менее нормальный прогер будет так же делать. И у меня протокол фоновый, функция не виснет во время отправки, за 1 такт функции передаётся 1 порция данных в зависимости от разрядности до 8бит нет смысла больше 8Бит слишком много портов надо и прибавку в скорости нет, обычно 4бит полностью фоновый (фоновый с обеих строно), и 1бит низкоскоростной полуфоновой (фоновый со стороны ведущего), ведомый как правило работает в реальном времени (аналоговая функция там все операции равные по времени выполняются за каждый такт, то есть там каждый такт нужно обрабатывать результат).
Любой последовательный интерфейс принимает и отправляет побитно, в байты эти биты складываются...
А вот и нет! А вот и да!
Байт данных загружается в регистр после чего уже уппаратно он передаётся по протоколу. Програмно не получится так быстро дёргать портам и слушать.
Если бы "Err это вообще ниочем" было, его бы не использовали вообще.
А не всего его используют, и он не чего не даёт. Без Err не чего не падает (то есть дело было не в этом), и то что зависало тут Err вообще лесом. Зависало из-за конфликта портов, и никакие Err не помогут!!! Никакие!!!
Отредактировано RadioHAM-433 (2020-02-27 06:00:08)
Байт данных загружается в регистр после чего уже уппаратно он передаётся по протоколу. Програмно не получится так быстро дёргать портам и слушать.
Получается иногда... 
Эмуляция 1-Wire устройства
Зависало из-за конфликта портов, и никакие Err не помогут!!! Никакие!!!
Рад, что разобрались. 
Вы здесь » Программирование ATMEL в BASCOM. » Связь проводная и бесп-ная, интерфейсы, протоколы » Устойчивость I2C к сбоям?