Добрый день. Возникает впечатление, что биос в Е440 из файла не грузится, хотелось бы разобраться.

LOAD_MODULE возвращает TRUE, а плата себя ведет, так как будто загружена прошивка из ресурса.
Сначала меня смутила строка:

if(!strcmpi(FileName, "flash"))
заменил ее на
if(strcmpi(FileName, "flash")==0)
это ни к чем не привело.

Cейчас у меня драйверы v6.0.1.0 + lusbapi v3.3
Эта прошивка работала раньше (и сейчас работает), при использовании lusbapi v2.0 + драйвер v1.0.0.0 все работало.

1. Что означает "себя ведет, так как будто загружена прошивка из ресурса"? Каким образом Вы это определяете?
2. Как именно выглядит вызов функции LOAD_MODULE?

1: Я туда гружу модифицированную прошивку. Модификация описана здесь: http://lcard.ru/forums/1?action=viewthread&thread=8781 (в контексте E140M).
2:
Var LBios : AnsiString;
begin
Result := pe440.LOAD_MODULE(PChar(lbios));
end;

LOAD_MODULE() возврашает TRUE
Когда в dll внутри LOAD_MODULE() оставил только LoadFromFile, она также возвращала TRUE, и свойства модифицированной прошивки никак не проявлялись.

Недопонял...
У Вас в качестве названия файла с LBIOS передаётся пустая строка?

Конечно нет. Она не может быть пустой, потому что LoadFromFile (в dll, вложенная в LOAD_MODULE) возвращает TRUE.
Вы попросили показать, как выглядит вызов, я показал, то, что с моей точки зрения важно.
Имя файла заполняется, файл существует.
Тут проблема миграции рабочего проекта с одной версии библиотеки+драйвер на другую.
В коде dll я проблем не вижу, т.к. он почти один в один совпадает с кодом библиотеки v2.0.
Видимо проблема в драйвере.

1. В данном случае от USB драйвера ничего не зависит, т.к. он абсолютно ничего не знает про железо (про модуль E14-440). Можно сказать , что единственная его задача - корректно оттранслировать запросы на уровень стека USB драйверов от Microsoft. Вся работа с железом модуля E14-440 сконцентрирована именно на уровне библиотеки Lusbapi.
2. Засылайте исходники Вашего примера. После праздников буду разбираться.

Даниил, а дельфи у Вас не слишком свежие?
А то они с версии 2009 сделали PChar юникодом, а 8-битный теперь PAnsiChar.

Если бы была зависимость от версии Delphi, то клиентское приложение со старой библиотекой (Lusbapi 2.0) тоже бы не заработало. В данном же случае идёт  процесс "миграции рабочего проекта с одной версии библиотеки+драйвер на другую".

Delphi7 в обоих случаях

>2. Засылайте исходники Вашего примера. После праздников буду разбираться
Сейчас пока не могу - уже не наработе, а после праздников еду в командировку.

Насколько я знаю, в Delphi 7 уже были сделаны те изменения, на которые указал Александр Е.
Тогда вопрос: я правильно понимаю, что собранное именно под Delphi 7 приложение со старой библиотекой Lusbapi 2.0 функционирует нормально, а приложение с новой библиотекой (Lusbapi 3.3) не работает?

Сергей: Да, Вы правильно понимаете. Еще есть желание посмотреть исходник?

Только кроме библиотеки еще и драйвер менять надо, т.к. иначе функция OpenLDevice не устанавливает соответствие устройство-драйвер.

Засылайте и старый и новый вариант Вашего приложения.

Отправил

1. Проверка показала, что приложение с Lusbapi 3.3 вполне работоспособно. В том смысле, что загрузка DSP модуля из внешнего файла проходит совершенно нормально.
2. Опознать правильность поведения функции ReadChan() я не могу. Нужна какая-нибудь дополнительная информация.

Вы можете проверить устанавливается ли цифровая линия №1?
У меня она управляет переключением реле. Поэтому я вижу, что с lusbapiv2 реле срабатывает, а с lusbapiv3.3 - нет.

Засылайте исходники Вашего драйвера DSP.

Отправил

может мне переписать биос на основе более новой версии?

Как оказалось LBIOS здесь не при чём.
Дело было в тонкостях преобразования типов в С++ и Delphi. Выслал подправленную версию библиотеки Lusbapi 3.3.

С виду работает. Спасибо большое!
Если не секрет, какое именно исправление? Просто тоже в код смотрел, но ничего не увидел.

Вместо:
PUT_LBIOS_WORD(L_ENABLE_TTL_OUT_E440, (SHORT)EnableTtlOut)
следовало использовать:
PUT_LBIOS_WORD(L_ENABLE_TTL_OUT_E440, (SHORT)(EnableTtlOut ? 0x1 : 0x0))