vovka1960

Это конечно замечательно - только чем отличается написанное вами от того, что я написал? Мешать IPD - значит подтянуть к питанию, нет? И таки да, в моей схеме нет ничего, мешающего IPD - и тем не менее, проц работал неверно. А то, что там в замечании по поводу IPD написано, что я могу (могу, а не должен!) продублировать IPD внешним резистором на 20 кОм - это не объясняет, почему в моем случае IPD не сработало... По ходу, если глянуть борду - то там все (!) адресные пины подтянуты куда-то. И, кстати, пин AEA7 висит к половине питания (пара резисторов по 1 кОм вверх и вниз). Это "не мешать IPD"? А на счет "Я с этим процом начинал свою карьеру инженера-схемотехника )" - что ж не помогли с решением вопроса? Или это так, для собственной значимости заява?

Киньте в меня камнем, если я что-то наврал!

В общем - опробовано. Действительно, имеет место факт недокументированной фичи. Итого, имеем разряд AEA7, для которого в описании кроме как в качестве адресного разряда не значится ничего. Лишь замечание, что он IPD (internally pulled down - внутренняя подтяжка к земле) и просьба не подтягивать снаружи вверх. Тот факт, что значение этого разряда при инициализации можно прочесть в DEVSTAT (12 разряд) вообще никак не указывается, но имеет место факт - бит, отмеченный как Reserved, означает значение на AEA7 в момент запуска. Далее. Этот разряд (AEA7) подключен у меня через буферный резистор 33 Ома к входу ПЛИС. Третий циклон. Никаких внутренних подтяжек в циклоне не включено (специально проверил проект). Никаких других цепей на этот разряд не заведено. И вот неожиданно, при чтении DEVSTAT.12 выясняется, что там высокий уровень. И неожиданно оказывается, что высокий уровень выключает оба McBSP! И все это подробно описано в документации на родственника С6455 - TCI6482. Там - да, а тут - ни слова... В общем, добавление резистора 15 кОм на землю моментально исправило положение. И теперь я могу спокойно настраивать последовательный стык. Всем спасибо, вопрос закрыт. К счастью - с положительным результатом.

По ходу, E2E помог. Собираюсь пробовать. Очень интересное объяснение... Если кому интересно - советую прочесть...

Не поверите - таки да! И более того! А если серьезно - я там, выше, уже отписался, что AEA5 не помог..

Ну в общем - не помогло. Оба (уже оба!) безвылазно сидят в Static Powerdown. Грешу на питание, но где??? Пошел задавать вопрос на E2E...

Софт чисто свой (никаких ОС). Смотрю практически сразу (до этого только настройка PLL, DRAM и EMIF) - в примере от TI первой командой идет включение модуля в PERCFG0 с контролем включение в PERSTAT0. "1" в PERCFG0 выставляется нормально (читается). Но PERSTAT0 вместо 001 (Enabled) возвращает 011 (powerdown). На счет AEA5 - сам к такому решению пришел - в обед плата уехала в цех. Увы, джампера на это дело не предусмотрели.. Кто бы мог подумать...

Хм. Дело в том, что то, что вы описываете, программируется уже после включения модуля McBSP. Т.е. внутри процессора есть области, функционально отвечающие за те или иные операции. Они могут быть включены или выключены (физически, а не логически). Т.е. за счет этого можно оперировать энергопотреблением в том числе. Так вот - если модуль не включен - любое обращение к регистрам этого модуля (то, что описано в 7 разделе указанного вами документа - к слову, мои скриншоты тоже оттуда ;)) невозможно. Это как нажимать на кнопки прибора, не включенного в сеть... Так вот, состояние Static powerdown - это такое состояние, из которого нет выхода программным способом (т.е. выключено навсегда). Изменить это можно только изменив условия начальной инициализации процессора. Но! McBSP0 - согласно таблице - не может находится в этом состоянии. McBSP1 - может! По крайней мере - согласно документации. В этом и вопрос. Что загонятет McBSP0 в состояние Static powerdown... И да - я писал об этом - попытки манипулирования с регистром управления SPCR0 привели к сожалению к ожидаемому результату (в свете того, что McBSP выключен) - т.е. регистр просто недоступен для записи... Ничего в него не пишется..

