Bare Metal USB host using NOP-based delays

[thomas_wolf]

I am currently evaluating the k22 as a potential replacement for our current micro (which is more expensive), and I believe I have found a potential deal-breaker in the USB Host protocol stack that is used in the MCUXpresso demo applications (both the bare metal and the freertos implementations for the msd fatfs demo).

In usb_host_khci.c in the function _USB_HostKhciAttach() there is a NOP-based delay loop of about 120ms (133ms by my rough calculations based on the disassembly).  There are also a few other smaller loops elsewhere in the file, but the 120ms loop is the worst offender.  We use a simple cooperative task scheduler in our code base, so something like this is just not going to work when we have 100, 10, 5, and 1 ms tasks which will be blocked every time a USB device is attached.

I am thinking that this would probably force us to use an RTOS (which is arguably where we should be headed), but even in an RTOS the NOP-based delay is wasteful compared to a vTaskDelay() call (and the timing will be longer if the task is preempted).

Are there alternative USB stacks which better support a bare-metal/cooperative environment?  I think it may in theory be possible to replace these delays with a state-machine-based delay mechanism, but if the stack was not designed for this use case then I am not sure if the effort would be worth it.

For reference, we are coming from a Tiva part, and as best I can tell the tivaware usb host library is implemented without loop-based delays.  The delays I see are all using counters that assume a task call rate of 1ms, so they yield to the superloop/scheduler instead of holding up the processor for the entire delay.

Any advice is appreciated.

[mjbcswitzerland]

Hi Tom

You can replace the delays with software timers if you are not using a pre-emptive OS.
Or by a HW timer interrupt  - in each case to execute the code "after" the wait when it fires (most such waits are just waiting for a time to pass before checking that the USB line state remains stable and filtering glitches).

If you choose a part with HS USB (rather than FS USB) they contain 2 x HW USB timers that are for such purposes rather than needing to use a general purpose HW timer.

Regards

Mark

[uTasker project developer for Kinetis and i.MX RT]

[Developer of uTasker USB device/host stack compatible with all Coldfire, Kinetis and i.MX RT parts]

[thomas_wolf]

Hi Mark,

Thanks for the response; it looks like we will have to make some changes to use this one way or another.  I guess we are spoiled coming from the Tivaware library.  We will most likely pursue modifications to the library, but we may be open to moving "halfway" to an RTOS by keeping a single task for all of our co-operative code and using a second for the USB stack.

I actually spent some time looking at uTasker just a few days ago.  It seems to be one of the few RTOS packages with USB host support, and I like the idea of the simulator.  I think it will be on my short list if I can convince the team to move to an RTOS.

[mjbcswitzerland]

Hi Tom

uTasker contains a co-operative scheduler and so you will probably feel at home without any changes  - it can also be used with FreeRTOS if some pre-emptive task operation is needed.

The USB stack will work on Coldfires, all Kintis parts with USB (both FS and HS) and also on single or dual HS USB on i.MX RT parts (take a look at the i.MX RT 1011 which gives you HS USB and 500MHz Cortex M7 operation for about $1 in quantity, compared to the approx.. $3 for a K22). No porting is required between these so one can develop on one and switch to another at any time with almost no effort.

I have attached a short video showing a simulated K22 in operation - connecting a memory stick, formatting it and writing data to it. The Kinetis peripherals - including USB - all interrupts and DMA and the memory stick are simulated so testing and debugging application code and drivers is many time faster and easier than traditional techniques that most people are still using - so it is a good way to move to a higher league of developing compared to your competitors ;-) [plus tons of industrially-proven integrated applications rather than just examples]

Regards

Mark