Отправлено aspect 22 ноября 2006 г. 03:17 В ответ на: Так а нафига стартовый бит? Паузы делаются между пакетами. Если нарушение произошло посередине пакета, ессно, пакет потерян. О восстановлении пакетов должен заботиться протокол связи. отправлено AZ 22 ноября 2006 г. 03:07

• Нет, даже тут в конференции были вопросы и в случае аппаратного UART - если подключиться к сплошному потоку в произвольный момент, то синхронизации не происходит. Протокольный уровень должен работать. — Vladimir Ljaschko   (22.11.2006 11:20 82.209.192.182, пустое)
  • Никто не мешает в коде анализировать не только DataReady, но и вспомогательные статусы - FrameError, DataOverrun/Underrun и т.д., и принудительно реинициализировать логику UART в таких ситуациях - тогда синхронизация непременно наступит. А протокол бессилен до того, как ему скормят миску данных, нет данных - нет и протокола, вот и приплыли — =AVR=   (22.11.2006 12:30 80.92.96.19, пустое)
    • Причем тут код программы ? — Тумблер   (22.11.2006 14:40 194.190.161.241, 497 байт)
      • UART и не должен ничего особенного уметь - он тупой по определению. А программист, если он тоже не тупой по определению, должен уметь пользоваться информацией о состоянии UART так, чтобы выводить UART из редких, но возможных ложных синхронизаций — =AVR=   (22.11.2006 14:49 80.92.96.19, пустое)
        • Для этого нужно уметь 1.расчитать "правильную" фазу сплошного потока бит, и кроме этого 2.перепрограммировать UART в строго определенный момент абсолютного времени. Программа не может этого сделать.Причем обе задачи . — Тумблер   (22.11.2006 17:41 62.33.241.14, 5 байт)
          • и состояние UART-а тут ни-при-чем. непрерывный поток 0x04==непрерывному потоку 0x40. — Тумблер   (22.11.2006 18:20 62.33.241.14, 60 байт)
            • Непрерывных потоков, состоящих из бесконечно повторяющихся одинаковых байт, НЕ БЫВАЕТ, о чем я неоднократно говорил раньше — =AVR=   (22.11.2006 18:28 80.92.96.19, пустое)
              • Это уже попадает под термин "протокол" :-) — Vladimir Ljaschko   (22.11.2006 18:52 82.209.192.79, пустое)
                • Ни на йоту. Как только поток изменится, UART самосинхронизируется безо всякого протокола — =AVR=   (22.11.2006 19:12 80.92.96.19, пустое)
                  • Да фигня. Допустим, идет поток с АЦП в котором не дрожат три старших разряда - 101. По нулю и произошла синхронизация. Все остальные разряды могут меняться как угодно - ничего не произойдет. — Vladimir Ljaschko   (22.11.2006 19:20 82.209.192.79, пустое)
                    • А теперь подумай, что ты сказал — =AVR=   (22.11.2006 21:17 80.92.96.19, пустое)
    • "Непременно"? Суть протокола в том, что (+) — Vladimir Ljaschko   (22.11.2006 13:31 82.209.192.182, 312 байт)
      • Слесарю - слесарево, кесарю - кесарево. Протокол пусть разгребает несуразицу в УЖЕ ПРИНЯТЫХ данных, а железо/firmware - битовые таймауты и прочие несуразицы в тайминге — =AVR=   (22.11.2006 13:35 80.92.96.19, пустое)
• И аппаратный может терять несколько байт. Ты посмотри, как сделан аппаратный UART, и все поймешь. Называется это "самосинхронизация" - принудительный сброс конечного автомата при несоблюдении условий обмена (старт и данные + стоп) — =AVR=   (22.11.2006 03:23 80.92.96.19, пустое)
  • если есть картинка(вхдл.верилог код), посмотрел бы !? (потерял картинку) — Ациль Шифер   (22.11.2006 08:17 62.118.147.92, пустое)
    • Так выше ведь дали ссылку --> — =AVR=   (22.11.2006 12:32 80.92.96.19, пустое, ссылка)
  • Дело в том, что если программная реализация небрежная, т.е. не учитывает всех нюансов, то и сброс автомата будет происходить гораздо реже, и самосинхронизация наступит позже и туже, и протоколу в итоге уже нечего будет разгребать — =AVR=   (22.11.2006 04:02 80.92.96.19, пустое)
    • Ответ: А в чем может быть дело, если на вход UART идет непрерывная последовательность данных (от многих источников) и через некоторое время прием прекращается - UART "затыкается". — Vach   (22.11.2006 11:29 62.244.12.24, 81 байт)
      • а к чему этот UART приделан? поди буфер переполняется. — pau62   (22.11.2006 11:47 88.86.64.164, пустое)
        • Ответ: UART приделан к контроллеру MOPS ф. Kontron. Включение или выключение буфера не изменяет характера затыка. Принимается несколько десятков байт и глохнет, затем переинициализация UART и снова можно принять несколько десятков байт. — Vach   (22.11.2006 14:49 62.244.12.24, 162 байт)
      • сам UART тут точно ни при чем — Тумблер   (22.11.2006 11:39 194.190.161.241, 610 байт)
        • Ответ: Согласен, но 1) почему для продолжения приема помогает переинициализация UART; 2) почему на входе UART остаются данные, а прием пропадает 3) сам контроллер мы не дергаем для продолжения приема. — Vach   (22.11.2006 15:03 62.244.12.24, пустое)
          • Ну например у PIC16f877 UART не помню уже при каких ошибках при приеме вставал раком и не принимал ничего до выключения/включения (програмного) — pau62   (22.11.2006 16:16 88.86.64.164, пустое)
            • То же самое будет и в других семействах МК - и в документации это описано. Нужно обязательно читать (и иногда сбрасывать) ВСЕ флаги, а не только флаг приема, да и регистр данных в иных МК нужно читать несколько раз подряд - до очистки иначе не доступного FIFO — =AVR=   (22.11.2006 16:22 80.92.96.19, пустое)
        • Ерунда. При грамотном и корректном коде никакая "ситуация постоянной ошибки" не возможна, а уж собственно UART тут абсолютно ни при чем, и паузы ему нужны как мертвому припарки — =AVR=   (22.11.2006 12:24 80.92.96.19, пустое)
          • А ты сам - пробовал посмотреть.. — Тумблер   (22.11.2006 14:32 194.190.161.241, 145 байт)
            • Не только "пробовал посмотреть", но и сам делал UARTы и на МК, и на CPLD - никаких пауз не требовалось. А чтобы исключить такие ситуации, как с "U", нужно код писать так, как я упоминал выше — =AVR=   (22.11.2006 14:46 80.92.96.19, пустое)
              • это часто так бывает. — Тумблер   (22.11.2006 17:47 62.33.241.14, 65 байт)
                • Если я - студент, то в этих "лабах" я уже живу, на них же езжу, ими же кормлюсь, на них отдыхаю и т.п. И теорию могу качественно преподать многим профессорам :) — =AVR=   (22.11.2006 18:31 80.92.96.19, пустое)