Отправлено aspect 22 ноября 2006 г. 02:54

К типу интерфейса отношения не имеет (RS-232, RS-422 и др.)
Так как передача не синхронная, приемник не может знать когда началась передача байта (обрывы связи случайны). Как минимизировать потери? Если приемник начал принимать пакет с середины байта он не может гарантированно отделить неполный байт от остального пакета.
Четность и проверка корректности старт/стоп бита поможет далеко не всегда. Единственное, что приходит в голову - делать паузу между байтами в передатчике. Но скорость теряю.
Что еще посоветуете?
(софтваре ЮАРТ)

• состояние линии в отсутствии обмена= логическая "1". Стартовый бит- логический "0". Стоповый бит- — ++   (22.11.2006 08:18 80.92.98.25, 104 байт)
  • Ответ: — ++   (22.11.2006 08:33 80.92.98.25, пустое, ссылка)
• Так а нафига стартовый бит? Паузы делаются между пакетами. Если нарушение произошло посередине пакета, ессно, пакет потерян. О восстановлении пакетов должен заботиться протокол связи. — AZ   (22.11.2006 03:07 212.58.171.150, пустое)
  • UART и без протокола четко работает — =AVR=   (22.11.2006 03:36 80.92.96.19, 816 байт)
    • Так и я о том же. Реализация UARTа хорошо расписана в даташите. Если канал нормальный, то аппаратные сбои большая редкость. А на этот случай - протокол связи. — AZ   (22.11.2006 03:58 91.145.205.37, пустое)
  • Ответ: Так и я думаю, но почему аппаратный ЮАРТ теряет только один байт? А остальные принимает верно. — aspect   (22.11.2006 03:17 217.70.108.225, пустое)
    • Нет, даже тут в конференции были вопросы и в случае аппаратного 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, пустое)