Skip to content

ST modules organization #16316

@erwango

Description

@erwango

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 STM32
  • hal_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.

Metadata

Metadata

Assignees

Labels

RFCRequest For Comments: want input from the communityarea: Modulesplatform: STM32ST Micro STM32

Type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions