MCU-Driver-HAL and CI Combined WG Meeting 2021-06-17

Owned by Bill Fletcher, created
Last updated: Jun 17, 2021
3 min read

Date

Jun 17, 2021

Participants

  • Saheer Babu

  • Fathi Boudra

  • Evelyne Donnaes

  • Eric Finco

  • Bill Fletcher

  • Kumar Gala

  • Chokri Gammoudi

  • Erwan Gouriou

  • Haley Guo

  • Martin Kojtal

  • Abhishek Pandit

  • Andy Powers

  • George Psimenos

  • Kenney Qu

  • Marcelo Salazar

  • Qinghao Shi

  • Paul Sokolovskyy

  • Bartosz Szatkowski

  • Bechir JABRI

  • Filip Jagodzinski

  • Hugues Kamba-Mpiana

  • Jerome Coutant

  • Konstantinos Chatzis

  • Mark Hicken

  • Pavel Chromy

  • Wilfried

Slides

Notes

BJ: Couldn’t find code in GitHub. Could you provide the link?

ED: Going to make it available in the new organisation in a few days.

AP: Scope of the demos?

HK-M : E.g. usage of GPIO - trying to limit each example to using one API

FJ: Have to update git submodules recursively - that’s why the greentea module was missing

EF: Build is directly using CMake? Understand Arm is working to clean up the build. Do you plan to introduce it?

ED: Plan to look at later.

EF: Will be 2 steps for MVP. Directly with HAL work previously, then second step.

ED: Yes, think the packaging will come after.

AP: To add support for different device - would they need the MbedOS port to run greentea?

FJ: Mbed team provided standalone client that doesn’t depend on MbedOS. Can still see the Mbed name in some places. Using ST implementation. Needs the serial to use the custom greentea client without MbedOS

AP: So it will become clear that you don’t need the whole MbedOS

FJ: Yes

KG: How will the greentea client be maintained?

FJ: Using git submodules - greentea client is a standalone client added as a submodule

KG: Will the client be considered part of the HAL. Who is maintaining it?

ED: Planning to leave the client under Arm Mbed.

AP: Think this is an open topic at the moment.

KG: HAL is not meant to be architecture specific, but if the perception is that the tooling is Arm specific, need to manage the perception to avoid that it limits adoption.

AP: Should probably at least be an independent repo - to be reviewed

 

EF: To clarify ADR process - if there are no comments - assume that something is good for approval?

ED: Need at least one approval but if there are no objections

EF: Think we need to go for a vote by the members and state the timing for it

 

PS: Are the builds not pushed to the repository?

QS: Once PRs get merged there are other workflows to be updated.

PS: See that push function is not yet implemented?

QS: Correct

 

EF: One topic: MCU-Driver-HAL name was said to be temporary - is it still the case? We’ve been thinking about it and could come with proposals

AP: My understanding is no decision has been made so we’re open to any proposals.

KG: Hopefully any new name scope doesn’t limit us to MCU

Recording