Given that there are like a zillion Cortex M libraries out there it is
perhaps the wrong question :-) There is CMSIS from ARM, there is ST's
library, there is the PeripheralTemplateLibrary, etc. To Noah's point
eventually there will be Wiring support and since Arduino is embracing ARM
in a reasonably big way I expect there to be a lot of support from that
community as well.
In that context your question is moot, but it is always useful to talk
about alternative APIs and how it might be improved. Especially if you
agree on the goals (which is the harder part). My goal is a minimal
overhead C API which until I started trying to use the FSMC and SDIO
peripherals this was fine. Now I find I've got my additional 'utility'
library that has some higher level functions in them and I go back and
forth between generality and specificity depending on whether or not I
think I will only build boards with the STM32F4 or if I'll use other Cortex
M4 parts.
--Chuck
On Wed, Oct 9, 2013 at 6:35 PM, Ken Sarkies <[email protected]>wrote:
> On 10/10/13 06:06, Michael Smith wrote:
> > However, IMO the programming model for peripheral en/disable in general
> is completely broken. As it stands, it requires that the application
> programmer know which bus the peripheral is attached to, and thus which
> register must be touched in order to power the peripheral up/down.
> >
> > Since these connections are not consistent between SoCs within the STM32
> family (for example) this means that code is even less portable between
> devices.
> >
> > A better interface would know how to control a specifically-identified
> device.
> >
> > This goes for GPIOs as well; the libopencm3 GPIO API is no better from a
> usability perspective than the ST library's.
> Am I then not the only one a little disturbed by the API (which has been
> historically meandering from quite limited origins)?
>
> The unaskable question is: should we start thinking about a better API?
>
> Is this library likely to have a significant future to justify the work
> needed doing? I believe quite irrationally that the API could be made
> much safer and also have a lot of commonality among families, although
> never fully common since peripherals in each family have their own
> idiosyncracies. It may even be expandable to future ARM CM families on
> the horizon if it were well designed.
>
> Does anyone have any serious reservations about this?
>
> Ken
> > 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
>
------------------------------------------------------------------------------
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
