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

[Dimon456]

Отсутствие внешнего кварца, программный UART, зависимость внутреннего RC-генератора от напряжения питания и от температуры.
Попробуйте стабилизировать напряжение питания.

Простая замена строчки #define F_CPU 9600000UL на #define F_CPU 4800000UL

Попробуйте уменьшить в 2 раза (надо подбирать под конкретные условия)

#if UART_SPEED == 19200 //
#define UART_DELAY (uint8_t) 122 // Delay for UART on 19200 baud

[GoldenAndy]

UL - это unsigned long - модификатор, указывающий компилятору, что число 9600000 - это беззнаковое целое длиной 4 байта.

#if UART_SPEED == 19200 //
#define UART_DELAY (uint8_t) 122 // Delay for UART on 19200 baud

для 9600 нужно увеличить задержку в 2 раза.
но при уменьшении тактовой с 9.6 до 4.8МГц - задержку надо уменьшить.
Т.е. в принципе, ее менять не надо.....

А вот с подбором частоты.... При ваших условиях питания и температуры.... Ну не знаю.
Смотрел я тот код микроУарта в свое время. Да, приемник там подстраивается под частоту передачи... Но передатчик молотит по заданным параметрам.
Т.е. на принимающей стороне тоже городить такой же самосинхронизированный приемнк нужно...

Для проверки можно в тиньке циклически запустить передачу какого то байта и смотреть тайминги осциллографом или лог.анализатором

[ПростоНуб]

Вообще-то, размер задержки надо делать не константой, а переменной. Значение ее устанавливать на синхроимпульсах при приеме и использовать и при приеме, и при передаче.

[GoldenAndy]

Так об этом и шла речь страницу назад. Я даже алгоритм накидал.
а microUart написан с целью минимизации используемого пространства, написан на Асме. И там нету измерения длины задержки. Там есть подстройка синхронизации при приеме по перепаду уровня на Rx...

[Combatos]

goldenandy писал(а):

для 9600 нужно увеличить задержку в 2 раза.
но при уменьшении тактовой с 9.6 до 4.8МГц - задержку надо уменьшить.
Т.е. в принципе, ее менять не надо.....

А вот с подбором частоты.... При ваших условиях питания и температуры.... Ну не знаю.
Смотрел я тот код микроУарта в свое время. Да, приемник там подстраивается под частоту передачи... Но передатчик молотит по заданным параметрам.
Т.е. на принимающей стороне тоже городить такой же самосинхронизированный приемнк нужно...

Для проверки можно в тиньке циклически запустить передачу какого то байта и смотреть тайминги осциллографом или лог.анализатором

Я тоже так думал насчет частоты и задержки, но не работает. Вообще ничего не передает. А насчет того, чтобы городить на мастере такой же самосинхронизирующийся приемник - хорошая идея. Там хоть и есть железный uart, но он задействован для общения через bluetooth модуль HC-05 с контроллером мотора (Kelly KLS7230S) моего мотоцикла. Наверное проще все-таки будет добавить туда такой же микроУарт, или другой. Вообще на ATmega328P и графическом LCD 128x64 (ST7920) у меня собрана панель приборов (типа бортовой компьютер) и захотелось прикрутить туда еще эту вот TinyBMS.

[GoldenAndy]

"Вообще ничего не передает."
1. заводИте в эмуляторе и смотрите, что оно делает
2. осциллограф или лог анализатор в руки - и смотреть, чего на линии.

3. бомж-вариант. Светодиод на свободную ногу и включать-выключать его в разных местах программы. И смотреть, куда доходит, куда нет.

[Combatos]

Есть осциллограф, даже 2: допотопный советский и китайский Hantek c wifi. Есть китайская копия Saleae Logic, именно с его помощью я хакнул протокол обмена данными Kelly KLS7230S. Так вот, лог. анализатор не показывает ничего, когда я меняю частоту с 9600000 на 4800000 в программе микроУарт.

[GoldenAndy]

ну значит ищите траблу в программе.
(я как то забыл сконфигурировать порт на выход и долго мучился с неработающим СПИ)
Попробуйте пошагово в эмуляторе вашей IDE пройтись ....
Подрыгайте программно ногой, попробуйте написать свой уарт - он простой....

[Combatos]

Та похоже, так и сделаю. Попробую свой написать, свои баги легче будет отловить.

Добавлено after 1 minute 23 seconds:
Возник возможно глупый вопрос: I2C для моих целей не подойдет?

[GoldenAndy]

Имхо, его сложнее будет развязать. оно двунаправленное. У вас UART вполне нормально зайдет.

[Combatos]

Ок. Беру за основу ваше описание алгоритма с предыдущей страницы и поехали...

[Dimon456]

Так вот, лог. анализатор не показывает ничего, когда я меняю частоту с 9600000 на 4800000 в программе микроУарт.

Смысла менять в программе строку #define F_CPU 9600000UL на #define F_CPU 4800000UL нет ни какого.
Допустим у вас прошивка собрана под параметры

Код: Выделить всё

#define F_CPU 9600000UL
#define   UART_SPEED     19200

