Уважаемые форумчане.

Софтовый уарт принимает не корректно.
Передача происходит без проблем, а принимает вместо:
Пример: Должен принять 000102030405
принимает FFFFFFFFFFFFF
В чем проблема, так и не понял(может настройки пррываний ?).
Компилятор IAR. Проверял на Proteus 7.2

Или быть может у кого нибудь есть рабочий софтовый уарт.
Скорость нужна макс. 115200.
Буду признателен любой помощи.

С Уважением,
Руслан.

Скорость великовата для софтового... Проверьте на 2400.
при большой загрузке процессора это предел. При малой наверное потянет 19200. Но точно не проверял.

Пробовал на 115200. Передает нормально а прием нет.
У меня есть другой софтовый уарт так он работает как раз на 19200.
Неужели 19200 предел ? Кстати прием и передача работают по очереди.
Неужели если только принимать, то не получится принять на большей чем 19200 скорости ?



А это оригинальный софтовый уарт.
Потом я его переделал под IAR(предыдущий аттачмент).
Может я где-то напартачил ?

Оказывается оригинал написан Питером Данеггером. Зная его дотошность и пунктуальность, могу сказать, что ошибки 100% нет, просто-напросто си-программа приёма не справляется с такой скоростью.

Если вам нужна такая скорость, то пишите на асме, получите существенный выигрыш. Вам для ориентации: для полудуплекса можно легко написать программу приёма и передачи на скорости 1 000 000 бод, а если постараться, то и на 2 Мбодах (с клоком 20МГц).

Если только на это время отказаться от всего остального и запретить прерывания. Может, лучше внешний УАРТ поставить, и общаться через SPI? намного проще и менее ресурсоёмко.

Ну почему отказаться, приём по прерываниям, основная работа в фоне. Для приёма на таких скоростях лучше, конечно, чтобы других прерываний не было.

С кварцем 14.7456 должно тянуть 57600.

ЗЫ: А почему не используете аппаратный?


5 выборок надо делать. 115200 x 5 = 576kHz (будет всего 16Mhz / 576 = с натягом 32 такта на выборку).

5-то зачем? Ну, для 1Мбода длительность одного бита 16МЦ(тактов), вполне хватит на приём по прерыванию.

Для того чтобы соответствовать стандарту (обеспечить нормальную работу при 2% отклонении частоты приемника и 2% отклонении частоты передатчика (суммарно 4% отклонение) ).


ну ну, хватит ровно на чтение из порта одной выбоки и задвигание в регистр.
Даже на анализ старт/стоп не хватит.
Работать будет так же г...но плохо как и то, что в примере автора ветки.

В стандарте не прописано число выборок. Вообще нет такого понятия. Хотя, аппаратно используется обычно 5. % отклонения частоты также никак не связан с числом выборок.

Очевидно, что чем больше выборок, тем точнее восстановление сигнала (в плане помехозащищённости), но если принять за основу что сигнал идёт без помех, то число выборок не влияет ни на что (при обнаружении старта). А 3 вполне достаточно.

Связаны если выборками отлавливать момент смены сигнала.
И связаны ровно настолько, насколько интервалов разбивается один бит этими выборками.
при пяти выборках получим сл. картину (каждая выборка покрывает 20% интервала одного бита):

[1][2][3][4][5]

Если в [1] словили смену сигнала, и начали читать данные в момент [3], то у нас есть запас 40% отклонения интервала в обе стороны. И если смены сигнала более за кадр не произойдет (напр передается 0xFF или 0x00), то к приему последнего "стоп" бита сигнал может уплыть на 40% в любую сторону без риска искажения данных. Теперь что такое 40%, - это 40% / 10 бит на кадр = 4% отклонение частоты приемника от передатчика.


я не говорил о выборках с последующим усреднением.
Я использую несколько выборок для подсихронизации.

Например если смена сигнала произошла на выборке [1] бита i, см иллюстрацию ниже, то устойчивое состояние бита можно брать с выборки [3], затем для бита i+1 смена сигнала проиcходит на выбоке [2], значит устойчивое состояние бита нужно бать уже не с выборки [3], а с выборки [4].

defunct ну ну, хватит ровно на чтение из порта одной выбоки и задвигание в регистр.

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

defunct Даже на анализ старт/стоп не хватит.

Ну старт бит я ещё понимаю, а стоп-бит зачем анализировать?

defunct Работать будет так же г...но плохо как и то, что в примере автора ветки.

Программа написана Питером Данеггером, я его знаю более 10 лет, и бился с ним время от времени на одном из английских сайтов, нормальный кодер, и программы делает добротные.

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

Теоретически - больше.
А на практике - определяется "скоростью реакции обработчика и точностью установки/переустановки таймера". плюс нет подсинхронизации по каждой смене уровня сигнала, а значит на кадрах 0x55 и подобных (где смены уровня происходят чаще одного раза) точность будет хуже.


Вы оптимист.
4 такта вход в прерывание, 5 тактов выход (сохранение SREG учтено), 3 такта макс джиттер (прерывание в момент выполнения длинной команды)
остается 4-7 тактов на полезную работу, считайте на что их хватит.


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


Что-то не пойму, неправильная работа программы, может быть оправдана квалификацией автора?!
Если автор "нормальный кодер", то программа не может быть нерабочей, это только нам кажется, что она нерабочая и принимает 0xFF FF FF вместо посылаемых данных?

