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

[OKF]

[uquote="Combatos",url="/forum/viewtopic.php?p=3578841#p3578841"]Спасибо большое всем! Выбрасываю из схемы 431, понижаем потребление! И можно приступать к софту.[/uquote]
Ну слава богу!) Теперь бы ещё резистор с оптрона убрать и ресет с питанием соединить. Ну и на мастере по 3 оптрона на один пин посадить для нормальности.

[ПростоНуб]

А можно еще выкинуть оптроны и сделать емкостную развязку. Но софт при этом существенно усложнится, так как потребуется модуляция сигнала и, скорее всего, его усиление.
Можно, конечно, сразу ISO7241С поставить, но вряд ли ТС требуется скорость до 30 мегабит )

[Combatos]

[uquote="ПростоНуб",url="/forum/viewtopic.php?p=3579417#p3579417"]А можно еще выкинуть оптроны и сделать емкостную развязку. Но софт при этом существенно усложнится, так как потребуется модуляция сигнала и, скорее всего, его усиление.
Можно, конечно, сразу ISO7241С поставить, но вряд ли ТС требуется скорость до 30 мегабит )[/uquote]

Ну, это уже высший пилотаж! Повоюем пока с оптронами..

[Combatos]

[uquote="goldenandy",url="/forum/viewtopic.php?p=3578055#p3578055"]повесил прищепкой-биндером на плату-переходку тиню85, завел на ней ногодрыг на килогерц.
На 2.2 вольта частота ногодрыга 994 гц, на 3 вольтах - 1001 гц, 4 вольта - 1008 гц, 5 вольт - 1015 гц. К сожалению, под прищепкой погреть зажигалкой не получилось.
Т.е. во всем диапазоне питания частота меняется от -0,5% и до +1,5%....[/uquote]

Собрал тестовую плату на 3 ячейки, прошил такой же ногодрыг на одной из тинек, только расчетный период таймера 0,8 мс (1250 Гц), а фьюзы прошил на частоту 4,8Мгц. Подтверждаю, от напряжения питания частота генератора почти не зависит, в пределах +-1 %. При 2В - 1135Гц, при 4,5В - 1140Гц
А вот с температурой все действительно печально. Только начал греть феном, частота поплыла вверх. Термометром не мерял, но по тактильным ощущениям при температуре корпуса тиньки около 40 градусов частота была уже 1200Гц, а это около 6% Ну да ладно, будем посмотреть. Пришло время софтовых испытаний..

[GoldenAndy]

Вот, кстати, еще вопрос нарисовался....
У вас в нормальных условиях частота уже ушла на 10% от заданной - uart не заведется в таких условиях...
Так что думайте или в сторону синхронизации по мастер-посылке, а потом либо свой протокол, либо uart

[ПростоНуб]

Альтернативный, слегка бредовый, вариант. Поставить на тиньки по ИК-светодиоду, а на мегу - один единственный TL1838. Обратную связь оставить через оптроны. Тогда мега сможет посылать данные через USART, начиная каждый обмен с синхробайта (10101010), а тиньки воспольузются устойчивостью передачи сигнала по ИК.

[Combatos]

[uquote="goldenandy",url="/forum/viewtopic.php?p=3580005#p3580005"]Вот, кстати, еще вопрос нарисовался....
У вас в нормальных условиях частота уже ушла на 10% от заданной - uart не заведется в таких условиях...
Так что думайте или в сторону синхронизации по мастер-посылке, а потом либо свой протокол, либо uart[/uquote]

В даташите написано: By changing the OSCCAL register from SW, see “OSCCAL – Oscillator Calibration Register” on
page 27, it is possible to get a higher calibration accuracy than by using the factory calibration. Попробую калибровать..
Предпочтительней конечно UART, т.к. он есть в железе главного контроллера. Я просто не особо продвинутый программист, пишу на С в CodeVisionAVR. Пора переходить на Atmel Studio, а лучше на Algorythm Builder.

[GoldenAndy]

ПростоНуб, а чем идея с ИК светодиодом лучше оптопары ?
Речь идет не о физическом уровне передачи данных, а о логическом. О том, что частота подчиненного нестабильна и стандартный протокол UART может не охватить такую нестабильность. (я в похожей задаче передачи по uart данных от уличных датчиков плюнул и поставил мегу 8 с кварцем. Ибо у меня в уличном датчике нет приема данных, только передача. И синхронизироваться не по чему... А на тиньку не получилось поставить кварц, ног не хватало. А ресет нужен пока что..)

Combatos, OSCCAL register
А не замахаетесь калибровать индивидуально каждую тню ? Особенно с учетом того, что тактовая плывет от температуры (в чем вы убедились) ?
вспоминаем графики из ДШ

Спойлер

Ну и какая разница, в какой IDE вы пишете, в ЦВАВРе или в Студии ? И там, и там один и тот же компилятор gcc....
Алгоритм билдер.... ну не знаю... С одной стороны он как то ближе к ассемблеру... С другой - это нишевый продукт и если у вас возникнут вопросы по вашему коду, то вам сможет помочь гораздо меньшее число людей... В отличие от Сишного кода.
По протоколам. Поскольку у вас система как в школе - пока училка не спросит, ученик молчит - а uart софтовый - начинайте обращение от меги к тиньке передачей байта 0х55. А все тиньки при начале приема, когда идет стартовый бит (ну или первый бит данных, ибо при стартовом бите тиньке еще проснуться надо, завести свой тактовый генератор....) считают длительность этого бита, сохраняют ее в какую то ячейку, дальше используют эту константу для обмена данными. Перед засыпанием эту константу тиньки должны забыть. Для того, что бы при следующем сеансе посчитать новую константу. Т.е. у вас по сути остается тот же софтовый uart, но он использует не "магические числа" таймингов, вычисленные при компиляции, а те, что посчитались при приеме.... В этом случае можно частоту вообще не калибровать, ибо автокалибровка скорости передачи может покрыть приличную дельту тактовой...
Единственное, придется "курить" протокол uart и писать свой приемопередатчик пробовать. либо допиливать готовый...
как минимум, приемник нужно будет подкорректировать, что бы при нерассчитаной задержке отлавливался первый бит, считалась его задержка, а потом первая задержка для чтения второго бита была равна половине расчетной (что бы потом читать серединки передаваемых битов).
Вот как то так....

[ПростоНуб]

[uquote="goldenandy",url="/forum/viewtopic.php?p=3580040#p3580040"]ПростоНуб, а чем идея с ИК светодиодом лучше оптопары ?[/uquote]
Исключительно тем, что и для тинек, и для меги, для ИК легко найти уже готовый код, а сам ИК протокол весьма устойчив к рассинхронизации.

[GoldenAndy]

Так, стоп.
Какой из ИК-протоколов вы имеете ввиду ?
Ибо IrDA - тоже протокол, базируется на uart и имеет те же ограничения по скорости....
Если вы предлагаете какой то из ИК-протоколов - то предлагайте конкретный (ибо даже у пультов ДУ их штук 5 наиболее употребительных), кратко напишите требования предлагаемого протокола к тайминагм и допускам. Ибо в половине протоколов требования достаточно жесткие (те же 3-5%). Обратите внимание, в части пультов из-за этого стоят керамические резонаторы на 432кгц...

[ПростоНуб]

[uquote="goldenandy",url="/forum/viewtopic.php?p=3580088#p3580088"]Какой из ИК-протоколов вы имеете ввиду ?
Ибо IrDA[/uquote]
IrDa как раз довольно привередлив. А вот NEC у меня устойчиво принимается от китайского пульта без всякого кварца STM8S тоже без всякого кварца. Там даже синхронизироваться почти не надо. Если
длительность нуля равна длительностьи предшедствующей единицы +-50%, значит 0, если длинее но не более, чем в четыре раза - значит 1.

[GoldenAndy]

Хороший протокол. Сам на нем делал когда то что то....
Но идея с применением светодиодов и приемника ДУ - не самая лучшая. Особенно, с учетом того, что приемники должны быть на определенную частоту....
Проще все же по проводам через оптопары.
А протокол можно любой придумать. навскидку - Старт - 20-30Т, лог. 0 - 1-5Т, лог. 1 - 7-14Т.

[ПростоНуб]

Все же мысль с емкостной развязкой не давала мне покоя настолько, что просимулировал ее. Просьба сильно не пинать, так как компоненты и их номиналы брались от балды из-за нехватки времени на рассчеты.
В симуляторе все выглядит просто замечательно. Емкости легко делают PC817 по скорости передачи на порядок. А вот будет ли в выходные время проверить в железе - не знаю.
Получилось так:

[akl]

Цепи разряда развязывающих конденсаторов нет, поэтому без ошибок длительная передача сомнительна.

[ПростоНуб]

[uquote="akl",url="/forum/viewtopic.php?p=3580564#p3580564"]Цепи разряда развязывающих конденсаторов нет, поэтому без ошибок длительная передача сомнительна.[/uquote]
А почему бы им на выход источника сигнала не разряжаться? Времени для разряда им в 19 раз больше длины импульса.

[GoldenAndy]

