Interesting library, I noticed it has 'blink tick' below: Can you compare
the chunk sizes of that on the STM32 with the one that is in
libopencm3-examples ? (I pulled a copy of the repo but I've got some
missing dependencies to work on before I can do this test)
#include <gpio.hpp>
#include <cpu.hpp>
#include <board.hpp>
#include <timer.hpp>
#include <rtos/ticks.hpp>
using namespace PTL;
typedef Ticks<> delayer;
typedef board::LED led;
namespace PTL {
// For Ticks to actually work, we must route hardware timer
// interrupts to it
IRQ_DISPATCH(timer, delayer::Irqs);
}
int main()
{
cpu::init(cpu::DEFAULT);
led::port::enable();
led::output();
timer::free_run();
timer::enable_irq();
cpu::enable_irq();
while (true) {
led::low();
delayer::delay(10);
led::high();
delayer::delay(10);
}
}
On Wed, Oct 9, 2013 at 1:03 PM, Paul Sokolovsky <[email protected]> wrote:
> 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
>
------------------------------------------------------------------------------
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
