Hmm, they haven't pulled it yet but look at
https://github.com/ChuckM/libopencm3-examples
Which has blink_tick in it. But that said, I did get it to build (using the
arm-none-eabi- toolchain from ARM Ltd)
I got stuck trying to figure out how I'd template the STM32F4-Discovery
board though. The docs on that are a bit thin :-) And then I got distracted
seeing if I could get the MSP430 working (which apparently I've got old
firmware on my launchpad board so that was a no go). Way to easily
distracted I think.
We can take this off list I suspect its not exactly interesting to others
here.
--Chuck
On Wed, Oct 9, 2013 at 5:02 PM, Paul Sokolovsky <[email protected]> wrote:
> Hello,
>
> On Wed, 9 Oct 2013 15:41:41 -0700
> Chuck McManis <[email protected]> wrote:
>
> > Interesting library,
>
> Thanks.
>
> > 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)
>
> Which one of libopencm3-examples you'd like to compare exactly?
> blink_tick implements RTOS-like (or Arduino-like if you prefer) delay
> waiting: OS has "ticks" variable, and you do all time handling
> using it. I didn't see something like that in libopencm3-examples. If
> you mean systick.c, which toggles LED in IRQ handler, then closest
> would be irq_dispatch_simple.cpp.
>
> Built with default -Os (stm32/f1/other/systick/):
> $ arm-none-eabi-size systick.o systick.elf
> text data bss dec hex filename
> 136 0 4 140 8c systick.o
> 1328 8 4 1340 53c systick.elf
>
>
> It makes little sense to build PTL with -Os, GCC (at least pretty
> ancient Sourcery G++ Lite 2010.09-51) 4.5.1) misses a lot when to do
> inlining and when not:
>
> -Os
> $ arm-none-eabi-size irq_dispatch_simple.o irq_dispatch_simple
> text data bss dec hex filename
> 146 0 0 146 92 irq_dispatch_simple.o
> 302 0 0 302 12e irq_dispatch_simple
>
> -O2 gets it right:
> $ arm-none-eabi-size irq_dispatch_simple.o irq_dispatch_simple
> text data bss dec hex filename
> 116 0 0 116 74 irq_dispatch_simple.o
> 252 0 0 252 fc irq_dispatch_simple
>
> Note also that irq_dispatch_simple doesn't do any counter checks in IRQ
> handler.
>
>
> For comparison, systick -O2:
> $ arm-none-eabi-size systick.o systick.elf
> text data bss dec hex filename
> 164 0 4 168 a8 systick.o
> 1356 8 4 1368 558 systick.elf
>
>
> Full binary sizes are kinda for completeness, they can't be compared
> one to one: PTL's includes just Cortex-M core IRQs and doesn't init
> crystals/PLLs. PTL is a research proof of concept library, not really
> suitable for developing USB gadgets yet ;-). On the other hand,
> irq_dispatch_simple is even more magic than it seems. You can't really
> abstract IRQ handling across MCUs while retaining asm-like efficiency.
> At least that was my presupposition. And yet irq_dispatch_simple runs
> on both MSP430 and ARM with the same source and with decent resulting
> asm. Hand-rewriting might save couple of bytes and couple of cycles, but
> that's about it.
>
> []
>
> >
> >
> > 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
> > >
>
>
>
> --
> 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