16 выборок на бит ,другое дело.
По идее можно вписатся в погрешность,вопрос остается хватит ли нам оперативки?
Если передача действительно идет,как описал автор темы,то мы даже впишемся в 320 байт.
Я думал про непрерывную передачу и однозначно решил что поллинг не проидет,так что извинямс
На асме можно и без прерывания обойтись,если других задач не нужно,
в цикле читать порты,если какой рыпнется,сливать всю посылку в оперативку,а потом пережовывать.
Главное что бы между посылками контроллер успел обработать полученные данные.
После пережовывания опять ждать следующую посылку.
Короче ,думаю,на 16 выборках на бит сделать можно.

GetSmart:
Схемотехника датчика мне неизвестна, да и какая разница, плясать будем от того, что есть.

Алгоритм вырисовывается примерно таков:
по появлению первой посылки c канала1(условно1) в прерывании pin chang запускаются таймера:
таймер 0 -прерывания через 80 мкс, такт опроса всего порта(всех каналов);
таймер 1 -счет с нуля и до заполнения, т.е. 65536 мкс.
По окончании старт-бита по повторному pin chang считываем со счетчиков TCNTL,H значения определяющие длину старт-бита(частоту) данного датчика. В ОЗУ пишем данные длины канала 1.
При появлении старта с других каналов также читаем данные с таймера1 о длине старт-бит.
По прерыванию с таймера0 читаем состояние порта и считаем счетчик кол-ва опросов по таймеру.
Значения накапливаем в ОЗУ. И так до окончания посылки или посылок если идут в одно время.
При самом худшем случае, если посылка 2 поступает к окончанию первой, третья к окончанию второй и т.д., на скорости 2400 заполняем ОЗУ не более 90%.
Обработка после окончания приема. Создаем таблицу времен и проводим анализ в какие промежутки времени уложились биты в каждой из посылок. В каждый бит должно укладываться 5-6 опросов порта, в зависимости от момента начала и частоты. При наличии одинаковых 4-х выборок принимаем решение о значении бита.
Прошу комментарии об ошибках или упрощениях.

Мои коментарии такие ...
Мы упорно идём своим путём!
Ну чтож. Может это даже и к лучшему!!! В конечном итоге никто за Вас прогу писать не будет. (бесплатно). А разведка "боем", - это лучший способ научиться работать самостоятельно.

Я не выражал сомнений по поводу реальности создания 7-ми канального RS232. На мой взгляд на скорости 1200 - 4800 это не сложно. Я выражал сомнение по поводу реальности автоопределения скорости по всем каналам.
Причина проста. Байт данных 0xfe на 4800, это байт данных 0xff на скорости 2400 (То же f8/fe; e6/fd). Между ними нет разницы! Поняв принцип того что я написал, Вы поймёте почему я был песимистом.
В модеме, который я реализовывал существует префикс команды (at/AT), но датчики же не являются интелектуальными. Или датчики интелектуальны?
Если данные могут быть любыми, то скорость по стартбиту не определишь. Это сложнее делается и всё равно не гарантирует от ошибки. Я восстанавливал примерно 97%.

от каждого датчика посылки поступают довольно редко (мин. 0.5 сек.), вот эту паузу и использовать для определения начала посылки. В m88 любую ножку можно использовать как источник внешнего прерывания. Прерывание это начало посылки, далее на время посылки запрещаем прерывание с этого пина, а по завершению приема 10 бит восстанавливаем разрешение прерывания

Согласен с Александром (SashaVitebsk).

Ну и плюс мой коментарий:
Определение длины старт бита это какая-то галиматья.. Почитайте Atmel appnote "AVR304" для того чтобы иметь хоть какое-то представление о природе УАППа.
Раз длину старт бита определить нельзя, то дальше алгоритм читать бесполезно.


Здесь абсолютно верный ход мысли.


Как бы вашу задачу решал я:
1. Завел бы таймер на генерацию прерывания с частотой 4800 * 5 Гц.
2. Разрешил бы PinChange int по N каналам.
3. Завел бы счетчик текущего бита для каждого канала.
4. Завел бы номер цикла чтения бита для каждого канала.
5. Завел бы флаг приема для каждого канала.
6. По прерыванию PinChange считывал бы весь порт.
7. В обработчике прерывания анализировал бы значения каналов для которых не ведется прием.
8. При обнаружении старт-бита устанавливал бы флаг "ведется прием" для этого канала, одновременно внес бы в номер цикла чтения бита - номер текщего цикла +2.
9. В обработчике таймера - первым делом считывал бы значение всех каналов.
10. В обработчике таймера увеличивал бы номер текущего цикла "циклически" (0, 1, 2, 3, 4, 0, 1 ... ).
11. При условии ("установлен флаг приема" AND (номер цикла = текущий цикл)) заносил бы приянтый бит с канала в сдвиговый регистр и увеличивал бы счетчик текущего бита.
12. Если счетчик текущего бита = 9, то сбрасывал бы флаг приема.
13. Заносил бы принятый байт в буфер канала если 9-й бит = 1 (стоп бит распознан) .

