Здравейте,
0. Има тема за STM32F4-Discovery, но тъй като новото STM32F429-Discovery има доста разлики откъм периферия (SDRAM, 2.4' TFT + touch) прецених, че е най-добре да има отделна тема за него.
1. Това, което ще споделя за начало е един проект, който ще ползвам за ОСНОВА на дипломна работа. В този си вид е чисто демонстративен и сигурно едно 90% от кода в него е генериран от STM32CubeMX за F4, но съм променил и добавил съществени части код, за да навържа всичко заедно и да е 100% стабилно плюс функционално.
2. Какво представлява проекта:
F429-Discovery има 8MB (64Mbit) SDRAM, има изведено също така потребителско USB, което макар да е с HS способности, то те са налични само с външно HS PHY, така че по подразбиране на Discovery-то може да постигнете само FS скорости с вграденото в микроконтролера FS PHY.
Проекта създава USB MSC устройство, което ползва за памет SDRAM-а. Определено е семпло като функционалност.
Каква е идеята обаче: трябваше ми памет, в която да буферирам данни от АЦП или след обработка, които данни да мога да достъпвам бързо и лесно, и без да губя много време в разработка как да стане това. Бързо е ключово, защото исках да виждам данните в реално време или близко до него. АЦП-то ще работи на максимум 1MSPS, 12битов резултат, режа 4-те LSB, получавам 1 байт на sample, което дава максимум 1MB данни за секунда. Full-Speed USB може да развие максимум 12Mbit/s или 1.5MB/s, но това включва протокола + потребителските данни. В крайна сметка полезните данни се предават със скорост около 1MB/sec по тестове, които видях в мрежата. Това ме устройва, може би ще съм на ръба, но не е проблем АЦП-то да работи и една идея под 1MSPS.
3. Постигнат резултат:
Първоначално имах проблема изобщо с подкарването на USB Device библиотеката на ST, но се оказа проблем със STACK-a. По-късно като пуснах FATFS имаше недостиг и при HEAP-а. Дори с тези проблеми отстранени обаче се държеше нестабилно и единствено работеше с изключено DMA (USB-то има Internal Dedicated DMA). След дълго четене на User Manual-a, където почти нямаше информация за DMA-то на USB-то; в комбинация с подробно преглеждане кода на USB инициализацията установих проблемите. USB FIFO буферите бяха на минимум като размер + грешна конфигурация на DMA-то. Оправих това и всичко заспа.
Направо литна според мен
Пренос на данни: 8Mbit/sec = 1MB/sec запис и 10Mbit/sec = 1.25MB/sec четене. Скоростите са постоянни, не са пикови стойности. Записването реално не ми трябва за момента, но и то, и четенето е повече от добре.
4. Проекта е създаден за IAR Workbench 6.70 и по-нови от CubeMX с 4.1.1.0 версия на библиотека на ST. Аз лично ползвам Kickstart 32KB версия 7.10. Ако промените нещо от CubeMX не забравяйте да дадете в опциите да запази user code-а при (ре)генериране, макар че съм сигурен че има места където не съм оградил в /* USER CODE BEGIN X */ ... /* USER CODE END X */, така че може да загубите част от промените, които съм правил и съответно проекта да започне да работи не както трябва.
Аз лично генерирам това, което ми трябва от CubeMX и ако ми потрябва още нещо го генерирам в нов отделен проект и го досглобявам в големият, защото CubeMX не винаги опазва 'негенериран',допълнително писан код.
5. Какво ще видите пускай проекта - нов USB Drive форматиран с FAT32 и един txt sample файл с едно изречение текст вътре за тест. Размера на устройството е 8MB (реално 7,94 като включим загубите от partition table + fatfs таблицата). Така може да изчитате данни, които контролера записва като файлове, аз лично ще ползвам бинарни, а не текстови файлове, за да не генерирам излишен трафик или може пък да качвате файл, който контролера да обработва, ползва .... сигурно ще има идеи повече от това, за което на мен ми трябва.
6. Възможности за подобрения:
Ще видите в коментарите ми при read/write функциите в usb_storage_if.c информация относно DMA за SDRAM-а, не става дума за USB DMA, а за стандартното DMA, което прави трансфер между периферии/памети.
В момента постановката е следната:
SDRAM ---- процесора чете 32бит дума по 32бит дума ----> Буфер ---- USB DMA ----> USB
А има възможност за
SDRAM ---- DMA ----> Буфер ---- USB DMA ----> USB
Въпросът е, че драйвера за USB MSC е така направен, че дефакто щом извика примерно Storage_Read очаква, че в края й след return _status_code_ данните са готови (в буфера) за изпращане с USB DMA-то. Само че ако в Storage_Read се пуска заявка за SDRAM to Memory DMA, то тя трябва да се изчака да свърши и тогава да се изпълни return, иначе буфера се изпраща празен (нули), защото DMA-то още не е свършило с трансфера. И така, ако DMA ще се чака, то ползата от нея между SDRAM и буфера почти отпада. Единствено и то може би, ако се окаже Burst на SDRAM-а може и да има подобрение във времето за което буфера ще е готов да бъде изпратен. Разбира се това няма да вдигне скоростта на трансфер, но ще намали малко или много, трудно ми е да преценя; времето в което процесора се занимава с трансфера по USB. Лично за мен това не е необходимо, но ме човърка да го пусна това DMA. На 168Mhz обаче ще имам достатъчно процесорно време за обработките, които ще правя, та за сега няма да се занимавам с това, но е нещо, което може да се направи/подобри
7. Надявам се за някой проекта да е полезен или поне интересен.
Като обобщение навързани са FMC + FATFS + HS USB in FS mode и цялото генерира един Mass Storage, от който може да четете за достъп до данни от MCU-то или да записвате данни, за да ги дадете на MCU-то. Друг вариант е да го ползвате като усб флашка с идеята, че това е енергозависима памет
Прикачам архив на проекта (rar ~900kB) , вътре освен сорса е и CubeMX проекта + EWARM проекта (За версия 6.70 или по-висока).
