Пересылаю массивы байт от COM1 в COM2 через нульмодемный кабель на одном компе. Использую прямой доступ к порту -Giveio ( или UserPort) с одной стороны, и терминалка с другой. В обоих случаях при приеме в программке с прямой доступом к порту пропадает самый первый байт на скорости 115кбит. На меньших скоростях-нормально, при приеме одного байта -нормально. Как только переходишь на 115200 -принятый массив начинается со второго байта.
Кто нибудь сталкивался с чем-то подобным?

а управление потоком какое стоит? все настройки в студи, телепаты в отпуске.

осталось узнать зачем???

Видимо, что бы пропадал первый байт

А затем что обычным образом через функции WINAPI работает медленнее в разы.

1.Да ну? Не успевает 115200
2.Вообще-то к портам RS232, в отличие от LPT, и так штатно доступ открыт.
3.Еще одно наслоение виде giveio только вносит дополнительное торможение.

krik
На скорости 115200 при практически постоянном потоке работали сутками. Через стандартный WINAPI не пропадало НИ ОДНОГО байта. А задач на ПК "крутиться" много (одних COM штук 6). Не тормозит.
С Linux через TTY точно такая же ситуация.

// вот и весь кусок. Используется UserPort
double dltt=0;
unsigned char buf[64]={0};
unsigned char*pbuf=buf;
unsigned char*str="HiTerminal!";
int c; int i=0;

// установки СОМ порта
outportb(BRH,0);//запрет прерываний

outportb(LCR,0x80);//bit DLAB=1

outportb(PORT1,0x1);//115200 bit

outportb(BRH,0);//

outportb(LCR,0x03);// 8 бит, 1-стоп, без контроля четности

outportb(FIFO,0);//запрет FIFO

outportb(MCR,0);//запрет modem

//======== ВЫВОД====================//
while (*str!=0)
{
outportb(PORT1,*str++);
do
{c=inportb(PORT1+5)&0x40;}
while(c==0);
}

//======== ВВОД====================//
while(1)
{
while((c=inportb(PORT1+5)&0x01)!=0x01) ;
buf[i]=inportb(PORT1);
i++; //число принятых байт
if ( buf[i-1]==0x30)// символ конца посылки
break;// выход из цикла опроса

}

.............................................
hUserPort = CreateFile("\\\\.\\UserPort", GENERIC_READ, 0, NULL,OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
CloseHandle(hUserPort); // Activate the driver
............................................................................
pz = StartUpIoPorts(PORT1, true, hParWind);// hParentWnd); //

...............................................
void outportb(UINT portid, BYTE value)
{
__asm mov edx,portid
__asm mov al,value
__asm out dx,al
}

BYTE inportb(UINT portid)
{
unsigned char value;

__asm mov edx,portid
__asm in al,dx
__asm mov value,al
return value;
}







См. например книжку Агурова" Последовательные интерфейсы ПК" стр.207.



Пропадает то не на WINAPI. С WINAPI просто меделнно. За 100 млсек надо успеть обменяться с 8-9 абонентами.

Простите, но это чистое безумие

Кошмар Вы отключили FIFO, и надеетесь, что успеете всё принять по опросу? Это Агуров так советует?

Да и с FIFO принципиально не изменится ничего. Полное отсутствие системного подхода и непонимание даже того простого факта, что дивный цикл опроса в приложении спокойно может быть прерван и на очень долго. Про то, насколько этот тупой опрос ВПУСТУЮ грузит систему тоже у Автора нет представления.

Агуров ничего здесь не советует. А что кроме опроса здесь может быть?

krik
Если за 100 млсек надо успеть обменяться с 8-9 абонентами , то удобней и проще подключить к ПК специальный коммуникационный контроллер (к примеру на МК), которые собирает данные с удалённых абонентов и пересылает подготовленные результаты в ПК для отображения. Windows так же как и Linux - это не ОСРВ, попытка использования их в этом режиме оборачивается сплошными проблемами.
Как верно заметил zltigo - отсутствие системного подхода (видимо у Вашего руководства).
Разделение задач на сбор информации и отображение сэкономит Вам массу времени и нервов.

FIFO + мультимедийный таймер + реалтайм приоритет процесса - можно добиться приемлемых результатов, почти сравнимых с грамотной работой через WinAPI

FIFO + мультимедийный таймер -поясните если можно.(например как обходиться с FIFO).