Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: ADuC841 UART
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > Все остальные микроконтроллеры > MCS51
Panych
Свой вариант работает, но присутствует эхо, чисто цифровое.
Хотелось бы посмотреть, как другие реализуют.
Есть у кого-нибудь ссылки на примеры, желательно на asm? Не могу найти.
Возможно, кто-то сталкивался с такой проблемой.
Linker
Цитата(Panych @ Jan 26 2008, 02:42) *
Свой вариант работает, но присутствует эхо, чисто цифровое.

А что за "эхо цифровое"? Т.е. он принимает то, что передает или как? А с кем идет обмен? Может это viz-a-vi попугайничает?
Panych
есть 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 трудно, т.к. они уже и в док-ии и в железе.
Linker
Цитата(Panych @ Jan 27 2008, 19:20) *
1.Некорректный алгоритм или текст п/программ приема/передачи.
2.Неизвестная особенность UART ADuC841.

С такой особенностью ADuC841 не встречался, хотя приходилось его гонять. Выложите фрагменты ASM приема и передачи по UART. Может чего увидим...
Tanya
Цитата(Panych @ Jan 27 2008, 16:20) *
Термин "цифровая" из-за того, что и микр. и спикер для проверки эффекта отключили на одном из терминалов.
Ясная фраза малой громкости, поторяется с затухающей ампл-дой в спикере говорящего в микр-н (на подключ. терминале).

Очень трудно себе представить, чтобы ЦИФРОВОЙ сигнал ретранслировался с затухающей громкостью...
rezident
Видимо речь про акустическое эхо (пускай даже и пропущенное через цифровой тракт) идет.
Panych, вам нужно программно каскад эхоподавления реализовать.
SALOME
Цитата(Panych @ Jan 27 2008, 20:20) *
есть 2 канала речевой связи FULL DUPLEX:
MIC - АЦП (ADuC841) - RS-232 - ЦАП (ADuс841) - SPEAKER
SPEAKER - ЦАП (ADuс841) - RS-232 - АЦП (ADuC841) - MIC.

Честно говоря, не догоняю как реализованно это устройство. Вы прочитатйте внимательно, что написали smile.gif. Я имею ввиду вторую строчку "SPEAKER - ЦАП (ADuс841) - RS-232 - АЦП (ADuC841) - MIC".???
Panych
Цитата(SALOME @ Jan 28 2008, 13:00) *
Честно говоря, не догоняю как реализованно это устройство. Вы прочитатйте внимательно, что написали smile.gif. Я имею ввиду вторую строчку "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
Linker
Цитата(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. Может там эхо и образуется? И еще: убедитесь, что у Вас отключено прерывание.
Tanya
Цитата(Panych @ Jan 28 2008, 14:49) *
MIC и SPEAKER находятся в одном узле (телефонная трубка).

Неверно ответил, п/программа обмена информацией в каждом устройстве терминала одна и та же и прилагается ниже.
Уточнение: тихое эхо присутствует как на вызывающем термин. при отключ. акустике на вызываемом термин. так и при подключенной акустике на обоих концах.

А как Вы отключаете? Вход микрофонный закорачиваете? Похоже на банальную наводку. Может по питанию даже...
Panych
Спасибо всем, особенно Linker.
Все заработало.
ncux
Так что же было? Нам тоже интересно smile.gif Действительно не успевал?
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.