anpilog

Винда может и тупит, но я проверил это еще и на MacOS. Результат тот же. 8( Что-то там другое... Такое впечатление, что где-то что-то сбрасывается. Сегодня ради интереса поигрался с оптимизацией (О0-О3). Так вот на О3 зависание происходит гораздо реже. Что-то тут не так. Спасибо. Ну тут таких размеров просто нету...

Интересно... Впервые о таком слышу. Есть какие-то пруфлинки для погружения в тему?

Всем привет, Давненько я ничего не спрашивал 8) Столкнулся тут со странным поведением примеров от Keil. Если в двух словах, то USBstack на STM32F103RB/C8 виснет под нагрузкой. Предистория длинная и не интересная, так что я постарался упростить все до минимума. Итак. Берем пример от Keil c:\Keil\ARM\Boards\Keil\MCBSTM32\RL\USB\Device\CDC_ACM\ Берем Nucleo-R103 с STM32F103RB. Подсоединяем внешний USB разъем: D- <-> PA11 D+ <-> PA12 Pull-up D+ to VCC, 1.5k resistor. Вырубаем инициализацию LCD. Иначе зависним в ней. // lcd_init (); // lcd_clear (); // lcd_print ("USB Device Demo "); // set_cursor(0, 1); // lcd_print (" www.keil.com "); Закорачиваем RX и TX для лупбек теста: PA9-PA10 В качестве тестовой апликухи на компьютере написал простенький JS скрипт. Он просто гонит кучу данный в порт и выводит на экран то что получил. Проект для Keil и скрипт можно взять тут: https://www.dropbox.com/s/ocbk2c4fenl75eb/CDC_ACM_nucleo.zip Все это работает какое-то время (десятки секунд - несколько минут) а потом затыкается. Затык выглядит как забытая FIFO на прием или передачу USB. То есть USBD_CDC_ACM_PutChar или USBD_CDC_ACM_GetChar возвращает -1. while (1) { /* Loop forever */ NotifyOnStatusChange(); /* Notification handling */ /* USB -> UART */ if (usb_rx_ch == -1) { usb_rx_ch = USBD_CDC_ACM_GetChar (); } if (usb_rx_ch != -1) { if (UART_PutChar (usb_rx_ch) == usb_rx_ch) { usb_rx_ch = -1; } } /* UART -> USB */ if (usb_tx_ch == -1) { usb_tx_ch = UART_GetChar (); } if (usb_tx_ch != -1) { if (USBD_CDC_ACM_PutChar (usb_tx_ch) == usb_tx_ch) { usb_tx_ch = -1; } } } Чаще всего именно USBD_CDC_ACM_PutChar. Проверил это безобразие на нескольких машинах, парочка Win и один Mac. И на нескольких процесорах. Кто-то с таким сталкивался? Сложно в это поверить, так как Keil-овский USB стек популярный. Что-то мне подсказывает, что наступаю на какие-то давно известные грабли. Regards

Это что за сертификация такая?

Мы пользуемся Ubuntu запущенной из под VirtualBox. Довольно удобно.

Никогда не компилировал QT под windows. Посмотрите какие платформы вообще доступны ./configure --help

./configure \ -opensource \ -embedded arm \ -xplatform qws/linux-arm-g++ потом в mkspecs/qws/linux-arm-g++/qmake.conf прописываем нужный компилятор.

Проверьте переменную PATH. Там однозначно есть путь к Delphi в котором и лежит make.exe

Присоединяюсь к вопросу. Наблюдал ту же проблему на LPC3250 c gcc-4.3.2 и glibc-2.7. Bus Error был на 4.7.0 и 4.7.1 Решения не нашел.

Да... Значит сарказм мне не привиделся 8) Пора вводить смайлик - "сарказм"...

Да я как бы и не должен... Я смотрю на него как на SoC. Да ещё работающий под Linux. Двойная цена за фактически те же возможности, в данном контексте - настораживает. ЗЫ: Тема ценообразования флеймовая... 8( ЗЫЫ: Немного оффтоп, но все же. Жаль что никто так и не запустил такой же массовый продукт как BeagleBoard на просторах СНГ. Мне кажется рынок есть. Не ударжался: Зачем же в таком случае делать что-то иначе и ЗНАЧИТЕЛЬНО дороже чем уже существующий прототип??? Я конечно прошу прощения, но на http://www.evodbg.com/index.php?option=com...99&Itemid=1 beagleboard стоит 235 у.е. А это купленный "там" товар с накруткой, без малого в $100. Обидно за державу как-то...

Аааа.... А почему у него цена 11500 руб. это же ~370 у.е. Или у них какой-то загадочный курс при оплате валютой??? Это же в два разо дороже чем новый биглбоард!!!

AT91SAM7S64: Status Production Flash (Bytes) 64K SRAM (Bytes) 16K RTC/RTT -/1 10-bit ADC Channels 8 Peripheral DMA Channels 11 Pb-Free Packages LQFP 64 QFN 64 Хмм... Кто ж Вас надоумил на этот проц Linux ставить??? P/S: Щас начнется... 8) PP/S: Не думаю, что у Вас получится поставить ucLinux на 7-е поколение армов. Так что гуглите на предмет ucLinux/Linux on arm.

Ясно. Спасибо. Ну вообщето чип-то достаточно новый, что бы его в основную ветку ядра засовывать. По сути в августе только появились чипы с нормальными серийниками... Были проблемы с LCD 800x600 под этот чип - сапорт сработал отлично, за что им большое человеческое спасибо.

А чем Вас 2.6.27 не устраивает? Искренне интересуюсь... В принципе никто не запрещает скопировать arch/arm-mach-lpc32xx с пропатченого 2.6.27 в 2.6.33 и подтащить все необходимые драйвера вручную. ЗЫ: Не видел никаких портов кроме как на 2.6.27...