niktagor

Продаю портативный спектроанализатор Signal Hound USB-SA44B в хорошем состоянии. Куплен в 2012 году, с 2013 года не использовался. Цена - 40000р. Готов привести в вашу лабораторию для тестирования. Тел.: +79165451679 e-mail: [email protected] Андрей

Так ведь в дэйташите и SOIC есть и MSOP, причем для SOIC указан суффикс R, а для MSOP - RM. Я правильно понял, что информация в терраэлектронике по этой микросхеме сама себе противоречит?

soic8 и uMAX8 - это одно и то же? Никак не разберусь. Вот тут, в терраэлектронике есть операционник http://www.terraelectronica.ru/catalog.php...e=2&PageS=1 У него четко написано в дэйташите, что суффикс AR - это SOIC. А в каталоге он идет как uMAX8 Вот тут с ним такая же путаница http://www.mitracon.ru/info/search.php?all...amp;x=0&y=0 Я думал, что uMAX8 - это MSOP... Объясните пожалуйста идиоту, что это все значит!

Почему? Мне не понятно. Он один байт всего содержит. И я посылаю массив запросов на 4097 байт. Там нет назначений битов. Просто байт запроса данных. Все конфигурирование типа установки скорости датчика происходит заранее, с помощью других команд. Размеры некоторых больше одного байта. Можно ли в этом случае делать MaxPktSize=1? Я правильно понимаю, что в устройстве буфер 64 байта и он его весь забивает нулями, когда я посылаю команду с MaxPktSize = 64, а мы пытаемся поместить в него несколько команд? Сейчас с таким работает: 0)BeginDataXfer() c "CYUSB_IN" на прием 4097 байт while(i<1000) { 1) BeginDataXfer() c "CYUSB_IN" на прием 4097 байт 2) XferData() для "CYUSB_OUT" 3) WaitForXfer() и FinishDataXfer() для "CYUSB_IN" i++ } 5)WaitForXfer() и FinishDataXfer() для "CYUSB_IN" Причем WaitForXfer вызывается для того запроса, который был послан раньше. Массив запросов ни в ту ни в другую сторону он не хочет воспринимать. XferData() выполняется совсем быстро (5мкс), поэтому делаю синхронно.

Изготовитель предоставляет программатор с одной кнопочкой "зашить", и прошивки раньше тоже были доступны. Скачивать он не умеет. Новую прошивку, которая у меня, не дают. Строку поменял, все нормально переконфигурировалось. Определяется как interrupt. Массив запросов с CYUSB_OUT он не хочет воспринимать. То есть сколько бы я ему их не посылал, после срабатывания "CYUSB_IN", он информацию перестает выдавать. Скорее всего, такой код. Зато с ситуации 2.1мс+- 0.1мс все изменилось на очень стабильные 2мс +- 0.001мс. И это очень радует. У родной программы было хуже(2.5мс +- 0.5мс и иногда несколько отсчетов выпадало вообще), так что работа не впустую проделана. Не радует вот что. У датчика время измерения можно менять. 1мс - это я писал самое минимальное, т.к. только в этом режиме будем работать с прибором. Так вот,со старой конфигурацией время цикла было примерно равно времени измерения + 1мс. А теперь оно равно t измерения для t>2мс. А при t<2мс оно все равно равно 2мс. То есть получается, что прибор умеет параллельно передавать данные и делать измерение, но это только для t>2мс. А в моем случае, при t=1мс, он намеренно ждет. Такой я могу сделать вывод. И скорее всего, выход один - копать ассемблерный код... :crying:

Проверил. Не соответствует. Самый первый байт - 0xС2. Потом идут судя по всему какие-то данные, совсем не то, что написано в мануале. Начиная с адреса примерно 0x2200 идет то, что должно быть с 0x01 (VID,PID...). Чуть подальше, с 0x2290 идет такая последовательность байт: 07 05 01 02 00 02 00 07 05 82 02 00 02 00 07 05 86 02 00 02 00 07 05 81 02 00 02 00 09 02 2E 00 01 01 00 80 32 09 04 00 00 04 FF 00 00 00 07 05 01 02 40 00 00 07 05 82 02 40 00 00 07 05 86 02 40 00 00 07 05 81 02 40 00 00 То есть что-то типа двух разных конфигураций эндпоинтов. Менять только самую первую? Это не повлияет на работу алгоритма считывания данных с прибора? Завершающая последовательность встречается только один раз, в конце файла. Самое забавное - то, что я считал всякие данные с адресов 0x4000 - 0x43FF, хотя в мануале написано: Считываю 0xE000 - 0xEFFF, там совсем пусто. Чудеса!!! Так ведь я ж не стал сначала проверять. Я сразу давай загружать прошивку обратно, чтобы проверить возможность совершения этого действия. И вот парадокс - работает! Причем при изменении чего-нибудь, работать перестает. То есть оно реально загружает то, что я ему подсовываю. Как Вы определили? У меня TRM на них один и тот же, и про EEPROM там для них одинаково написано.

