* merged: nrf tree from unicore-mx
* fixed: small changes to make merged code play with rest of locm3 again
* added: linker script generator defines for nRF51/52 stubs
* added: doxygen support
This removes code and changes names and styles where relevant to be more
inline with normal libopencm3.
NRF52x library is built for hardfloat, M4F by default. The M4 no float
variants are less common, and if needed, the library can be built
manually for those variants. Unless some very common boards show up
using those parts, we don't need an extra library build.
Reviewed-by: Karl Palsson <karlp@tweak.net.au>
Tested-by: Karl Palsson <karlp@tweak.net.au>
Updates to a base set of includes to map to the h7 include files which are
mainly based on the f7 versions for simple devices (e.g. SPI, USART, GPIO).
Custom files that have been implemented from the datasheet/ref manual include
the memory map, RCC, PWR definitions, and irq.json file for generation of
nvic files for interrupt mapping.
Additional functionality, especially PLL and tweaks for non-F7 compatible
implementations coming in future commits.
Added documentation tree configuration.
Reviewed-by: Karl Palsson <karlp@tweak.net.au>
Changed dmaX_streamX to dmaX_strX in a few places for consistency
SWM050 is a series of MCU made by Foshan Synwit Tech. It contains a
Cortex-M0 CPU core, 8KiB of Flash and 1KiB of SRAM. The only peripherals
are GPIO, Timer and WDT. There's only two parts in this series, with
either TSSOP-8 or SSOP-16 packages.
This commit introduces the interrupt vector and GPIO support for them.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
GD32F1X0 (X can be 3, 5, 7 and 9) is a series of Cortex-M3 MCUs by
GigaDevice, which features pin-to-pin package compatibility with
STM32F030 MCU line. F150 adds USB support to F130, and F170/F190 adds
CAN support.
Currently the code mainly targets GD32F130 and F150 chips. Some register
are different between F130/150 and F170/190, just like the difference
between STM32F1 Performance line and Connectivity line.
From the perspective of registers and memory map, GD32F1X0 seems like a
mixture between STM32F1 and STM32F0 (because it is designed to be
pin-to-pin compatible with F0, but with Cortex-M3 like F1). A bunch of
code are shared between STM32 and GD32, and these code are specially
processed to include the GD32 headers instead of STM32 headers when meet
GD32F1X0.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Reviewed-by: Karl Palsson <karlp@tweak.net.au>
gd32/rcc.[ch] are forks of stm32f1/rcc
gd32/flash.[ch] are forks of stm32f0/flash
No attempts at deduplicating this have been done at this stage. We can
see where they move in the future.
The original submitter of this squished everything into one series, and
has not returned. The code mostly appears good, and review comments were
followed for the most part. The project doesn't really maintain any
testing or board farm for sam3/sam4 parts, so we're going to just trust
our users.
Reviewed-by: Karl Palsson <karlp@tweak.net.au>
sam/4l: IRQ Configuration file (irq.json)
sam/4l: Basic Memory Map.
sam/4l: GPIO Defines.
sam/4l: GPIO Functions
Added everything that needed to compile the library: Makefile, Linker
Script and common includes.
sam/4l: SCIF function to start OSC.
sam/4l: GPIO Enable/Disable and Multiplexing configuration functions.
sam/4l: PLL Clock configuration.
sam/4l: Peripheral clock configuration and basic USART support.
sam: USART Character length configuration.
sam/4l: Generic Clock configuration functions.
sam/4l: Analog to Digital Converter Interface (ADCIFE) basic support.
Thoughts: should this be a "sam0" family rather than samd? (Much like Atmel's
own software package lumps all the cortex-m0+ devices in one family)
This was enough to get a basic blinky working at least.
Newlib and arm-non-eabi-gcc likes to use the FPU by default on
Cortex-M4F chips. AS a result, do the right thing and enable the FPU
by default.
This fixes issues where code is generated which uses the FPU and
causes the CPU to hard-fault. This change removes the responsibility
of FPU initialization from the application code.
This makes the lm4f consistent with other M4+ devices that enable the
FPU in core library startup code.
Signed-off-by: Karl Palsson <karlp@tweak.net.au>
Helpful if you don't like seeing:
(gdb) vecstate
HardFault: forced due to escalated or disabled configurable fault (see below)
UsageFault due to access to disabled/absent coprocessor
Values from RM0351rev1, with the correction of the duplicate TIM1_CC entry.
Only stub support so far, but this opens up the beginning of build testing.
Most changes are noise from doxygen.
Readme udpated to explain newer FP_FLAGS for m7
stm32f7 library is skipped if the toolchain doesn't support it yet.
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).
Added --terse and --mailback options to the make stylecheck target. It
also does continue even if it enounters a possible error.
We decided on two exceptions from the linux kernel coding standard:
- Empty wait while loops may end with ; on the same line.
- All blocks after while, if, for have to be in brackets even if they
only contain one statement. Otherwise it is easy to introduce an
error.
Checkpatch needs to be adapted to reflect those changes.
Add an "#ifdef(LM4F)" clause to include/libopencm3/dispatch/nvic.h
and lib/dispatch/vector_nvic.c. This compiles in the vector table
and allows interrupts to be used.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
the LM3S irq list was previously unused as it was missing in the
dispatch files; now it got added. (before HEAD^, it wouldn't have made
any difference because the discriminating constant wasn't defined
anyway)
also, this enhances the warning messages