This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

RL- ARM usb libs and host msd

Folks looking for quick guidence or willing to learn from other peoples expreiences.

I started a project over a 18 months ago and apart from the rtx and Fs the libs provided in the RL-ARM package were either flaky or there was next to no documetation on how to use all the libs together.

The project I have worked on basically data logs to a internal SD card using FS lib then when required the data is trasnferred to a USB memstick connected to the FS port of a stm32F205

I started the project using ST code for the USB and they had a project using FAT_FS so included that in.

Recently the USB has become very problematic by not working with random USB msd - by either not enumerating - getting to the stage where its enumerated but first data transfer fails
or simply ends up in a USB ISR storm locking the project until a watchdog kicks in.

So after trying to compare the ST USB and drivers to Keil I noticed things seem to have moved on regards USB host examples for the STM32F2xx so converted the MSD_File host exmple to a RTX application
( so now its using the RTX, FS and USB libs).

Simply bodging all you do is take blinky and change the main in MSD_file to a task and create a task for it using its own stack.

IF you look in the MSD_file.c the main() is never blocked and will call
usbh_engine_all(); as fast as it can run.

But since I have other tasks also requiring processor time ( display, CAN etc ) I need to either RoundRobin it or block it with a 0s_wait call or os_itv_wait ();

In discussion with another engineer I decided upon the os_itv_wait(); option and set the
inteval period with os_itv_set (20); /** 20ms **/.
I understand this was once used with trying to get the TCP lib working with RTX ( could be wrong)

So the question is is this interval too long or too short e.g. 20ms for the USB to operate reliably.

It seems to work well with 8 tasks running and the USB task being the higest priority.
Are there any observations anyone would like to make ?

0