From the data-sheet for SAME70x21, UART seems to be lacking HW-FIFO, yet DMA is supported. From the UART driver code, it's clear that buffers are used but it's unclear if send/recieve depends on IRQ:s or are managed by HW. I need to send blocks of data where back-to back latency must not exceed 2.5 periods of the bit-rate where the bit-rate is somewhat pushing SAM's HW-limits (6Mbps).
Please advice
Correct; there is only a single octet of buffering. Use the XDMAC device in memory<->peripheral mode to offload Tx to DMA.
Steve
Hi Steve, thanks for your reply.
Our primary concern is back-to-back byte transfer within 2.5 TX-bits (=650nS at UART bitrate of 6Mbps).
We need to avoid the per-byte feeding TX of UART using ISR's as it puts high requirements on IRQ_response + ISR_handling time. ASF driver is roughly 10x off to satisfy the criteria (MCU running at 150MHz). Pushing the limit of SAME70 and rewriting in pure assembly may work, but I'd rather use another solution as it's crude, fragile and error-prone.
The concern at this point is mainly TX and the back-to-back RT-requirement originates from the transmission media.
Regarding DMA:
Can the XDMAC be set up in conjunction with "Peripheral Hardware Requests" such that:
If the above is within the XDMAC's intended use, examples would be appreciated as the XDMAC is a complex controller and it's linked-list ability is more clobbering than helpful for this simple use-case.
Kindly //Michael
Can the XDMAC be set up in conjunction with "Peripheral Hardware Requests" such that:
- DMA controller feeds UART one byte at a time on each TX-transfer complete without MCU intervention (except the set-up).
- From any generic RAM buffert (array). Transferring to this buffert is not important if addresses can be generic, i.e. dubble buffering.
- Autonomous fetch-and-feed of next byte, to UART TX-register either by
- Autonomous increase of source adress by one
- Re-invoke DMA transfer such that the complete TX-buffert is shifted by one (overlapping buffers).
- Re-execute (any of) the above until complete buffert is transferred, and whence done interrupt the uC.
- Completes any of the above faster then CPU ~10 cycles.
Yes to all of the above.
If the above is within the XDMAC's intended use, examples would be appreciated as the XDMAC is a complex controller and it's linked-list ability is more clobbering than helpful for this simple use-case.
I've attached a basic driver for the SAMx70 XDMAC and a code fragment showing how it could be used to send data to a USART.
The code comes with no guarantees it'll compile or run, but it has been used (in a less redacted form) to DMA data to a TFT display over SPI at 20 Mb/s. So 6 Mb/s, in your case, should be no problem.
Steve
Hi Steve,
thank you for your help. It answers my questions well beyond satisfaction. I now really want XDMAC based drivers :-)
I'll close this thread as the question is answered. Following is a small follow-up which you can disregard if you want:
I had a look at your code its high quality. The interfaces especially are very nice.
Basing XDMAC on ASF/CMSIS is somewhat quirky but got it compiling and running.
The "perid" USART2_DMAC_ID_TX was undefined which I picked it from the docs (0x18 for UART2_TX).
Our HW is set so I exchanged USART2 to UART2. (The IP has been tested OK before for ISR based operation).
Despite USART and UART not being identical wrt to DMA, I think it should work. No XDMA interrupt and no output however. The UART is configured prior calling sam_xdma functions init_tx_dma & start_tx_dma. I'm assuming the HW configuration is identical except for not setting up UART IRQ.
I.e. Peripheral clock should be routed and enabled, and HW-config should be done. Destination register adress checked for correctness. Am I missing something or is there any register in UART that should not be set for DMA operation? Any hints appreciated.
Kind Regards
//Michael
Hi Michael,
Did you enable the XDMAC peripheral clock?
PMC->PMC_PCER1 = 1u << (ID_XDMAC - 32);
Steve
Hi Michael,
Did you enable the XDMAC peripheral clock?
PMC->PMC_PCER1 = 1u << (ID_XDMAC - 32);
Steve
Hi Steve, yes I did.
I kept your interfaces but ended up re-writing the driver completely to get rid of some crippling ASF dependencies.
I extended the driver feature to support linked lists as well as generalising PERID selection and support transfer in any direction with any peripheral. Yet keeping your API's intact (as mentioned it was great).
Your code-comment about re-triggering was also very helpful as it had me take an interest XDMAC linked-list, realising that the slack one byte worth in time was not enough. ISR's to re-trigger would take too long unless using all the tricks in the book (like TCM, cashing and hard assembly optimization. All but TCM non-acceptable by us and TCM not yet supported by our arcane ASF). Our RT-requirements were quite high. Packets back-to-back can not jitter more than individual bytes and no byte can jitter more than 1.5 bit.
System now runs at full peripheral-clock speed RX/TX with ~0% CPU utilisation yet handling double buffering and without loosing a single byte nor needing support of critical-section handling and best of all: without ANY hard RT-criteria in SW. That's actually really amazing making rest of SW a breeze.
Good job Atmel making such a fine IP.
Regards //Michael
