Здравствуйте, cr lf, Вы писали:
CL>>>Что такое Cypress ?
G>>Cypress — микросхема аля FTDI только для USB 2.0 и от другого производителя.
CL>А FTDI не USB2.0 ?
CL>Впрочем, мне без разницы.
Наша была USB 1.1. Может они и сделали уже USB 2.0 — я не знаю.
CL>>>Другой вопрос: является ли правильной сама организация программы чтения в виде цикла ?
CL>>>Вот если бы можно было связать появление единички на входе с неким событием ...
CL>>>Там в библиотеке есть какая-то FT_SetEventNotification, но я не совсем понял как ей пользоваться.
G>>Если логику организовывать у себя в софте, тогда эт немного сложнее. Но думаю, что мужику все равно придется переделывать что-то. Потому что на сколько я понял, то сигнал уст-ва тебе приходит только когда замкнута цепь, иначе уст-во молчит.
CL>А разве можно как-нибудь иначе ?
Можно. Можно опрашивать устройство на предмет засветки датчика. Или постоянно принимать сигнал с этого датчика, характеризующий его засветку.
G>>Ты должен иметь возможность постоянно опрашивать состояние оптического датчика либо в крайнем случае, чтоб тебе постоянно приходили сигналы
G>> о его состоянии.
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>
Вот это не совсем так. Тут ты читаешь только данные, пришедшие в USB, а опрашивать — это значит ты отправляешь некую команду в свое устройство и получаешь ответ от него с состоянием датчиков или чего угодно.
G>>По поводу архитектуры программы, то тут вопрос не простой. Все зависит от того, как работает электроника, что еще тебе надо отслеживать на ней и какие задачи выполняет сам софт.
CL>Мне надо
CL>1. записать в устройство 4 байта — 00000000,000000001,00000010,00000011,
CL>2. дождаться прихода от него других 3-х байт — 00010000b,00001000,00000100.
CL>3. засечь интервалы времени между этими сигналами.
Я обычно пишу свой класс для работы с устройствами, в котором есть поток, отвечающий за прием/передачу данных. В классе есть методы для отправки команд и события по их приходу с устройства. Поток должен иметь синхронизацию! Я использую критические секции и TEvent.
Больше сказать сложно, т.к. не понятно назначение этих байт... Как часто нужно их получать...
Каждое конкретное устройство (из-за своей логики и назначения) требует своего подхода и решений. Нет универсальных решений... Есть только рекомендации.
G>>Лучше конечно с устройствами работать в отдельных потоках, а при работе с портами использовать Overlap-структуры.
CL>Что такое Overlap-структуры ?
Это просто другой способ общения через порты. Почитай... Есть доки. Даже в справке Delphi описано. Основной смысл в том, что ты НЕ ИСПОЛЬЗУЕШЬ просто ReadFile/WriteFile и не ждешь данных, а можешь повесить на прием евент и ждать его WaitForSingleObject (тогда будешь точно знать когда пришли данные и прога не останавливает работу).
G>>Твой цикл ничего не сможет отобразить на экране, если он выполняется в контексте основного потока и прога будет висеть.
CL>Почему же не сможет ? — Если приложение консольное (это пока), то отображает, ну а потом при переходе на GUI я собирался засунуть его либо в отдельный поток, либо в TTimer.
Если консольное — то конечно.
G>> Хотя можно еще на таймер повесить проверку, но это не лучший стиль (лучше так не делать).
CL>Почему ?
Потому, что это плохой стиль. Все равно что GOTO использовать. Таймером можно только часы сделать на форме... Ну или мигание какое-нибудь...
