Posted on February 17, 2014 at 13:14> The reason is that the bytes arriving from the UART is unknown.
> I need to transfer them as soon as possible, and not wait the reaching of the treshold.
Well, this might be seen as a drawback of the FIFO, I admit... :)
OK, no FIFO. But that means, you can't count on it; that's it.
> So my choice is to use the direct mode, but the problem, in that case, is the speed: the DMA
> transfer is fast enough to transfer each byte as soon as it arrives, or can I occurr in some
> overwriting?
This depends on many factors. First, within the DMA module itself, the DMA stream in question might wait for other DMA stream to finish its transfer - this can be mitigated by setting the priority of this DMA stream high and others' lower; so if you set it so, it's a no problem.
Then, the DMA controller might wait on its ''peripheral'' port to read out the received byte from UART. This happens through the AHB-APB bridge, which arbitrates between the requests from its two AHB ports; and of course through the APB bus itself. There is no public information on that arbitration I know of; a sane assumption might be, that both AHB ports are given access in round-robin fashion, so if the processor-side AHB port made a request just before the DMA-side port, it would take to finish that first. Now I am not familiar with the APB bus timing, but let's just assume that for a processor read request there would be one APB cycle to resynchronize with the AHB, one cycle to transfer the address, and one cycle to transfer back the data. Similarly for the DMA request, so that would result in worst case of 6 APB cycles for the DMA to perform the read. Maybe some test could be devised to find out the worst case for this read. You may mitigate this by not allowing the processor to access the APB directly during the critical DMA transfer, but whether this is viable is upon your application.
On the ''memory'' port, the DMA again needs to wait until the arbiter of AHB bus where the target SRAM sits would give it access. Plus there might be other AHB masters fighting for that bus - again the processor, the other DMA, the ETH DMA, the USB HS DMA. And again, little is known of the arbiter here too. You can mitigate this by chosing different target SRAMs for different DMA transfers.
On the other hand, the double-buffering USART receiver allows for worst-case of almost 2 characters' time from Rx-complete signalling until the receiver character is fetched, so you have roughly 2us rather than 1us to complete the operation in the worst case, provided the total throughput is good enough to transfer the characters in average 1us each.
Generally, unless there is a very heavy data traffic going on from multiple peripheral sources, in a tens-of-MHz system even a 1MBps USART *transfer* presents only a few % of the total throughput. It's usually the *processing* side where the bottleneck occurs.
JW
