Пересылаю массивы байт от 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).

Про FIFO - читайте там же, где вычитали как его отключать.
Про мультимедийный таймер:
Using Multimedia Timers.
Вот пример (Дельфи):


Но ещё раз повторюсь, лучше чем грамотно написанное приложение с использованием WinAPI всё равно не выйдет.

ОСРВ-денег стоит, насчет отсутствия системного подхода у нашего руководства- Вы сто раз правы, только это слабое утешение. Отдельный коммуникационный контроллер прицепить не могу- штатный комп в формате PC104-туда не так просто что-то прицепить. Я даже в DOS уйти не могу- отлаживаться с аппаратурой приходится через переходник USB-COM MOXA, который про DOS ничего не знает. Но вообще то я спрашивал про возможные причины пропадания байта.

Все изначально задумано делать и сделано через заднепроходное отверстие. Частности не интересны.

Совершенно не нужно отлаживать Win программы под DOS.

Вот вместо этой самой

и цепляете.

Если действительно, в чем я совершенно не уверен, обслуживание UART по времени не укладывается, то многие проблемы реального времени можно разрулить на уровне собственного, а не штатного драйвера COM порта. Но в Вашем случае, Вы явно создаете себе проблемы сами, виду крайне поверхностных представлений . Начните банально с WinAPI. Для этого вся информация есть, как ни странно, на сайте Microsoft.

Работа с последовательным портом - стандартная. И нет никакого смысла использовать giveio.
Могу рекомендовать Async Professional библиотеку для Дельфи 7. Удобная и быстрая (гугл отыщет).

Наблюдение фенолога. Запустите свою программу и посмотрите процент загрузки в таск менеджере. Вот если там цифирка отличается от 0 - вы неправильно написали программу.

Господи, ну зачем вся эта муть "библиотеки" с "компонентами" образующие нафиг ненужную надстройку над API. Впрочем, насколько мне помнится, MOXA на FTDI работает, посему можно для спрямления выкинуть эмуляцию виртуального COM порта с еще и дополнительной виндозной надстройкой и работать через Direct Drivers.

А затем, что это проще.
Чтобы использовать апи в чистом виде, надо слегка нагрузиться MSDN.
А лишние знания всегда требуют лишнего времени.

Да и всегда можна спросить - а зачем эта дурацкая надстройка над оборудованием в виде апи. С чего, собственно, человек и начал.

http://asm.shadrinsk.net/uroki.htm

При этом ограничиться синхронным приемом.

Про потери байт надо посмотреть : не выполняется ли в этот момент файловая операция. С большим интересом обнаруживал , что под досом при выполнении файловых операций приемник терял байты на скоростях начиная с 57600. Получалось, что при записи на диск запрещались все прерывания и соответственно падал обмен на больших скоростях.

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

API это в данном случае интерфейс Операционной системы. Отработанный-минимально-универсально-достаточный.
Наличие операционной системы, между прочим, не противоречит созданию собственного драйвера для железа для обеспечения большей
заточенности под конкретную задачу, о чем уже писал.

Только заставлять человека изучать АПИ (а тут одними функциями компорта не обойтись) ради простой операции - садизм. Вот потихоньку изучать АПИ - интересоваться, то есть - это нормально.

Вот честно скажу. Рабочий комп у меня - древний. Prescott 2.8. Ни на каких скоростях не было никогда потерь байтов.
При этом - абсолютное правило - у меня параллельно всегда крутится Южный парк на втором экране (ATI 9600), который берет мультик с внешнего USB диска.
К слову, большая часть COM портов - это мосты Silabs. И только один - родной.

Для работы с COM портом из API понадобятся 7 функций. Если делать Overlapped IO, то еще 4. Мне не кажется, что изучить 11 функций это 'садизм' Тем более, что работа с COM портом достаточно подробно расписанна в MSDN ( http://msdn.microsoft.com/en-us/library/aa...v=VS.85%29.aspx )

Давайте засечем время.
Напишем терминалку на дельфях и тоже самое с апи.
У меня уйдет на это минуты 2. У человека, который первый раз этот компонент видит - минут 5.
У вас - который уже сто раз писал такое - только на набивку текста уйдет 10 минут (11 функций, с офигенно длинными типами...). И еще 20 - на поиск - чего-то не подключил, что не компилируется...
Ну, и кроме того, в такой программе не одни только вызовы апи. Еще, собственно, и процессы описывать как-то надо...

Самое главное, не сочтите за труд незамедлительно вывалить "это" в Интернет, дабы неоскудели образчики борлондячего "творчества" из 2х минутных программ и 3x строчных "библиотек" сделанных 4мя движениями мышки.
То, чем пользуетесь, в данном случае OS Windows, нужно знать. И использовать оптимально не загромождая ее, по причине собственного непонимания, ни вульгарными прибамбасами над системой, ни ломовыми заплатками ломающими систему.

А давайте не будем писать терминалку - их уже и так как собак нерезанных Давайте писать программу ТС 'за 100 млсек надо успеть обменяться с 8-9 абонентами'
А сколько времени уйдет на доработку напильником компонента под такую задачу? И каких размеров напильник потребуется?