use the DMA ( in order to receive block of data) and still filter failures of parity error

Well, you can use DMA when and where you want (for example I'm using DMA with my USB stack), but I didn't found (and spend some time in trying) how DMA can improve (on any way) UART RX (receiving). At the end I finished at starting point, using RX interrupt instead of DMA for UART receiving side. This was related to my MSP430F5xx 4 Mbps USB-UART bridge.

http://forum.43oh.com/topic/3350-msp430f550x-based-usb-uart-bridge

http://forum.43oh.com/topic/3413-msp430-uart-benchmark

Hi Asher,

Do you want to discard characters with errors like FE and PE?  If so, set UCRXEIE =0 (default) in UCAxCTL1.  Then DMA won't pick up characters with errors.

DMA works great as long as you want to ignore breaks and characters with FE and PE.

Jeff

Hi Jeff,

In my case I do need to get errors alerted , raise a flag, and then ignore those bytes (discard those characters with errors).

is there solution for this case??

if i understand your answer correct,  the DMA can not provide  a solution in this case .

Asher.

DMA can move data without CPU. But it cannot do anything else that CPU does.

asher bara said:

Hi Jeff,

In my case I do need to get errors alerted , raise a flag, and then ignore those bytes (discard those characters with errors).

is there solution for this case??

if i understand your answer correct,  the DMA can not provide  a solution in this case .

Asher.

And you are using DMA on UART RX side because of ...

And what MCLK, what baudrate you are using for transfer, 1 Mbps?

Hi ,

Using DMA is to receive messages and to achieve better work efficiency and minimize software interrupts.

The baud-rate will be 57600.

About the hardware itself, the hardware is still in the planning stages. I guess the frequency of the processor will 1Mhz (not clear if it will be possible to reach such frequency with the internal oscillator, but the subject is in test).

If no choice, the solution may be to return using software receive interrupt. instead the DMA. Or to waive the benefit of pe and to prefer checksum test.

Asher

asher bara said:

Using DMA is to receive messages and to achieve better work efficiency and minimize software interrupts.

If you are receiving by UART not-constant len messages (and circular buffer is must), than DMA will not improve anything.

asher bara said:

The baud-rate will be 57600.

About the hardware itself, the hardware is still in the planning stages. I guess the frequency of the processor will 1Mhz (not clear if it will be possible to reach such frequency with the internal oscillator, but the subject is in test).

If no choice, the solution may be to return using software receive interrupt. instead the DMA. Or to waive the benefit of pe and to prefer checksum test.

I am working on USB-UART MSP430F5xx bridge, with MCLK 24 MHz, on 4 Mbps baudrate. If you scale this down to 1 MHz, it still be able to have 166667 bps. It should be possible to work on 57600 without any problem (and without DMA). Just remember, that UART receiving side must be always ready, without possibility to be blocked by other interuppts.

Based on what you claim that there is no advantage to work with the DMA?

Based on the literature? Or from experience?

How do you evaluate that work with interrupt is much more rapid?

 If it from the literature, then in the user guide(slau.odf) it write: that only the RTI is between 5 MCLK Cycles (6.5.1.5 MSP430 Instruction Execution) , and about the interrupt itself

1.3.4.1 Interrupt Acceptance

“ The interrupt latency is six cycles, starting with the acceptance of an interrupt request, and lasting until the

start of execution of the first instruction”

if I add the move command  ( between 1 to 4  MCLK cycles) … and  I sum it all together it will result at least  6 – 8   MCLK cycles for each character that I accept using interrupt.

Instead, there is the DMA , that “Requires only two MCLK clock cycles per transfer”

“The DMA controller requires one or two MCLK clock cycles to synchronize before each single transfer or complete block or burst-block transfer. Each byte/word transfer requires two MCLK cycles after synchronization, and one cycle of wait time after the transfer”

the DMA take about 2 (Without the part of the synchronization and wait time after the block).

Seems significant savings…

Thanks.

Asher

asher bara said:

Based on what you claim that there is no advantage to work with the DMA?

Based on the literature? Or from experience?

How do you evaluate that work with interrupt is much more rapid?

I claim that if DMA is used for UART RX side, where more bytes (unknown not-fixed number) will be received and stored multiple times, there will not be any advanted over standard UART RX ISR. I am using DMA in my USB stack for copyng 32 words (fixed len) from USB RAM to non-USB RAM, and there is no better/faster way to do it.

For me literature is starting reference point. Final result depend on how algorithm is implemented and can be in comletaly differen direction from literature.

If I made 2 versions, one with UART RX ISR, and another with UART RX DMA, and version with DMA don't improve anything but give me more troubles, than my conclusion is that there is no reason for using UART RX DMA in my project.

asher bara said:

 If it from the literature, then in the user guide(slau.odf) it write: that only the RTI is between 5 MCLK Cycles (6.5.1.5 MSP430 Instruction Execution) , and about the interrupt itself

1.3.4.1 Interrupt Acceptance

“ The interrupt latency is six cycles, starting with the acceptance of an interrupt request, and lasting until the

start of execution of the first instruction”

if I add the move command  ( between 1 to 4  MCLK cycles) … and  I sum it all together it will result at least  6 – 8   MCLK cycles for each character that I accept using interrupt.

Instead, there is the DMA , that “Requires only two MCLK clock cycles per transfer”

“The DMA controller requires one or two MCLK clock cycles to synchronize before each single transfer or complete block or burst-block transfer. Each byte/word transfer requires two MCLK cycles after synchronization, and one cycle of wait time after the transfer”

the DMA take about 2 (Without the part of the synchronization and wait time after the block).

Seems significant savings…

Yes, but this is if you are have simple picture in front of you. Let say that you are receiving from UART few commands, with 3 byte len, 6 byte len and 8 byte len. In this case there are must be some way of circular buffer. With DMA transfer will go in 2 cycles, but there are also will be DMA ISR (that eat cycles like any other ISR) for reconfiguring DMA (prepareing for filling up circular buffer with new commmand).