Проблема с софтовым UART на Mega8, Проблема с софтовым UART на Mega8 Опции

[Ruslan Konovalov]

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

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

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

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

Прикрепленные файлы

 soft_uart.zip ( 2.35 килобайт ) Кол-во скачиваний: 42

 

[bgc]

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

[Ruslan Konovalov]

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

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



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

Прикрепленные файлы

 suart_1_.zip ( 2.13 килобайт ) Кол-во скачиваний: 55

 

[defunct]

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

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

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

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

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

[=GM=]

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

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

[defunct]

5-то зачем?

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

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

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

[SasaVitebsk]

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

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

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

[defunct]

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

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

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

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

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

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

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

Код

[----бит-i----][----бит-i+1--]....
[1][2][3][4][5][1][2][3][4][5]....
-------^-----------------^----....

_|----------------|___________ сигнал
  
--------------------------------------->t

[AHTOXA]

Связаны если выборками отлавливать момент смены сигнала.

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

[defunct]

При таком подходе точность даже больше, чем при пяти выборках на бит.

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

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

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

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

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

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

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

[AHTOXA]

Теоретически - больше.
А на практике - определяется "скоростью реакции обработчика и точностью установки/переустановки таймера".

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

OCR = ICR + 1_5_BIT_TICKS;

а потом

OCR += 1_BIT_TICKS;

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

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

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

[defunct]

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

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

Погрешность установки и переустановки там отсутствует, ибо делается сначала
OCR = ICR + 1_5_BIT_TICKS;

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

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

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

[AHTOXA]

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

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

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

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

Насчет ICR, это конечно здорово если он есть, а там где нет?

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

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

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

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

[defunct]

Там просто не получится достичь таких скоростей.

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

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

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

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

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

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

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

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

[AHTOXA]

Почему же не получится. Без всяких ICR - пускаем 8-ми битный таймер на 5-ти кратной частоте UART'a...

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

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

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

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

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

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

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

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