Does anyone have any information on the maximum data throughput of the PDC? I cannot find any information on this in the datasheet or anywhere else and it seems that I have a problem with this issue. The chapter on the PDC in the datasheet is written more like some advertising and doesn't provide a lot of useful information.

I am using the SPI with SCBR = 2 (MCLK = 48MHz so SPI clock is 24MHz) and using the PDC for the data transfers works reliably until I start using the PDC for receiving data from the UART as well. Occasionally the SPI transfer/receive is not completed and the program can only recover by closing and re-opening the PDC.

The datasheet only makes a vague comment regarding priorities when two devices need to access memory using the PDC at the same time, but does not list the priorities. I am assuming that if the UART and the SPI need to access the memory at the same instant, the PDC gives the UART priority and the SPI is blocked for a moment. By the time the transfer for the UART has completed, I suspect it is too late for the SPI transfer and an overflow results (which cannot be detected in program code because the PDC probably reads SPI_SR itself and clears the overflow bit).

With SCBR set to 2, the PDC has 16 cycles to write each byte to memory. Perhaps that is only just enough (if one considers the pointer and counter updates that are necessary for each transferred byte) as long as nothing else is happening. Changing SCBR to 3 seems to fix the problem but unless I see some reliable information about the maximum data throughput, I do not want to make this change since (a) it slows down the system and (b) perhaps I have an entirely different problem and the change is only hiding it for now.

Doesn't anyone find this interesting? Surely others have run into performance issues when using the PDC with the SPI, especially because the SPI is (1) fast and (2) reads imply writes at the same time, doubling the PDC's workload.

It surprises me that there is so little information on this.

I have tried using the PDC for UART and the speed is 'great' (ei. as fast as it can be for the given baud). But before you go any further with the AT91SAM7S please read the errata section of the datasheet!!!

The handshake of the UART on AT91SAM7S does not work. And therefore, for most applications the PDC is useless.


Don't use the AT91SAM7S before it is working. Atmel needs to update the chip.
It would be nice if Atmel would give a timeshedule for that. At the moment there is a 'preliminary' datasheet from Januar this year.

i wouldn't expect any updates on the at91sam7s. some of the errata entires are existing since this part is available.


regards
gerhard

How can you say that? The errata on the AT91SAM7S says that the USART handshake is not working, under some conditions. The problem is that these conditions are not something that can be avoided. When the handshake siganls are used, the AT91SAM7S, and AT91SAM7SE will loose bytes. It will happen in approximately 1 in 10000 bytes. For most applications this is not acceptable.

Are you speaking of the hardware handshaking concerning CTS? If so, I am not using that so I believe using the PDC is not a problem. Also how can there be a preliminary datasheet only from January? We have been using the AT91SAM7S64 for two years so the IC should be getting pretty mature by now. However before we get off-topic and begin talking about bugs in the UART, the information that I am after is:

• What is the maximum throughput of the PDC, or how many clock cycles does the PDC need for each byte of transferred data? If this depends on the peripheral, then we need a list.
• Is the SPI peripheral doubly affected when receiving because this implies a transmission at the same time? Is there a way to avoid this?
• Are there any latencies switching between peripherals when servicing multiple peripherals simultaneously?
• What are the peripheral priorities used by the PDC? How are these defined?

The chapter on the PDC needs to contain some hard information written by engineers rather than being something written by the marketing department.

Have you seen the PDC presentation of atmel that is somewhere here on this site? It explains the transfer delays on page 11. If I understand it right, it takes 8 clock cycles.

I've noticed similar items with the SPI PDC. My PDC won't run with a /4 clock and 8 bit transfers. But it works with a /6 clock and 8 bit transfers, so it needs between 32 and 48 clocks between transfers. I have both SPI PDCs running and the SSC PDC running.

I've been trying to guess as to how many clocks you need between PDC transactions, it sure would be nice if Atmel published an equation to help.

If you look at the ARM7 TRM, it talks about sequential cycles. The LDM and STM instructions can be about 18 cycles long, with the memory bus locked the entire time. So, the PDC can't do a memory access in the middle of this, however, I don't know if some of the 8 cycles from the slide (say the 4 for the PDC arbiter,) can be in parallel with this. I haven't seen any 18 cycle LDM/STM instructions, but 16 cycle ones are common (e92d5fff PUSH {r0-r12,lr}) on entry and exit of interrupts.
The TRM is vague, but it infers that the ARM7 may be able to keep the memory a little longer to do some pre-fetching of instructions either right before, or right after the LDM/STM instruction. Also, it may be able to keep the memory bus for the branch that tends to occur after an LDM (pop the registers from the stack and then return from the subroutine)

Next, there are probably some pipeline delays with TX/RXRDY and THR/RHR. For example, you may not see TXRDY until one clock later.

Then, does the PDC spend a little time looking for an idle cycle before it does the memory access? The PDC could try and do the transfer in a window when the ARM isn't accessing the memory bus, for example in the middle of a multiply instruction (a multiply takes 2 to 6 clocks, depending on the input data and the exact instruction called).
This would require a couple of clocks between transfers while the PDC looks for such a window, and then gives up and forces a write.

Then, what happens if 2 DMA requests occur at the same time, or another PDC has just started it's 8 cycle transfer when this PDC request occurred. How much of the 8 cycles can occur in parallel?

A simple starting equation is 18 (for LDM/STM) + 8*(activePDCs - 1), so in my case I may need 34 clocks between transfers.
With 2 PDCs active, you would need 26 clocks between transfers.

Of course, if you can make your SPI transfers be 16 bits, then you can double the clock...

I have the same problem:
1, SPI with PDC TX/RX at 48MHz/2=24M, i.e. SCBR = 2 (MCLK = 48MHz so SPI clock is 24MHz).
2, ADC with PDC RX at 0.5K sample/s.
3, SSC with PDC TX/RX at 256KHz.
Occasionally the SPI RX--receive only is not completed, RCR always is 1, and the program can only recover by closing and re-opening the PDC. So, I have to retry again, then it's ok next time.

Hello,

I have the same problem. I'm communicating with an SD-card through SPI with DMA, and sometimes the RCR does not decrease to 0, it stays at the value 1. Sometimes it works for days.

Did you find the problem?