DMA Operation

[electroRF]

Hi guys,

I'd appreciate your input on this.

When it is said that a DMA can be programmable with data-burst sizes (8, 16, or 32 bytes), what does it mean?

At each Transfer Operation, it takes 8, 16 or 32 Bytes?

Thank you.

 

[misterT]

You should read the details from the devices datasheet.

Simply put, the DMA transfers the "burst"-amount of data and then triggers an interrupt or waits for an event or just transfers another block etc. There are many reasons to use short or long bursts.. maybe you don't have much data to move, or maybe you need to move data between many locations and do not want to keep others waiting too long.

EDIT: I mixed burst mode a little bit with "block transfrer" and "dma transaction" there. Basically burst mode is an "atomic" operation for the DMA. It does not let anything interrupt one "burst". Between bursts the CPU may take over. Now.. if that happens while you are transferring 2 byte ADC data (in 1 byte bursts), then the data may get corrupted. At least in Atmel Xmega, the CPU and DMA share the same databus.

This is what Xmega datasheet says:

Since the AVR CPU and DMA controller use the same data buses, a block transfer is divided into smaller burst transfers.
The burst transfer is selectable to 1, 2, 4, or 8 bytes. This means that if the DMA acquires the data bus and a transfer
request is pending, it will occupy the bus until all bytes in the burst are transferred.

A bus arbiter controls when the DMA controller and the AVR CPU can use the bus. The CPU always has priority, and so
as long as the CPU requests access to the bus, any pending burst transfer must wait. The CPU requests bus access
when it executes an instruction that writes or reads data to SRAM, I/O memory, EEPROM or the external bus interface.

.. but, like I said, you need to read the datasheet of your processor.

 

[electroRF]

Hi T,
Thank you very much

I understand everything you said.

However, according to what you said, I tend to disagree though with the following:

Between bursts the CPU may take over. Now.. if that happens while you are transferring 2 byte ADC data (in 1 byte bursts), then the data may get corrupted.

Why would the ADC Data get corrupted?

Even if the DMA transfer 1st ADC Byte, then the CPU takes over the controls the bus, and when CPU finishes, the DMA will transfer the 2nd ADC Byte.
Where could the ADC Data get corrupted in that bus arbitration?

 

[misterT]

Why would the ADC Data get corrupted?

Even if the DMA transfer 1st ADC Byte, then the CPU takes over the controls the bus, and when CPU finishes, the DMA will transfer the 2nd ADC Byte.
Where could the ADC Data get corrupted in that bus arbitration?

Maybe the CPU writes to the same location. Or a new ADC result overwrites the data before the DMA can finish transferring the previous data.
.. or maybe the CPU reads the data before it is all transferred.

 

[misterT]

Or a new ADC result overwrites the data before the DMA can finish transferring the previous data.

I have to correct myself. I think it is pretty standard to have double buffer on (2 byte) ADC result registers. This means that when you read the low-byte, the adc result will not be updated until you have read the high-byte.
This is one source of bugs.. if you read high-byte first and then low-byte, the ADC register gets "stuck".

I know that the ADC/DMA example was kind of poor. There is only a very small chance that the data gets corrupted between bursts. But the point is that it can get corrupted. If you move 16bit data in 16bit bursts, then the data can not get corrupted.