Просто меняем фьюзы (без изменения прошивки) контроллера с 9,6МГц на 4,8МГц, и у вас уарт будет работать не на 19200, а на 19200/2= 9600.

На 9,6 МГц UART работает на скорости 9600, но при напряжении питания больше 4В

Могу предположить одно, во фьюзах вы случайно включили монитор питания Brown-out detection level at VCC=4.3 V; [BODLEVEL=00]

[Combatos]

Dimon456 писал(а):

Так вот, лог. анализатор не показывает ничего, когда я меняю частоту с 9600000 на 4800000 в программе микроУарт.

Смысла менять в программе строку #define F_CPU 9600000UL на #define F_CPU 4800000UL нет ни какого.
Допустим у вас прошивка собрана под параметры

Код: Выделить всё

#define F_CPU 9600000UL
#define   UART_SPEED     19200

Просто меняем фьюзы (без изменения прошивки) контроллера с 9,6МГц на 4,8МГц, и у вас уарт будет работать не на 19200, а на 19200/2= 9600.

На 9,6 МГц UART работает на скорости 9600, но при напряжении питания больше 4В

Могу предположить одно, во фьюзах вы случайно включили монитор питания Brown-out detection level at VCC=4.3 V; [BODLEVEL=00]

Спасибо, прошил фьюзы без имменения програмимы - запустился этот микроУарт. Но он оказался какой-то кривой, там длительность нуля и единицы в кодовой посылке разная, соотношение такое: 0 - 0,241мс, 0 - 0,192мс (это при скорости UART 4800, когда должно быть 0 и 1 по 0,208мс каждый). На этой скорости работает также в ограниченном диапазоне питания (3,5-4,2В), что мне не подходит. Надо либо допиливать программу, либо писать свою. Этим и занимаюсь, пишу свою.

[Combatos]

Беру свои слова обратно, микроУарт работает отлично, это оптроны у меня "кривые". Для теста соединил Tx, Rx напрямую, без оптопар. Подобрал задержку в программе здесь:

#if UART_SPEED == 9600
#define UART_DELAY (uint8_t) 230//246 // Delay for UART on 9600 baud //

При выставленной скорости UART 9600 и фьюзах тиньки, прошитых на 4,8МГц, получаю скорость 4800. При этой скорости и напряжении питания тиньки 2,5В: 0 - 0,209мс, 1 - 0,211мс. При питании 4,5В: 0 - 0,208мс, 1 - 0,211. Можно сказать идеально и практически не зависит от напряжения питания в нужном мне диапазоне! Пробовал греть феном (при питании 2,5В): на второй секунде нагрева пошли ошибки. Трудно сказать, при какой температуре начинаются глюки, нечем измерить. Но думаю, где-то после 35..40 градусов, а то и раньше. Печалька, но я об этом знал. Капнул спиртом на корпус тиньки и стал дуть - никаких глюков до полного испарения спирта! Охлаждение не так страшно, как нагрев. Теперь вопрос, как еще снизить скорость до 2400 и ниже?

[GoldenAndy]

А поможет ?
отклонение тактовой частоты в процентном соотношении никак не зависит от выбранной скорости

[Ivanoff-iv]

а эти 9600 при Н.У. ровно такие, как надо? может у них изначально отклонение есть и при нагреве только всё усугубляется?
попробуй с OSCCALом поиграться немного и померять, как меняется термостабиьность

Добавлено after 2 minutes 17 seconds:
ещё проверь, чтобы х2 было выключено - оно тоже снижает стабильность канала.

[Combatos]

goldenandy писал(а):

А поможет ?
отклонение тактовой частоты в процентном соотношении никак не зависит от выбранной скорости

Снижение скорости UART нужно для адекватной работы медленных оптронов. Попробую пока поиграться с резисторами обвязки оптронов..

Добавлено after 7 minutes 15 seconds:

Ivanoff-iv писал(а):

а эти 9600 при Н.У. ровно такие, как надо? может у них изначально отклонение есть и при нагреве только всё усугубляется?
попробуй с OSCCALом поиграться немного и померять, как меняется термостабиьность

Добавлено after 2 minutes 17 seconds:
ещё проверь, чтобы х2 было выключено - оно тоже снижает стабильность канала.

Термостабильность - полбеды. На данном этапе нужно разобраться с оптронами.

[Kavka]

Хмм... У подчинённых контроллеров отсутствует стабильное тактирование. Соответственно, возможны сбои при пересылке данных в обе стороны, как от главного, так и от подчинённых.
А что если исключить ошибки при передаче хотя бы в одну сторону? Как думаете, это как-то поможет?

[akl]

Combatos писал(а):

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

Можно воспользоваться CLKPR – Clock Prescale Register, позволяющий программно менять предделитель тактовой на лету. Например, CLKPR задает предделитель тактовой 16 и для формирования битных интервалов, вместо задержек, использовать таймер Т0 в режиме CTC.
OCR0A=4800000/16/2400=125-1

[ПростоНуб]

akl писал(а):

Можно воспользоваться CLKPR – Clock Prescale Register, позволяющий программно менять предделитель тактовой на лету.

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