Применение МК без кварца.

[SlovachevskyDV]

Т.е. "искажается" только один бит, 7й, который следует сразу после старта... А остальные идут условно нормально... Интересно, если 7й бит будет 1 (посылать 0хАА вместо 0х55) будет ли он искажаться... Впрочем проблему это не решит...

Кстати, а какое напряжение питания контроллера?

Когда просматривал свои данные, тo искажался не только старший бит. Бывало, что даже количество принятых байт было больше на 2-3 чем нужно. Напряжение 5в. Стабилизировано 78l05

[Someone]

Напряжение 5в. Стабилизировано 78l05

Эх, жаль гипотеза пропала хорошая. Ну да ладно. осталось только подтвердить, что всё дело в частоте. В тестовом коде задать частоту (изменить значение F_CPU, в самом начале программы ), отличающуюся от номинальных 8 МГц в плюс и минус. Скажем на 100 - 200 кГц. Т.е. проверить работу тестового кода на частотах 7800000...8200000 Гц.

Я ведь к чему так заинтересовался - в 2013 я разработал оповещатель пламени, и в нём штатная возможность работа RS485 по протоколу модбас. Изначально кварц там присутствовал, КХ7, на 7.3728 МГц. Сначала объёмы продаж были небольшие - в первый год вообще ни одного не продали, потом постепенно росли, и в 2017 превысили 1000 в год. Руководство говорит - что-то очень маленькая прибыль, продаём почти по себестоимости, оптимизируй себестоимость. Ну я и подумал: 1 кварц 70р. А тысяча - уже 70000р. Ещё прошелся по элементам, что-то упростил, что-то из "железа" в контроллер перенёс, в общем на 300р снизил цену комплектующих. И с 2017 схема работает на внутреннем RС. Контроллер мега168. И вот с 2017 произведено около 3000 таких извещателей. И каждый из них проходит ПСИ. Ставятся в камеру тепла-холода (до 20 извещателей влезает), подключается 485й к каждому, и проверяется работа при -40 и при +85. После достижения температуры - выдержка 3 часа, после проверка работы. И всё это время идёт опрос состояния извещателей. При скорости 38400 много пакетов (10-15%), принимаемых компом, получается битой (неверная контрольная сумма или нет ответа на запрос). На 19200 за 3 часа накапливается пара сотен пакетов, а на 9200 битых пакетов - 0. И при -40, и при +85. Вот и заинтересовался, как так получается, что в нормальных условиях (20 градусов, плюс-минус), да на 2400, и перестаёт работать...

[alex_t2]

Похоже, ключевой момент - скорость 9600.
У меня сейчас планируется RS485 в модулях на меге168. Кварц на плате разведен, но пока официально 485 не поддерживается, его не распаиваю, и тактирую от внутреннего RC.
Обмен работает идеально, WAKE протокол. Ставил сутками на непрерывный запрос-ответ, ошибок 0. Скорость именно 9600.
Хотя глянул, на 2400 тоже 0,2% отклонение при 8 МГц. По идее, должно бы лететь.

[Someone]

По идее, должно бы лететь.

Вот и я о том же. При озвученных, можно сказать нормальных, лабораторных условиях, работать должно. Разве что сам контроллер бракованный, но это очень маловероятно - за, примерно 10 лет, я помню всего два случая - мега 128, пин как вход работал нормально, а вот на выход вместо 0 выдавалось 1.5В, и не работал АЦП на мега 48 - всё время выдавал 1024, при любом напряжении на входе.

[alex_t2]

Если официальная поставка - брак обычно 0%
Однажды по срочной нужде взял в чипдипе - дохли при пайке массово, сейчас уже давно налажена нормальная поставка - вообще не помню, чтоб хоть один нерабочий попался.
Калибровка внутреннего RC бывает неточной, упоминал выше. Но это очень редко.

[SlovachevskyDV]

Да. Планирую сделать следующее:
Устройство на STM или комповая программа, если будет часто принимать от меги мусор, пошлет ей команду "старт калибровки". В ответ мега начнет перебирать значения регистра OSCCAL от 0 до 0xFF и отправлять их. Приемник посчитает все правильно принятые, вычислит среднеарифметическое и отправит обратно в команде "калибровка завершена".

Калибровка имеет право быть.
Ответную прогу на комп или stm еще не писал
Пока проверил только через терминал вручную.
Но результат налицо. После перебора OSCCAL стабильно выводило значения только на диапазоне 9C - AF. При значении FF прием тоже перестал работать. Когда задал OSCCAL равным А5 и прием и передача стали работать стабильно.

[ForcePoint]

Но результат налицо. После перебора OSCCAL стабильно

Простите великодушно, но я не заметил в предыдущих сообщениях упоминаний этого регистра. Значит ли это, что о нём вспомнили только сейчас и, соотвественно, о "Calibration Bytes" не вспоминали тоже?

[SlovachevskyDV]

Простите великодушно, но я не заметил в предыдущих сообщениях упоминаний этого регистра. Значит ли это, что о нём вспомнили только сейчас и, соотвественно, о "Calibration Bytes" не вспоминали тоже?

Вспоминал. В сообщении #35 на 3-й странице. О Calibration Bytes не вспоминал. Сейчас посчитаю.
==============
Спасибо. Почитал. Никогда не заморачивался на эту тему, а как вник, то офигел, насколько "удобно" на 8-й меге сделана калибровка частоты. Т.е автоматически грузится значение только для 1МГц, если используется другое значение внутреннего генератора, то нужно прочитать программатором калибровочное значение для нужной частоты, и (ручками) записать куда-нибудь в EEPROM или Flash, а потом в программе прочитать и использовать. Если я все правильно понял - это ЖЕСТЬ!

[Someone]

Калибровка имеет право быть.

Йа, Йа, натюрлих.

Вот только вместо того, чтоб самому искать пути (я про "посылать запрос на калибровку"), давно исхоженные миллионами программистов за 15-20 лет (всё украдено до нас, увы) может быть стоит использовать "стандартные" методы, например AVR54: Run-time calibration of the internal RC oscillator. Всего-то один или два синхробайта в начале пакета запроса от "мастера", и алга...

[ForcePoint]

Спасибо. Почитал. ..... Если я все правильно понял - это ЖЕСТЬ!

"Не читал, теперь - негодую!" Что тут сказать... "учите матчасть, мужики".

P.S. ЕМНИП, ATmega88 позволит читать калибровочные байты командой SPM.