[firstvald 12]

вылезайте Вы из этой котельной, оглянитесь - за ее пределами тоже есть жизнь и промышленность!

 

Жизнь - есть! Согласен. Но USB в ней места нет . USB живет там где кошечки, брелочки, MP плееры и т п.

 

Ни в каком проекте никто не не использует USB. Вы что? У отдельных заказчиков вообще требование ни за что не использовать Форточки ни в каком виде.

[galjoen 0]

Вот именно для отладки и именно в изделии, и именно на объекте UART и надо использовать. А JTAG (подключение+железо+драйвера+офигенный софт)в этих условиях гарантированно идет лесом.

В моих условиях не только JTAG, но и USART идут лесом ибо не только человек (высокое напряжение), но и комп (с UART) там просто не поместится. Пользуюсь флешкой с SPI - сильно помогает. Поэтому про JTAG написал чисто теоретически, если не прав, то пусть будет так.

А еще пофантазировать? А в бубен, постучать? Шаманы рекомендуют.....

Если вы знаете способ лучше, как восстановить байтовую синхронизацию в непрерывном потоке данных (8N1) то так и напишите, а в бубен постучим параллельно.

Равноправные варианты пакетной синхронизации:

1. При 9-битах (не к этой теме, по все же) - прием байта адреса (бит9=1)

2. Посылка BREAK, прочищающего мозги всем и откидывающего на дефолтные настройки

3. По модбасовски - тайм-аут между посылками

4. Преамбула 0х55 (одновременно и автонастройка скорости, кто может)

5. Любой символ, считающийся признаком начала пакета с разруливанием двойного толкования этого символа (эскейп-последовательности).

6. Самосинхронизация за счет длины пакета и контрольной сигнатуры - например, длина пакета не более 10байт, сигнатура, как в далласах(onewire) - пожалста, приняли байт, отсчитали от него назад контрольную сумму в окне, не более длины пакета, если совпало с принятым байтом - пакет принят.

Все это так или иначе делал. Сказать, что какой-нить из методов (особенно спорный №6) - полный ацтой - не скажу. Номер шесть тоже вполне ничего.

По пунктам 1,4,5 - после потери байтовой синхронизации (стартовый бит принимается как бит данных) работать не будет.

П. 2 - таймаут может помехой быть изменён на 0xFF, 0xEF и т.д.

П. 6 не спорный, а вынужденный под win - тоже делал.

Но по теме, с учётом ограничений родного драйвера в win, остаются только 2, 6 (вынужденный) и отчасти 3 (модбас), но там время паузы может стать слишком большим. Да и вообще, модбасу давно на пенсию пора...

Собственно, только 2 то под win и остаётся...

 

А USB я успешно использую в условиях 6..10кВ * 1..2кА. Работает под lin. Там к хабу без без проблем обратится можно. И если потеряется EOP и хаб отключит мой девайс (в этом ведь проблема USB), то тут-же переподключаюсь и всё - 5 мСек max. Но если нет 5 мСек ограничения, то можно и по win работать - даже со стороны девайса всё решается. Только уже порядка 50 мСек будет.

[_Pasha 0]

По пунктам 1,4,5 - после потери байтовой синхронизации (стартовый бит принимается как бит данных) работать не будет.

Дык как же не будет? Это бит данных может быть воспринят как стартовый - я это понимаю.

По этой причине вопросы могут быть к п.1 и 5.

Про п.1 - ничего не скажу, там где использую 9 бит, посылка идет с паузой между байтами.

А п.5 - на символ начала можно наложить ограничения, забив старшие биты единицами.

[rezident 0]

Жизнь - есть! Согласен. Но USB в ней места нет . USB живет там где кошечки, брелочки, MP плееры и т п.

 

Ни в каком проекте никто не не использует USB. Вы что? У отдельных заказчиков вообще требование ни за что не использовать Форточки ни в каком виде.

Действительно кругозор узковат у вас. В наших контроллерах, предназначенных для учета энергоресурсов, которые в т.ч. и в котельных работают ;), используется USB для снятия журнала. USB заменил FDD, который использовался в предыдущем поколении приборов для той же цели - снятие журналов с удаленных объектов, не имеющих связи. Естественно, что для организации сетевой связи в приборе имеются и RS232 и RS485, посредством которых также можно считывать и журнал и текущие рабочие значения/параметры. То бишь, USB это еще один интерфейс в приборе.

[firstvald 12]

Про кругозор советую помолчать. Выношу вам замечание.

Ну и в моих приборах есть USB дырка. Это кстати не общение , а перенос архива (еще можно конфигурить - но это экзотическая особенность). Ни нафиг она никому не нужна. (Хотя вопрос о FDD в свое врем тоже обсуждался :) ) Те заказчики, кто архив через USB сливает - их единицы (буквально, хотя есть тоже). По крайней мере все что я видел по объектам - это желание видеть в Москве аж температуру каждого подшипника ( и делаю ведь). И уж тем более предлагать общение с промышленным прибором через USB - глупость какая то. Основные заказчики строят скады . Большие или маленькие, но скады.

Тема топика - что делать при приеме с паритетом. Когда в такую тему влезают с советами использовать USB , нужно тут же банить за глупость.

Вопрос темы непростой - при DOSe все решалось, при винде - стало плохо. Советов по теме было только на первой странице - остальное - междусобойчик. Кстати про запоминание в буфере для каждого байта паритетов для 550 серии я не знал (не надо было и внимания не обращал), надо посмотреть, может и в самом деле запоминает в буфере. В 450, по моему не было. Вот это была полезная часть обсуждения.

