[En-Nut-Discussion] Designing Interfaces, e.g. DMA

Ulrich Prinz ulrich.prinz at googlemail.com
Tue Jul 3 23:16:31 CEST 2012


I fear that there is a good reason why ADC and DMA are not available as 
unified nut/os interfaces.

DMA and ADC are highly manufacturer depending. While DMA copies things 
from A to B and might be unified, ADC is a total mess.

The list starts with options like differential or not, multiple 
references or only one, external or internal, DMA (STM32!) support or 
only interrupt. Multiple conversion or single or burst? Or even burst 
multiple with priority?

Could be that it is possible to use a setup struct like guessed for DMA.
On the other hand... it is highly project dependent what you like to do 
with the ADC. So it might be up to the user what to do with the ADC and 
how to correctly set it up. We could provide some chip specific examples 
of how to use it.


Am 03.07.2012 13:36, schrieb Uwe Bonnes:
>>>>>> "Harald" == Harald Kipp <harald.kipp at egnite.de> writes:
>      Harald> Hi Ulrich, Hi Uwe,
>      Harald> On 02.07.2012 22:00, Ulrich Prinz wrote:
>      >> Am 29.06.2012 11:20, schrieb Uwe Bonnes:
>      >>> void DMA_Enable(uint8_t ch); void DMA_Disable(uint8_t ch);
>      Harald> I'm still not very familiar with LPC and STM32 chips. Still I'm
>      Harald> wondering, who would want to enable or disable DMA.
>      Harald> Are these functions usable by application code or are they just
>      Harald> for drivers?
> The first use case is for drivers internal. So no need for a public
> interface. Larger memcpy could also be implemented with DMA. But probably
> this is also architecture specific. So DMA was no good example. But maybe
> ADC is an better example. But I will come up, when time allows with
> something line stm32can.h modelled after atcan.h and stm32adc.h modelled
> after adc.h  and at91_adc.h, as a base for discussions.
> Bye

More information about the En-Nut-Discussion mailing list