14. Проверил бы работу N каналов на одной скорости.
15. При НЕУСПЕШНОМ прохождении теста - правил бы баги, до тех пор пока все каналы не заработают.
16. При успешном прохождении теста внес бы переменную "делитель скорости" для каждого канала.
17. В пункт 11 внес бы коррективу с учетом "делителя скорости".
18. Проверил бы работу N каналов на разных скоростях.

все.

Оказывается я так и не написал важную мыслю. Хотя мне казалось что писал на 1-2 странице. Мысля такая:

Чтобы по старт-биту определять скорость передачи нужно либо его поделить пополам на пол-бита 0 и пол-бита 1. А я бы сделал два стартовых бита 0 и 1. А для совместимости со стандартным УАРТом передавал бы байты с всегда установленным младшим битом, в которых было бы только 7 бит произвольных данных.

и с чем бы это дело было совместимо интересно? ;>
хотя идея практичная.

Но не проще ли просто забить скорости каналов в EEPROM или выставлять джамперами.

Ну как... Передавая по обычному UART байт с всегда установленным младшим битом мы имеем два стартовых бита 0 и 1, 7 бит данных и стоп бит. Это я имел ввиду. Так в самом начале можно определить скорость.

А насчёт джамперов... Я до сих пор не понял постановку задачи. Что это за объяснение:

Непонятно, скорость стабилизирована кварцем? Может принимать только стандартные значения? Или вообще любая +-200% с шагом до 1%. Непонятно!

Я перечитал текст своего вопроса: Формат передачи: старт-бит, 8 бит данных, 1 стоп. Скорость передачи 2400 или 4800 бод.
Фраза с разночтением. Скорость у всех датчиков одинакова или 2400, или 4800. Переключается.

Еще мне минус, в конфе fulcruma я указал на уточнение облегчающее мне жизнь: данные в посылке занимают 7 бит, старший бит нулевой, ВСЕГДА. Поэтому мне очень удобно измерять длительность старт-бита. Скорость дрейфует очень медленно, а разброс, читай скорость, фактически измеряется.

SasaVitebsk внимательно прочитал ваше сообщение:
1) Надо зафиксировать скорости по каналам. Иначе - не верю в успех.
2) Я бы делал на ASMе
3) Я бы делал так, как это делает аппаратный контролер на уровне железа, а именно:
a) Обрабатывал бы прерывание от таймера с частотой, как минимум в три раза выше максимальной частоты передачи. Лучше в пять!
б) в прерывании читал бы ВСЕ каналы.
в) Если 2 из 3 или 4 из 5 засвечено - единица.

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

С предполагаемого m8, принял m88 из-за наличия pin chang. До сих пор не применял. Из-за расположения адресов в пространстве во многих обращениях к портам используется по два такта. Скорость то падает вдвое, чем лучше новый m88 старого m8? Ну это так...

Я думаю здесь "схемотехника датчика неизвестна" можно трактовать как - "датчик покупной". А покупной датчик обязан придерживаться стандартного допуска к отклонению (2%).


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

Вы пример(здесь) хоть скачали и посмотрели уже?

Да, pin chang намного жизнь упростит. Именно он должен обнаруживать поступление первого стартового бита.

С такой постановкой задачи действительно хватит 3-5 выборок на бит.


Думаю это не так. Я почти уверен, что скорость чтения портов у обоих процов одинаковая.

Не знаю схемотехнику датчиков, залиты, есть разъем и параметры выходных сигналов. И все. Все вопросы к заказчику...., моему.

Знаком я с УАПП. Но если присутствует разброс по скорости, как привязаться? И дрейф. Измеряя длительность старт-бита я привязываюсь точно. Так и поступал когда работал с одним или двумя датчиками.
Мне кажется все потеряли условие: разброс скоростей датчиков от номинала ±10%, а не разные скорости. Или не правильно выразился, как написал.

defunct
Я принял примерно тоже, но так подробно не расписывал. Вот только не уверен, что успею обработать прием по ходу, поэтому скидываю в буфер.

