| |
|
  |
 ADuC841 UART, Full Duplex Software |
|
|
|
|
 Jan 25 2008, 20:42
|
Местный
Группа: Свой
Сообщений: 335
Регистрация: 17-06-04
Из: Москва
Пользователь №: 35
|
Свой вариант работает, но присутствует эхо, чисто цифровое.
Хотелось бы посмотреть, как другие реализуют.
Есть у кого-нибудь ссылки на примеры, желательно на asm? Не могу найти.
Возможно, кто-то сталкивался с такой проблемой.
--------------------
Всегда не хватает времени, чтобы выполнить работу как надо, но на то, чтобы ее переделать, время находится. (Закон Мескимена.)
|
|
|
|
|
|
|
|
Jan 26 2008, 18:45
|
Местный
Группа: Свой
Сообщений: 210
Регистрация: 15-01-08
Из: Новосибирск
Пользователь №: 34 105
|
Цитата(Panych @ Jan 26 2008, 02:42)  Свой вариант работает, но присутствует эхо, чисто цифровое. А что за "эхо цифровое"? Т.е. он принимает то, что передает или как? А с кем идет обмен? Может это viz-a-vi попугайничает?
--------------------
Я здесь и сейчас...
|
|
|
|
|
|
|
|
Jan 27 2008, 13:20
|
Местный
Группа: Свой
Сообщений: 335
Регистрация: 17-06-04
Из: Москва
Пользователь №: 35
|
есть 2 канала речевой связи FULL DUPLEX:
MIC - АЦП (ADuC841) - RS-232 - ЦАП (ADuс841) - SPEAKER
SPEAKER - ЦАП (ADuс841) - RS-232 - АЦП (ADuC841) - MIC.
------------- -------------
ADuс841-1chip ADuс841-1chip
Термин "цифровая" из-за того, что и микр. и спикер для проверки эффекта отключили на одном из терминалов.
Ясная фраза малой громкости, поторяется с затухающей ампл-дой в спикере говорящего в микр-н (на подключ. терминале).
На вызывающем терм. используется циклическая п/прогр (по обнаружению TI-флаг оконч-я передачи байта), за время передачи байта производится ввод инф-ии с АЦП и ввод в
ЦАП. На вызываемом терм. - похожая п/прогр, но цикл организован по прерыв-ю RI(флаг приемника).
Взаимопроникновение сигналов приема/передачи ставит вопросы:
1.Некорректный алгоритм или текст п/программ приема/передачи.
2.Неизвестная особенность UART ADuC841.
Поэтому и понадобилась помощь - скорректировать алгоритм или сам текст *.asm.
Заменить ADuC трудно, т.к. они уже и в док-ии и в железе.
--------------------
Всегда не хватает времени, чтобы выполнить работу как надо, но на то, чтобы ее переделать, время находится. (Закон Мескимена.)
|
|
|
|
|
|
|
|
Jan 27 2008, 15:42
|
Местный
Группа: Свой
Сообщений: 210
Регистрация: 15-01-08
Из: Новосибирск
Пользователь №: 34 105
|
Цитата(Panych @ Jan 27 2008, 19:20) 1.Некорректный алгоритм или текст п/программ приема/передачи.
2.Неизвестная особенность UART ADuC841. С такой особенностью ADuC841 не встречался, хотя приходилось его гонять. Выложите фрагменты ASM приема и передачи по UART. Может чего увидим...
--------------------
Я здесь и сейчас...
|
|
|
|
|
|
|
|
Jan 28 2008, 10:00
|
Местный
Группа: Свой
Сообщений: 311
Регистрация: 11-06-07
Из: Российская империя, 1861г.
Пользователь №: 28 349
|
Цитата(Panych @ Jan 27 2008, 20:20) есть 2 канала речевой связи FULL DUPLEX:
MIC - АЦП (ADuC841) - RS-232 - ЦАП (ADuс841) - SPEAKER
SPEAKER - ЦАП (ADuс841) - RS-232 - АЦП (ADuC841) - MIC. Честно говоря, не догоняю как реализованно это устройство. Вы прочитатйте внимательно, что написали  . Я имею ввиду вторую строчку "SPEAKER - ЦАП (ADuс841) - RS-232 - АЦП (ADuC841) - MIC".???
--------------------
Итак увидел я, что нет ничего лучше, чем наслаждаться человеку делами своими (Еккл) .
|
|
|
|
|
|
|
|
Jan 28 2008, 11:49
|
Местный
Группа: Свой
Сообщений: 335
Регистрация: 17-06-04
Из: Москва
Пользователь №: 35
|
Цитата(SALOME @ Jan 28 2008, 13:00) Честно говоря, не догоняю как реализованно это устройство. Вы прочитатйте внимательно, что написали . Я имею ввиду вторую строчку "SPEAKER - ЦАП (ADuс841) - RS-232 - АЦП (ADuC841) - MIC".??? MIC и SPEAKER находятся в одном узле (телефонная трубка). Неверно ответил, п/программа обмена информацией в каждом устройстве терминала одна и та же и прилагается ниже. Уточнение: тихое эхо присутствует как на вызывающем термин. при отключ. акустике на вызываемом термин. так и при подключенной акустике на обоих концах. Код DEXCHANGE:
setb RI
setb RI
AA:
jnb RI,ADCS
mov A,SBUF ;Receive
clr RI
call Decompression
mov DAC0H,r7 ;DAC HighByte
mov DAC0L,r6 ;DAC LowByte
ADCS:
setb SCONV ;ADC - sample
jnb ADCI,$ ;
clr ADCI ; `
clr SCONV ;
MOV A,ADCDATAH ;ADC HighByte
anl A,#0Fh
MOV r7,A
MOV r6,ADCDATAL ;ADC LowByte
call Compression
jnb TI,$
clr TI
mov SBUF,A ;Transmit
jmp AA ;then again
RET
--------------------
Всегда не хватает времени, чтобы выполнить работу как надо, но на то, чтобы ее переделать, время находится. (Закон Мескимена.)
|
|
|
|
|
|
|
|
Jan 28 2008, 16:20
|
Местный
Группа: Свой
Сообщений: 210
Регистрация: 15-01-08
Из: Новосибирск
Пользователь №: 34 105
|
Цитата(Panych @ Jan 28 2008, 17:49) Код DEXCHANGE:
setb RI
setb RI
AA:
jnb RI,ADCS
mov A,SBUF ;Receive
clr RI
call Decompression
mov DAC0H,r7 ;DAC HighByte
mov DAC0L,r6 ;DAC LowByte
ADCS:
setb SCONV ;ADC - sample
jnb ADCI,$ ;
clr ADCI ; `
clr SCONV ;
MOV A,ADCDATAH;ADC HighByte
anl A,#0Fh
MOV r7,A
MOV r6,ADCDATAL ;ADC LowByte
call Compression
jnb TI,$
clr TI
mov SBUF,A ;Transmit
jmp AA ;then again
RET Здесь возможна ситуация пропуска принимаемого байта, если время выполнения "call Compression" велико. Если не успеваешь считать данные до прихода новых, то они пропадают. У вас передача идет точно без пропусков (jnb TI,$), а прием - возможны пропуски (jnb RI,ADCS), пока программа занимается получением и обработкой данных от АЦП. Не ясно, что делает и возвращает "call Compression". Судя по всему не простое масштабирование 12 разрядного результата АЦП. Именно это и отправляется в буфер обмена UART. Может там эхо и образуется? И еще: убедитесь, что у Вас отключено прерывание.
Сообщение отредактировал Linker - Jan 28 2008, 16:28
--------------------
Я здесь и сейчас...
|
|
|
|
|
|
|
|
Mar 3 2008, 18:38
|
Участник
Группа: Участник
Сообщений: 24
Регистрация: 2-12-07
Пользователь №: 32 880
|
Так что же было? Нам тоже интересно Действительно не успевал?
|
|
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
