CL>>Так ведь это и делается
CL>>

CL>>while <условие> do begin
CL>>  Read_USB_Device_Buffer(1);
CL>>  Signal := FT_In_Buffer[0] and $10 <> 0; // поступил сигнал
CL>>    if Signal then begin
CL>>     работа
CL>>    .............
CL>>    end;
CL>>end
CL>>

G>Вот это не совсем так. Тут ты читаешь только данные, пришедшие в USB, а опрашивать — это значит ты отправляешь некую команду в свое
G> устройство и получаешь ответ от него с состоянием датчиков или чего угодно.
Наверное я тупой, но я не вижу разницы в твоих словах и в моем коде ;(
Я читаю данные из USB, которые и описывают состояние датчика.
Датчик является тем самым устройством, которое замыкает/размыкает цепь, подающую сигнал на вход микросхемы FTDI, а она в свою очередь переправляет его в USB.

G>>>По поводу архитектуры программы, то тут вопрос не простой. Все зависит от того, как работает электроника, что еще тебе надо отслеживать на ней и какие задачи выполняет сам софт.
CL>>Мне надо
CL>>1. записать в устройство 4 байта — 00000000,000000001,00000010,00000011,
CL>>2. дождаться прихода от него других 3-х байт — 00010000b,00001000,00000100.
CL>>3. засечь интервалы времени между этими сигналами.
G>Я обычно пишу свой класс для работы с устройствами, в котором есть поток, отвечающий за прием/передачу данных. В классе есть методы для
G> отправки команд и события по их приходу с устройства. Поток должен иметь синхронизацию! Я использую критические секции и TEvent.
G>Больше сказать сложно, т.к. не понятно назначение этих байт... Как часто нужно их получать...
Непонятно насчет синхронизации ... ;(
Мне там синхронизировать особенно нечего.
Записываемые байты пишутся с интервалом в 1 сек.
После чего следует ожидать 00010000b,00001000b,00000100b именно в этой последовательности.
Хотя 00010000b может прийти и раньше, чем будут отправлены в устройство первые 4 байта.
Короче суть задачи:
стоит автомобиль на старте, перед ним светофор.
Зажигается
— красный сигнал (00000000b)
— красный сигнал (00000001b)
— красный сигнал (00000010b)
— зеленый сигнал (00000011b)
Старт — срабатывает фотоэлемент — получаем 00010000b, начинаем отсчет времени.
Где-то посередине дистанции другой фотоэлемент, проехав через который, получаем 00001000b.
И в конце дистанции третий фотоэлемент, который даст нам 00000100b
Вот собственно и все.
Разве что, если у водителя дрогнут нервы, он может стартовать раньше зеленого сигнала и тогда мы получим сигнал от первого фотоэлемента раньше, чем запишем 00000011b

G>>>Лучше конечно с устройствами работать в отдельных потоках, а при работе с портами использовать Overlap-структуры.
CL>>Что такое Overlap-структуры ?
G>Это просто другой способ общения через порты. Почитай... Есть доки. Даже в справке Delphi описано. Основной смысл в том, что ты НЕ
G> ИСПОЛЬЗУЕШЬ просто ReadFile/WriteFile и не ждешь данных, а можешь повесить на прием евент и ждать его WaitForSingleObject (тогда будешь
G> точно знать когда пришли данные и прога не останавливает работу).
Вот я и говорю, что есть там какая-то FT_SetEventNotification

FT_STATUS FT_SetEventNotification (FT_HANDLE ftHandle, DWORD dwEventMask, PVOID pvArg)
Sets conditions for event notification.

Parameters
ftHandle - Handle of the device.
dwEventMask - Conditions that cause the event to be set.
pvArg - Interpreted as the handle of an event.

но воспользоваться ей у меня так и не получилось, хотя там и пример есть.
Вот ты говоришь, что прога не останавливает работу...
Как же не останавливает ?! — WaitForSingleObject в данном случае вешает программу навечно:

hEvent := CreateEvent(0,false,false,'');
FT_SetEventNotification(h,FT_EVENT_RXCHAR,@hEvent);
WaitForSingleObject(hEvent,Infinite);
FT_GetStatus(h,@RxBytes,@TxBytes,@EventDWord);
if RxBytes > 0 then begin
  FT_Read(h,@Buf,1,@Count);
  WriteLn('buf = ',IntToBin(buf));
end;

G>>> Хотя можно еще на таймер повесить проверку, но это не лучший стиль (лучше так не делать).
CL>>Почему ?
G>Потому, что это плохой стиль. Все равно что GOTO использовать.
Остается TThread ?