Конденсаторы - это хорошо.
Но за скоростью ТС не гонится. Оптроны 817/827/847 на 9600 работают прекрасно.
Особенно в свете того, что ТС нужно будет еще свой протокол рисовать либо уарт перепиливать.
Зато оптика дает полную развязку цепей - управляющий модуль можно питать от чего угодно.
Конденсаторы в данном случае нужно искать высоковольтные, ибо никто не знает, к чему прикоснется своим корпусом транспортное средство, а к чему будут подключены мозги управляющего модуля. Если в розетку 230 вольт, то разница потенциалов может подскочить до 310 вольт. Т.е. конденсаторы нужны на 400 вольт. А с учетом 24 аккумуляторов по 4,3 вольта - еще 103 вольта - то и на все 630 вольт.
Далее, даже если не будет 230 вольт, помним, что у ТС 24 аккумулятора по 4.3 вольта. Это больше сотни вольт. Т.е. даже в этом случае емкости нужны минимум на 160 вольт. Нормальный конденсатор пленочный (а не китайская керамика) по цене не намного меньше оптопары. Плюс еще по высоковольтному диоду надо поставить.
Соответственно, если делать конструкцию модульной, то особого выигрыша в цене мы не получим на емкостной развязке. Но получим головняк из-за гальванической связи.
ИМХО проще на каждом батарейном модуле развести оптопару РС827 - и получить готовый, гарантированно развязанный от внешнего мира модуль. С защитой (если мне не изменяет память) до 5 кВ.
И эти модули можно каскадировать и масштабировать в достаточно больших пределах, в т.ч. и одновременно на разных батареях, гальванически не соединенных друг с другом.

Combatos, У вас 24 модуля с индивидуальными адресами. Что бы не извращаться с индивидуальной прошивкой для каждого модуля, предусмотрите либо просто хранение адреса в ЕЕПРОМе (у вас в тиньке 64 байта ЕЕПРОМ), либо режим программирования адреса с сохранением в ЕЕПРОМ (по отдельной команде от мастера, например, или при замыкании одного из выводов на землю запомнить адрес, по которому мастер обратился.... Это если хватит программной памяти)

[Combatos]

Интерфейс связи по UART представляю себе так: мастер посылает байт с номером ячейки (1...24), слэйвы одновременно принимают посылку. Каждый слэйв имеет свой номер, если номер совпал, слэйв отправляет 2 байта результата АЦП измерения напряжения ячейки. Как-то так.

[GoldenAndy]

Я об этом и говорю - как слейв будет знать, что обращаются к нему ?
Была бы у вас восьмая мега - можно было бы 5 битов порта какого то использовать как задатчик адреса, адрес устанавливать перемычками.
А в вашем случае либо 24 прошивки компилировать, либо держать адрес где то отдельно, например, в еепром.
А как туда записать адрес - я выше написал.
Я бы лично, если бы хватило программной памяти, программировал этот адрес спец.командой от мастера или переводил слейва в режим записи адреса установкой низкого уровня на свободном пине (высокий поддерживать внутренним пуллапом).

[ПростоНуб]

[uquote="goldenandy",url="/forum/viewtopic.php?p=3582228#p3582228"]Я об этом и говорю - как слейв будет знать, что обращаются к нему ?
Была бы у вас восьмая мега - можно было бы 5 битов порта какого то использовать как задатчик адреса, адрес устанавливать перемычками.[/uquote]
Можно сделать как в охранных сигнализациях на одном оставшемся свободным выводе. Все тиньки соединяются в цепочку таким образом, чтобы n-ая тинька могла коммутировать питание (n+1)-ой тиньки своей свободной ногой. При подаче питания тинька проверяет в EEPROM наличие ранее полученного адреса. Если он есть, она проверяет уровень на своем выводе управления последующей тинькой. Если он уже высокий, то это режим сброса адреса и она просто очищает ранее полученный адрес. Если низкий, то переключает вывод на выход и выдает высокий уровень на этот вывод, включающий питание следующей тиньке. Если ранее полученного адреса нет - то выдает информационную посылку и ждет команды присвоения адреса от хоста. Так как в цепочке может быть включена только одна тинька, еще не получившая адрес, то такой импульс выдает только одна тинька и только она одна получит новый адрес.
Сброс адреса, само собой, выполняется уже вручную для одной тиньки. Но это редкая операция.
Так как токи копеечные, а разница в напряжениях земли и питания соседних тинек не превышает 10В, то можно коммутировать питание дешевыми полевиками, типа 2N7000.

[GoldenAndy]

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

Если уже развязали полностью оптронами, то не нужно такое делать. Это потенциальный бабах.

Проще в фузах выключить очистку еепрома при стирании кристалла, иметь одну прошивку и 24 хекса для еепрома.... Это если программная запись в еепром не взлетит.