[En-Nut-Discussion] Designing Interfaces, e.g. DMA
Ulrich Prinz
ulrich.prinz at googlemail.com
Tue Jul 3 23:16:31 CEST 2012
Hi!
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.
Regards
Ulrich
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