[AHTOXA 14]

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

 

Про FIFO - читайте там же, где вычитали как его отключать.

Про мультимедийный таймер:

Using Multimedia Timers.

Вот пример (Дельфи):

var
    MmTimer         : MMResult;
    MmTimerInterval : integer;

// эта процедура будет вызываться по мультимедиа таймеру:
procedure MmTimerProc(uTimerID, uMessage: UINT; dwUser, dw1, dw2: DWORD); pascal;far;
begin
    timeKillEvent(CksTimer);  // шлепнем событие
    try
        // делаем что-то полезное (достаём данные из FIFO)
    finally
        // зарядим таймер на следущий раз
        MmTimer:=timeSetEvent(MmTimerInterval,0,@MmTimerProc,0,TIME_ONESHOT)
    end;
end;

// начальный запуск таймера:
procedure StartMMTimer;
var TC: TTimeCaps;
begin
    if timeGetDevCaps(@tc, sizeof(TTIMECAPS)) = TIMERR_NOERROR then
    begin
        MmTimerInterval :=TC.wPeriodMin*3;  // период (обычно wPeriodMin = 1мс, берём втрое больше)
        timeBeginPeriod(MmTimerInterval);
        MmTimer:=timeSetEvent(MmTimerInterval,0,@MmTimerProc,0,TIME_ONESHOT);
        if MmTimer=0 then raise Exception.Create('Can''t start MmTtimer');
    end
    else
        raise Exception.Create('Can''t get MmTimer caps');
end;

 

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

[krik 0]

krik

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

Как верно заметил zltigo - отсутствие системного подхода (видимо у Вашего руководства).

Разделение задач на сбор информации и отображение сэкономит Вам массу времени и нервов.

 

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

[zltigo 0]

Но вообще то я спрашивал про возможные причины пропадания байта.

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

Я даже в DOS уйти не могу- отлаживаться ...

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

Отдельный коммуникационный контроллер прицепить не могу- штатный комп в формате PC104-туда не так просто что-то прицепить.

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

переходник USB-COM MOXA

и цепляете.

ОСРВ-денег стоит,

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

[DpInRock 0]

Работа с последовательным портом - стандартная. И нет никакого смысла использовать giveio.

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

 

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

[zltigo 0]

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

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

[DpInRock 0]

А затем, что это проще.

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

А лишние знания всегда требуют лишнего времени.

 

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

[firstvald 13]

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

 

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

 

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

[zltigo 0]

А затем, что это проще.

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

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

API это в данном случае интерфейс Операционной системы. Отработанный-минимально-универсально-достаточный.

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

заточенности под конкретную задачу, о чем уже писал.

[DpInRock 0]

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

 

Вот честно скажу. Рабочий комп у меня - древний. Prescott 2.8. Ни на каких скоростях не было никогда потерь байтов.

При этом - абсолютное правило - у меня параллельно всегда крутится Южный парк на втором экране (ATI 9600), который берет мультик с внешнего USB диска.

К слову, большая часть COM портов - это мосты Silabs. И только один - родной.

[xvr 12]

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

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

[DpInRock 0]

Давайте засечем время.

Напишем терминалку на дельфях и тоже самое с апи.

У меня уйдет на это минуты 2. У человека, который первый раз этот компонент видит - минут 5.

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

Ну, и кроме того, в такой программе не одни только вызовы апи. Еще, собственно, и процессы описывать как-то надо...

[zltigo 0]

У меня уйдет на это минуты 2.

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

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

[xvr 12]

Напишем терминалку на дельфях и тоже самое с апи.

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

У меня уйдет на это минуты 2. У человека, который первый раз этот компонент видит - минут 5.

А сколько времени уйдет на доработку напильником компонента под такую задачу? И каких размеров напильник потребуется? :cranky: