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

[Yuri222]

из силовой установки вытаскивать можно только оптикой

Я было подумал - принципиально что-то беспроводное...
Заложить туда метр-другой (в зависимости от роста персонала) оптоволокна, если уж персоналу руки зудят сунуть их куда не нужно.
Хотя - 3 киловольта - при надлежащей изоляции - как бы и не так уж и много...

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

Ну или развязывающие микросхемы поставить - опто или магнито. Рассчитанные на пяток киловольт между входом и выходом. А к ним - подключаться проводками.

какие шторки? куда?

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

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

Как раз при засветке, если не применить избыточное кодирование, при одновременных пакетах они 100% забьют друг друга, если будут светить не в свой приемник. И не будет принят ни один. Без шторок.

[threadstarter]

с какой скоростью идет (должен идти) обмен?

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

Мысль была предавать значения температуры например 5град, а раз в 10 передач уже реальные значения. На стороне приемника игнорировать температуры ниже 10град. Скорость обмена может и возрастет.

2. Atxmega32A4U - не имеет порта B4.

Вот это спасибо - что то смотрел в книгу видел фигу - пока даташит читал. Значит PORTD 1 пусть за оптику отвечает.

[threadstarter]

Я было подумал - принципиально что-то беспроводное...

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

Опыта и знаний на эту тему ноль. Если не сложно - накидайте вкратце что посмотреть(приемопередатчики и протоколы) - чтобы не с ноля сейчас изучать всё это.

Как раз при засветке, если не применить избыточное кодирование, при одновременных пакетах они 100% забьют друг друга, если будут светить не в свой приемник. И не будет принят ни один. Без шторок.

может не много не понимаю Вас - но каждый канал изолирован - штекер в передатчик, штекер в приемник. Светить кому то в другое место не получиться физически.

[Yuri222]

Светить кому то в другое место не получиться физически

Ясно, это я Вас не понял, даташит а Вашу комплектуху не смотрел, думал - в открытом пространстве светом передаете, идет засветка друг друга.

[Yuri222]

на базе беспроводки

BLE смотрите при таких потоках. Питание - может, литиевой таблетки хватит на несколько лет.

[makakus]

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

идеал в пару секунд опрашивать.

Так это задачка для лабораторной работы на 3 курсе.
Делайте, как я сказал во втором варианте.

физически отгородить несколько групп потоков световых пучков, то при асинхронной передаче данных в общем пространстве

В оптоволокно пустить что-то быстрое, на мегагерцах

Иногда лучше молча посмотреть даташит, прежде чем торопиться. Там про 5 МБод.

[Yuri222]

threadstarter, обновил свой пост вверху страницы (№11 который)

[eddy]

Вот уже и выяснилось, что ничего там страшного нет. Можно сделать нормальную полудуплексную (или даже полнодуплексную, хотя это в данном случае излишество) связь по RS-485, а для развязки воткнуть преобразователи RS-485 в оптику (в принципе, их и самому можно сделать).
Еще непонятно, зачем формировать фронты ногодрыгом: хоть аврки и говно, но в них тоже есть UART и таймеры. А в некоторых даже DMA есть… С помехозащищенностью на оптоволокне получается намного лучше, чем если использовать радиоканал, так что, если вдруг какой косяк и проскочит, можно тупо выбросить этот пакет…

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

В точку! И ногодрыг сюда же!!!
P.S. Судя по страшному коду, сдается мне, что ТС либо студент, которому какой-нибудь старый мастер поручил сделать это на старых, как говно мамонта, микроконтроллерах, либо же тот самый старый мастер...

[eddy]

По датчику на блок, 12 штук в итоге

При длине провода не больше метра-полутора, на одну шину 1-wire спокойно можно 20 DS18 навешать (проверял с 24 штуками, все работало). В этом случае не нужен будет арбитраж коммуникационной шины - получится всего один приемник и один передатчик...
Понятно, что с помехами в силовой установке трындец, но если 4 датчика на шине более-менее уживаются, то почему бы к ним еще 8 не присоседить?

И да, я бы эти показометры (DS18 ) заменил на нормальные терморезисторы. Во-первых, выше будет точность, во-вторых, значительно выше рабочий температурный диапазон (при 150 градусах ваш DS18 скорей всего сдохнет, а терморезистору ничего не будет).

[sat_art]

Я бы на передатчике прицепил любой TX uarta и передавал по последовательному порту.
А на приемнике организовать софтварный uart.
С передатчиком в таком варианте вопросов, как бы, вообще нет.
С приемником возникает вопрос скорости и согласования.
Возьмем скорость например 9600.
Настраиваем таймер на частоту 9600*6 (к примеру)=57600.
В прерывании этого таймера

if(++sync==7) sync=1;
if(recv1)
{
if(sync==recv1) recv1_recv_bit();
}
..
..
if(recv12)
{
if(sync==recv12) recv12_recv_bit();
} 

где sync переменная unsigned char
recv1_recv_bit.. recv12_recv_bit двенадцать функций приема бита для каждого из двенадцати каналов
recv1..recv12 двенадцать переменных которые равны нулю, но при приеме 0 (стартового бита) будут равны от 1 до 6 до конца приема байта.
На каждую ножку настроенную на прием нужно организовать прерывание по спаду.
В этом прерывании для канала 1

if(!recv1)
{
recv1=sync+3;
if(recv1›6)recv1-=6;
} 

recv1 обнуляется после приема 8-го бита.
Как то так.
Как организовать софт уарт расписывать не буду.
Почему именно 6 - надо при приеме попадать в середину принимаемого бита, поэтому при приходе стартового бита sync+3 будет в середине бита и recv_recv_bit будет вызываться примерно в середине. Ну и не забыть пропустить первый бит (стартовый) в recv1_recv_bit .