Огромное спасибо всем кто отозвался.
Мне было бы достаточно работать на скорости 115200.
Большая скорость не нужна.
Мне нужно использовать именно 2 уарта.
Аппаратный уарт уже занят.
Может кто нибудь имел дело с софтовым уартом на скорости 57600-115200 ?
Не знаю что я делаю не так.
Пример, который я привел нормально не работает даже на скорости 9600.
Проверял в протеусе.
Спасибо за ответы.

Скорость входа в обработчик - да, влияет. Но это мизер. Погрешность установки и переустановки там отсутствует, ибо делается сначала

OCR = ICR + 1_5_BIT_TICKS;

а потом

OCR += 1_BIT_TICKS;

, то есть, все интервалы отмеряются строго от момента начала старт-бита.



Ну, подсинхронизация - это чересчур. На сколько должны расползтись частоты приёмника и передатчика, чтобы за 8.5 бит выехать за пределы бита?

Не мизер, если имеются другие обработчики прерываний.


Ну не стоит так громко.
Как минимум возможна погрешность в полтакта. На низких скоростях конечно чепуха, а на высоких (115200) это почти 1%.
Насчет ICR, это конечно здорово если он есть, а там где нет?


Не бита, а половины бита (читаем же по-середине). Всего лишь на 2.5% приемник, и настолько же передатчик от заданной.

Ну это конечно. Для больших скоростей придётся отключить



Это уже придирки. Естественно, говоря "отсутствует", я имел в виду - с точностью до такта процессора. И не 1%, а менее 0.5%, ибо полтакта



Там просто не получится достичь таких скоростей. С другой стороны, в MSP-шке ещё лучше, там можно аппаратно захватывать состояние ноги ICP по прерыванию сравнения. То есть, время входа в прерывание не имеет значения (в пределах длины бита ессна).



Всё же битов не 10, а 8.5. Потому запас побольше выйдет

Короче, моё имхо - работать на 115.200 должно (96 МЦ на бит), хоть и с напрягом. А не работает скорее всего из-за протеуса.

Почему же не получится. Без всяких ICR - пускаем 8-ми битный таймер на 5-ти кратной частоте UART'a. делаем 5 выборок, ловим старт, устанавливаем значащую выборку и все, читаем, складываем до тех пор пока нет стопа. Дергаем псевдообработчик принятого байта.
До тех пор пока есть 50 тактов на одну выборку - производительности хватит, т.е. 57600 @14.7456 гарантированно будет работать, причем с использованием всего одного 8-ми битного таймера.
Можно снизить количество выборок до трех, тогда не исключено что потянет и 115200.

Можно обслуживать сразу несколько каналов. Никаких телодвижений с таймером - один раз заправили и забыли.

Тратить серьезный таймер на один UART, гм... ;>


Все же битов 10. Или первый интервал в 1.5 бита вы не считаете?
От того что вы его не считаете, он никуда не делся (его ошибка ничем не скомпенсирована).

Может быть. Не обратил внимания, что тестирование на протеусе сделано ;>

Ладно, шут с ним с Питером, пусть сидит в своём Берлине(:-). Давайте не будем никого слушать и поступим следующим образом.

0) Отказываемся от данеггеровской программы.

1) Подключаете вход RX к INTх, которая срабатывает на 1-0 перепад.

2) В подпрограмме обработки прерывания от INTх пишете настройку таймера на переполнение через ПОЛТОРА периода вашей скорости 115200, т.е. таймер должен сработать по переполнению через 13 мкс, bitcounter=8, запрещаете прерывания от INTх и выходите. Больше ничего.

3) В подпрограмме обработки прерывания от переполнения таймера пишете занесение текущего принятого бита в srxdata, как-то так

srxdata=srxdata<<1;
if(srxpin&0x01) srxdata++;

скручиваете счётчик бит, если счётчик бит скручен, останавливаете таймер и взводите флаг srxdone.
if((bitcounter--)==0) {stoptimer(); srxdone=1}; else настраиваете таймер на переполнение через ОДИН период, т.е. 8.68 мкс и выходите.

4) В фоне опрашиваете флаг srxdone, если он взведен, читаете принятый байт, сбрасываете флаг srxdone и разрешаете прерывания от INTх. Вы снова готовы принимать байты.

Ну, вроде всё, должно помочь горю. Держите нас в курсе.

Я так тоже делаю, только на 4-кратной. Когда надо быстрее, то обхожусь 3-кратной Плюс ещё в том, что работает на всех контроллерах. Но с ICR-то получше всё же.



Ну да, только скорость пропорционально уменьшится.


Ну он там не целиком, всего один модуль захвата/сравнения из кучи



Ошибка копится не на битах, а на интервалах А интервалов - 8.5 (полуторный до середины первого бита + 7 одинарных). Стоп-бит меня не интересует, ибо пока не придёт единица, захвата следующего старт-бита не произойдёт.

В общем, как делаю я (скорость до 19200 - больше не проверял.)
0) прерывание по старт - биту. Засекли 1/2 длит. бита (в таймер)
1) прерыв по таймеру - если имеем "0" на входе RxD_2, продолжаем прием, для чего засекли длит 1 бита в таймер
2) прием информационных бит по прерыванию таймера
3) прием стоп-битов с их верификацией на лету, аналогично приему старт-бита.
4) если посылка правильная, выставляем флаг.

Ну в общем всё то же самое, плюс проверка старт-бита. Для случая отсутствия помех это не обязательно.