Как дополнение - не заведены (сидят на земле) следующие цепи питания: 1. DV DDR (1.8-V I/O supply voltage (SRIO regulator supply). NOTE: If Rapid I/O is not used, this pin can be connected directly to VSS) 2. DV DDRM (SRIO interface supply: 1.25-V core supply voltage (-1000 and -1200 devices) DVDDRM S 1.2-V core supply voltage (-850 devices). V17 The source for this supply voltage must be the same as that of CVDD. NOTE: If RapidIO is not used, these pins can be connected directly to VSS) 3. DV DD12 (Main SRIO supply: 1.25-V I/O supply voltage (-1000 and -1200 devices) DVDD12 S 1.2-V I/O supply voltage (-850 devices). W18 Do not use core supply. NOTE: If RapidIO is not used, these pins can be connected directly to VSS) 4. DV DD15 ( RGMII / EMAC ) 5. AV DDA (SRIO analog supply NOTE: If Rapid I/O is not used, these pins can be connected directly to VSS) 6. AV DDT (SRIO termination supply. NOTE: If RapidIO is not used, these pins can be connected directly to VSS) 7. VREF HSTL ( RGMII / EMAC )

Добрый всем день! Столкнулся тут с неожиданной для себя проблемой - не могу запустить McBSP0 на процессоре С6455. Ситуация: имеем работающий C6455 (EMIF, DDRAM, EMAC - то, что сконфигурировано и давно пашет). Появилась необходимость пользовать последовательный канал. Изначально McBSP1 выключен как класс (AEA5 задавлен при инициализации проца) и не планировался к использованию. В отличие от McBSP0, на который планы были. И вот теперь, когда до McBSP0 дошли руки - выяснилось, что он не запускается. Во-первых, до установки соответствующего бита в PERCFG0 состояние модуля MCBSP0 - Static Powerdown (троечка в PERSTAT0). Это же состояние и у McBSP1 - что логично исходя из вышесказанного. Но у McBSP0 не должно быть по определению состояния Static powerdown! Смотрим картинки в приложении - McBSP0 должен быть изначально Disabled. Ну да ладно. Пытаемся включить McBSP0, записав соответствующий битик в PERCFG0. Битик записывается и ... состояние модуля MCBSP0 не меняется (!) - все также Static Powerdown (как я уже писал - троечка в PERSTAT0). К слову - при попытке включить McBSP1 в моей ситуации - соответствующий битик в PERCFG0 не пишется, что и ожидаемо. Танцы с бубнами (попытка снять сбросы в SPCR0) не привели ни к чему - биты банально не записываются - модуль McBSP0 неактивен... По сему есть ряд вопросов. Первый - возможно, мы что-то упустили с питанием и для MсBSP что-то не завели. Но я нигде не нашел указаний, какие цепи питания проца питают McBSP. В частности, не были заведены цепи питания для SRIO ввиду отсутствия необходимости в этом интерфейсе и желания снизить энергопотребление. Но вроде это другой модуль, не связанный с McBSPx. Возможно, что-то с цепями синхронизации (кто-то не сконфигурировано), но в примерах для McBSP ничего такого специализированного отмечено не было.. В общем - очень хотелось бы помощи, бо мысли (разумные) у нас кончились.

О! Тогда такой вопрос: что проще? Поднять стек на FPGA (у нас на плате 3-ий циклон стоит полупустой) или морочить голову с NDK и поднимать на С6455?

