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

Софтовый уарт принимает не корректно.
Передача происходит без проблем, а принимает вместо:
Пример: Должен принять 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.
Проверял в протеусе.
Спасибо за ответы.