Software UART, проблемы с полноценной реализацией Опции

[Kuzmi4]

Здравствуйте.
Есть у меня макетка с 32-й мегой - решил прикрутить туда 2-й UART, зачем - долго рассказывать..
В опсчем пересмотрел я гору исходников - и атмеловских AVR304,AVR305 - и так, что люди писали - в принципе не сильно от атмеловских отличается - проникся я значит главной мыслёй - и решил написать с нуля своё. Ну и естественно "...вдруг откуда не возьмись..." начали возникать проблемы - и что не странно именно с приёмом - потому как с передачей там всё чётко и ясно - сначала сделал приём на INT2 - по спадающему фронту и провёл такой тест - когда МК ловит 5 байт - отсылает их обратно. В опсчем отсылал я 3 байта - например 0хАА,0хАВ,0хАС - ручками на кнопочки макросов нажимал в которые были забиты байты - тобто последовательно - и после отправки 3-х сразу получал ответ - в ответе было как и положено 5 байт, токо выглядели они как то хитро 0хАА,0xFF,0хАВ,0xFF,0хАС - проверил - действительно за приёмом байта идёт сразу есчё 1-но прерывание - в принципе просимулил процесс в студии - ничего такого не заметил. Как добрался до осцилографа - тыканулся посмотреть - увидел что за байтом практически всегда идёт эдакий шум - при чём бывает очень сильный провал - ну где то 0.7 -1 вольт от 5. В студии я получал похожую ситуацию когда ручками проваливал значение на лапке.. Значит поменял я INT2 на INT0 - как в примерах даётся - и сделал прерывание по низкому уровню. Пропала эта белиберда с 0xFF - то есть отсылаю 5 байт - получаю 5 байт. Но тут возникли опять траблы - тобто они и были когда UART был на INT2 - нельзя было отправить в терминале сразу пачку - то есть
отправляю сразу 1 байт '1' - ok
отправляю сразу 2 байта '12' - ok
отправляю сразу 3 байта '123' - err
отправляю сразу 4 байта '1234' - err

Просмотрел код - ну вроде всё верно - не должно такого быть - но тогда почему не работает ??
В опсчем код не сильно маленький - прикрутил аттачем.
Там загорается красный лед у меня на макетке когда ошибка. Зелёный лед не загорался (там в коде описано: загорается красный - когда ошибка фрейма после 1-го полученного байта, зелёный - после 2,3 и так далее.. ).
Буду признателен за любые конструктивные предложения.
Спасибо.

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

 soft_uart.txt ( 6.73 килобайт ) Кол-во скачиваний: 309
 defs.txt ( 1.61 килобайт ) Кол-во скачиваний: 88

 

[Kuzmi4]

2 =GM= - на счёт 1-го - спасибо - действительно, как то просчёлкал я....стыдно....
На счёт 2-го - ну на счёт настройки таймера - 192 от 195 - не сильно отличается - комп должен кушать- что он в принципе и делает, а на счёт 288/254 - я то понимаю что это выжидание в полтора байта, чтоб после старта начать проверять в середине значения - "0" или "1". Я в принципе проверяю не в середине - ближе к краю - знаю чем чревато, но скушало ж....
На счёт 3-го - действительно TCNT0 сбрасывается в прерывании по сравнению, однако код не маленький и у меня таймер успевает натикать 3 раза - вот я его с брасываю - понимаю что не очень корректно - каюсь...
На счёт 5-го - та мне и нужно было проверить 1 раз..

А вот на счёт 4-го я с вами не согласен - читал как то документацию на SIGNAL и INTERRUPT в WinAVR`е , да и где то на форуме даже дискуссия была по этому поводу - в обсчем суть в том что в SIGNAL нету кли а в INTERRUPT - есть. Хардварно ж флажок I не сбрасывается при вызове любого прерывания.... Поправть или ткните носом если не прав.

[=GM=]

На счёт 2-го - ну на счёт настройки таймера - 192 от 195 - не сильно отличается - комп должен кушать- что он в принципе и делает, а на счёт 288/254 - я то понимаю что это выжидание в полтора байта, чтоб после старта начать проверять в середине значения - "0" или "1". Я в принципе проверяю не в середине - ближе к краю - знаю чем чревато, но скушало ж...

Неправильный подход. Для асинхронного протокола и так всего 5% на разницу скоростей, а вы своими руками её уменьшаете, спрашивается, зачем? Да, на столе и в тепличных условиях иногда будет работать, а в реале не будет. Кроме того, надо менять подход, вы не сможете записать 288 в 8-битный таймер, там максимум 255. Проще всего сделать так. В прерывании инт0 поставить константу=144, т.е. на длительность половины бита, и счетчик бит установить на 9 (фиктивный счет старт-бита).

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

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

На счёт 5-го - та мне и нужно было проверить 1 раз..

Ну вы ж принимаете несколько байт, значит, потенциально мс может быть 1, 2, 3 и т.д. А проверяете почему-то на 1. А если мс=2 - это не ошибка?

А вот на счёт 4-го я с вами не согласен - читал как то документацию на SIGNAL и INTERRUPT в WinAVR`е , да и где то на форуме даже дискуссия была по этому поводу - в обсчем суть в том что в SIGNAL нету кли а в INTERRUPT - есть. Хардварно ж флажок I не сбрасывается при вызове любого прерывания.... Поправьте или ткните носом, если не прав

Неправы, вот цитата из doc2466o, page 14
When an interrupt occurs, the Global Interrupt Enable I-bit is cleared and all interrupts
are disabled. The user software can write logic one to the I-bit to enable nested interrupts.
All enabled interrupts can then interrupt the current interrupt routine. The I-bit is
automatically set when a Return from Interrupt instruction – RETI – is executed.