Мост USB-USART проблемы с ноутбуком

[Yurkin2014]

Раз уж ждёте пакеты с синхробайтами, то читайте по одному байту из приёмного буфера и тут же проверяйте на == USART_SYN_OUT.
Типа так

void serialPortMCU_DataReceived(object sender, System.IO.Ports.SerialDataReceivedEventArgs e)
{
   int temp, tempold;
   tempold = 0;
   while (serialPortMCU.BytesToRead › 0)
   {
      temp = serialPortMCU.ReadByte();
      if((temp ==USART_SYN_OUT) && (tempold ==USART_SYN_OUT)) 
      {
          serialInByte[countByteInBuff] = USART_SYN_OUT;
          serialInByte[countByteInBuff+1] = USART_SYN_OUT;

          for (int i = countByteInBuff+2; i ‹ countByteInBuff + 6; i++)
          {
               serialInByte[i] = serialPortMCU.ReadByte();
          }
          break;
      }
      tempold=temp;
   }
}

[Boba_spb]

Если принято меньше 32 байтов, то serialPortMCU.Read() будет до упора ждать, а потом вылетит в catch{} по таймауту.

Да что Вы говорите !!! По умолчанию ReadTimeout установлено в InfiniteTimeout. Я вроде не советовал что-то с ним делать

[Boba_spb]

Раз уж ждёте пакеты с синхробайтами, то читайте по одному байту из приёмного буфера и тут же проверяйте на == USART_SYN_OUT.

Я лет 30 пользуюсь протоколами передачи, которые придуманы Бог знает сколько лет назад.

Если передается символьная информация то протокол простой:
‹STX› ‹передаваемые символы›‹ETX›.

Ах, да что такое ‹STX› и ‹ETX› ? Посмотрим в ASCII ( разработана в 1963 году)
STX - 0x02 - START OF TEXT
ETX - 0x03 - END OF TEXT
Далее все просто как мычание.


Для бинанарных сообщений чуть сложнее:
‹DLE›‹STX›‹ бинарные данные› ‹DLE›‹ETX›
DLE - 0x10 - "SYNCHRONOUS IDLE"
Естественно ‹DLE› будет байт-стаффингом в этом протоколе, т.е.,
если среди бинарных данных встречается код 0x10, то он дублируется.

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

[Yurkin2014]

По умолчанию ReadTimeout установлено в InfiniteTimeout.

Я считаю, что InfiniteTimeout не есть хорошо.

При разрыве передачи

вот-вот, при прекращении передачи по какой-либо причине программа с InfiniteTimeout просто тупо зависнет, и поможет только комбинация из трёх пальцев. На заказчика такие зависания производят плохое впечатление.

Я лет 30 пользуюсь протоколами передачи ...
Для бинанарных сообщений чуть сложнее:
‹DLE›‹STX›‹ бинарные данные› ‹DLE›‹ETX›

Не, ну, Вы - просто молодец, никто ж не спорит!

[omercury]

программа с InfiniteTimeout просто тупо зависнет

Ребят, я, возможно, туплю, но не для предотвращения ли вечных ожиданий таймауты придуманы?

[Boba_spb]

Если тупо писать, то можно и комп подвесить.
Делали системку - круглосуточный мониторинг. Два устройства на двух USB-COM. Замена устройств "налету" - какие зависания, о чем речь? Прогу писал на С#;

[Boba_spb]

Не, ну, Вы - просто молодец, никто ж не спорит!

Гляньте на досуге http://opds.sut.ru/old/electronic_manuals/sde/sde5.htm
Может сарказма поуменьшится.

Если заинтересует, то можете исчо про БЧХ почитать - если вдруг помехи появятся на линии, то можно будет ошибочки и поправлять .

Мы не так долго живем что б все придумывать самому!

[Boba_spb]

Ребят, я, возможно, туплю, но не для предотвращения ли вечных ожиданий таймауты придуманы?

Да не виснет она - в данном случае она вызывается в дополнительном потоке, который организуется при непустом буфере СОМ.

Но пионеры вызывают ее из основного потока , например из тика Form.Timer, и при отсутствии байт в буфере блокируют свой основной поток, потому что Form.Timer работает на основном потоке. А что б его разблокировать надо чуток еще постараться.

Организовать обмен на System.Timer - надо ж догадаться, да и работает он по - взрослому.

Ну так это руки кривые, а не

[Yurkin2014]

вызывают ее из основного потока , например из тика Form.Timer

Причём тут таймер?!? Процедура serialPortMCU_DataReceived() вызывается драйвером компорта в тот момент, когда пришёл байт в приёмный буфер.

Боба, друг, ну, что за манера вести дискуссию! Я просто обратил внимание, что при бесконечном таймауте и недостаточном количестве байтов в буфере функция чтения порта зависнет навсегда. Вот и всё. В качестве контраргументов Вы почему-то приводите пример использования байт-стаффинга и описание какого-то "костыля с четыремя сетками". Всё это как-то неубедительно.
Ваши послания, ведь, читают тысячи начинающих программистов, и многие будут повторять, вон, мол, дядя Боба из Питера всегда ставит InfiniteTimeout и у него никогда ничего не виснет!

[Boba_spb]

Мы плавно переходим с зависания в SerialPort.Read() , в зависание процедуры serialPortMCU_DataReceived()

Сделайте процедуру serialPortMCU_DataReceived() такой:

private void serialPortMCU_DataReceived()
{
// Чему тут висеть ??
}