Ну, "сами наваяете" есть, используем.. Но не хочется ошибиться (ну - чтоб не получилось, что схема правильная, а вот какие-то битики просто описаны не так - и не работает ничего :( )... Софт из NDK брали? Я в плате - PHY там любой подойдет? Я просто в разновидностях PHY не рублю совсем. На сколько они взаимозаменяемы? Особенно - с точки зрения стандартного софта. Совершенно не хочется тратить время на адаптацию NDK под какой-то особенный тип PHY. При этом заказчику позарез надо 100/1000 (при том, что его оборудование точна 10/100 и в ближайшие -надцыть лет меняться не будет.. :( )

Добрый всем день! Имеем вот девайс (который год работающий) на C6455. А тут приплыло, что надо срочно к нему Ethernet прикрутить. Потому - если есть какие-то наметки - накидайте сюда ссылок. Поисковиком уже побегал. И вот, например, CSL6455 найти не смог (на сайте TI она значится как "not available"). Скачал схемку кита с Intel LXT971 (10/100), но хотелось бы 100/1000. Скачал NDK 2.25 с описаниями (523/524). В общем - буду рад, если и опытом поделитесь, как стек проще в своё приложение прикрутить (приложение пока живет вне RTOS). Спасибо заранее!

По поводу HOLD - des00 уже отписался по поводу примеров с сайта альтеры.. Ну что ж - опыт есть опыт.. По мне было бы логичным HOLD оставлять внутри, но авторитет сайта для меня был высок и стиль я поменял. Будем отыгрывать назад. По поводу перечня в списке чувствительности - тот же квартус жутко ругается на сигналы, используемые внутри и не включенные в список - на это просто не обращать внимание?

А где тут кнопочка "Спасибо"?

Как правило, ПЛИС в своих проектах я использую в качестве интерфесных элементов с внутренним интеллектом. Зачастую, создание модели внешних воздействий для работы с симулятором требует значительного времени. Да, я понимаю важность симулирования, поверьте. Но когда времени на это нет, то симулятор первым вылетает из графика работ. По поводу не очень уверенного знания языка. Когда-то меня зазвали в одну контору (пригласили на собеседование). Почитали резюме и стали тестировать мои знания С++. На котором я к тому времени писал уже лет 10.. В общем - мне сказали, что академических знаний у меня меньше, чем у студента. И что вероятнее всего (они так думали) резюме мое - выдуманное. Так вот - скажу вам по правде. Академизм знаний и понимание предмета - очень разные вещи. Первое без второго куда хуже, чем второе без первого. Но - если что - я стараюсь учиться. Если этого требует дело. Даже не знаю, что вам ответить. Как я до сих пор жил, не зная этого? Когда-то давно, в прошлой или позапрошлой жизни меня убеждали, что для разработки своей ОС нужно провести НИР, ОКР. Что нужны специалисты.. А еще - требовалось, чтобы ОС была написана с использованием новейшей разработки в области проектирования - R-технологии. До главного инженера завода диспут дошел. Хорошо, что он (главный) их не послушал :) Но вы не сомневайтесь - таки да, к осциллографу даже не стоит приближаться, если вы не просимулировали вашу схему. И - спасибо за советы. Наверное - надо извиниться за то, что не удержался и все же ответил. Удачи вам. Сигналтап - это кто? ПОнимаю, что вопрос глупый, но все же... Я разделял строчку сравнений на 4, впоследствии их соединяя по "И". Результат не изменялся. Правда, я надеялся упростить себе задачу в воссоздании функции, генерируемой синтезатором (и все же я грешу не на него, а на оптимизатор) - но не удалось. Все в итоге опять же смешивалось. По симметричности ключей - на самом деле я стремился изменить соотношение 0 и 1 в ключах. Если в сумме по первым было 10 к 6, то во вторых - 9 к 7. И все. Но по каким-то причинам этого хватило. Стыдно признаться, но я бросил изучать проблему, найдя далеко неоднозначное решение (мне оно непонятно). Может, через месяцок я к ней вернусь (когда времени станет больше). Очень странное проявление. Еще добавлю - если вы не забыли - код изначально работал, но при проверке последнего байта полностью!!! Т.е. при проверке 8 бит, 7, 6 последних - все работало как часы. Но стоило в сравнение включить первый бит при неполном байте - и все сыпалось... Даже если я заменял std_logic на bit...

А можно тут "разжевать"? Вроде как HOLD - это Enable триггера, а клок как раз WE синхронный (если че, он ругается на асинхронные клоки безбожно). Ну и установочный вход триггера - RESET. По моему - все честно. Кстати - я раньше "Enable" ставил внутрь клока - но на сайте альтеры увидел классический пример описания триггера и там Enable был именно так использован.

Это - намек на порядочность писателя кода? ;) А если серьезно, то 1. Перед тем, как сюда вопрос выложить, я постарался локализировать максимально проблему. Выложить весь код? Какую-то его часть? Что именно интересует? 2. Если бы проблема была в коде, то КАК может изменение ключа (2-х констант) повлиять на функционирование кода (созданного "порядочным синтезатором")? 3. Это, кстати, второй глюк, который я обнаружил у данной версии синтезатора. Так что - не все так однозначно у синтезаторов ((С) Жена синтезатора :)) ПыСы. Приведу итоговую коррекцию, приведшую к работе кода: Было constant A_BYTE_KEY : std_logic_vector (7 downto 0) := X"7E"; constant B_BYTE_KEY : std_logic_vector (7 downto 0) := X"5A"; Стало constant A_BYTE_KEY : std_logic_vector (7 downto 0) := X"B2"; constant B_BYTE_KEY : std_logic_vector (7 downto 0) := X"97"; Константы используются только в указанном выражении срванения. Выражение сравнения было возвращено в исходное (первоначальное) состояние: got_It <= '1' when xHeader(4) = A_BYTE_KEY and xHeader(3) = B_BYTE_KEY and xHeader (2) = (not xHeader(1)) and xHeader(0)(7 downto 2) = "000000" else '0'; Для любителей - код элемента, выделяющего ключ, приведен ниже полностью library ieee; use ieee.std_logic_1164.all; use IEEE.numeric_std.all; entity HEADER_CATCHER is port ( RESET, WE, HOLD : in std_logic; DATA : in std_logic_vector (7 downto 0); FindHeader, EndMessage, EndMessageCRC, Error : out std_logic ); end entity; architecture pll_type of HEADER_CATCHER is type t_xHeader is array (0 to 4) of std_logic_vector (7 downto 0); signal xHeader : t_xHeader; signal got_It, end_main, end_with_crc : std_logic; signal msg_len, bytes_got : unsigned (9 downto 0); signal crc1, crc2 : std_logic_vector (7 downto 0); signal slc_len : std_logic_vector (9 downto 0); constant A_BYTE_KEY : std_logic_vector (7 downto 0) := X"B2"; constant B_BYTE_KEY : std_logic_vector (7 downto 0) := X"97"; constant CRC_MASK : std_logic_vector (7 downto 0) := X"3C"; begin got_It <= '1' when xHeader(4) = A_BYTE_KEY and xHeader(3) = B_BYTE_KEY and xHeader (2) = (not xHeader(1)) and xHeader(0)(7 downto 2) = "000000" else '0'; slc_len <= xHeader(0)(1 downto 0) & xHeader(1); msg_len <= unsigned (slc_len); end_main <= '1' when msg_len = bytes_got else '0'; end_with_crc <= '1' when (msg_len+1) = bytes_got else '0'; FindHeader <= got_It; EndMessage <= end_main; EndMessageCRC <= end_with_crc; Error <= '0' when crc2 = X"00" else '1'; process (RESET, HOLD, WE) begin if RESET = '1' then bytes_got <= (others=>'0'); elsif WE = '1' and WE'event then if HOLD = '1' then bytes_got <= bytes_got + 1; else bytes_got <= (others=>'0'); end if; end if; end process; process (RESET, HOLD, WE) begin if RESET = '1' then crc1 <= (others=>'0'); elsif WE = '1' and WE'event then if HOLD = '1' then crc1 <= crc2 xor DATA xor CRC_MASK; else crc1 <= (others=>'0'); end if; end if; end process; process (RESET, HOLD, WE) begin if RESET = '1' then crc2 <= (others=>'0'); elsif WE = '0' and WE'event then if HOLD = '1' then crc2 <= crc1(6 downto 0) & crc1(7); else crc2 <= (others=>'0'); end if; end if; end process; process (RESET, HOLD, WE) begin if RESET = '1' then for I in xHeader'range loop xHeader(I) <= (others=>'0'); end loop; elsif HOLD = '0' then if WE = '1' and WE'event then xHeader(0) <= DATA; xHeader(1) <= xHeader(0); xHeader(2) <= xHeader(1); xHeader(3) <= xHeader(2); xHeader(4) <= xHeader(3); end if; end if; end process; end pll_type;

