Передача данных из множества ATtiny13A в один ATmega328P

[GoldenAndy]

Combatos, может, все же посмотреть в сторону самописного протокола ? Который кодирует 1 и 0 длиной импульсов?

оптроны у меня "кривые"

Напомните, что за оптроны ?
Ибо вот эти РС829, судя по даташиту, имеют Response time 4uS....
У меня данніе через РС849 на 9600 бегают, аж пищат.

Последний раз редактировалось GoldenAndy Сб мар 09, 2019 09:46:16, всего редактировалось 1 раз.

[Dimon456]

Теперь вопрос, как еще снизить скорость до 2400 и ниже?

Собираем проект с параметрами

Код:

#define F_CPU 9600000UL
#define   UART_SPEED     19200

Во фьюзах включаем 9,6МГц, внутренний делитель на 8; [CKDIV8=0]. 19200/8=2400
При

Код:

#define F_CPU 9600000UL
#define   UART_SPEED     9600

9600/8=1200

Еще меньше надо?
Собираем проект с параметрами

Код:

#define F_CPU 9600000UL
#define   UART_SPEED     19200

Во фьюзах включаем 4,8МГц, внутренний делитель на 8; [CKDIV8=0]. 19200/2/8=1200
При

Код:

#define F_CPU 9600000UL
#define   UART_SPEED     9600

9600/2/8=600

[OKF]

Dimon456, как то через жопу у вас всё. А с задержками зависящими от F_CPU что будем делать? Тоже делить? Не, не, не. Это не наш метод.

[Dimon456]

Dimon456, как то через жопу у вас всё. А с задержками зависящими от F_CPU что будем делать? Тоже делить?

Пока что F_CPU ни на что не влияет, любое значение. Вот когда будет видно что оно на что-то влияет...

Не, не, не. Это не наш метод.

А какой ваш метод? Предложите свой метод.

[OKF]

А что мешает писать F_CPU какой есть на самом деле? И не надо в голове держать всякие делители. Как минимум.

[Combatos]

Уря! Заработало! Много времени убил на эксперименты, конечно, но не зря. Долго подбирал резисторы обвязки оптронов, вооружившись осциллографом и лог. анализатором. В конечном итоге изменил только один номинал - резистор на входе Rx тиньки, на коллекторе транзистора оптрона (было 470 Ом, стал 300 Ом). Потом путем подбора величины задержки в программе микроУарт добился устойчивой работы УАРТ с оптронами на частоте 4800. Работает в диапазоне питания тиньки от 2,1В (тайминги 0 и 1 соответственно 0,204мс и 0,223мс) до 4,5В (тайминги (0)0,240мс, (1)0,190мс). Тайминги конечно не идеальные, но это работает! Величина задержки для этой тиньки получилась 227 (заводская установка OSCCAL= 86).
Но я спаял тестовую плату на 3 ячейки, проделал то же самое и с остальными двумя. Результаты такие: вторая ячейка работает от 2,5В до 4,5В (задержка 253, заводская установка OSCCAL= 75); третья ячейка 2,3В-4,5В (задержка 238, заводская установка OSCCAL= 80). Результаты везде разные, заводская калибровка очень неточная к сожалению.
В принципе, оптроны выгребают эту скорость в нужном мне диапазоне питания, наверное еще уменьшать скорость не стоит. А вот с подбором задержки и калибровкой частоты вручную - беда, долго приходится возиться. Надо подумать, как автоматизировать этот процесс.. Правда я пока в калибровку частоты тинек не лез.

[GoldenAndy]

А теперь положите одну платку на полчасика в морозилку

[Ivanoff-iv]

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

[OKF]

Какая разница от чего калибровка! От любого внешнего источника. Хоть даже от 220!

[GoldenAndy]

пример по калибровке осскал по частоте сети...

Какая разница от чего калибровка! От любого внешнего источника. Хоть даже от 220!

Там правильней всего калиброваться по тестовому принимаемому сигналу.
Но. Это нужно самому писать. И тня там всего 512 машинных команд.....

[OKF]

Этих 512 команд достаточно для этой задачи. Ещё и остаться должно.

[Combatos]

Читал этот апноут : http://www.gaw.ru/html.cgi/adv/app/micr ... AVR053.htm
Там решения для Atmel Studio и программаторы под него. Мой программатор работает по CodeVision.. Я так понимаю, калибровка OSCCAL осуществляется аппаратно, с помощью программатора. Или есть программный вариант?

