Отправлено CJ Mahov 04 июня 2004 г. 23:21

Алгоритм такой: передаю байт контроллеру, он передает мне этот же байт обратно. Вот такой простой цикл. В качестве буфера - MAX202EEPE.
Проблема следующая: например, передаю я #80h, а получаю - #C0h!
Кроме того, контроллер мне иногда присылает 2 байта вместо одного!!!(что, вообще-то, программой исключено). Причем, второй байт принимает одно из 3-х значений: #FCh, #8Fh, #E3h (при любых значения байта, переданного контроллеру). Неизвестно лишь время появления этого сбоя - появляется случайным образом.
Вот программа:
org 00
ljmp begin

pcon equ 87h

org 100
begin:
mov p1,#11111111b
mov p3,#11111111b

mov ie,#00000000b
mov tmod,#00100000b
mov th1,#11111111b
mov tl1,#11111111b
orl pcon,#10000000b
mov scon,#01010000b
setb tr1
nop
start:
jnb ri,start
mov a,sbuf
clr ri

mov sbuf,a
loop_ti:
jnb ti,loop_ti
clr ti
jmp start
end

Откуда берется второй байт и почему контроллер возвращает значения, не соответствующие посланным ему?

Если предположить, что некая помеха инициирует ложный прием байта, то можно объяснить, почему приходит 2-й байт. Но тогда он приходил бы в любое время, независимо от "полезных" пересылок. Но этого не происходит. Второй (ложный) байт может появиться только сразу же после первого ("полезного") и ни в какое друго время.

Когда контроллер работает по более серьезной программе, с использованием таимера 0 (в режиме - два 8-ми разрядных счетчика, которые подвешены на прерывания), можно сделать вывод, что в этих сбоях виноват контроллер. Один из счетчиков формирует ШИМ. Скважность этой ШИМ поступает с компа, вручную - один байт. Этот байт пишется в РОН и, затем, в задающий регистр таймера. Все бы хорошо, но вот во время этих сбоев (когда вместо одного ответного байта приходят два), ШИМ резко меняет скважность на наименьшую (как-будто записали FF в задающий регистр таймера). Очередная посылка байта-параметра ШИМ нормализует сигнал,не будет следующего сбоя и т.д.

И для более полной картины: кварц 22.1184 мГц, com-порт опрашивается программой - Advanced Serial Port Monitor, скорость передачи 115200 бод, провод от мыши (немного перепаян), силовые линии рядом не проходят.

Заранее благодарен всем ответившим!

• Была такая бяка. Попробуйте в SCON грузить не 50h, а 60h. Это позволит в режиме UART №1 контролировать STOP-бит, тогда RI дернется только, если появится корректный stop-бит. — one_man_show   (05.06.2004 09:46, пустое)
  • Правда это только лишь ужесточит критерии приема, но позволит выловить ошибку расхождения скоростей. — one_man_show   (05.06.2004 09:49, пустое)
    • Для Вашего примера лучше 70h, чтобы REN был разрешен. Я использую 60h, так как REN разрешаю позже после инициализации. — one_man_show   (05.06.2004 09:57, пустое)
• Первое, с чего бы начал - это определить (правильно ) скорость передачи. Любым осцилом. — Андрей Сорокин   (05.06.2004 06:50, пустое)
• 1) проверить на меньшей скорости типа 9600 2) попробовать другой терминал 3) проверить установки хендшейка — Zman   (05.06.2004 01:14, пустое)
• Ответ: Проверьте как работает задающий генератор — A_S_N   (05.06.2004 00:51, 264 байт)
• Возьми вместо "Advanced..." простую ДОС-терминалку — AVR   (05.06.2004 00:18, 122 байт)
• Не хочу никого обидеть, но на микросхеме точно написано -24__, а не -12__? — Пауль Зиберт   (05.06.2004 00:07, пустое)
• У вас при тестировании работает только этот фрагмент или вся программа? Может у вас проблемы с роспределением памяти или со стеком. — Sinelogic   (05.06.2004 00:01, пустое)
  • Отдельно включал этот фрагмент, затем совсем другой фрагмент, а результат один и тот же — CJ Mahov   (05.06.2004 07:46, пустое)