AVRFreaks.net

The PDCA of the UC3B is pretty much the same as the one of the UC3A architecture, so you might want to have a look at some of those example projects. The USBB is very similar, but not exactly the same.

1) The PDCA has no handshake interface for the USBB, but in theory you might be able to just have the PDCA blindly write into the USBB’s memory banks, triggered by whatever peripheral you’re reading from. The the USB HSB Memory Map table for that. I can’t recommend this, though.

2) The compiler won’t know which areas the UDDMAC will manipulate, but you will. You have to tell the UDDMAC where to write data to or where to read from. That’s what the UDDMAnADDR registers are for. Allocate a buffer, tell the UDDMAC to use it, done.

3) I assume you’re talking about the PDCA: It uses exactly the word size you tell it to use. It won’t split larger word sizes into smaller blocks or use just byte transfers for everything. That’s why you can’t tell it to use three-byte “words”.

I’m not sure whether the memory locations have to be aligned to their natural boundaries. The PDCA might puke if they aren’t.

I recommend to buffer whatever you’re transferring from your peripheral to the USBB. Use the PDCA to transfer from the peripheral into SRAM an once that’s done, use the UDDMAC to transfer from memory to the USBB endpoint.

You can also have the UDDMAC automatically switch endpoint banks for you, which the PDCA can’t do.

You should also keep in mind that the USB endpoint can fill up and stall if you’re not picking up your data on the PC side fast enough.

Hope this helps.

One thing to note, if you're not certain about how the PDCA/DMA transfers work, you might want to try basing your project (or the first revision at least) off of an existing ASF example.

For instance, I'm doing some work with USB Mass Storage Devices, but I didn't really understand how the DMA worked to get the data from the disk (Dataflash, SD Card, whatever) to the USB endpoint. Instead of "wasting" time trying to figure out exactly how it worked, I started working with the ASF examples, and got a working proof of concept on my EVK1104. Now that I've proven that my project is feasible I can spend some more time trying to understand what's actually happening at a more detailed level, and try to find any areas I can optimize (speed, size, etc).

I personally found the datasheet to not be helpful in understanding the DMA controller. After reading that section I was still just as confused. It wasn't until reading through, and more importantly working with the examples that I began to understand how it all works.

In AVR studio, if I look at all the DMA example projects for AVR32 devices, all the ones using a PDCA do the same thing (transfer static flash memory to UART), while the others use a DMACA to do transfers from memory to memory, which isn't really relevant to the UC3B parts. Are you referring to other projects which happen to use the PDCA?

I was referring to the PDCA, not the UDDMA, but I guess the question still applies. How can the compiler know in advance what those address registers will be, and how much memory space the buffers will take? Do you have to declare the buffer as a static data type at the beginning of the program, and ensure it's big enough to fit whatever buffer size you could possibly want? That's what's done in the example project I have, anyways.

What do you mean by "natural boundaries"?

So you mean that when an endpoint is full (while transmitting) or empty (when receiving) it can automatically start writing/reading another endpoint?

Will this happen when just one endpoint fills up or all of the enabled ones?

Well so far I'm finding the USB stuff to be orders of magnitude more confusing than the DMA,(...)

On the contrary, after reading through the datasheet I came off thinking that the DMA was too simple. At the bit/register level it's really straightforward, but the datasheet gives no insight into the details of handshaking, timing, or coding. At least that's the case for the PDCA;

the UDDMA is still killing me. Nominally ASF takes care of that stuff, but I find the ASF USB code to be almost unusable.

The compiler can’t know that so you either have to use static buffers or use malloc() for dynamic buffers. It’s up to you to make sure that the used buffer is large enough for whatever you want to put in there. Btw, don’t use local variables/arrays as buffers because they’ll be invalidated once you leave the function you declared them in.

Half-words must start at an address that’s evenly divisible by 2, words must start at an address that’s evenly divisible by 4. (And quarter-words, aka. bytes, must start at an address that’s evenly divisible by 1. )

No. You can configure an endpoint to use two banks with half the endpoint’s size each. You can only have one bank open for access at any time and you have to release it when it’s full/empty. With two banks you can access one while the USBB filling/emptying the other one, increasing performance and avoiding wait times. It’s explained in the AVR32B’s datasheet.

I'm going to want to take 16 bit SPI data and transfer it to a UART in bytes. So I can I use a DMA channel (say 0) to do half word transers from SPI to a buffer, and then use another DMA channel (say 1) to do byte transfers from the same buffer to the UART? Will each 32 bit register in the buffer be used fully (storing two 16 bit SPI results), since DMA channel 0 increments its address by two bytes, rather than by a whole register? And will channel 1 not miss any of the bytes?

Okay so I take it when you say "bank," you don't mean the endpoint itself, but a block of SRAM that's meant as a buffer for the endpoints...?