[zvs 0]

2 jur: Спасибо, я уже разобрался.

У меня ПЛИС и дескриптор просто хранится в ROM. Так вот глюк был связан с тем, что в дескрипторе было одно "лишнее" значение (в файле инициализации ROM был пропущен один адрес).

Теперь все в норме.

[zvs 0]

Проблемы продолжаются :angry2:

Установил ЕР6 как изохронную. По этому поводу программа A_d_v_a_n_c_e_d U_S_B P_o_r_t M_o_n_i_t_o_r сообщает следующее: (кстати, болеет программка. Ни у кого микстуры нету?)

    Endpoint descriptor 
      Endpoint address:  0x86, Input
      Transfer type:  Isochronous
      Synchronization type:  none - вот эта строчка меня тихо смущает... :(
      Usage type:  data endpoint
      Max packet size:  0x0200 (512)
      Interval:  0x00 (0)

 

Теперь о главном. Пытаюсь читать из этой ЕР...

Данные в FIFO сыпятся когда только можно (то есть если FIFO заполнилось, то прекращаю сыпаться. Как только оно не пустое - пишем снова).

FIFO забивается целиком (то есть все 1024 байта) за 1,825 мс.

Почитал CyAPI Programmer's Reference. Согласно ему

For ISOC transfers, the buffer length and the endpoint's transfers size (see SetXferSize) must be a multiple of 8 times the endpoint's MaxPktSize

То бишь размер буфера на прием должен быть равен восьми размерам пакета. Причем поскольку EP изохронная не обязательно что все пакеты будут приняты. Вот мой кусочек проги, которым осуществляется чтение данных в ПК. Прием данных осуществляется в отдельном потоке. Оставил только все самое ценное...

    CCyIsocEndPoint *IsoIn = USBDevice->IsocInEndPt;
    if(IsoIn)
    {
        long i_count = 4096; //количество принимаемых байт
        UCHAR buf[4096]={0}; //буфер для приема

        long recvdBytes; //реальное количество принятых байт

        CFile f;
        f.Open("ADC_contents.i16",CFile::modeCreate|CFile::modeWrite); //принятые данные пишутся в файл
        
        for(int addr=0; addr<100; addr++) // больше сотни раз не принимать
        {
            i_count = 4096;
            CCyIsoPktInfo *isoPktInfos; 
            int pkts;  
            isoPktInfos = IsoIn->CreatePktInfos(i_count, pkts); 
            if(!(IsoIn->XferData(buf,i_count,isoPktInfos))
            {
            //обработчик ошибки, когда невозможно принять данные от USB
            }
            else
            {
                recvdBytes = 0; 
                for (int i=0; i<pkts; i++)
                {
                    if (isoPktInfos[i].Status == 0)
                    {
                        recvdBytes += isoPktInfos[i].Length; 
                    }
                }
                                                f.Write(buf,recvdBytes);
                delete[]isoPktInfos;
            }
        }
        f.Close();
    }
    return(0);

Собственно в чем проблема:

Согласно тому же ЮСБ Порт Монитору из 4к данных при каждой попытке принимается только 2к :(

Но самое жуткое, что период между двумя "приемами" составляет порядка секунды :angry2:

 [21] URB_FUNCTION_ISOCH_TRANSFER 20070317163800.578 (+0)
Pipe handle: 0x84C999CC
Transfer flags: 0x00000007 (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK)
[21] URB_FUNCTION_ISOCH_TRANSFER (SUCCESS/0x00000000) 20070317163801.421 (+843)
IRP status: 0x00000000 (STATUS_SUCCESS)

 

Ну какой он после это Isochronous? У меня Bulk передавал быстрее :(

Никто с подобным не сталкивался?

[zvs 0]

Вернулся обратно к булкам.

При увеличении буфера према в программе на ПК до 8192 байт, т.е. грубо говоря

USBDevice->EndPoints[3]->XferData(buf[8192],8192)

добился скорости в 7,5Мб/сек. Дальнейшее увеличение размера буфера прибавки в скорости не дает.

 

Ну что ж, будем жить так...

[jur 0]

      Synchronization type:  none - вот эта строчка меня тихо смущает... :(

По всей видимости, Монитор имеет ввиду, что изохронная передача не использует квитирования.

 

Собственно в чем проблема:

Согласно тому же ЮСБ Порт Монитору из 4к данных при каждой попытке принимается только 2к :(

Но самое жуткое, что период между двумя "приемами" составляет порядка секунды

К сожалению, с изохронами я не работал, ничего толкового подсказать не могу...

 

Вернулся обратно к булкам.

При увеличении буфера према в программе на ПК до 8192 байт, т.е. грубо говоря

USBDevice->EndPoints[3]->XferData(buf[8192],8192)

добился скорости в 7,5Мб/сек. Дальнейшее увеличение размера буфера прибавки в скорости не дает.

Ну что ж, будем жить так...

Странно... Булка стабильно качает под 40 МБ/сек. Я проверял даже на слабых embedded-материнках. Думаю, что стоило бы попробовать передавать не с помощью синхронной XferData, а с помощью асинхронной связки BeginDataXfer-WaitForXfer-FinishDataXfer. Дело в том, что эта троица позволяет здорово распараллеливать процесс передачи данных, поэтому получается наивысшая возможная скорость передачи (я использую очередь из 4-х запросов, как в сайпрессовском примере Strimmer). А простая XferData - синхронная передача. Пока одну передачу не завершит новую не начнет. Наверное именно в этом проблема.

[vhlshik 0]

скиньте плз у кого есть содержание eepromины с дескрипторами (не дефолтовыми). Я по образу и подобию приведенного в датащите написал свой, но винда ругается и говорит, что устройство failed enumeration

[vhlshik 0]

пардон, дефолтовая енумерация тож не проходит, хотя сайпрес пзуху читает - видно на осциллографе, после чтения подтягивает D+ - и все!

вот то что я гружу

c4 0a 00 c4 06 00 33 33 20 02 10 11 (все ID "от фонаря")

что бы это могло быть?

[jur 0]

вот то что я гружу

c4 0a 00 c4 06 00 33 33 20 02 10 11 (все ID "от фонаря")

что бы это могло быть?

Может стоит попробовать реальные ID? Их можно взять из INF файла USB-шного драйвера (VID и PID).

[Warlord 0]

Какие грузить VID и PID - это все равно, проблема еще в чем-то. Попробуй микросовтовскую утилиту USBView или USB Monitor, глянь ходит ли там ваще чего-нибудь.

[vhlshik 0]

докладываю :)

USBView - все в нулях, похоже обмена по юсб нет ваще. для чистоты эксперимента подтянул к 3.3 SLRD,SLWR,SLOE,RST так что при енумерации ниче не должно мешать. кварц вроде тож завелся. чудеса какие-то

[Warlord 0]

Если по нулям, то может камню не нравится содержимое пзухи или он не может ее прочитать, хотя делает попытки... А почему первый байт 0xC4??

During the power-up sequence, internal logic checks the I2C

port for the connection of an EEPROM whose first byte is

either 0xC0 or 0xC2.

[vhlshik 0]

странно, у меня в описании написано

During the power-up sequence, internal logic of the SX2 checks for the presence of an I2C EEPROM.[1,2] If it finds an EEPROM,

it will boot off the EEPROM. When the presence of an EEPROM is detected, the SX2 checks the value of first byte. If the first

byte is found to be a 0xC4, the SX2 loads the next two bytes into the IFCONFIG and POLAR registers, respectively. и т.д.

у меня cy7c68001.pdf revision D. ща скачаю более новый

[Warlord 0]

прости, я про fx2... но не суть важно, убедись, что камень считывает ПЗУху, т.е. достает информацию. А то может он стучит, а достучаться не может.. В мануале сказано, что если нет памяти внешней никакой, то камень грузит инфу по умолчанию, так вот я проверил, что если выдернуть ПЗУху, то камень молчит как партизан, виндофс говорит, что устройство неправильно пронумеровано, а USBView соотвесно дает нули.. почему камень не энумеруется, вот вопрос..

[vhlshik 0]

у меня без пзу D+ висит в воздухе. так что, по крайней мере, первые два байта читаются :). Ладно, буду искать аппаратные глюки

[vhlshik 0]

дас, все прозаично :glare:

на плате были перептаны местами D+ и D-...

[zvs 0]

Странно... Булка стабильно качает под 40 МБ/сек. Я проверял даже на слабых embedded-материнках. Думаю, что стоило бы попробовать передавать не с помощью синхронной XferData, а с помощью асинхронной связки BeginDataXfer-WaitForXfer-FinishDataXfer. Дело в том, что эта троица позволяет здорово распараллеливать процесс передачи данных, поэтому получается наивысшая возможная скорость передачи (я использую очередь из 4-х запросов, как в сайпрессовском примере Strimmer). А простая XferData - синхронная передача. Пока одну передачу не завершит новую не начнет. Наверное именно в этом проблема.

 

Переделал программу под BeginDataXfer-WaitForXfer-FinishDataXfer. Ничего не изменилось. Все те же 7.5 Мбайт/сек.

Данные запихиваются в SX2 через каждые три такта 20 мегагерцового клока. Используется асинхронный интерфейс с SX2.

То бишь в контроллер я засовываю данные со скоростью 13 Мбайт в секунду, а с другой стороны (в ПК) получаю их в два раза медленнее :(.

 

2 jur:

1. Вы с SX2 работаете синхронно или асинхронно?

2. Дескриптор тот что по умолчанию или свой?

3. Какие-то настройки в регистрах делаете?

4. Когда принимаете большой массив (например 100 мегабайт) связкой BeginDataXfer-WaitForXfer-FinishDataXfer какой выставляете размер буфера на прием?

Заранее спасибо за ответы!