Администрация форума не несёт ответственности за достоверность информации и оставляет за собой право редактировать или в особых случаях даже удалять посты без предупреждения. Спасибо за понимание.

Программирование ATMEL в BASCOM.

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.



Устойчивость I2C к сбоям?

Сообщений 31 страница 47 из 47

31

Andrusha написал(а):

хочу просто понять.

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

0

32

RDW написал(а):

компилятор баскома не глупый

Ага. Подключаю вышеупомянутую библиотеку, получаю ошибку "Library not found", хотя в папке LIB она присутствует.

0

33

Библиотека нашлась. Попробовал перекомпиллировать часы на Меге 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

Получается что тинька не поддерживается этой библиотекой, или не поддерживает эту библиотеку. Или что я сделал не так? Код рабочий, приемник на даче уже несколько лет трудится.

0

34

Пётр написал(а):

Откуда такие предположения? Зачем это нужно?

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

Пётр написал(а):

Nord написал(а):Перенаправление пинов + использование аппаратного модуля TWI - очень даже логичное решение для реализации программного I2C на базе имеющихся аппаратных средств.

С чего вы решили что аппаратный модуль I2C в поддерживает переназначение выводов?

Я не сказал про использование аппаратного I2C, я сказал про аппаратные средства МК. ;)
"Штатные" ножки I2C расположены в общем доступе шины МК.
Что мешает вместо них указать другие ? ;)

Ладно, это все полемика.
В любом случае - компилятор - т.н. "черный ящик" и что внутри, знает только разработчик.
Мы видим только результаты работы этого ЧЯ... ;)

0

35

Пётр написал(а):

Nord написал(а):Кстати, протокол I2С в AVR "замешан" не на задержках, а на прерываниях...

Прерываниях от чего?

Цитата из ДШ ATbanned28:

Блок управления
Блок управления наблюдает за шиной TWI и генерирует отклики в соответствии с установками регистра управления TWI (TWCR). Если на шине TWI возникает событие, которое требует внимания со стороны программы, то устанавливается флаг прерывания TWINT.

А этих "событий" - не так уж и мало и все они описаны в таблицах ДШ... ;)

0

36

Andrusha написал(а):

Получается что тинька не поддерживается этой библиотекой, или не поддерживает эту библиотеку. Или что я сделал не так?

Раскопайте ДШ на Тиньку, выясните, как обзывается регистр, который в Меге называется TWCR, замените в библиотеке "TWCR > найденное", сохраните библиотеку под новым именем.

Только не получится... ;)
Нет в ATTiny2313 ни одного регистра I2C, т.к. нет в нем этого аппаратного модуля...
Ножки есть, а модуля нет... ;)

Отредактировано Nord (2020-02-24 17:18:56)

+1

37

Nord написал(а):

Ножки есть, а модуля нет...

И смысл в этих библиотеках. Прежде чем применить, нужно выяснить, поддерживается ли она контроллером. Не, мы лучше по старинке, ручками. :crazyfun:

0

38

Andrusha написал(а):

И смысл в этих библиотеках. Прежде чем применить, нужно выяснить, поддерживается ли она контроллером.

Смысл в них есть. Стабильность работы выше (ИМХО).

А выяснять ничего не надо - достаточно запомнить, что аппаратный I2C в ATTiny отсутствует... ;)

0

39

Andrusha написал(а):

Получается что тинька не поддерживается этой библиотекой

В ATtiny2313 есть аппаратный TWI? :)

Nord написал(а):

Я не сказал про использование аппаратного I2C, я сказал про аппаратные средства МК.

Нет вы написали про аппаратный I2C, упомянув TWI.  :)

Nord написал(а):

Перенаправление пинов + использование аппаратного модуля TWI - очень даже логичное решение для реализации программного I2C на базе имеющихся аппаратных средств.

Как такое можно было придумать - "реализация программного I2C аппаратными средствами"? Вообще отличаете программные реализации интерфейсов и аппаратные? В чем по вашему между ними отличие?

Nord написал(а):

"Штатные" ножки I2C расположены в общем доступе шины МК.Что мешает вместо них указать другие ?

Только для программного I2C. Попробуйте переназначить выводы аппаратного I2C. :)  Расскажите что получится. :D

Nord написал(а):

В любом случае - компилятор - т.н. "черный ящик" и что внутри, знает только разработчик.

Библиотеки открыты. Они на асме но все равно в общем можно понять как они работают. :)

Nord написал(а):

Цитата из ДШ ATbanned28:

