it sounds like what you're suggesting is an additional layer like
Wiring that is based on a small database tailored toward achieving the
same effect across multi-CPUs. this could be done with the underlying
layer or the ST one without disturbing the existing stuff. the value
is really in the collections of database info that translate from
application-level "GPIO("A5") to the group of commands (this bus, that
bus, this word, this reg, this bit) require to effect it.
from what I can see so far, the arm architecture is simply funky in
that the complete nexus of hardware peripherals must be known. it's
not that the existing functions are broken, it's that the architecture
is so flexible imo.
just like the OSI model has layers i think a second layer API would be
useful... and why not Wiring? the Maple project ported it to cortex
m3 and at one point gbulmer had ported at least some of it to cortex m4.
--
http://diydsp.blogspot.com has wild and wonderful digital music instruments
Quoting Ken Sarkies <[email protected]>:
> 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
