Dummy questions from a newbie regarding how to use DMA

Il 22/08/2016 15:24, David Brown ha scritto:
> On 22/08/16 14:49, pozz wrote:
>> Il 22/08/2016 13:29, David Brown ha scritto:
>
>>> And you also want to check if you really /need/ the DMA here.  If the
>>> processor is not overloaded, an ISR can be simpler and easier - and
>>> often it does not matter if that "wastes" a few percent of your cpu
>>> capacity.  DMA on transmit is often very simple, but for receive the
>>> complications of timings and timeouts can make the DMA less of a win.
>>
>> What do you mean with "timings" and "timeouts"?  I think those
>> complications must be implemented even with the "simple" ISR-only approach.
>>
>
> Indeed they do need to be implemented in the ISR-only approach - but
> then you have fewer bits that need to interact.
>
> For example, if you have an incoming telegram and you want to react
> quickly when it has been completely received, an ISR can give you that
> easily.  When the interrupt for the final character arrives, you trigger
> your handling action.

Oh, I got your point now.  However I never had the need to trigger an 
action quickly after receiving a message from the UART.  I usually use 
UART for not real-time tasks.
Anyway the processing of an incoming message could take some time (CRC 
check, destination address, ...)


> But if you are using a DMA then it will just be
> one more character in the buffer - you don't get an interrupt until the
> buffer is full.  So you need additional methods, such as timer
> interrupts, to regularly poll the DMA buffer to see if the final
> character has come in.

In ISR-only implementation, I already use this approach.  In the main 
task I poll the FIFO buffer (continuously or with a timer) to check for 
new incoming data.


> So a DMA on receive is good for some things, but adds complications for
> other tasks.
>
> DMA on transmit, however, is usually very simple because you know
> exactly how much you are sending.  It gets "fun" if you want to add to
> the DMA buffer while the DMA is running - synchronising between DMA and
> the processor is not always a simple task.  It is really easy to make
> something that works fine most of the time (and during all your
> testing), yet fails if the DMA triggers half-way through the buffer add
> function.

I see.

On Mon, 22 Aug 2016 14:42:29 +0200, pozz wrote:

> Il 22/08/2016 13:45, Dave Nadler ha scritto:
>> On Monday, August 22, 2016 at 7:03:55 AM UTC-4, pozz wrote:
>>> ...No, I don't have a fixed message size.
>>
>> A variable sized message means you have to periodically poll the
>> results, which means stopping the DMA and likely restarting DMA with a
>> different buffer.
> 
> Why stopping the DMA?  DMA should silently work in background, even if
> I'm checking for its results.

Well, if you mean "should" as in "is morally obliged to", yes.

But if you mean "should" as in "can be reasonably expected to" -- 
unfortunately, no.

Bottom line -- you can't count on your assumed behavior for a part to be 
the designer's assumed behavior for the part, or for the part's actual 
behavior to match either of the assumed behaviors.  You just have to read 
the data sheet (or "user's guide") closely, and then hope that you 
haven't missed anything.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

I'm looking for work -- see my website!

Il 22/08/2016 19:40, Tim Wescott ha scritto:
> On Mon, 22 Aug 2016 14:42:29 +0200, pozz wrote:
>
>> Il 22/08/2016 13:45, Dave Nadler ha scritto:
>>> On Monday, August 22, 2016 at 7:03:55 AM UTC-4, pozz wrote:
>>>> ...No, I don't have a fixed message size.
>>>
>>> A variable sized message means you have to periodically poll the
>>> results, which means stopping the DMA and likely restarting DMA with a
>>> different buffer.
>>
>> Why stopping the DMA?  DMA should silently work in background, even if
>> I'm checking for its results.
>
> Well, if you mean "should" as in "is morally obliged to", yes.
>
> But if you mean "should" as in "can be reasonably expected to" --
> unfortunately, no.

I think you haven't to stop DMA to check how many bytes are already 
transferred in the FIFO buffer.
If there are any, the application can pop those bytes from FIFO buffer 
to an application-level buffer where the protocol is able to understand 
if the message is complete, corrupted, and so on.


> Bottom line -- you can't count on your assumed behavior for a part to be
> the designer's assumed behavior for the part, or for the part's actual
> behavior to match either of the assumed behaviors.  You just have to read
> the data sheet (or "user's guide") closely, and then hope that you
> haven't missed anything.
>