Call One time tu_fifo_write_n on cdcd_xfer_cb

[HiFiPhile]

Describe the PR
I thought it was included in old PRs but seems not...

In my CDC test with SAME70, throughput increased from 800KB/s to 27MB/s.

[hathach]

thanks for the PR, yeah, this is one of the improvement I planed to do but totally forgot. However, the implementation is not actually quite right. The driver must invoke the wanted_cb() right at the time it push the wanted_char into the fifo. which allow the application callback that call read() and see the wanted_chr as the LAST character in the fifo.

For example, to catch the \n then call read() to get the whole line. Else application must skip dozen of characters. which can potentially has another '\n' ( received multi-line within a packet) and cause some confusion when the callback is invoked with more data than it could expect.

Solution: we should still keep the loop however instead of writing one byte one, we keep an count and write_n(count) when we see the wanted (or write all if found none).

Update: please skip this review request and follow the below review. I have an change of mind, thanks :)

[hathach]

After giving it more thought, I think it is not worth to have wanted as the last char in the fifo at the time of the callback. It doesn't occur often and also doesn't have much impact on existing usage (application may need a minor of adjustment). Let's do it this way, though we still need to check if there is still data in the fifo before invoking the wanted callback, else it could confuse the app.

[hathach]

Perfert !! though I just realized the fifo_empty() did a quicker check than computing the actual count. and changes to both callback check to !fifo_empty().