On 09/10/2013, at 12:03 PM, [email protected] wrote:
> Linge> void rcc_peripheral_enable_clock(clock_enable_reg_t > Linge> clock_enable_reg, uint32_t en); > > I think that function is overcomplicated and as you point out dangerous. > > What is the advantage of e.g. writing > rcc_peripheral_enable_clock(&RCC_APB1ENR, RCC_APB1ENR_USBEN); > against directly writing > RCC_APB1ENR |= RCC_APB1ENR_USBEN; The function as it stands does nothing useful. 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. = Mike ------------------------------------------------------------------------------ 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