А есть какой-то способ автоматизированный собрать реальную функцию сигналов в маппере? Там 3 страницы - и сигналы бегают туда-сюда.. Смерть... Пытался разбить выражение на составные части в надежде вытащить по каждому сравнению.. Но внутренние сигналы даже не проявились в маппере.. Может - есть какие-то технологические секреты/советы? Чуть позже -------------------------------------------------------------------- Пытаясь воссоздать функцию поиска ключа, бегал по схеме. Одно из выражений вызвало недоумение. Вместо того, чтобы сравнивать два разряда один с нулем, другой с единицей, схема сравнивала их между собой и ждала равенства! При том, что в далнейшем это равенство не инвертировалось. Закралось подозрение в глюке. Решил попробовать изменить значения ключей. И - о чудо - все заработало.. Увы, это конечно не объективное решение.. А скорее - уход от проблемы. Просто сегодня уже не было сил дальше воссоздавать функцию.. А "решение" нашлось.. Спасибо всем огромное! des00 - особенно - вы для меня открыли еще один инструмент

Эх, если бы еще уметь это делать... Меня максимум хватало на RTL-viewer. Но там я ничего крамольного не увидел. Пытался обмануть. Сделал массив 9-разрядным.. Хе-хе.. Оптимизатор мне сказал, что ай-яй-яй и убил 52 неиспользуемых регистра

