-
Couldn't load subscription status.
- Fork 8.1k
Description
Introduction
Due to move of ext/hal/st to modules a reorganization of ST libraries is needed.
This issue is mainly a formal request about what was discussed in #16044 and summarized in #16044 (comment)
Problem description
ext/hal/st contains 2 different types of 'libraries' (in the most generic acceptance of the word):
- Code that is supposed to run on STM32 products (STM32Cube HAL/LL, Product specific IPC library). This restriction does not come from license type but purely that it is made to drive STM32 HW.
- Code that is made to drive ST products, with no restriction on the CPU on which it could run (could be STM32 or also HW from any other vendor). This is typically small libraries driving a small ST component (sensor, RF module, ..)
Following introduction of Zephyr module, all code under ext/hal/st should be moved under zephyr module. Moving it as a whole inside a single ST module would imply that anyone that want to use a ST component on a non ST product would have to pull the whole STM32Cube packages (> 220MB).
Proposed change
Split ST libraries into 2 modules:
hal_stm32: For the code meant to run on STM32hal_st: For the code meant to drive ST components
Detailed RFC
Move code under ext/hal/st in 2 ST specific modules, using the following trees:
hal_stm32
└── stm32cube
│ ├── common
│ ├── stm32f1
│ ├── ...
│ └── stm32wb
└── lib
├── stm32wb
│ └── hci (cf #14188)
└── ...
hal_st
└── stsensors
│ ├── audio
│ │ └── microphone
│ ├─ ....
│ ├── proximity
│ │ └── vl53l0x
│ └── stmemsc (cf #14111)
│ ├── a3g4250d
│ ├── ais328dq
│ └── ...
└── strf
├── subg1 (cf #16086)
└── ...
Concerns and Unresolved Questions
As explained, these modules would not contain only HAL(s).
It might make sense to use lib_st and lib_stm32 instead of hal_st and hal_stm32.
Unless 'hal' is made to be recognized as a zephyr keyword for this kind of stuff.
Second point would be feasibility of keeping git history following this migration. Keeping it would be great.
Alternatives
Move ext/hal/st in a single ST module, with the drawbacks listed above.