Все сходится. Файл 17КБ. В начале - 0xC2. В конце - 0x80 0x01 0xE6 0x00 0x00. Дизассемблировал программку с помощью IDA Pro (сказал ему, что это Intel 8051). Зацепился нормально, выделил процедурки. Но найти, где эндпоинты конфигурируются, пока не получилось. Сижу, пыхчу.

Сегодня хотел попробовать загрузить обратно данные, которые скачал из EEPROM. Но теперь уже сомневаюсь в соответствии скачанного с реальным. Хотя ведь возможно такое, что чип по мере надобности подгружает себе программу из EEPROM в память, если это реализовано программно? В дэйташите не нашел, что объем внешней EEPROM чем-то ограничен. Скорее всего, он ограничен только максимальным размером адреса в чипе. А он обычно 2^8n, то есть не 16КБ.

EEPROM скачал успешно! Всего 17КБ вышло. Глянул в hex-редакторе, вроде все по-честному. Какой посоветуете дизассемблер? К сайпрессовскому девайсу подойдет любой для 8051? Пытался открыть Keil-ом, он выдает "error 59: invalid absolute module". Сшивал 5 кусочков по 4КБ в hex-редакторе, проверял, все правильно сшито. Может нужно в конец или в начало файла что-нибудь дописать?

Konst_777, большое спасибо. Пробовать буду завтра или послезавтра.

Konst_777, прошу прощения за невнимательность. Объём не ограничен. То есть в описанном режиме я могу накапливать данные например сутки, а потом еще неделю их анализировать. Это не критично. Если не буду успевать записывать на диск - можно например снимать данные 5 секунд, потом прерываться на запись и продолжать дальше. Пока не знаю, как это сделать. Боюсь что-нибудь испортить. Есть простой безопасный алгоритм? Какую программу нужно использовать? В USB-командах есть: -READ EEPROM -PSOC READ -READ REGISTER Соответственно, эти комплектующие есть внутри. Еще в документе упоминается, что внутри есть FPGA. Разбирать прибор нельзя. Картина пока что не сложилась.

Мой запрос содержит всего один байт. Или в этот буфер идут все запросы, в том числе "CYUSB_IN"? И они каждый по 64 байта? Не нашел, как сделать массив запросов в CyAPI Programmer's Reference. Есть другие документы по CyAPI? Что-то я не понял, зачем XferData? Разве WaitForXfer() не записывает в нужный буфер принятую информацию? В примерах исползуется только BeginDataXfer-WaitForXfer-FinishDataXfer. Реализовал такой алгоритм: 1) 9 запросов BeginDataXfer() c "CYUSB_IN" 2) запрос BeginDataXfer() c "CYUSB_OUT" 3) WaitForXfer() для "CYUSB_OUT" 4) 9 раз WaitForXfer() для "CYUSB_IN" 5) 10 раз FinishDataXfer() Лог: 0.000001 Timer test dt = 0.001 ms 0.000040 Timer test dt = 0.039 ms 0.000047 Timer test dt = 0.007 ms 0.000054 Timer test dt = 0.007 ms 0.000061 Timer test dt = 0.007 ms 0.000067 Timer test dt = 0.007 ms 0.000074 Timer test dt = 0.007 ms 0.000081 Timer test dt = 0.007 ms 0.000195 BeginDataXferIn dt = 0.114 ms 0.000230 BeginDataXferIn dt = 0.035 ms 0.000260 BeginDataXferIn dt = 0.030 ms 0.000290 BeginDataXferIn dt = 0.030 ms 0.000321 BeginDataXferIn dt = 0.031 ms 0.000351 BeginDataXferIn dt = 0.031 ms 0.000387 BeginDataXferIn dt = 0.036 ms 0.000419 BeginDataXferIn dt = 0.031 ms 0.000449 BeginDataXferInSync dt = 0.030 ms 0.000487 BeginDataXferOut dt = 0.038 ms 0.000497 WaitForXferOut dt = 0.010 ms 0.001406 WaitForXferIn dt = 0.909 ms \\Тут прибор снимал данные с датчика 0.001444 WaitForXferIn dt = 0.038 ms 0.001464 WaitForXferIn dt = 0.020 ms 0.001562 WaitForXferIn dt = 0.098 ms 0.001682 WaitForXferIn dt = 0.121 ms 0.001818 WaitForXferIn dt = 0.136 ms 0.001931 WaitForXferIn dt = 0.112 ms 0.002061 WaitForXferIn dt = 0.130 ms 0.002193 WaitForXferInSync dt = 0.133 ms 0.002211 FinishDataXferOut dt = 0.017 ms 0.002226 FinishDataXferIn dt = 0.015 ms 0.002234 FinishDataXferIn dt = 0.009 ms 0.002243 FinishDataXferIn dt = 0.008 ms 0.002251 FinishDataXferIn dt = 0.008 ms 0.002259 FinishDataXferIn dt = 0.008 ms 0.002267 FinishDataXferIn dt = 0.008 ms 0.002276 FinishDataXferIn dt = 0.008 ms 0.002284 FinishDataXferIn dt = 0.008 ms 0.002292 FinishDataXferSync dt = 0.008 ms За вычетом времени работы таймера, вся операция в среднем занимает (2,1+-0,1)мс. По задумке разработчиков, все 4Кб должны приниматься за оставшиеся ~100мкс после обработки сигнала датчика. Это равносильно скорости 40МБ/c. Для bulk многовато, но даже если будет 10МБ/c, для моих целей это будет очень значительное улучшение. Анализируя логи, прихожу к выводу, что WaitForXfer() выполняется один раз за микрокадр, но бывают исключительные ситуации, когда случается 2 WaitForXfer() в кадре. Как бы проконтроллировать и улучшить этот показатель?