Столкнулся с очень странной проблемой. Задача - принимается массив байт и ищется ключ. Ключ простой. Байты запихиваются в массив type t_xHeader is array (0 to 4) of std_logic_vector (7 downto 0); signal xHeader : t_xHeader; В процессе приема этот массив со сдивгом переписывается xHeader(0) <= DATA; xHeader(1) <= xHeader(0); xHeader(2) <= xHeader(1); xHeader(3) <= xHeader(2); xHeader(4) <= xHeader(3); (привожу все элементы кода, т.к. проявление уж больно странное) А вот теперь самое интересное. В момент совпадения в последнем (а он, как видно из кода, имеет индекс 0) слове старшие 6 бит обязательно должны быть равны 0. Вырабатываем сигнал, означающий, что заголовок найден got_It <= '1' when xHeader(4) = A_BYTE_KEY and xHeader(3) = B_BYTE_KEY and xHeader (2) = not xHeader(1) and xHeader(0)(7 downto 2) = "000000" else '0'; И - не работает. Не работает на осциллографе (вживую). Самое интересное, что в тестовом примере этот злополучный байт весь равен 0 (частный случай). Методом перебора было выяснено, что работает(!) вот такое выражение (проверяется не часть байта, а весь!): got_It <= '1' when xHeader(4) = A_BYTE_KEY and xHeader(3) = B_BYTE_KEY and xHeader (2) = not xHeader(1) and xHeader(0) = "00000000" else '0'; А еще - работает в таком виде (проверяется не старшие 6 бит, а средние или младшие) got_It <= '1' when xHeader(4) = A_BYTE_KEY and xHeader(3) = B_BYTE_KEY and xHeader (2) = not xHeader(1) and xHeader(0)(6 downto 1) = "000000" else '0'; Запись производится по сигналу длительностью 1 микросекунда. Тактовая - 2 МГц. Запись производится примерно каждые 64 микросекунды. Т.е. по времени запас огромный. В момент записи данные не меняются (строб чтения отстоит от строба записи на 2 такта, т.е. на 1 микросекунду) Проект - для третьего циклона. Сигнал сравнения выведен наружу безо всякого стробирования. Проект обрезан до безобразия (в процессе поиска) и занимает 2% от ПЛИС. Вот такие дела.. Пока не знаю, как выйти из ситуации. Сравнивать на байт - неверно по определению. Да и непонятно, почему не работает! Пока писал - придумал еще пару экспериментов . Не работает так: got_It <= '1' when xHeader(4) = A_BYTE_KEY and xHeader(3) = B_BYTE_KEY and xHeader (2) = not xHeader(1) and xHeader(0)(6 downto 2) = "00000" and xHeader(0)(7) = '0' else '0'; И вот так тоже - не работает (ну в общем-то - и не должно было) got_It <= '1' when xHeader(4) = A_BYTE_KEY and xHeader(3) = B_BYTE_KEY and xHeader (2) = not xHeader(1) and xHeader(0)(6 downto 2) = "00000" and xHeader(0)(7) = '1' else '0'; ПыСы: это я пробовал раздельно проверять старший бит: он должен был быть равен 0; замечу, что если убрать проверку бита 7 и проверять только 5 бит с 6-го по 2-ой, то все работает...

