Flexz

В STM-ках приоритет Bus master-ов не контролируется, Round Robin и точка. По крайней мере так говорит мануал.

Прелесть СФ1 в том, что в одном корпусе и проц, и плис, и довольно богатая аналоговая часть. В СФ2 аналоговой части нет. Кстати, для написания софта под СФ Актель тоже предлагает Эклипс.

Раздел System architecture, почти вся периферия, кроме GPIO, сидит на одном AHB-APB мосту. Пересылка с помощью DMA занимает минимум пять тактов, а цикл из первого поста, если не ошибаюсь, выполняется за три. Вот и выходит, что ядро и DMA почти постоянно заняты дележкой шины.

Тут еще другое интересно - в других процессорах серии (F1/2/4) в регистре статуса АЦП присутствует бит Overflow, который устанавливается в 1 в случае если DMA не успевает забрать данные из DR. При этом АЦП останавливается, что защищает от получения перепутанных данных (при преобразовании последовательности каналов). В F37x такого бита нет, и что происходит, если DMA не успевает забрать данные - мануал умалчивает. Видимо, данные по-тихому теряются.

Настройте для начала один канал АЦП с записью в массив с помощью DMA, безо всяких таймеров. И смотрите данные по прерыванию TC.

Видимо, вам нужен регистр DBGMCU_IDCODE

Какая у вас скорость поступления данных с датчика? Может достаточно будет SPI-флешки? Для USB, в качестве отправной точки, можно взять пример Mass Storage, который идет с библиотекой. И либо общаться с устройством как с RAW диском, тогда приложению потребуются админские привилегии (в win7) и система при подключении устройства будет предлагать отформатировать диск. Последнее обходится созданием фиктивной файловой системы - в начале диска, на десяток килобайт, лишь бы система увидела что раздел есть и не паниковала. Либо заюзать libusb.

А ваш опыт относится к первой BeagleBone или уже к новой BeagleBone Black? Если к первой, то может сейчас хотя бы баги платы поправили...

А не могли бы вы перечислить модели флешек, с которыми возникли проблемы?

А обычные линейки по что забыли-то? Полный список из stm32f10x.h /* #define STM32F10X_LD */ /*!< STM32F10X_LD: STM32 Low density devices */ /* #define STM32F10X_LD_VL */ /*!< STM32F10X_LD_VL: STM32 Low density Value Line devices */ /* #define STM32F10X_MD */ /*!< STM32F10X_MD: STM32 Medium density devices */ /* #define STM32F10X_MD_VL */ /*!< STM32F10X_MD_VL: STM32 Medium density Value Line devices */ /* #define STM32F10X_HD */ /*!< STM32F10X_HD: STM32 High density devices */ /* #define STM32F10X_HD_VL */ /*!< STM32F10X_HD_VL: STM32 High density value line devices */ /* #define STM32F10X_XL */ /*!< STM32F10X_XL: STM32 XL-density devices */ /* #define STM32F10X_CL */ /*!< STM32F10X_CL: STM32 Connectivity line devices */

Вот в этом месте у меня во всех проектах немного по-другому - тело цикла вынесено в функцию, которая кладет в буфер один единственный байт (изначально делалось для putchar). uint16_t VCP_ByteTx (uint8_t dataByte) { APP_Rx_Buffer[APP_Rx_ptr_in] = dataByte; APP_Rx_ptr_in++; /* To avoid buffer overflow */ if(APP_Rx_ptr_in == APP_RX_DATA_SIZE) { APP_Rx_ptr_in = 0; } return USBD_OK; } В том проекте, на который я выше ссылку давал, перемещение массива в буфер дополнительно обернуто в запрет прерываний, и там тоже по байту кладется. Возможно, это имеет значение, по-другому я даже не пробовал.

Может у вас проблема в другом месте? Кабель плохой, например.. У меня с USB на STшных процессорах никогда проблем не было - просто брал пример, заменял верхнюю часть и оно просто работало. (если не учитывать некоторых косяков в HS режиме, с которыми я так и не взялся разобраться)

Да, пример из этого архива. Пачки уходят вплоть до 24кб за раз. Правда на каком-то этапе они разбиваются на блоки размером не более 4кб (видно в USBTrace). Подробно не вникал где именно, но это явно больше чем 32 байта. Один из проектов есть в открытом доступе https://code.google.com/p/logicdiscovery/so...FLogicDiscovery PS а вы случайно не в HS режиме его запускаете? У меня в HS режиме с внешней физикой этот код тоже тупил.

А пример из библиотеки ST вы брать не пробовали? у меня на его базе пара проектов построена, работает без нареканий.

Новые плюшки это, конечно, хорошо, но.. Старым косякам они вниманию почему-то не уделяют, непонятная политика. Еррату пока не выложили, но что-то мне подсказывает, что там все по старому.

С чего вы взяли? Замечательно работает. По времени, замерял на F4, пересылка через DMA в режиме M2M занимает 4 такта. F1 архитектурно почти такой же в плане DMA, шины и портов, так что скорости должны быть аналогичными. Но с портами 4 байта за раз не прокатит, они же 16-битные.

Большую часть времени съедает вычитывание команд: FLASH_SetLatency(FLASH_Latency_2); На каждое обращение к флешу тратится два лишних такта. Или разместите код в озу или снизте частоту процессора так что бы работать без дополнительных циклов ожидания.

Озвученный F4 - вполне подходящее решение для данной задачи, данные сливать на SD-шку или NAND-у.

1 - Все правильно, assign это, грубо-говоря, подключение провода (wire) к комбинаторной конструкции. А если данные записываются в регистр - нужно указать по какому фронту какого клока это делать. 2 - Если абстрактно - то правильно по тому фронту, по которому у вас весь дизайн построен. Однако, в большинстве случаев работают по положительному.

Был у нас проект как раз на L151, данные снимались с SPI-датчика и сливались в SPI-флешку. Процессор работал на своих полных 32МГц, флешка вроде бы 16, датчики медленнее, точно скорости не помню уже.. зато помню забавный момент - заменили кварц на вдвое более быстрый, а инициализацию PLL я исправить забыл :) в итоге проц вполне успешно работал на частоте вдвое выше номинала. PS а вы не пробовали работать по второму SPI? их же два в этих процах.

Неправда ваша. Замечательно махает на частоте 1/2 системной, без использования таймера. Правда на младших моделях (без акселератора и кеша, stm32f1 и ниже) я не замерял, но думаю если разместить код в озу - замахает. А настройки порта определяют крутизну фронтов.

Добавлю, что копирование из RAM в GPIO через DMA с триггером от таймера укладывается в 5 тактов, а если DMA без триггера, просто M2M - 4 такта.

У вас все правильно работает, и в документации тоже все так. Для таймеров делитель в два раза меньше берется. Это видно, например, из картинки Clock Tree в RM.

Почему вы вообще решили что прерывание от 13 ноги придет на вектор EXTI3_IRQn, EXTI4_IRQn? Должно быть EXTI15_10_IRQn

Ну да, наоборот :) По памяти пишу, платы под рукой нету. В остальном все так - PA9 соединяйте с 5V.