[GoldenAndy]

В том аппноте описывается простая идея. В контроллер заливается тестовая программа, потом на контроллер подается эталонная частота, а контроллер пытается подобрать калибровочную константу так, что бы измерение эталонной частоты давало результат +/-1%.
Далее подобранное значение калибровочной константы закидывается в ЕЕПРОМ, откуда его нужно потом забрать и использовать в своей программе.

Но это калибровка исключительно под одну температуру и напряжение питания.

Используйте все же или калибровку задержи uart на лету по принятым данным, или придумайте свой протокол, которому +/-15% частоты до лампочки.
А то замахаетесь калибровать свои 24 тни.

[Dimon456]

goldenandy писал(а):

Как на данный момент я представляю себе ваш уарт...
От мастера прилетает 2 байта - первый 0х55 - для синхронизации, второй - запрашиваемый адрес.

Откуда алгоритм?

Код:

13. Если СЧЕТЧИК>0: уменьшаем СЧЕТЧИК; возвращаемся к п.13

14. РХ сдвинули влево ( РХ <<= 1 )  // раз ошибка к счетчику СЧЕТЧИК
15. если РХПОРТ == 1: РХ |= 0х01    // два ошибка к счетчику СЧЕТЧИК
16. БИТ++                                        // три ошибка к счетчику СЧЕТЧИК

17. если БИТ<9: СЧЕТЧИК = ЗАДЕРЖКА; переход на п.13     // четыре ошибка к счетчику СЧЕТЧИК

Это все условно, в итоге за место 52мкс получаем где-то 82мкс при скорости 19200, и вылазим за диапазон 9 бит, мы еще 9 бит не приняли, а передача 9 бит уже закончилась давным давно.
Не возможно выравнять, выравнять можно под конкретную скорость и под конкретную тактовую частоту, тактовая частота поплыла и все выравнивание поплыло. Скорость меняем и выравнивание уже ни куда не годится, то же и с частотой получается.

Тот же вариант, приобрел ATtiny13A надо на что-то их использовать.

Автор, хотя бы ATTINY24 с внешним кварцем, и проблем меньше, в самом худшем случае 50ppm (т.е. где-то 0.005%).

[GoldenAndy]

Откуда алгоритм?

Из головы.
По ошибкам - в конце алгоритма была приписка.
Указанные вам ошибки - не плавающие. Их можно скомпенсировать.
Если бы я делал такого плана устройство - и быо ограничение на кристалл - я бы делал именно так, как предложил.
После компиляции посмотрел бы дизасм для подсчета количества ошибочных тактов и посмотрел бы, сколько тактов занимает изменение счетчика на 1. На основании этого определил бы коректирующую константу.

У меня стояла похожая задача - внешний датчик с батарейным питанием, который сам в себе и только отдает данные.
Прикинув все нюансы - я поставил мегу8 и кварц на 4 МГц. Хотя начинали думать на тне85. При этом получаю железный uart, стабильную частоту и бОльшее количество GPIO. Мега 8 по цене соизмерима с тнёй 13.

[Dimon456]

Из головы.

Вообще-то алгоритм работает, довольно эффективно работает +-1МГц.
Проверил на Atmega8 (не подумайте что аппаратный уарт использовал) включив тактирование на ножку XTAL1 от внешнего регулируемого генератора, в пределах +-1МГц от заданной частоты. Получается где-то +/-20%.

[Combatos]

А какой размер кода получился? Не могли бы поделиться прогой, раз уже работает?

[GoldenAndy]

Dimon456 , спасибо, что смогли попытаться превратить мои домыслы в живой код.
Компенсацию задержек вводили ?

И да, присоединюсь к Combatos, покажите код

[Kavka]

А если такая идея. Надо тинькам (подчинённым) от главного принять принять адрес. Это одно действие, которое надо сделать, в идеале, без ошибок. А дальше главный делает паузу и передаёт несколько байт 0x55 (или 0xAA), чтобы у тинек были "опорные" фронты по которым они будут передавать свои данные. Т.е. передавая по фронтам от главного не будет ошибок при передаче от тинек к главному. К тому же, когда одна передаёт, остальные калибруются. У главного можно аппаратный УАРТ задействовать. Что-то вот такое придумалось.

[GoldenAndy]

Так это и реализовали.
Я в теории, Dimon456 в железе.
Первый байт 0х55, второй - адрес.
По первому биту байта синхронизация, далее прием адреса и выплевывание данных