Только для аппаратного I2C. Упоминание TWI ведь не просто так. Попробуйте получить прерывание от программного I2C.  :)  Расскажите что получится. :D

Nord написал(а):

Раскопайте ДШ на Тиньку, выясните, как обзывается регистр, который в Меге называется TWCR

Его там нет, но есть USI. :)

Nord написал(а):

А выяснять ничего не надо - достаточно запомнить, что аппаратный I2C в ATTiny отсутствует...

Он есть в ATtiny2313. https://avrhelp.mcselec.com/config_usi.htm
Надо выкладывать проверенную информацию иначе вы вводите других в заблуждение.

+2

40

Пётр написал(а):

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)

0

41

После

Код:
Config Usi = Twimaster , Mode = Normal 

библиотека $lib "i2c_twi.lbx" подключилась нормально. Выводы SDA и SCL только аппаратные. На другие ноги не перекидываются. Правда код вырос на 2 процента.

0

42

Nord написал(а):

Я все верно написал - I2C в ATTiny нет. USI есть.

Тогда следуя этой логике в ATmega нет I2C, а есть TWI. :) То есть в AVRах вообще нет аппаратного I2C, а в место него "заменители". :D

0

43

За что бан и где в последнем сообщенгие мат?
А проблема то решилась кофликт портов UART "был включен" то есть он не использовался а строка конфига была и всё, такая досадная мелочь.
А Err это вообще ниочем, просто там будет 1 если устройство не ответило, ни как на работоспособность не влияет, это чисто для инфы об ошибке.
Да уж тут баталии разгорелись!
О чём вообще спор? Аппаратный принимает и отправляет биты, а прогрмма уже только с байтами работает это даёт возможность работать на гораздо более высоких скоростях. Тут дело не размере кода. Аппаратные интерфейся для того и сделали что бы снять нагрузку с ядра! А если бы еще и буфер был тогда бы можно было пакетами работать и не надо было функции висеть пока работа закончится.

Что мешает вместо них указать другие ? ;)

Указыть не чего не мешает, но вот как сигнал направить на модуль! Так же как и PWM и внешние прерывания. Нет в данных чипах переключателей портов. Да и это лишнее, лишняя переферия которая будет характеристики ухудшать переключатели это ёмкость, сопротивление, да и значительное усложнение кристалла, который уже разработан.
Вы что на машиные коды пишите?
Но вообще то задача языка высокого уровня свести код программы до текста в независимости от там чего либо аппаратной платформы и прочего!

Отредактировано RadioHAM-433 (2020-02-27 02:46:12)

0

44

RadioHAM-433 написал(а):

А проблема то решилась кофликт портов UART "был включен" то есть он не использовался а строка конфига была и всё, такая досадная мелочь.

Если только это был программный UART и были назначены те же ножки, что и для I2C.
Тогда, возможно, будут накладки...

На практике - И снова часики
Часы и датчик на аппаратном I2C, дисплей - на аппаратном UART.
Все трое весело работают... ;)

0

45

RadioHAM-433 написал(а):

А Err это вообще ниочем, просто там будет 1 если устройство не ответило, ни как на работоспособность не влияет, это чисто для инфы об ошибке.

Если бы "Err это вообще ниочем" было, его бы не использовали вообще. ;)
Err = 1 будет:
- при отсутствии устройства на шине...
- при обращении по адресу АА, тогда как адрес устройства будет ВВ...
- при выходе устройства из строя
Err = 0 будет:
- при правильной работе шины и устройств
- при замыкании линии SDA на "корпус"

RadioHAM-433 написал(а):

Аппаратный принимает и отправляет биты, а прогрмма уже только с байтами работает это даёт возможность работать на гораздо более высоких скоростях.

Любой последовательный интерфейс принимает и отправляет побитно, в байты эти биты складываются...

RadioHAM-433 написал(а):

Вы что на машиные коды пишите?

Компилятор ЯВУ на выходе дает набор машинных команд - машинный код. ;)
Это, как думать по-русски, а мысли записывать на листочек по-английски... ;)

0

46

Если только это был программный 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)

0

47

RadioHAM-433 написал(а):

Байт данных загружается в регистр после чего уже уппаратно он передаётся по протоколу. Програмно не получится так быстро дёргать портам и слушать.

Получается иногда... ;)
Эмуляция 1-Wire устройства

RadioHAM-433 написал(а):

Зависало из-за конфликта портов, и никакие Err не помогут!!! Никакие!!!

Рад, что разобрались.  :flag:

0