[galjoen 0]

А п.5 - на символ начала можно наложить ограничения, забив старшие биты единицами.

По п. 4 передача первым символа 0x55 это хорошее решение, но не для приёма компом. МК может 0x55 вообще с помощью входа захвата принять и настроится, а комп - нет. Для компа лучше уж 0xFF передавать. Как, собственно, и по п. 5. Но два 0xFF подряд будет ещё лучше.

Тема топика - что делать при приеме с паритетом.

Ничего не делать - отказаться от паритета как от устаревшего и неэффективного решения. Паритет, этот CRC1 - совершенно неэффективен. Если принимается от 10 байт, то CRC8 на все эти байты займёт времени меньше, чем паритет. А уж эффект несравнимо выше будет. А CRC16 и CRC32 с CRC1 даже и сравнивать смешно...

[_Pasha 0]

отказаться от паритета как от устаревшего и неэффективного решения.

Для ограниченного набора символов - никогда он не устареет. Еще вспоминается темка из одной хорошей книжки по помехоустойчивому кодированию. Рассматривается блок данных, пусть это будут биты

b0  b1  b2  p1
b3  b4  b5  p2
b6  b7  b8  p3
p4  p5  p6  p7

p - это биты полученные путем xor по строкам и столбцам. Такой блочок данных позволяет восстановить все одиночные и часть двойных ошибок. Если совсем не фантазировать, то

b0 b1 p1
b2 b3 p2
p3 p4 p5

такой блочок (р5 - паритет) позволяет исправить все двойные ошибки

Извините за оффтоп.

[galjoen 0]

p - это биты полученные путем xor по строкам и столбцам.

Это называется поблочный контроль чётности. Он низкоэффективен и бессилен против ошибок возникающих в чётном кол-ве строк. А использовать для восстановления 4-х бит данных 5 дополнительных бит - это уже слишком. Есть методы получше.

Насчёт поблочного контроля в частности, и насчёт обнаружения и исправления ошибок вообще, очень хорошо и понятно написано тут: Р.Л.Хаммел Последовательная передача данных.

[firstvald 12]

Первый раз с проблемой паритета столкнулись, когда появилась 95 форточка, а надо было делать новое поколение медицинского прибора, в котором до этого дня непрерывно валились данные в сыром виде , а начало кадра обозначалось выставленным паритетом. Решили не заниматься фигней и перепаковали передаваемые данные в байты (вот там как раз и можно было сделать групповой бит проверки), а паритет ессно использовать никак.

 

Потом паритет всплыл когда пришел modbus. Тут ограничились обнаружением ошибки в принимаемой посылке (собственно после ReadFile читаем ошибку и смотрим есть ли она). Но задачу приема с получением информации о паритете в каждом байте так и не решили (и нафиг не нужно было). Хотя возможно она и решаема для всего диапазона скоростей.

 

С кадрированием (тут тащат не нравящийся мне термин "синхронизация")вот как раз столкнулись когда валится непрерывный поток данных без всяких перерывов. Да только перерыв более чем несколько интервалов передачи байта спасет, а никакие 55 или ff. Пока автомат в UART не отработает цикл - бесполезно что-то делать (значит нужно хотя бы 2 интервала передачи байта подождать), а в компе как правило еще буферизация включена.

 

Кстати говоря, заглянул в описание (exar)16с550, так там ничего про хранение в FIFO ошибок (паритета) нет. Так что, скорее всего, есть разные 550 и, вообще говоря, что на самом деле сделано в большой микросхеме в компе (когда пишут 550 совместимый UART)- совершенно не ясно. Скорее надо ориентироваться - что сделано, как делалось вначале - в FIFO пишется только данные , а флаг ошибки выставляется скопом для всего FIFO.

[_Pasha 0]

Пока автомат в UART не отработает цикл - бесполезно что-то делать (значит нужно хотя бы 2 интервала передачи байта подождать)

Стоп. Автомат в уарт отбрыкнется после ложного старта максимум через 0,5 битового интервала. Инфа об испорченном байте появляется апостериорно. Что еще надо для жизни?

[firstvald 12]

А если старт не ложный? Вот и начинается мешанина и конца и краю ей бывает не видно. Есть шанс, что ошибка кадрирования опознается, если стопа не окажется там, где он должен быть. Но это зависит от содержимого байта. И то. Мы в винде получим ошибку кадрирования, но мешанина продолжиться дальше.

 

Про паритет. Кто - нибудь чего придумал ?

[galjoen 0]

А если старт не ложный? Вот и начинается мешанина и конца и краю ей бывает не видно.

Мешанина закончится сразу после того, как в линии появится неповреждённый байт 0xFF (говорим про формат 8N1 и непрерывный поток данных). Сам этот 0xFF будет принят неправильно, точнее его вообще не будет, но в какой бы момент не был принят ложный стартовый бит (он может быть только раньше стартового бита 0xFF) , 9-ти единиц подряд (8 бит данных и 1 стоповый бит) хватит, чтобы следующий стартовый бит воспринялся именно как стартовый, и с этого момента всё пойдёт нормально до следующего сбоя байтовой синхронизации.

 

Кстати, к сбою байтовой синхронизации в непрерывном потоке 8N1 может привести только 2 случая:

1. Стоповый бит =0 (соединится со следующим стартовым) , но тогда будет ошибка кадра.

2. Стартовый бит =1. Тогда никаких ошибок не будет (пока на место стопового не попадёт 0).

[_Pasha 0]

А если старт не ложный?

Все, я устал. Извините за компанию.

[firstvald 12]

Согласен :)