MSP430 DMA efficiency

Paolo Meriggi said:

I have read that using DMAs on MSP430 causes a 20% free CPU time

Where did you read that?

Paolo Meriggi said:

Actually the fw i coded is in the 3rd mode (basically due to my laziness), but any comments (or reference to further literature/examples) about the issue is very very welcome.

You can run out of DMA channels using 1st approach. I think that it is worth to try using DMA for energy saving, just overcome your laziness and create one, measure current consumption for DMA+LPM and IRQ+LPM approach.

Ilmars said:

I have read that using DMAs on MSP430 causes a 20% free CPU time

Where did you read that?

[/quote]

He is referencing to DMA burst mode, when the CPU is not stopped, but executing together with DMA transfer (with 20% CPU execution capacity).

Hi,

Since only few MSP430 support more than 3 DMA channels, one will have to use them for most timing-critical transfers.

DMA is a lifesaver when dealing with high-speed serial ports while not wishing to crank 430 to high clock speeds (i.e. 12+ MHz). E.g. 1MHz device generally fails to receive UART bytestream at bitrates higher than 57600 (19200 is realistic), while DMA-enabled reception handles 115200 without any problem. The only problem is that using DMA does not permit straightforward implementation on pause-based UART packet protocols.

Oleg Komlev said:

DMA is a lifesaver when dealing with high-speed serial ports while not wishing to crank 430 to high clock speeds (i.e. 12+ MHz). E.g. 1MHz device generally fails to receive UART bytestream at bitrates higher than 57600 (19200 is realistic), while DMA-enabled reception handles 115200 without any problem. The only problem is that using DMA does not permit straightforward implementation on pause-based UART packet protocols.

If my 430 is running @ 24 MHz and it should move blocks of 256 or 512 bytes, what kind of benefit should I receive by using DMA? I am a little worried by the figure of 20% of CPU available in burst mode, since I don't know if that could influence other IRQs as well...

Paolo Meriggi said:

If my 430 is running @ 24 MHz and it should move blocks of 256 or 512 bytes, what kind of benefit should I receive by using DMA?

Either you free-up CPU while DMA is doing full-speed RAM to RAM transfer because you still have 20% of CPU resources for other tasks.

In case DMA transfers are not full-speed but for example 2 bytes each 2ms, then CPU can sleep whole DMA transfer time. In this case you will have better power efficiency than when using CPU to transfer same data because CPU consumes much more cycles for each 2byte manipulation than DMA.

Paolo Meriggi said:

If my 430 is running @ 24 MHz and it should move blocks of 256 or 512 bytes, what kind of benefit should I receive by using DMA? I am a little worried by the figure of 20% of CPU available in burst mode, since I don't know if that could influence other IRQs as well...

From where to where and why you need to move 256/512 bytes? Moving 1 byte, after some time another... or all at once?

For example if I need to receive 5 KB from PC to MSP430F5xx over USB at once, than I will copy 64 byte blocks from USB RAM to non-USB (main) RAM using DMA because USB RAM is limited to 2 KB. Of course, with benefit.

If I just need to receive 1.5 KB from PC to MSP430F5xx over USB at once, than I will not go outside of USB RAM space, and don't need to copy anything anywhere, and DMA is not needed.

Paolo Meriggi said:

If my 430 is running @ 24 MHz and it should move blocks of 256 or 512 bytes, what kind of benefit should I receive by using DMA?

The main advantage is that DMA can react on a hardware trigger without having the CPU constantly checking the trigger or entering an ISR.
An single DMA transfer will take only 4 MCLK cycles. Less than the CPU would require to just execute the move instruction. Not to count the time to check for the trigger.

For a memory/memory block transfer, usually, the transfer time isn't that important and the advantage of DMA is eaten up by the required setup time. it can be used, especially to initialize arrays from a flash table or such things, but unless timing is very critical and every clock cycle counts, this can be done by CPU as well.
But if you want to e.g. receive (or send) data using SPI with maximum speed, CPU might be too slow.
You have 8 MCLK cycles per byte, which is plenty for DMA (both, receive and send at the same time), but by far not enough to do the same with the CPU. Here DMA excels.

Also, if you want to spend as much time as possible in sleep, you can use DMA to handle incoming UART transfers until the buffer is full, or send out data in a buffer, with the CPU in sleep. Same for ADC conversion results.

One usage for DMA I just did in a project was waveform generation. I used the DMA @8MHz to output D/A values to the D/A converter with 4mHz sampling frequency. The values were precalculated and the result was a fine sine-wave output with 50kHz and 80 points per wave (very low distortion). With CPU, I could have done only a fraction of it.

Paolo Meriggi said:

I am a little worried by the figure of 20% of CPU available in burst mode, since I don't know if that could influence other IRQs as well...

True, it is either DMA or byte-per-byte processing - and in former case it is harder to clean the mess in case of truncated packet.

333kbps is entirely possible on bare device (after all, it is ~33 core cycles per byte), but toss in CC430 radio and (worst of all) C workflow, and...well, it gets worse :)

I was wondering if there was any information about using the single-transfer or repeated-single-transfer modes of DMA.

I would expect these modes would have a similar effect to the burst mode except possibly inverted since the bus rate (or other data trigger rate) would dictate the rate of transfer execution and thus you should see a high transfer rate and have more than 20% CPU efficiency for any data rate below a certain frequency.

Does anyone have any experience in this regard?

The explanation in the users guide is quite complete.

The perhaps missing hint is that both, DMA and CPU, compete for access to the memory bus. On each MCLK cycle, only one sing byte/word can be read or writing (including CPU instructions). So a DMA transfer requires 2 MCLK cycles during which the CPU is stalled, as it cannot do anything.

To summarize: Single transfer: one trigger, one single transfer (byte/word). After this, the CPU will continue until next trigger.
block transfer: one trigger, a whole block of data is copied. Which takes 2 MCLK cycles per byte/word transfer, during which the CPU is halted.
burst transfer: one trigger, a whole block is copied. But after every two transfers, the DMA pauses and lets the CPU do something for a clock cycle. (4:1 = 20% CPU time)

Repeated modes mean, after the programmed number of bytes has been copied, the next trigger will start all over.

After posting that I found the information I was looking for in the state diagram for single-transfer. What I wanted to know was if it released the memory bus between single transfers, which it does.

I've since calculated that it would be very efficient to use single-transfer mode (for UART or I2C) based on the clock speeds and the time the DMA module would occupy the memory bus.