Односторонний сбор данных с 12 МК

[Yuri222]

на одну шину 1-wire

Как вариант - если уж без гальваноразвязки никак не обойтись - добавить один контроллер, чтобы на "горячей"стороне собирал данные с остальных платок и по одному гальваноразвязанному каналу передавал на сторону оператора. Каким угодно интерфейсом...

[sat_art]

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

С такими мощностями и напряжениями беспроводка шуметь будет шо ппц. Нужна будет большая избыточность без обратной связи.
Если у Вас оптика влазит в бюджет и уже в процессе, по моему, нормальный вариант.

[vladisslav1]

Программный UART или манчестер (на таймере без прерываний), 300 baud даст примерно 3 опроса в секунду для пакета 10 байт (4 ds18b20+байт состояния входов+crc) и еще останется куча времени для того чтобы разложить полученные данные в выходном буфере, пересчитать crc и добавить буфер в очередь передачи через аппаратный UART (DMA+прерывания).

[ForcePoint]

Код с передающего МК:

Это чего, разные каналы кодируются разной длиной импульсных пакетов? А данные в каналах как кодируются?
И, как отметили, предыдущие ораторы - что-бы не нацепить это на стандарный интерфейс вместо ногодрыга?

Температурный в принципе не так часто - там секунд 10-20 есть запас.
А контроль того что с 4 ног идут импульсы (не важно причем сколько) желательно по всем 12 датчикам получать в районе 2 сек.

Только уж хотел прицепиться к принципиальной инерционности температуры и её измерений... Ну ладно, идём дальше. Если не хотите стандартный интерфейс, то сигнал о наличии импульсов можно вообще передавать постоянкой (если ФБР'ки такое могут). Если давать постоянную засветку в канал, то можно контролировать и наличие импульсов и наличие самого канала.

За delayms надо сжигать на медленном огне (с)

+100500. В передатчике ещё может прокатить, хоть и говнокод. А в приемнике, очевидно, - никак не может.

добавить один контроллер, чтобы на "горячей"стороне собирал данные с остальных платок

Наверное - нет. Вероятно - нужна развязка и между высоковольтными фазами.

[makakus]

Сложилось в голове, пока обедал.
Там.
передаём с ШИМ. Например 0xE2: _______----__----__----__--____--____--____----__--________
На небольшой скорости.
Конечно, хочется юзать готовый UART но там разбираться с временем опроса следующего бита - геморрой, их 12 каналов и сдвиг по времени любой. Тут всё по порядку, не торопясь, опросил - передал.

Тут.
Настраиваем порты на прерывание по изменению уровня. Таймер какой запускаем пусть считает постоянно.

В прерывании:
Изменилось так: _-- записываем таймер в память для этой ноги.
Изменилось так: --__ вычитаем записанный таймер из текущего. Получилось две чёрточки: бит=0, четыре - это 1. Задвинули бит в текущий байт буфера приёма для этого канала. Eсли он восьмой, то нарастили адрес буфера, если он равен значению "конец_пакета" (байт-стаффинг маст юз), то сбросили адрес буфера на начало, поставили флаг "пакет в канале NN принят".
Время этого всего умножаем на 20 получаем длину бита, чтобы всё успевало для всех каналов.

В фоне.
Анализируем флаги, вычитываем из буфера, обрабатываем чотам надо.

Тиньки хватит.

[eddy]

Я бы на передатчике прицепил любой TX uarta и передавал по последовательному порту.
А на приемнике организовать софтварный uart.

Да не нужно так заморачиваться! Тупо Tx'ом дергаем светодиод, а с фотодиода напрямую на Rx заводим. Чтобы поменьше мучить светодиод, можно инвертировать UART...

[sat_art]

а с фотодиода напрямую на Rx заводим.

Их 12 шт. Де RXов набраться?

[makakus]

Да не нужно так заморачиваться! Тупо Tx'ом дергаем светодиод, а с фотодиода напрямую на Rx заводим.

Вот и распиши алгоритм для 12-ти софтварных юартов работающих одновременно, с любым сдвигом битовых интервалов.

[sat_art]

threadstarter, еще одна мысль.
У atxmega128A3 шесть uart-ов. Т.е. можно по два ус-ва запарралелить на один RX uart-а. Но надо передавать пакетом и контролировать целостность пакета (контрольная сумма), в пакет номер ус-ва. Одно из ус-в передает (к примеру) с интервалом 200мс а второе 300мс (можно посчитать более приемлемый вариант). За секунду, по любому по одному верному пакету будет от каждого ус-ва.

[mike-y-k]

А для упрощения синхронизации на отдельном канале сделать CLK и использовать его для синхронизации. На случай помех для синхронизации счета использовать пропуски в CLK на несколько тактов для сброса счётчика.
Этот же CLK использовать для тактирования или квитирования обмена.