Совсем недавно передо мной встала задача сбор последовательной информации (текстовые сообщения), которые приходят на параллельный порт (те используется 6 пинов параллельного порта, на каждый из которых приходят собственные текстовые сообщения разной длинны), собираются в буффере последовательно и отправляются через стандартный порт UART.
C процессом отправки и буфферизации сообщений все вроде ясно, примеров очень много вокруг, а использование порта в качестве приемника последовательной информации практически нет (по крайней мере мне не удалось найти даже близкого примера).
Если будут какие нибудь мысли - пишите.

Ага, мысли есть. Точнее вопросы.
С параллельным портом задачу кто-то поставил, или Вы сами себе поставили?
Кто бы это ни делал, он знал принципы работы параллельного порта?
Речь идет о порте персонального компьютера?
С какой скоростью приходит "последовательная информация" ?

Не совсем понятно. Поясните. Требуется принять 6 асинхронных потоков с помощью LPT-порта? С какой битовой скоростью эти потоки передаются?
Дык неудивительно. Сделать несколько UARTов на входных сигналах LPT (да еще, если под управлением ОС типа Windows) это мазохизм высшей закваски Реализация приема асинхронного потока требует некоторой передискретизации частоты опроса с равномерными отсчетами. А как обеспечить равномерность отсчетов опроса пинов LPT при наличии ОС, я не представляю себе?

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

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

Впрочем, можно сделать и как затребовано. Например, если "сообщения" - азбука Морзе или скорость передачи 1..2 бод и код с самосинхронизацией, что-нибудь типа "Манчестер-2"...

Сообщение отредактировал r_dot - Jan 19 2008, 04:47

Понял проблему, иззиняюсь, задача действительно без самых главных параметров нерешабельна 8))))
Сей прожект выполняется на контроллере Atmega8515 с частотой кварца в 4 мегагерца (порты не уточняю, в принципе возможно использовать любой из четырех). Скорость приема информации 4800 бит в секунду, скорость выдачи 115200

Я так понял: надо собрать информацию с 4-х независимых USART, работающих на скорости 4800 бит/c и выдать все полученное через один USART со скоростью 115200 бит/c. Это правильно?
А почему бы не воспользоваться чем-нибудб готовым для приема информации от 4-х разных источников. Ну там типа IIC, если с одной платы, или CAN, если далеко надо? Опять же RS485 с каким нибудь известным протоколом поверх.

Информации все равно маловато. Еще вопросы.
1. Какое кодирование сериальных каналов, UART? (NRZ + старт/стоп)?
2. Все 6 каналов асинхронны по отношению друг к другу или нет?
3. Данные по всем каналам могут приходить одновременно или только один канал активен в одно время?


Судя по всему с 6-и !

1) Кодирования там нет и схемы на асинхронных приемопередатчиках лепить нет смысла
2) Информация поступает на каждый пин в АSCII (текстовые сообщения NMEA начинаются с $ заканчиваются возвратом каретки)
3) 8N1 (8 бит передаваемых данных, проверки на четность нет, один стоповый бит)
4) Информация приходит асинхронно

В принципе я сам себе накидал алгоритм, как бороться с такой бедой 8))) для 6 входов "UART". не так и сложно получилось, гораздо хитрее получается складирование полученной информации (двумерный массив с текстовыми сообщениями, получаемыми с портов - огроменный кольцевой буфер), и непосредственно выдача из этого кольцевого буфера через стандартный порт UART микроконтроллера, где придется организовать буфер FIFO с адресами ячеек массива, которые были заполнены непосредственно текстовыми сообщениями.

Теперь все понятно: 6 независимых UARTов на прием на 4800,8,N,1 в один UART на 115200,8,N,1 на передачу. На Atmega8515 @ 4 MHz

Боюсь, что складирование полученной информации хотя и не очень простая задача, но ничего принципиально невозможного в ней нет.
Гораздо проблематичней выглядят 6 программных UARTов на прием на 4 MHz. Боюсь, что мега не успеет.
Честных приемников с 16-ю выборками на бит вы сделать точно не сможете.
Упрощенные приемники с отлавливанием старта и выборками в середине битов попробовать сделать можно. Но при этом возникнет главная проблема - несинхронность каналов и наложение времен обработки битов различных каналов
Это нужно по таймеру каждые максимум 50 мкс (4 раза на бит или чаще) опрашивать порт с UARTами и производить разборку комбинаций.

Так что, даже если это и будет как-то дышать, то возможны периодические сбои приема.

Я бы на вашем месте взял бы шесть внешних UARTов или Tiny-ек и слепил вместе с мегой.

В принципе я видел пример кода на один порт UART там действительно отлавливался старт бит (использовалась задержка на полбита), а при приеме стартового бита задержка увеличивалась до целого бита. С начала попробую организовать прием для одного пина, если получится позже попробую для 6 входов, если получаться не будет, тогда придется уже наращивать схему 8)))))))

Дык для одного пина (программного UARTа) проблем нет. Даже два без проблем будут работать
Проблема с 6-ю

Гхмм. Так пойдёт? У каждого приёмника есть несколько состояний. "Ждём старт-бит", "Ждём n тактов до середины старт-бита", "Ждём n тактов до середины информационного бита" и т.д., причём 0=<n < 16. На каждый канал заводится по байту состояния, таймер щёлкает на примерно 4800*16 Гц, в каждом прерывании пробегаются все шесть байт и вызывается один из двух соответствующих обработчиков состояния - если на ножке ноль и если единица. IMHO, по времени вполне можно уложиться (хотя сам не пробовал).

Задача легко решается на ПЛИСе.

Ага, 1/4800*16 Гц = 13 мкс, 52 цикла процессора
Еще эти данные нужно разодрать по строчкам и перенаправить в аппаратный UART


Задача много на чем "легко решается", речь шла о Atmega8515 @ 4 MHz

Мне кажется, что 16 раз на бит - довольно много, если синхронизироваться по началу каждого байта, то в принцпе должно хватить и двух раз, единственное надо будет снизить фактор помех на линиях