[k155la3 26]

17 minutes ago, rx3apf said:

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

скорее всего да. Разве что захват уже на грани. Если PLL от 32768, (не про AVR речь), то вполне может хватить.

[NStorm 0]

At 5V, 25*C and 1.0MHz Oscillator frequency selected, this calibration gives a frequency within ±3% of the nominal frequency.

Плюс вот это:

На 60*С и питании +5В, уже будет около 7.7 МГц, при меньшем питании еще ниже. Какое у вас напряжение питания?

[zombi 0]

20 hours ago, Arlleex said:

Угу... Буду ждать, значит, когда дадут свободную для тестирования плату.

Зачем чего-то ждать?

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

Осциллографом смотрите что происходит при нагреве/охлаждении/касании пальцем и пр.

[k155la3 26]

Здесь RC гарантирует только одно, что при 5В/25С и определенной (просчитанной, корректирующей) константе генератор можно заставить работать на 8МГц. Похожая хрень была на MSP430F2618, где эта константа просчитывалась специальным прогр. кодом, с "базой" тактирования от 32768.

Далее кварц мог не использоваться. У меня так от RC, без сбоев, работал USART на 57600.

Вообще, у чипосторителя для RC должна была быть заложена хотябы параметрическая корректировка от ухода по температуре. Тогда в этом есть смысл.

Вообще, должен быть доступ к этой константе, ограниченная защита. Если уж совсем хорошо думать о FW-писателе - то и режим калибровки должен быть прописан в FW (к примеру, по удерживаемой по включению кнопке). Кварц, правда, все равно придется для этого подключать. Или менять константу методом полутыка.

[Arlleex 131]

Да я постарался найти вообще другую плату с таким же контроллером.

Настроил UART на прием, по приему определенного байта переключал светодиод.

Запустил в терминале циклическую отправку этого самого спецсимвола.

Светодиод замигал. Начал греть феном, и, этак градусах на +70 связь начала пропадать.

При еще большем нагреве связь прекратилась вовсе.

 

Потом зашил фьюз-бит на ту же частоту, только от кварца. Сбоев нет. Греть/не греть, без разницы. Работает всегда.

 

ЧТД, собственно. Всем спасибо!

[zombi 0]

6 hours ago, Arlleex said:

ту же частоту, только от кварца. Сбоев нет. Греть/не греть, без разницы. Работает всегда.

[Arlleex 131]

Возвращаюсь к теме.

 

Собственно, забавная ситуация. Требуется мозговой штурм Кому интересно - подключайтесь

 

Дано: ATMega8A с ее внутренним RC-генератором на 8МГц. Точность его сами знаете какая.

К девайсу подключается по UART 9600-N-1 (физика RS-232), грубо говоря, комп. Он шлет в него запросы, а девайс отвечает.

Перепаивать глобально ничего нельзя, фактически имею, что имею. И переписывать ПО на комп тоже нельзя

Одну ножку МК (с программатора), в общем-то, можно, наверное, выцыганить.

 

Итак, при нагреве МК первым отключался прием аппаратным модулем UART из-за все-таки плывущей частоты RC-генератора.

Да-да, изначально я слишком надеялся на "ох ща как поплывет". А она плывет ооочень незначительно... По крайней мере от +~33 до +~90 градусов.

 

Порылся я в протоколе обмена (то еще дромыхло), нарыл важную статистическую инфу.

Если смотреть не качественно, а количественно на данные в протоколе, то комп отправляет

• 2 байта при запросе статистики девайса;
• 3 байта для запроса "полезных данных".

На 2-байтную команду запроса статистики девайс должен выплюнуть данные А, на 3-байтную - данные Б. Именно за эту количественную особенность я и зацепился.

 

Завел достаточно ВЧ-таймер и в некоторой логике в основном цикле + в прерывании по этому таймеру выделил количество приходящих байт в посылке.