10. В обработчике таймера увеличивал бы номер текущего цикла "циклически" (0, 1, 2, 3, 4, 0, 1 ... ).
Это 4800*5 и счетчик. Я правильно понял.

Самое "смешное", после старт-бита идет старший и в инверсном коде. Это наверное роли не играет, протокол дан.

Самое "смешное", что протокол дан Вам, а на обсуждение вы его не представили. И это действительно смешно.

Последнее Ваше уточнение является определяющим. Теперь точно можно сказать, что задача поставленная в первом посте - решаема на AVR как есть, с автоопределением скоростей. Только для отклонений в +-10% придется брать не 5 и тем более не 3 отстчета, а хотя бы 15-25 отсчетов. Опорная частота таймера (4800 * 15) - (4800 * 25) Гц... Столько отсчетов просто необходимо для компенсации 10% отклонения передатчика, которое для 10-ти бит выливается в +-100% отклонение. Соответвенно частота МК у вас должна быть не 8Mhz, а как можно выше - 14.7456 - 20Mhz чтобы справляться с этой задачей.


да правильно, счетчик момента считывания, моментов всего 5 т.к. частота завышена в 5 раз,
только это для допуска 2%, у вас же допуск отклонения 10% соответвенно моментов должно быть больше в 10%/2% раз. И алгоритм приведенный выше придется подкорректировать (номера п. соответвуют вышеприведенному посту):
1. Таймер завести на 4800*15 гц
1.1. Добавить байт-коррекции цикла считывания.
8.1. При обнаружении старт-бита установить флаг "ведется прием" для этого канала,
8.2. одновременно установить номер цикла чтения бита как номер текщего цикла +7.
8.3. Определить количество циклов удержания старт-бита.
8.4. Записать байт-коррекции номера цикла чтения бита для текущего канала как: "15 - (минус) количество циклов удержания старт-бита".

11.1 При условии ("установлен флаг приема" AND (номер цикла = текущий цикл)) занести принятый бит с канала в сдвиговый регистр и увеличить счетчик текущего бита.
11.2. Подправить "номер цикла чтения бита" на величину хранящуюся в байте-коррекции канала.

пп 14-17 - удалить.

остальные пункты без изменений.

10% ???
Это очень подозрительно. Обычно 2..5%, но чтобы 10 ? Ведь 10%*10бит = 100%, а это уже ошибка. Что-то здесь не так. И протокол ещё какой-то странный!?

Это означаетодно из двух. Либо Вы не умеете читать, либо я не умею писать. Давайте выберем второе. Итак в третий раз старик забросил свои сети ...

Разница в алгоритме СУЩЕСТВЕННАЯ. Я исходил из того что датчики независимы. Это значит, что даже если посылка происходит раз в несколько минут, то всё равно наступит момент когда прерывание от одного не закончится, а от второго поступит.
Т.о. может поступить посылка от двух и более датчиков. И если их обрабатывать по прерыванию, то те посылки которые предут "не вовремя" не будут обработаны должным образом.
Моему алгоритму - данное не страшно.

Итак ещё раз.
1) Инициализируем ОДНО прерывание от таймера с частотой 1/16 от максимальной частоты посылки.
2) В НАЧАЛЕ прерывания (до ветвлений) читаем все порты.
3) Если хотите определять старт бит, то пожалуйста определяйте примерно так.
(Данная работа выполняется не с портом, а со считанными данными по каждому порту)
3.1) Если посылки не было, то проверяем 0/1 и если 0, - то помечаем номер такта посылки как нулевой такт (начинаем отсчёт тактов по каждому каналу)
3.2) Если посылка идёт, то смотрим какой такт и какой бит сверяем бит и считаем длину бита если равна 16, то переходим к след биту.
(для более низкой скорости - 32)
3.3) Если прошло 10 бит, то формируем байт и выставляем признак готовности данных по данному каналу. (Или "загоняем" его в кольцевой буффер канала)
3.4) Сбрасываем признак того что идёт посылка.

При таком подходе Вы можете принимать данные от N каналов одновременно.

Данный подход не исключает возможность автоопределения частоты. Просто размеры битов Вы будете видеть в тактах прерывания.

Откуда у Вас данный расчёт по занятому ОЗУ - можно только гадать. Я со своим опытом работы предсказать не берусь.
Но я бы весь сигнал загонял в озу и работал бы в голове. Думаю что озу m8 Вам за глаза. Если не делать сжатие "на лету".