ahulap

Контроллер - LPC1343. Программа посылает команды в устройство используя libusb: usb_bulk_write(handle, EP_OUT, buffer, size, 0); В устройстве размер команды заренее не известен, оно собирает всю команду и только после этого отдает на обработку. Окончание передачи я определял по короткому пакету (<64 байт). Но, как оказалось, если размер передачи например равен 64 байтам, то приходит только один пакет 64 байта и все. ZLP нет. Возможно ли как-то разрешить данную проблему без доработки компьютерной программы? Только вычислением размера команды по ее коду и прочим параметрам, идущим в первом пакете? Похоже такая же проблема была и с контроллером SAM3U, там прием осуществлялся по DMA и DMA transfer завершался только при приеме короткого пакета. Но там все разрешилось просто переходом на размер эндпоинта в 512 байт (high speed), что было гарантированно больше любой передачи, т.е. все пакеты были короткими. Хочется учесть данную особенность при разработке следующих устройств. Заранее спасибо.

Похоже дело и не в этом. В SAM-BA v2.10\applets\isp-project\flash\main.с я добавил код чтобы зажечь светодиодик на плате. Он не загорелся, так что похоже до загрузки апплета не доходит. А циклы ожидания и все остальное настраиваются как раз в самом апплете.

Проверил на старом компьютере - результата никакого. Дело скорее всего не в этом, т.к. загрузчик опознается и можно залить туда апплет для другого процессора. Работать он конечно не будет, но загрузка проходит. Можно было бы предположить что ошибка в самих апплетах для sam3u, но они же нормально грузятся в sam3u4E и зависают в sam3u4C. Вроде как внутренности у них должны быть одинаковые, да и загрузчик выдает одну и ту же версию: v1.1 Oct 16 2008 17:28:07. В схеме с sam3u4c все нормально, платы работают. До этого программировали через JTAG, а в серии хочется избавиться от этого разъема. Подскажите, где еще искать?

У меня та же проблема, только с sam3u4c. SAM-BA зависает на -I- Loading applet isp-flash-at91sam3u4.bin at address 0x20001000 Кроме этого, есть самодельный макет на sam3u4e, там SAM-BA ругается что не может проинициализировать PSRAM (эту часть скрипта можно убрать в tcl-файле), но дальше работает и шьет флеш и GPNMV биты. Пробовал и SAM-BA 2.10 (CDC и через atm6124.Sys) и 2.9 - результат один и тот же. Так же пробовал перекомпиллировать апплет - аналогично... Кто-нибудь знает решение данной проблемы? Заранее благодарен.

С WinAVR идут утилиты для LibUSB, WinAVR-xxxxxxxxx\utils\libusb\bin с помощью inf-wizard можно создать inf-файлы для любого подключенного устройства. Там же есть libusb0_x64.sys и libusb0_x64.dll ... я никогда не работал с 64-разрядной системой, но может это оно и есть?

ИМХО самое простое решение здесь - перекомпиллировать исходники USBasp, отключив установку SPI2X. Частота снизится до 187.5 кГц - новые чипы (на 1МГц) можно будет шить без утановки дажампера. Правда скорость программирования снизится раза в 2... Пользуюсь USBasp уже где-то 2 года, никаких особых проблем не было, правда я сразу сделал вариант с 3.3В стабилизатором и токоограничивающими резисторами на SPI.

Похоже у вас неверно вычисляется BAUD. У вас используется фомула для получения частоты из значения UBRR-регисра F_CPU/(16 * (BR + 1)) , а нужно по обратной: #define BAUD (F_CPU/16/BR - 1)

На всякий случай: первые 256 байт в ОЗУ занимают копии регистров, так что хранить данные можно начиная с адреса 0x100.

Если брать самый простой вариант (без usbFunctionWrite и usbFunctionRead), то, например, в uchar usbFunctionSetup(uchar data[8]): data[1] - код команды. data[2]...data[5] - ее данные. Так же есть какой-то static uchar replyBuffer[8]; , который заполняете необходимым ответом, ставите usbMsgPtr = replyBuffer; и возвращаете длину ответа. Со стороны компьютера: int usb_transmit(unsigned char functionid, unsigned char send[4], unsigned char * buffer, int buffersize) { int nbytes; nbytes = usb_control_msg(usbhandle, USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_ENDPOINT_IN, functionid, (send[1] << 8) | send[0], (send[3] << 8) | send[2], buffer, buffersize, 5000); if(nbytes < 0){ // Error } return nbytes; } Если надо передавать большие блоки, то посмотрите USBasp.

Для данного драйвера 10мс - минимальный период опроса interrupt-in endpoint, для control transfer, который тут в основном используется, он не применим. А пакеты по 8 байт могут идти хоть друг за дружкой, правда в драйвере есть ограничение в 254 байта на одну передачу. Вот пример: программатор USBasp считывает мегу32 за 4.6с, получается ~7к/с. Хотя тут завязана еще и передача по SPI, которая теоретически занимает ~3c. Так что чистая скорость точно не меньше :)

Только что проверил на tiny2313-20pu (пр-во 0613), фусы: 0xff 0xdf 0x64. Т.е. 8МГц с делителем на 8. Раньше специально не смотрел, но все, что у меня были (примерно 30 шт, разных партий) шились AVRISP с частотой SPI 230кГц. А по документации частота SPI должна быть как минимум в 4 раза меньше частоты контролера. Так что ИМХО будь там 500кГц - то не программировались бы.

В самом драйвере - да, о вот в компьютере - принципиально. Для передачи задается тайм-аут, за который устройство должно ответить ACKом. Например, в usb_control_msg (если пользоваться libusb) этот тайм-аут идет последним параметром. У меня 10мс цикл при подключении через хаб растягивался прерываниями примерно до 30-50мс, что в некоторых случаях приводило к исходу тайм-аута. А какие тайм-ауты установлены для стандартного CDC-класса, честно говоря, даже не знаю...

Пустой цикл - N-ое количество тактов + все прерывания, которые возникли во время этого цикла. А таймер идет автономно, ничто его не прерывает и максимальная погрешность (задержка) такой паузы гораздо меньше. У себя я сделал паузу примерно как в USBasp'е: void delay10ms(void) { uchar startTime = TCNT0; while ( (uchar)(TCNT0 - startTime) < 118 ) ; /* prescaler = 1024 */ }

У меня тоже была проблема с хабом. Правда со своим девайсом на AVR-USB. Устройство работало нормально, но при подключении к хабу usb_control_msg вылетал с ошибкой тайм-аута. Осциллографа не было, но имхо хаб гораздо чаще опрашивал устройство, чем контроллер в компьютере, поэтому все паузы, выполненные в виде простых циклов, сильно растягивались (прерывания в это время разрешены). Заменил цикл на ожидание по таймеру: temp = TCNT; while ( (uchar)(temp - TCNT) < t) ; - все заработало. В данном программаторе тоже используются задержки в виде циклов, может, в этом дело?

Да, возвращает принятый байт по SPI. Работает в SPI mode 0, как по app.note AVR320. Задержка при "высоком полупериоде" SCK - половине частоты SPI (-2 такта на установку пина), при "низком" полупериоде - та же половина частоты SPI (- ~12 тактов на зацикливание, установку MOSI и считывание MISO). Каждая итерация _delay_loop_1() занимает 3 цикла (ldi; dec, brne).