Стал выплевывать нужные кадры данных в зависимости от типа команды. Все стало работать даже при очень высокой температуре МК (+~125 градусов, судя по пирометру, на 126 уже начинает контроллер плохо отличать 2 байта от 3 - ну да и фиг с ним, точности хватает с головой).

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

Ну, в общем: смотрю индикатором на USB-UART-переходнике и вижу, что даже когда якобы связь потерялась, МК правильно распознает тип входной команды и отправляет нужную пачку данных.

Но теперь уже USB-UART-переходник перестает правильно видеть входные кадры, которые передаются из девайса.

То есть, поплыла частота на МК и, соответственно, поплыли тайминги UART-передатчика.

 

Вот думаю, какой магией еще воспользоваться

Подумывал даже какой-то хитрой логикой "подстраивать" OSCCAL на лету и отправлять 3 ответные посылки - при OSCCAL = 0, 50 и 100% тюнинга.

Но это тестить надо - сжует ли это компуктер. Кадры защищены CRC (ну как, тупо сумма байт фактически facepalm)...

А можно, наверное, припаять к одной свободной ноге датчик DS18B20 и тоже подстраивать OSCCAL... Жжеееесть.

 

P.S. Фьюзы настроил на 8МГц, но генератор не калибровал. Нужна гарантия работы девайса от -25 до +50 градусов по Цельсию.

[aaarrr 63]

2 hours ago, Arlleex said:

Подумывал даже какой-то хитрой логикой "подстраивать" OSCCAL на лету и отправлять 3 ответные посылки - при OSCCAL = 0, 50 и 100% тюнинга.

Подстраивать лучше не OSCCAL, а UBRR. В качестве источника частоты использовать запросы хоста, если первый байт имеет не произвольное значение.

[Arlleex 131]

7 минут назад, aaarrr сказал:

Подстраивать лучше не OSCCAL, а UBRR. В качестве источника частоты использовать запросы хоста, если первый байт имеет не произвольное значение.

Грубо говоря, настроить все-таки UART, и при обрыве связи "искать" рядом с текущим UBRR до тех пор, пока содержимое посылки не восстановится?

Хм, а это вполне себе вариант Спасибо. Завтра, возможно, этим и займусь, благо не долго.

 

Первый байт... Он имеет одно из двух значений.

Грубо говоря, для 2-байтовой посылки он один, для 3-байтовой - другой.

 

Кстати, можно просто объединить оба метода - определять длину сообщения, и исходя из этого плясать в сторону получения нужного байта.

[aaarrr 63]

17 minutes ago, Arlleex said:

Грубо говоря, настроить все-таки UART, и при обрыве связи "искать" рядом с текущим UBRR до тех пор, пока содержимое посылки не восстановится?

Нет. Измерить время бита хоста, затем выставить по нему точный UBRR.

[Vladivolt 0]

Насколько сильно загружен ATmega? Есть ли возможность реализовать софтверный приёмник? Так в отличие от аппаратного раньше можно заметить уплыв в ту либо другую сторону и подстроить свою сетку.

[Arlleex 131]

18 минут назад, aaarrr сказал:

Нет. Измерить время бита хоста, затем выставить по нему точный UBRR.

16 минут назад, Vladivolt сказал:

Насколько сильно загружен ATmega? Есть ли возможность реализовать софтверный приёмник? Так в отличие от аппаратного раньше можно заметить уплыв в ту либо другую сторону и подстроить свою сетку.

Да не особо, в целом.

Матричная клавиатура и ШИМ-выход.

 

Да только все сделано и разведено через одно место.

Все ноги не сгруппированы и раскиданы по портам тяп-ляп. Оптимально не написать.

А их надо отфильтровать от дребезга, при нажатии - зафиксировать до ближайшего опроса.

А потом еще перекодировать из внутреннего представления во внешнее для компуктера.

 

Также ШИМ... Завели на обычную ногу, вместо таймера. А ШИМ управляет подсветкой экрана, и схемотехника этого "каскада счастья" полный ахтунг.

При единичном импульсе на сотню-другую с чуть более широкой длительностью, чем остальные, происходит заметное мерцание экрана. Кошмар.

 

