| Patron |
31st January 2013 13:41 |
Quote:
Originally Posted by nzeemin
(Post 571950)
Поэтому вероятно мы и видим overrun.
|
А мы таки видим именно overrun ?
Мы видим именно бит 010000 в регистре статуса приёмника ?
Если да - это неправильная эмуляция.
Вот такой код в принципе ошибочен:
Code:
if (m_SerialInCallback(&b))
{
if ((pMemCtl->m_Port176570 & 0200) == 0) // Ready?
{
pMemCtl->m_Port176572 = b;
}
else
{
pMemCtl->m_Port176570 |= 010000; // Set Overflow flag
}
pMemCtl->m_Port176570 |= 0200; // Set Ready flag
}
Quote:
Вообще общение с COM-портом у меня построено не на overlapped и не на событиях, а по более простой схеме -- чисто байтовое чтение и запись. При чтении если очередной байт не готов -- он не отдаётся. Но при записи пишется всё не взирая на возможные переполнения.
|
Так и надо.
Но ещё надо учитывать, что драйвер com0com - пакетный. Он не следит за промежутком времени между байтами ( в Windows вообще ни одна программа этого не делает ), поэтому, если эмулятор допускает формирование признака overrun - при работе в Windows этот признак обязательно будет формироваться.
---------- Post added at 11:38 ---------- Previous post was at 11:35 ----------
Здесь даже промежутки времени не столь важны.
Ведь в реальном порту действует квитирование, т.е. байт не может быть принят, если порт не готов. А в эмуляторе может! И даже признак overrun формируется!
---------- Post added at 11:41 ---------- Previous post was at 11:38 ----------
Поэтому - в нынешнем состоянии эмулятор эмулирует работу 1801ВП1-065 по кабелю без линий квитирования. А по такому кабелю ни TU58, ни сеть УКНЦ работать не могут. |
