В общем-то соглашусь с предыдущим автором. С учётом цен на МК особо нет смысла усложнять и удлинять процедуру разработки/отладки.

Есть единственное отклонение из этого правила - массовость. В смысле как минимум сотни тысяч штук. Иными словами если удорожание разработки приведёт к удешевлению конечного изделия и разница в стоимости * на объём выпуска даст существенный экономический выигрыш (при достаточной надёжности работы изделия) - то тогда - оправдано.

На мой вгляд если рассматривать только обработку USART исключая другие задачи, то эта задача выполнимая, но повозится придётся. Но существует ещё кварц 11059920 и 14745600 (18432000 уже за пределами). Скажем на кварце 14745600 исходя из формулы F/115200/2 = 64 такта на выборку/128 на бит - вполне реально обработать 8 каналов непрерывно передающих информацию.

Ну, за 64 такта можно и 24 канала на передачу залудить, а как на приём?

Я имел ввиду приём/передачу. Хотя конечно 2 выборки на бит и маловато. 8 каналов, естественно исходя из порт на вывод и порт на ввод. Я думаю вы понимаете о чём я.

Конечно при таком подходе рост затрат от числа каналов будет незначительным, но всётаки будет, в связи с тем, что придётся распихивать данные по каналам (буферам).

На устойчивый прием надо хотя бы 3 выборки на бит, еще лучше 5. Если рассматривать 3 выборки и кварц 16Mhz - получим 46 тактов на выборку. Теоретически подъемно, и погрешность будет меньше чем те же 3 выборки с кварцем 14.7456Mhz.

Про то, что на "C" можно реализовать - можно забыть сразу, на "C" прием/передачу 115200 поднять нельзя..

Про 3 выборки - согласен. Про "С" - скажем так - хлопотно. Собственно то же самое можно сказать и про ASM. Всётаки приходится признать, что это изврат.

Это будет уже не C ;>

Вернусь опять к поднятому вопросу по поводу SOFT UARTA.

Ситуация следующая, в основном всё заработало, линию ТХ сделал первую, для начало пришлось как посоветовали на АСМ написать Program Modul, и подключить к основному проекту на С. Скорость вывода решил оставить 57600. Все заработало нормально.

До настоящего времени всё устраивало но потребовалась линия SOFT RX. Восновном решил изначально пойти по тамуже пути, но наткнулся на одну проблему.

При приёме байта информации в HARD реализции UARTA, у меня вызывается прерывание, в котором, (хоть и не желательно так делать) выполняются некоторые действия над принятым байтом, собственно перевожу их ASCII в HEX по таблице. Ничего серьезного НО, SOFT UARTA в той реализации которую я сделал не оставляет совсем свободного времени для работы программы перевода между входящими байта.

Хотелось бы для этих целей задействовать часть свободной аппаратуры контроллера, прерывание таймера или внешние прерывания, чтоб дать поработать контроллеру.

Возможно уже кто-то сталкивался с подомными ситуациями ?

Честно говоря - не совсем понял проблемы. Более точно её опишите.

Если вы вызываете софтовое прерывание одно на 8 прерываний приёма (я так понял) и оно вам мешает, то разрешите в нём прерывание. Соответственно оно размажется на 2-3 прерывания от бита и всё. Только за переменными следите.

Принимаем только с одного устройства.

Получается так, чтоб принять пакет данных, около 150байт, между приёмами байт входящие байты обрабатываются, это для аппаратного юарта. А софтовый не позволяет так сделать так как после приёма одного байта мне сразу надо прыгать в процедуру приёма следующего байта, чтоб его не пропустить.

Хотелось както уйти от неприрывного опроса ноги а перекинуть это дело на таймер или прерывание, или на оба этих средства сразу.

Посмотрите как это реализуется на таймереА в применении MSP430.
http://focus.ti.com/mcu/docs/mcusupporttec...ctName=slaa078a
Пару лет назад делал накопитель с IrDA и UART на таймереА MSP430. На скорости 57600 работало при тактовой 7372,8 кГц.

Так тут и обсуждалось таймером!!! Что значит непрерывный???

Обычно делается так.
1) Таймер инициализируется на частоту полинга. Обычно данная частота в 3 раза превышает максим. частоту передачи.
2) Сущ. 2 варианта начала приёма. 1 - по прерыванию фронта (старт бит) запускается таймер, 2 - непрерывный поллинг старт бит определяется по первому нулевому биту.
3) бит мажоритарным методом, либо другим на ваше усмотрение.
4) формируется байт по всем условиям - ST+X...+P.
5) По формированию байта - таже процедура, что и при приёме байта по аппаратному USART. Разницы быть не должно, это позволяет обрабатывать единым образом.

Я бы сделал без формирования прер по фронту с 3 выборками на бит, либо с формированием + 1 выборка на бит. Драйвер закончил стандартным кольцевым буфером.

Я реализовывал на 7372800 115200. Работало очень устойчиво. Правда в этот момент все остальные прерывания были запрещены.

Можете кидаться тапками, но контроллер ИМХО мог бы заниматься чем-нибудь более полезным...

Берется какая-нибудь ПЛИС с минимумом внешней обвязки и встроенной флеш-памятью. Клепается на ней хоть 30 УАРТов с буферизацией. Связь с контроллером - желательно по параллельной 8бит шине.
Тут и дуплексный throughput порядка 8 МБит@20 MHz будет обеспечен легко, и скалабельность достигается дикая...

Есть вариант еще проще! AT94K10AL-25AJC
Давно мечтал заюзать такую штюкку... AVR+FPGA в одном флаконе! Ценник ок. 300 рублей. Ноль обвязки. На 10к вентилей можно затолкать столько УАРТов, что и не снилось. А AVR ядро доделает все остальное.

Ход мыслей понятен. Вижу реализацию в таком порядке:

1. Ожидаю внешнее прерывание по спаду.
2. Как только происходит EXTint, захожу в прерывание и запускаю таймер TIMERint на длину (бит/2). Отключаю EXTint.
3. По прерыванию TIMERint обновляю время срабатывания на (бит) и считываю подряд 8 байт.
4. Как только считано 8 байт, обновляю время срабатывания TIMERint на (бит + (бит/2)). Физически игнорирую стоб бит , чтоб дать возможность контроллеру обработать принятый байт.
5. По прерыванию TIMERint очищаю флаги. Отключаю TIMERint. Включаю EXTint. Дальше пункт 1.

8 бит



Нет, все еще на (бит), по девятому прерыванию от таймера проверяете, получили ли 1, если да - значит обрабатываете байт (если видите 0 - значит, ошибка фрейма). В любом случае запрещаете прерывания от таймера и разрешаете EXTInt.

А в остальном - совершенно правильно.

PS Перед разрешением EXTInt не забудьте его сбросить флаг.

Да, там биты, это я поспешил .

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