С добавлением этого моего софт-приемника-анализатора, загрузка еще больше увеличилась. Но еще есть место для творчества.

 

Идея с подстройкой UBRR мне нравится. Сейчас в регистре у меня записано 51, при 8МГц это 9615 Бод.

Изменив на 1 вверх, получим уже 9434 Бод. Разница в 181 Бод. ИМХО, достаточно для того, чтобы автоподсинхронизация работала.

[NStorm 0]

Лучше всё-таки OSCCAL подгонять. Чтобы все тайминги в порядке были.

http://ww1.microchip.com/downloads/en/appnotes/doc2563.pdf вот прям целый аппнот под вас написан, на калибровку внутреннего RC по как раз таки UART и для UART.

Если кратко - RXD подкидываем на прерывание INT0 (ну или на INT1 или захваты таймера). В случае ошибок по UART, с ведущего ус-ва (ПК) посылается специальный сигнал. Отключаем UART и ловим длительность синхросигналов таймером. По расхождению таймера от заранее известных значений - мы понимаем куда у нас "уехала" частота и подстраиваем OSCCAL. Там бинарный поиск описывается, я думаю в вашем случае можно заранее таблицу для поиска составить просто.

Изменено 21 апреля, 2020 пользователем NStorm

[Arlleex 131]

1 час назад, NStorm сказал:

Лучше всё-таки OSCCAL подгонять. Чтобы все тайминги в порядке были.

http://ww1.microchip.com/downloads/en/appnotes/doc2563.pdf вот прям целый аппнот под вас написан, на калибровку внутреннего RC по как раз таки UART и для UART.

Если кратко - RXD подкидываем на прерывание INT0 (ну или на INT1). А ведущего ус-ва (ПК) посылается специальный сигнал. И в случае ошибок на UART, по прерыванию определяем в какую сторону смещать OSCCAL и т.д.

Было б все так гладко... Подкинуть RXD на INT0 нельзя. Никуда нельзя - все ноги заняты. Ну, MOSI свободен...

Так-то и без аппноута понятно, что делать Я видел его утром.

 

Тут нужна реальная магия...

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

Для уверенного приема UART на 8-N-1 нужна 2% точность соответствия желаемой и фактической скоростей.

А это значит, что я очень точно должен измерить длительность старт-бита, при условии, что LSB данных будет '1'.

На скорости 9600 длительность старт-бита равна ~104мкс. По сути, уход на проценты мне надо отслеживать мегагерцовым таймером.

При таких раскладах ISR такого таймера забьет на 99.9% все процессорное время...

 

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

 

Сейчас, допустим, при ровных 8МГц тактовой и UBRR равным 51 получаем 0.16% относительной погрешности.

При UBRR равным 52 получаем -1.73% относительной погрешности. При UBRR 50 погрешность уже 2.12%.

Инкремент/декремент UBRR соответствует компенсации в девиации входной частоты на 153.6кГц.

Грубо судя по графику в даташите на ATMega8A, от -40 до +85 градусов частота RC-генератора может быть в диапазоне от 7.5...8.5МГц.

А это 6.5 шагов по 153.6кГц, то есть 4 шага UBRR вниз и 4 вверх максимум при поиске оптимальной скорости.

 

Значит, алгоритм сводится к следующему:

1. u8 cal = 0;

2. При инициализации установить UBRR = 51 + cal (якобы у нас точно 8МГц RC).

3. Если в течение интервала прихода сообщений от компа не было установлено корректного приема, делаем ++cal, UBRR = 51 + cal.

4. Если в течение интервала прихода сообщений от компа не было установлено корректного приема, делаем UBRR = 51 - cal.

5. Повторить шаги 3 - 4 до тех пор, пока cal <= 4.

Внутри этого алгоритма должно подобраться оптимальное UBRR, ИМХО.

[zombi 0]

А не получится ли точнее подстроить если выбрать Double speed mode (U2X=1)?