Osal queue timeout

[hathach]

Describe the PR

• add mili-second timeout to osal_queue_receive (mynewt does not support this).
• tud_task() and tuh_task() timeout in 1 ms wait forever on event queue, but will exit once processed all events to allow RTOS thread to be shared with other background work e.g cdc flush().
• tud_task_ext() and tuh_task_ext() are added to take timeout_ms and in_isr (not yet supported)
• In case where 1 tick > 1ms (e.g 1 tick = 10ms), at least 1 tick will be used.
• add TU_ATTR_ALWAYS_INLINE to most of osal function.
• add tinyusb docs and disable blank issue

@dhalbert

[Nikitarc]

Please set a configurable timeout for each queue (something like CFG_TUSB_TMO_xxx). Not a hard value. Currently there is no timeout so I managed it in the OSAL layer: sometimes 0 and other times infinite. The value 1 is not practical because it leads to useless context switches when there is nothing to do, and a waste of time if we wanted 0. Moreover, if tud_task() is called by an interrupt, it is forbidden to have a timeout!
You say that a 1KHz SOF interrupt is expensive, but you are going to introduce a 1KHz context switch. It's the same order of magnitude...

[hathach]

yeah, that makes sense on the context switch overhead, the tud_task() should take an timeout as argument instead. Though regarding ISR, tud_task() must not be called within ISR when using within an RTOS, current mutex, queue API does not take this into account (yet)

[hathach]

@Nikitarc thank you for your feedback, I have updated the pr to add new API tud_task_ext() and tuh_task_ext() that takes timeout_ms and in_isr as parameters. The task will exit once processed all events so that thread can still be shared with other background function if needed.

[Nikitarc]

I see you add timeout_ms, and specify 0xFFFFFFFF = wait forever.
Please add a define for this value, e.g. in osal.h and use it in usbd.h and usbh.h.
If this value changes in the future, it will be easier to track.
Greetings

[hathach]

there is one OSAL_TIMEOUT_WAIT_FOREVER, you could also use the UINT32_MAX as well.

tinyusb/src/osal/osal.h

Line 41 in 55a5fd5

#define OSAL_TIMEOUT_WAIT_FOREVER (UINT32_MAX)

[Nikitarc]

Thanks for the info on OSAL_TIMEOUT_WAIT_FOREVER.
Why doesn't TinyUSB's code use it?

[hathach]

osal.h isn't considered as public header, I don't have time right now to change it.I intend to use -1 with int, but decide 0xFFFFFFFF isn't too bad. This may change in the future.

[Nikitarc]

_osal.h isn't considered as public header
This is strange.
An application should include tusb.h wich is public.
And tusb.h includes osal.h. So an application can use what is in osal.h.

Anyway, we are not talking about application code, but about USB stack code. In my opinion the USB stack code should use its own definitions.