You can't have two mainpage items, and the second was just being
ignored. This restores them, which makes the left side list longer,
which we may or may not like, but it's at least how it was documented to
be.
All the macro arguments that are user supplied, or potentially, wrap properly
in () as good practice.
Probably missed one or two, and a lot of them are possibly unnecessary, but
it's straightforward to just do it always.
Fixes github issue #321
Add I/O mux controller which is required to mux pins according to
their used function. For all pads, the alternative function 0 is
GPIO. For different pin mux function refer to the reference manual.
This adds GPIO module support. GPIO can be controlled using the GPIO
number as stated in the reference manual, similar to Linux. Also
32-bit access to whole ports is possible. Reading a GPIO is possible
without muxing the pad as GPIO, however writing a GPIO needs the pad
to be muxed as GPIO.
This adds UART support for Vybrid VF6xx. Baud rate is calculated
from IPG clock, which need to be initialized by using the
ccm_calculate_clocks functions. Also clock need to be gated using
the ccm_clock_gate_enable function. Tested with an unitialized
UART with a baud rate of 115200.
Extend the clock controller module with a function to calculate
core clocks from the current registers settings. On Vybrid, we
assume that the core clocks are setup by the main operating system
running on the Cortex-A5. Nevertheless we need to know their actual
values in order to calculate other clocks or baud rates.
Verified on a Colibri VF61, which calculates following values:
ccm_core_clk: 500210526
ccm_platform_bus_clk: 166736842
ccm_ipg_bus_clk: 83368421
Add initial memorymap for Vybrid VF6xx module. Also add the clock
control module which allows to control system clocks and enable
clocks of individual pheripherials.
Freescale Vybrid is a familiy of ARM SoC, wheras the VF6xx models
have two cores in one SoC, a Cortex-A5 and a Cortex-M4. This adds
initial support for the Cortex-M4 in the libopencm3 library.
By using two different ram areas (pc_ram and ps_ram) the user can
put the code in a RAM area bounded to the code bus. The data can
be stored in the data area. However, currently the initial values
of for the variables in the data section are stored in the code
section and copied to the ram section by the initialization code
(like it's copied from ROM to RAM on microcontrollers).
Karl Palsson