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
