zltigo 1 8 марта, 2010 Опубликовано 8 марта, 2010 · Жалоба То есть все сделано правильно Про правильно ничего не понял - автор периодически в произвольный момент вычитывает байт УЖЕ ИЗ софтового буфера, неведая сколько байт-килобайт в этом буфере лежат и при этом считывает флаг признака ошибки, который мог быть взведен (в том числе и многократно) при заполнении этого буфера и сбрасывает его. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Гость @Ark 8 марта, 2010 Опубликовано 8 марта, 2010 · Жалоба Про правильно ничего не понял... Правильно реализован прием на аппаратном уровне. После ошибки приема, все последующие принятые байты, вплоть до начала следующего фрейма, будут отброшены или помечены как ошибочные. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 8 марта, 2010 Опубликовано 8 марта, 2010 · Жалоба Правильно реализован прием на аппаратном уровне. После ошибки приема, все последующие принятые байты, вплоть до начала следующего фрейма, будут отброшены или помечены как ошибочные. Бред. UART оперирует исключительно байтами и совершенно спокойно выделяет следующий БАЙТОВЫЙ ФРЕЙМ. По фрейму медленно и печально перечитайте пост #14 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Гость @Ark 8 марта, 2010 Опубликовано 8 марта, 2010 · Жалоба Бред. Изложите, тогда, "свой бред". Сравним. ... Гарантированные "Паузы" есть - это стоп-старт биты. При ошибках внутренняя логика UART рестартует и осуществляет поиск нового фрейма. Таким образом достоверность байта следующего за сбойным по анализу трех бит (start-parity-stop) гарантируется железом. Вот это действительно бред. После сбоя ничего уже не гарантируется... Медленно и печально перечитайте пост №3. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
galjoen 0 9 марта, 2010 Опубликовано 9 марта, 2010 · Жалоба После сбоя ничего уже не гарантируется... Гарантируется с того момента, как будет принят байт 0xFF (при отсутствии контроля чётности или с той чётностью когда 0xFF передаётся в виде только стартового бита). Поэтому жел-но в протоколе периодически вставлять в передачу по два FF-а - второй из этих FF-ов обязательно примется правильно. Например, каждый пакет с них начинать. Это гарантирует восстановление синхронизации даже в непрерывном потоке данных. А потом можно перепередать только разрушенные пакеты, а не всё... Но вот из-за того, что ошибки в win хранятся не на каждый принятый байт (хотя железо 16550 это позволяет), там использовать такую фичу невозможно. Тем более с переходником USB-COM (там и железо не позволяет). А в передачах между МК можно и нужно использовать... А вот BREAK (достаточно долгий) можно использовать и под win. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 9 марта, 2010 Опубликовано 9 марта, 2010 · Жалоба Медленно и печально перечитайте пост №3. Вот именно эти Ваши "гипотезы" о том, что в течении времени образуется разрыв, куда пропадают биты я и называю бредом. Гарантируется с того момента, как будет принят байт 0xFF Для восстановления БАЙТОВОЙ синхронизации глубоко безразлично по какому байту восстанавливаться. Но вот из-за того, что ошибки в win хранятся не на каждый принятый байт (хотя железо 16550 это позволяет) 1. Позволяет с оговорками. 2. Вы читаете НЕ из железа, а из многокилобайтовых буферов операционной системы - тогда и их пришлось-бы расширять. 3. Пишите свои драйвера - никто не запрещает. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
galjoen 0 9 марта, 2010 Опубликовано 9 марта, 2010 · Жалоба Для восстановления БАЙТОВОЙ синхронизации глубоко безразлично по какому байту восстанавливаться. Что в вашем понимании значит БАЙТОВАЯ синхронизация? Я так считаю, что БАЙТОВАЯ синхронизация имеется, когда стартовый бит принимается именно как стартовый, а не как бит данных. Вот это гарантированно произойдёт после появления в линии 2-х последовательных байтов FF (после сбоя синхронизации правильно примется только 2-й). А вот передача байтов 0xAA - самый худший вариант для восстановления байтовой синхронизации. 1. Позволяет с оговорками. 2. Вы читаете НЕ из железа, а из многокилобайтовых буферов операционной системы - тогда и их пришлось-бы расширять. 3. Пишите свои драйвера - никто не запрещает. 2. Многокилобайтовые буфера стали бы в 2 раза больше, если бы в них было по 2 байта на каждый принятый байт. По современным меркам это мизер. 3. Драйвера писать не буду. На мой взгляд использование USART в компе, при наличии там USB хоста, это анахронизм. Сейчас, при появлении 3-х долларовых МК с USB девайсом на борту использование RS-232 для подключения к компу лишено всякого смысла. Протоколы на базе USART стоит использовать только для связи между МК, при только при соединении точка-точка. А в остальных случаях там CAN лучше, хотя он и пока (!) несколько дороже. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
forever failure 0 9 марта, 2010 Опубликовано 9 марта, 2010 · Жалоба Ксати да, тоже ожидал, что обязательно появится некто, кому череп жмёт, с полезными советами использовать CRC вместо чётности, CAN или USB вместо RS232/RS485, молоток вместо отвёртки, и другими глубокими мыслями. Напомню: про всё, что хотелось бы выяснить - спрашивалось в первом посте. Про црц, кан, усб и забивание шурупов - в другой раз. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 9 марта, 2010 Опубликовано 9 марта, 2010 · Жалоба Сейчас, при появлении 3-х долларовых МК с USB девайсом на борту использование RS-232 для подключения к компу лишено всякого смысла. Ну а если подумать о том, какое количество софта, с каким количеством ошибок и какой зависимостью от окружения требуется для облуживания USB? Нужен, например, отладочный интерфейс - при вылете системы через USB стек Вы почти наверняка вообще ничего не увидите. UART, как минималистичная штучка будет востребован еще очень и очень долго. Протоколы на базе USART стоит использовать только для связи между МК, при только при соединении точка-точка. А в остальных случаях там CAN лучше, хотя он и пока (!) несколько дороже. Практически уже нет и использование UART для организации сетей в стиле 70х годов прошлого века уже не оправдано. молоток вместо отвёртки, и другими глубокими мыслями. Вынужден заметить, что "глубокую мысль" использовать Бит-UART-молоток и, полагаю, PIC/AVR до кучи, вместо "отвертки" высказали именно Вы. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Гость @Ark 9 марта, 2010 Опубликовано 9 марта, 2010 · Жалоба Цитата(zltigo) Вот именно эти Ваши "гипотезы" о том, что в течении времени образуется разрыв, куда пропадают биты я и называю бредом. Замечательно. А я называю бредом Вашу уверенность в том, что после ошибочного приема байта, стартовый бит следующего байта непременно останется неповрежденным, и синхронизация не будет нарушена. Я думаю, мы определились с позициями. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 9 марта, 2010 Опубликовано 9 марта, 2010 · Жалоба А я называю бредом... Жаль, что вы не способны понять, как работает реальный контроллер UART и пытаетесь подменить его своими чрезмерно вульгарными представлениями. Категорическое непонимание того, что, как минимум, в пределах одного байтового фрейма контроллеры работают в СИНХРОННОМ режиме порождают у Вас совершенно искаженную картину реальности :(. Контроллер UART совершенно спокойно выделяет одиночные ошибки и восстанавливается при одиночных ошибках в байтовых фреймах. Для работы в непрерывном потоке ошибок оно просто не предназначен и это принципиально. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Гость @Ark 9 марта, 2010 Опубликовано 9 марта, 2010 · Жалоба Категорическое непонимание того, что, как минимум, в пределах одного байтового фрейма контроллеры работают в СИНХРОННОМ режиме порождают у Вас совершенно искаженную картину реальности. В свою очередь, я наблюдаю с вашей стороны категорическое нежелание видеть полную картину этой реальности. Во всем ее многообразии... Контроллер UART совершенно спокойно выделяет одиночные ошибки и восстанавливается при одиночных ошибках в байтовых фреймах. Вот именно, только в одном этом конкретном случае - из всего множества ситуаций, которые реально могут случиться на линии. Это лишь частный случай, "закладываться" на который в реальных условиях - просто наивно. Для работы в непрерывном потоке ошибок он просто не предназначен и это принципиально. Никто и не претендует. Речь идет о правильной (надежной) обработке ошибок. В частности, не допускающей недостоверную передачу, если вдруг на линии появился их "непрерывный поток". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 9 марта, 2010 Опубликовано 9 марта, 2010 · Жалоба Речь идет о правильной (надежной) обработке ошибок. В частности, не допускающей недостоверную передачу, если вдруг на линии появился их "непрерывный поток". Только вот какой "облом" пауза, которую Вы пытаетесь продвигать, как панацею, точно так-же повергается, например, внешним воздействиям, как и передача байта и если вы получаете плотный поток дерьма вместо байтов, то ни чуть не лучший поток дерьма Вы получите вместо пауз вот и все. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Гость @Ark 9 марта, 2010 Опубликовано 9 марта, 2010 · Жалоба Только вот какой "облом" пауза, которую Вы пытаетесь продвигать, как панацею, точно так-же повергается, например, внешним воздействиям, как и передача байта и если вы получаете плотный поток дерьма вместо байтов, то ни чуть не лучший поток дерьма Вы получите вместо пауз вот и все. ... главное, что я не получу недостоверную информацию. И даже не буду пытаться работать в этом "слошном потоке дерьма". Мне этого вполне достаточно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 9 марта, 2010 Опубликовано 9 марта, 2010 · Жалоба ... главное, что я не получу недостоверную информацию. С чего-бы это вдруг? Ваша волшебная байт-пауза превратилась в какие-то непонятные биты. В такие-же непонятные биты превратилcя в тех-же условиях, например, жутких помех, обычный байт. В чем разница? Только в том, что из-за своей ненормированной паузы Вы еще совсем потеряли битовую синхронизацию. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
