- STM32 Repository for learning HAL and CMSIS (Baremetal)
- Developing an Enterprise-level Embedded software stack from scratch by identifying and integrating required components
arm-none-eabi-*
GNU Toolchain- CMake
- Ninja
- STM32CubeProgrammer
- OpenOCD
- VSCode Plugins
- CMake
- Cortex-Debug
- C/C++
- STM32 Website for B-L475E-IOT01A
- STM32L475_x examples use the B-L475E-IOT01A board
- STM32 Website for NUCLEO-F746ZG
- STM32F7ZG examples use the NUCLEO-F746ZG board
- Baremetal
- Low level Linker script and Learning
- Integrate critical external components to a project
- doc
- PDF Documents
- STM32_HAL
- STM32 HAL based examples for various microcontrollers
- Template
- Projects built after
Minimal_CMSIS
in Baremetal - Actual application level code
- Projects built after
- third_party
- Third Party software ZIP files
- tools
- Tools used by the project
- Links or ZIP files
AIM: Create a folder structure can would need minimal change when porting between different architectures and microcontrollers
In this below structure to port our project to a different controller we would need to update these folders
- l0_device_specific
- l1_third_party_device_specific
- l2_drivers
+-- l0_device_specific
| +-- arm_cmsis
| +-- linker_script
| +-- device_headers
| +-- device_startup
| +-- toolchain_specific_syscalls
+-- l1_third_party_device_specific
| +-- RTOS
| +-- External_Libraries_device_specific
+-- l2_drivers
| +-- gpio_device_specific
| +-- uart_device_specific
+-- l3_board_specific
| +-- peripheral_initialization
+-- l3_functional_third_party
| +-- ring_buffer
+-- l4_user_module
| +-- external_hardware
+-- l5_application
| +-- application_logic
| +-- main.c
- l0_device_specific
- l1_third_party_device_specific
- l2_drivers
- ARM CMSIS 5 has different compiler and architecture specific changes
- ARM CMSIS 5 Linker script is dependent on architecture of microcontroller
- Device Header is dependent of the Microcontroller Manufacturer
- Device Startup is dependent on ARM Architecture and Microcontroller Manufacturer
- Certain Third Party software changes its behaviour based on the architecture and device
- For example: FreeRTOS needs to be configured differently according to different microcontroller family and architectures
- Basic drivers for GPIO, Interrupt Handing
- Basic protocol for UART, SPI, I2C
- These are microcontroller and architecture dependent
- l3_functional_third_party
- l4_user_module
- l5_application
- For internal board_specific initialization
- Syscalls based externed functions
- Functional Third Party code integrated into the project
- For example: Ring Buffer, JSON Library
Writing code for various hardwares i.e
- Communication
- Sensors
- Actuators
- Application Logic for the project
main.c
resides on the top level
- arm-none-eabi-*
- clang for ARM
- CMake
- Meson
- Bazel
- Premake
- Scons
- Custom Linker Script
- Custom Startup
- Integrate CMSIS Linker Script
- Integrated CMSIS Startup
- CMSIS_5
- STM32 HAL
- Amazon FreeRTOS
- Microsoft ThreadX
- C
- C++
- Rust
- openOCD
-
arm-none-eabi-gdb
- Semihosting
- Unity
- CppUTest
- Google Tests
- Catch
- Fake Function Framework (FFF)
- CMock
- CppUMock
- Google Mock
- Ring Buffer
- JSON Parser
- Clang Format
- Static Analysis
- Code Coverage
- Continuous Integration
- Documentation Generator