Hello All, This is not a KEIL related question. I decided to cross post here(and lpcware) as I get good responses here.
I wish to use GPDMA for asynchronous UART communication from a ring-buffer.
UART TX DMA is straightforward.
Now, UART RX DMA needs to know size of bytes to be received. To receive variable sized transfers, I plan to use a timer with duration of say 16 bytes. On each timer expire interrupt, I will check the transferSize value(control register of DMA channel used for UART DMA Rx). If the value is changing, just reload the timer to check again. If the value is unchanging call a RxCallback function.
What I wish to do is selectively enable and disable UART RX DMA. - So UART Rx interrupt(non DMA) will be enabled to begin with. - If any byte received, in the receive interrupt set up a DMA desc of maximum expected size, disable UART Rcv interrupt and enable timer. -When transferSize stops changing, stop DMA, disable timer, reenable UART Rcv and call RxCallback function.
User manual UM10360 is incomplete in describing GPDMA operations. I have used PL080 as reference. Now UM10360 says in section '14.4.6.1 DMA Operation' (pg 314, Rev. 3.1 2/4/14)
The user can optionally operate the UART transmit and/or receive using DMA. The DMA mode is determined by the DMA Mode Select bit in the FCR register. This bit only has an affect when the FIFOs are enabled via the FIFO Enable bit in the FCR register.
But there is only one bit to select FIFO and DMA modes. They affect both UART RX and TX. I cannot find any reference to how to selectively enable/disable UART RX dma. Does anyone have other ideas?
In absence of selectively controlling RX UART DMA, one option is to reserve a DMA ch for it, keep timer running always and use above logic for callback. I would prefer to not have timer interrupts all the time. If anyone has implemented a similar scheme, please elaborate.
I don't know of any solution that doesn't make use of a timer for timeout handling of partially received data.
So if multiple timer ticks sees the same, non-zero, count then it may decide on a non-lossy deactivation of the partial DMA transfer to let the program take care of the received data before a full DMA count has been received. A new DMA transfer may then immediately be started again, waiting for more data.
It would have been nice if NXP could have added a timeout register, to configure a maximum time since the either the first or the most recent byte was received before timing out the full transfer. But I haven't seen any indication of any such functionality.
But unless you are in need of very low latencies, it doesn't cost very much to keep a timer tick regularly checking the current state of the DMA rx state. You can probably use that same timer ISR for other tasks too.
Hmm - today I got the most excellent Captcha: A uniform gray image with no single character or digit. I have to guess that the image was intended for a different aspect ratio so the character(s) got clipped... Thanks Keil for being so quick adding real accounts with login so we don't have to constantly enter Captcha answers!
So as I expected, I get quicker and better responses here than lpcware forums :) Yes, I agree a timer ISR with just a quick check shouldn't affect latency much. I was just trying to decipher NXP's horribly incomplete documentation. After reading it more than a couple of times, I still havn't found a way to selectively enable/disable RX and TX DMA's.
I found this thread searching for a solution to my similar problem.
We run Linux 4.1 on an LPC4337, and I'm having a hard time getting the UART to run at my desired 921600 baud. I get buffer overruns with DMA turned off, and turning DMA on it waits for 4096 bytes to transfer until the data gets released to me. The CTI interrupt is never triggered once DMA engine has been started.
I am digging deep into the Linux uart driver and DMA driver to solve this. Another user has mentioned always leaving one byte in the fifo, thus forcing a CTI interrupt at the end of each message. That might work for you as well?
Hi, That will work if I am manually copying bytes of a FIFO in background(say on RCV interrupt). But using DMA for RX, the issue is you do not know in advance how many bytes you will receive in a burst. If your system receives an equal number of bytes each time in a burst, that's easy and can be done. My solution was to use a scatter-gather DMA for UART RX. The descriptor points to itself, so after receving n(size of ringbuffer) number of bytes, the hardware fetches new descriptor which is itself. So without software intervention, I get my buffer filled with received bytes in the background. To empty it out I use either frequent polling or a timer which keeps track of bytes added and interrupts when no Rx activity seen for a few character times. It is a little overhead to compare number of bytes, but I have not found any other way to do it. I unfortunately, have no idea of linux DMA and strategies. Good luck and keep posted.