# STM32Cube MCU Overall Offer: the map of ST's open source embedded software > The STMicroelectronics/STM32Cube_MCU_Overall_Offer repository is an index rather than code: three markdown files and an images folder that route an engineer to the right STM32Cube repository for a given microcontroller series, and explain the split between the HAL1 and HAL2 hardware abstraction layers. It is a starting map for STM32 developers, not a library to depend on. **STMicroelectronics/STM32Cube_MCU_Overall_Offer** — This repo describes all STM32 MCU related GitHub projects. The open source offer for the STM32 MCU products - Repository: https://github.com/STMicroelectronics/STM32Cube_MCU_Overall_Offer - Stars: 737 · Forks: 111 - Language: Unknown - License: not declared - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/stmicroelectronics-stm32cube-mcu-overall-offer ## An index with three files and a folder of images The repository is small by design. Its top-level contents are README.md, STM32Cube_HAL1_Offer.md, STM32Cube_STM32C5.md and an images directory, and the description says it describes all STM32 MCU related GitHub projects and offers the open source offer for the STM32 MCU products. What the README does is routing. It gives a concise overview of the STM32Cube embedded software available for STM32 microcontrollers, with links to the relevant repositories, and it directs readers to the appropriate introduction page depending on the series in use. The images directory holds the icons used in the series tables, including the Mainstream, High-performance, Ultra-low-power and Wireless markers that group the parts. For an STM32 developer, this solves a navigation problem rather than a technical one. The STM32Cube ecosystem is spread across many repositories, one per component and per pack, and the choice of where to look depends on the exact part family. The index makes that choice explicit in a way a search engine cannot. It is also a mirror of the vendor's own view of its catalogue. The README notes that the same resources are accessible through www.st.com, through the STM32CubeMX tool and through the STM32 Example Library, so this repository is the GitHub-native index of an offer that exists in several places. ## HAL1 and HAL2 split the catalogue by generation The most decision-relevant content in the README is the split of the hardware abstraction layer into two major versions. HAL1, version 1.x.x, is included in the STM32Cube MCU packages listed in the HAL1-based software table, and it is also present in the STM32Cube MPU packages. HAL2, version 2.x.x, is included in the packages listed in the HAL2-based table. The README states that HAL2 is introduced with the latest STM32 series and that it offers enhanced features and improved performance. The series tables then assign each family. The HAL2-based table currently has one entry, Mainstream STM32C5, which points to a dedicated page for that series. The HAL1-based table groups the rest into four rows: Mainstream covering STM32C0, STM32F0, STM32F1, STM32F3, STM32G0 and STM32G4; High-performance covering STM32F2, STM32F4, STM32F7, STM32H5, STM32H7, STM32H7RS and STM32N6; Ultra-low-power covering STM32L0, STM32L1, STM32L4, STM32L5, STM32U0, STM32U3 and STM32U5; and Wireless covering STM32WB, STM32WB0, STM32WBA, STM32WL and STM32WL3. That table is the practical takeaway. Before you write driver code you need to know which abstraction generation your part is served by, and the answer changes with the series rather than with the peripheral. ## HAL for portability, LL for people who know the silicon Inside either generation the README describes two layers with different audiences. The Hardware Abstraction Layer is described as ensuring maximum portability across the STM32 portfolio, and it is complemented by the low-layer APIs, described as a lightweight, expert-oriented layer closer to the hardware. The README makes a point that surprises newcomers: both HAL and LL APIs can be used together with minimal restrictions. That last sentence is the practically useful one. The usual fear with a portable layer is that you lose the ability to touch a register when you need to, and the README says you do not have to choose. You can start in the portable layer for the bulk of the code and drop to the low-level API for the few places where timing or a specific register matters. The low-layer API carries a different cost, which is that it is tied to the hardware and therefore to a specific device family, so code written against LL is not portable in the way HAL code is. The expert-oriented framing in the README is a hint about who the LL layer is written for. If you are porting between parts, the HAL is what makes that possible. If you are chasing a hard timing requirement on a product, the LL layer is the escape hatch, and using both together is a supported arrangement rather than a workaround. ## The modular repositories: CMSIS, board drivers, middleware and utilities Beyond the all-in-one repositories, which include example projects for popular development kits such as Nucleo and Discovery boards, the platform provides modular repositories for specific components and packs. The CMSIS interfaces give access to the Arm Cortex-M processor core features and to device-specific peripherals of the STM32 microcontrollers. This is the layer closest to the processor itself, and it sits below both the HAL and the LL APIs in the model the README describes. Then there are drivers for additional hardware found on the promotion boards, with the examples given being external memories, audio codecs and screen controllers. These matter because a Nucleo or Discovery board carries components that are not part of the microcontroller die, and each of them needs its own driver. The middleware category covers RTOS, USB, file systems, touch sensing and open bootloader. The utilities category covers standard output redirection and basic task scheduling for bare-metal applications, which is the smallest layer a project without an RTOS would use. The practical takeaway is that the layering is a stack rather than a choice: core interfaces, then the abstraction layer, then board-level drivers, then middleware, then utilities. Knowing which repository holds your problem is most of the work when integrating a new component. ## Where code, issues and contributions actually live The README points out that the STM32Cube resources are accessible in several ways: on the STMicroelectronics GitHub organisation, through www.st.com, through the STM32CubeMX tool and through the STM32 Example Library. The GitHub organisation is the one with a working relationship to developers. The README states that these repositories empower STM32 developers to report issues and contribute updates, facilitated by a Contributor License Agreement feature, and it points to each repository's own CONTRIBUTING guide for the details. Issues therefore belong in the component repository that owns the code, not in this index. The CLA is worth understanding before signing anything. It is a mechanism through which ST receives the right to distribute contributions, which is how a vendor can keep a single official distribution channel while accepting outside patches. Reading the CONTRIBUTING guide of the specific repository you are contributing to is the step that tells you the exact terms in force for that component. For support questions that are not software related, the README points to the ST Community topic catalogue and the ST Support Center, and for a broader view of the ecosystem it points to the Getting Started with STM32Cube Ecosystem documentation. Note also that the STM32 MPU offer lives in a separate repository, STM32MPU_EmbSW_Overall_Offer, so the MCU index does not cover the MPU line. ## The licence is unrecorded and the release history is empty Two facts in the repository metadata are worth stating plainly rather than glossing over. The licence is not recorded, and the primary language is not recorded either, which is consistent with a repository that contains prose and images rather than source code. The repository has no GitHub releases, and the last push was on 2026-06-23. The absence of a licence entry here does not mean the STM32Cube software is unlicensed. The components are distributed under their own terms in their own repositories, and this index merely links to them, so the terms that matter for the driver or middleware you actually use are the ones stated there. If a licence question matters to you, read it in the component repository rather than assuming from this one. The missing release history follows the same pattern. There is nothing to tag or pin here, and the versioning that matters is the version of the component repositories, including the HAL1 and HAL2 version schemes, which is what determines whether your project can move to a newer package without a rewrite. The index itself is maintained, with the last push in June 2026, which is a reasonable cadence for a document that changes when a new series is added to the catalogue or when a family migrates from HAL1 to HAL2. ## The index versus the vendor channels, and the choice in front of you The genuine alternative to using this repository is to skip it and work from the vendor channels directly, through the STM32CubeMX tool, the STM32 Example Library or www.st.com. The README lists all of these as access points for the same software, so the difference is not in the code you get. The difference in approach is in the working relationship. The GitHub repositories are per component and per pack, they are versioned in git with a history you can check out, they have issue trackers where a defect report reaches the people who own that driver, and they accept contributions under a Contributor License Agreement. The tool and the website distribute the same software as prepared packages, which is convenient for getting a project started but gives you no issue history and no upstream patch path. So the choice is between a catalogue that tells you which repository to use, and a tool that hands you a working project configuration. In practice you end up using both, and the index earns its place by removing the guesswork about which family of repositories and which abstraction generation applies to your part. The failure mode to avoid is treating the index as the source. Copying driver code out of an all-in-one package without knowing whether it is HAL1 or HAL2 based, or without tracking which component repository it came from, is how projects end up with fixes that never arrive. ## Conclusion STM32Cube_MCU_Overall_Offer fits an engineer starting an STM32 project who has to decide which family of repositories to work in, and it fits teams that need to know whether a given series is served by HAL1 or HAL2 before choosing an abstraction level. It does not fit anyone looking for source code, since the repository contains no code of its own, and it does not replace the per-component repositories, which hold the drivers, middleware and examples and are where issues and contributions belong. Before you start, open the series page for your part number, confirm whether it is HAL1-based or HAL2-based, and then work in the corresponding driver, middleware and CMSIS repositories rather than in this index. ## FAQ ### What is the STM32Cube MCU Overall Offer repository? It is an index rather than a library. It holds a README, STM32Cube_HAL1_Offer.md, STM32Cube_STM32C5.md and an images folder, and it links to the STM32Cube embedded software repositories that apply to each STM32 microcontroller series. ### What is the difference between HAL1 and HAL2 in STM32Cube? HAL1 is version 1.x.x and is included in the HAL1-based MCU packages and in the STM32Cube MPU packages. HAL2 is version 2.x.x, is introduced with the latest STM32 series, and offers enhanced features and improved performance, with STM32C5 listed as the HAL2-based series. ### Should I use the STM32Cube HAL or the low-level LL API? The README describes the Hardware Abstraction Layer as ensuring maximum portability across the STM32 portfolio, and the low-layer APIs as a lightweight, expert-oriented layer closer to the hardware. It also states that HAL and LL APIs can be used together with minimal restrictions. ### Where do I report a bug in STM32Cube software? Issues go to the component repository that owns the code, since the README says these repositories let developers report issues and contribute updates through a Contributor License Agreement, with each repository carrying its own CONTRIBUTING guide. Non-software questions go to the ST Community or the ST Support Center. ### Does this repository cover the STM32 MPU line? No. The README notes that a separate repository, STM32MPU_EmbSW_Overall_Offer, covers the STM32 MPU offer on GitHub, and this index is limited to the STM32 MCU products. ## Sources - [Issues](https://github.com/STMicroelectronics/STM32Cube_MCU_Overall_Offer/issues) - [README](https://github.com/STMicroelectronics/STM32Cube_MCU_Overall_Offer/blob/master/README.md) - [STMicroelectronics/STM32Cube_MCU_Overall_Offer on GitHub](https://github.com/STMicroelectronics/STM32Cube_MCU_Overall_Offer) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/stmicroelectronics-stm32cube-mcu-overall-offer