Слияние 4х потоков USART

[insiderbik]

А чего такое ограничение в камнях-то? Есть камень с 5( 8 ) UART - так и используйте его. Делал я 4 программных UART - но гемор ещё тот.
А у вас ситуация осложняется тем, что данные могут придти ОДНОВРЕМЕННО. Всё, конечно, решаемо. Но зачем самому себе создавать лишние проблемы?

Если со всех устройств идёт запрос-ответ, то есть, одновременно идёт работа только с одним из датчиков, то всё упрощается. Берёте любой мультиплексор и TINY2313.

P.S. Не помню, сколько у вас пакет данных весит. А то тиньки может и не хватить.

из камней в моем распоряжении к сожалению только тиня12, 13, 2313, мега 8, 48, 88, 168, 328. запроса-ответа нет - датчики могут передавать как одновременно, так и перекрывать посылки друг друга. тиньки хватит - 30 слов

[Alex9797]

Если есть возможность корректировать программу на контроллерах-сборщиках инфы с датчиков, то самое лучшее - это сделать им прогу так, чтобы они выдавали свои накопленные данные только по команде центрального контроллера. То есть, центральный процессор опрашивает сборщиков тогда, когда посчитает нужным, и тем самым проблема с приоритетами решается сама собой. А чтобы не заморачиваться с поиском многопортового камня, лучше всего UARTы переделать под RS-485. И тогда можно все сборщики инфы посадить на одну пару проводов, и достаточно будет проца с одним УАРТом. Это и намного дешевле, и правильнее, и помехоустойчивость у RS-485 значительно выше.

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

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

А передавать накопленные данные на центральный проц они будут по команде, по опросу. Для этой передачи лучше всего подошел бы SPI. Его и программно легко реализовать.

[niXto]

Зачем плодить сущности, мега48 прекрасно будет принимать хоть все 4 потока одновременно на 9600

из камней в моем распоряжении к сожалению только тиня12, 13, 2313, мега 8, 48, 88, 168, 328. запроса-ответа нет - датчики могут передавать как одновременно, так и перекрывать посылки друг друга. тиньки хватит - 30 слов

Так в чем проблема? Бери и делай, работы на пару вечеров... Или доставай кошелек

[Godzilla82]

из камней в моем распоряжении к сожалению только тиня12, 13, 2313, мега 8, 48, 88, 168, 328.

А что мешает добавить в этот список мегу с 5 уартами?

запроса-ответа нет - датчики могут передавать как одновременно, так и перекрывать посылки друг друга. тиньки хватит - 30 слов

30 слов - это 60 байт. По хорошему, 60 x 4 x 3. А это входной буфер 720 байт.

Если уж делать всё нормально, то надо 4 выборки за интервал бита. А это 104 мкс. То есть, за 25 мкс надо решить, какой бит пришёл, положить его в нужный подбуфер. Если пришёл стоп-бит, то сформировать байт и положить его в соответствующий буфер (1 из 4).

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

25 мкс - это примерно 260 тактов в вашем распоряжении (при кварце 11,0592 МГц).

Если хорошенько подумать, то можно уложиться.

[oleg110592]

Предложу изящное решение 1 КР580ИК80 + 5шт. КР580ИК51 + ОЗУ + ПЗУ и еще немного обвязки. Все можно найти на мусорке.

[jump]

Godzilla82,
атмел уже все придумал... давно... на асме. аппноты 3хх были ориентированы еще на 90s1200.
выборок обычно делают 3, на 7, 8, 9 такте частоты сом-порта*16, т.е. 9600*16=153600 - с такой частотой должны быть прерывания от таймера.
и почему для м88/168/328 не поднять частоту до 22,1184МГц?
насчет слов - сейчас уже байты становятся 16-битными, а уж слова...
и формировать пакеты не нужно - количество буферов на 1-4 больше, чем сом-портов, т.е. 6-9, на случай внезапного прихода данных от нескольких источников. адреса-указатели буферов, готовых к отправке, ставятся в очередь и сдвигаются по мере исполнения

oleg110592,
4-хпортовая плата сом для ПК стоит 40-50уе - аллес, все решено

[oleg110592]

4-хпортовая плата сом для ПК стоит 40-50уе - аллес, все решено

Действительно - идеальное решение. Правда автору придется освоить работу с потоками, но это уже не важно.

[Boba_spb]

сейчас уже байты становятся 16-битными, а уж

километры морскими милями

[Boba_spb]

Действительно - идеальное решение. Правда автору придется освоить работу с потоками, но это уже не важно.

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

[akegor]

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

В Билдере компонент CommPort имеет свой буфер, счетчик байтов в буфере, события по приему информации. Четыре компонента для четырех Com-ов, каждый обособленный, никаких заморочек с потоками, никаких опросов в цикле - просто обработка событий.