Проблема (как я ее себе вижу) не в приборе или его управляемости. RS-232 пропускает команды в чистом виде. И - наверняка, они будут работать. У меня же - USB. Что там стоит в качестве моста - неизвестно. Вот, кстати, попробую задать вопрос производителям. Если, например, стоит что-то типа EHCI - то там перед началом работы надо мост сконфигурировать.. Кстати - тот же HID (CP210x) требует конфигурирования. Вот и вопрос. Надо что-то сказать пакетом control? Или - все же я что-то не так делаю.. Пока - в раздумье. Щас буду писать письмо авторам вольтметра. Добавлено позжее.. Ага. А вот и информация к раздумью. У вольтметра в качестве USB стоит некий USBTMC. Появилось новое ключевое слово для поиска... Добавлено еще позжее... А вот и первый интересный пример для изучения.. USBTMC & USBLIB Ушел в процесс изучения...

Наверное. Думаю - все даже будет работать. И что это даст? USB-сниффера у меня нет...

Добрый всем день! Значит так, все по порядку. В качестве хоста имеем: процессор AR9331 c с подключенным к нему USB-хабом на 4 входа от TI (TUSB2044). На хосте установлена OpenWRT с поддержкой LIBUSB (на ней и пишется управление устройствами USB). С другой стороны - вольтметр В7-78/1 с USB управлением с поддержкой SCPI (текстовый протокол). При подключении к хабу устройство уверенно появляется в списке (наше устройство - 164e:0dad): Bus 001 Device 002: ID 0451:2046 Texas Instruments, Inc. TUSB2046 Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 005: ID 164e:0dad Bus 001 Device 003: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC У устройства - один интерфейс и 3 end-point: root@BlackSwift:/new_project# lsusb -s 001:005 -v Bus 001 Device 005: ID 164e:0dad Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 16 idVendor 0x164e idProduct 0x0dad bcdDevice 1.00 iManufacturer 2 PICOTEST CORP iProduct 3 Voltmeter V7-78/1 iSerial 1 TW00024605 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 39 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x60 (Missing must-be-set bit!) Self Powered Remote Wakeup MaxPower 2mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 254 Application Specific Interface bInterfaceSubClass 3 Test and Measurement bInterfaceProtocol 1 TMC iInterface 4 (error) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0010 1x 16 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Device Status: 0x0001 Self Powered Далее - привожу последовательность (условную, ибо команды разбросаны по классу управления) открытия устройства: libusb_init libusb_set_debug libusb_get_device_list/libusb_open_device_with_vid_pid libusb_set_configuration - добавлено от безысходности в поиске проблем libusb_claim_interface / 0 в качестве подтверждения, что устройство открыто - еще пара команд от безысходности libusb_get_string_descriptor_ascii (dev, 2, manufacturer, 256); libusb_get_string_descriptor_ascii (dev, 3, product, 256); Ну и под конец libusb_bulk_transfer (dev, snd_t->endpoint, buff, buff_size, &actual, 10000); // endpoint - 0x02 Команды передавались разные SYSTEM:BEEPER\n READ?\n DISPLAY:TEXT \'ABCD\'\n В качестве buff_size использовалась длина команды, длина буфера bulk (64), снова - длина команды с добавлением еще одного libusb_bulk_transfer с длиной 0. Все команды (в том числе - и libusb_bulk_transfer) заканчивались без ошибок. Actual содержала правильное количество переданных байт. Но! Никакой реакции со стороны вольтметра.. Увы. Возможно - надо как-то что-то предварительно конфигурировать. чтобы вольтметр услышал мой голос :) Не знаю. Очень рассчитываю на помощь клуба. В расстерянности и с уважением...

В общем, как я понял, пора смотреть глубже.. Пошел я форматы файлов изучать. Хотя - была надежда на стандартное решение. Спасибо! Если что сделаю (завтра) - выложу.