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
