Hello,

On Wed, 9 Oct 2013 12:06:18 -0500
Linge Dai <[email protected]> wrote:

> Hi,
> 
> I'm using STM32F4 + libopencm3. I have noticed that some of the
> library functions are declared to have a pointer to registers as a
> parameter:
> 
> For example, in rcc.h:
> void rcc_peripheral_enable_clock(volatile uint32_t *reg, uint32_t en);
> 
> which allows modifying any arbitrary register. The programmers need to
> explicitly enforce restrictions on what to pass to the function. Is
> the API meant to be designed this way?
> 
> A fix to this problem is to wrap the valid register values in an enum
> and use the enum as the function parameter. The new declaration of
> this function will be:
> 
> void rcc_peripheral_enable_clock(clock_enable_reg_t clock_enable_reg,
> uint32_t en);

Would it change *that* much? There still will be a function which needs
to be called, do the dynamic bit manipulation and return. Shouldn't it
be something like:

peripheral_enable_clock<clock_enable_reg_t, uint32_t>() to emphasize
that it should be compile-time constants?

Actually, shouldn't it be Block::clk_foo::enable() ?

Shameless plug: https://github.com/pfalcon/PeripheralTemplateLibrary
tries to do exactly that, providing efficient abstraction of MCU blocks
and algorithms. Already has something to show off across AVR, MSP430 &
Cortex-M.


-- 
Best regards,
 Paul                          mailto:[email protected]

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
_______________________________________________
libopencm3-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libopencm3-devel

Reply via email to