Да, обрабатывать можно не в реальном времени. Важно обеспечить максимальную скорость снятия данных с датчика. А так как внутри прибора задокументированного буфера нет, приходиться извращаться.

1) Не известно. 2) К сожалению, в реальном времени. Накопить их можно только в компьютере. Можете пояснить, что плохо в этой конфигурации?

Выкладываю всю информацию об эндпоинтах и приступаю к реализации вышеуказанного алгоритма. <DEVICE> FriendlyName="Cypress Generic USB Device" Configurations="1" MaxPacketSize="64" Class="00h" SubClass="00h" Protocol="00h" BcdDevice="00 02" BcdUSB="02 00" <CONFIGURATION> Configuration="0" ConfigurationValue="1" Attributes="80h" Interfaces="1" DescriptorType="2" DescriptorLength="9" TotalLength="46" MaxPower="200" <INTERFACE> Interface="0" InterfaceNumber="0" AltSetting="0" Class="FFh" Subclass="00h" Protocol="0" Endpoints="4" DescriptorType="4" DescriptorLength="9" <ENDPOINT> Type="BULK" Direction="OUT" Address="01h" Attributes="02h" MaxPktSize="512" DescriptorType="5" DescriptorLength="7" Interval="0" </ENDPOINT> <ENDPOINT> Type="BULK" Direction="IN" Address="82h" Attributes="02h" MaxPktSize="512" DescriptorType="5" DescriptorLength="7" Interval="0" </ENDPOINT> <ENDPOINT> Type="BULK" Direction="IN" Address="86h" Attributes="02h" MaxPktSize="512" DescriptorType="5" DescriptorLength="7" Interval="0" </ENDPOINT> <ENDPOINT> Type="BULK" Direction="IN" Address="81h" Attributes="02h" MaxPktSize="512" DescriptorType="5" DescriptorLength="7" Interval="0" </ENDPOINT> </INTERFACE> </CONFIGURATION> </DEVICE> Config Descriptor: bLength: 0x9 bDescriptorType: 2 wTotalLength: 46 (0x2e) bNumInterfaces: 1 bConfigurationValue: 1 iConfiguration: 0 bmAttributes: 0x80 MaxPower: 200 ********************************** Interface Descriptor:1 -------------------------------- bLength: 0x9 bDescriptorType: 4 bInterfaceNumber: 0 bAlternateSetting: 0 bNumEndpoints: 4 bInterfaceClass: 255 bInterfaceSubClass: 0 (0x0) bInterfaceProtocol: 0 (0x0) iInterface: 0 (0x0) ********************************** EndPoint Descriptor: 1 -------------------------------- bLength: 0x7 bDescriptorType: 5 bEndpointAddress: 0x1 bmAttributes: 0x2 wMaxPacketSize: 512 bInterval: 0 ********************************** EndPoint Descriptor: 2 -------------------------------- bLength: 0x7 bDescriptorType: 5 bEndpointAddress: 0x82 bmAttributes: 0x2 wMaxPacketSize: 512 bInterval: 0 ********************************** EndPoint Descriptor: 3 -------------------------------- bLength: 0x7 bDescriptorType: 5 bEndpointAddress: 0x86 bmAttributes: 0x2 wMaxPacketSize: 512 bInterval: 0 ********************************** EndPoint Descriptor: 4 -------------------------------- bLength: 0x7 bDescriptorType: 5 bEndpointAddress: 0x81 bmAttributes: 0x2 wMaxPacketSize: 512 bInterval: 0 **********************************