Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add stm32 support #134

Open
wants to merge 4 commits into
base: stm32-support
Choose a base branch
from

Conversation

MichaelStubbings
Copy link

Following the initial STM32 support provided by CERN, this PR captures the work Diamond has done to integrate this into the upstream.

This code has been refactored from a CERN fork to provide STM32F30x support in OpenMMC.
CERN Fork: https://gitlab.cern.ch/twlostow/openmmc/-/tree/tom-rf
Original Authors: Tomasz Wlostowski <tomasz.wlostowski@cern.ch>, Adam Wujek <adam.wujek@cern.ch>
This code has been refactored from a CERN fork to provide STM32F30x support in OpenMMC
CERN Fork: https://gitlab.cern.ch/twlostow/openmmc/-/tree/tom-rf
Original Authors: Tomasz Wlostowski <tomasz.wlostowski@cern.ch>, Adam Wujek <adam.wujek@cern.ch>
This code has been refactored from a CERN fork to provide STM32F30x support in OpenMMC
CERN Fork: https://gitlab.cern.ch/twlostow/openmmc/-/tree/tom-rf
Original Author: Adam Wujek <adam.wujek@cern.ch>
This code has been refactored from a CERN fork to provide STM32F30x support in OpenMMC
CERN Fork: https://gitlab.cern.ch/twlostow/openmmc/-/tree/tom-rf
Original Authors: Tomasz Wlostowski <tomasz.wlostowski@cern.ch>, Adam Wujek <adam.wujek@cern.ch>
@augustofg
Copy link
Member

Hi Michael,

We are still reviewing your PR before merging, but so far we have the following observations:

  • The STM32 hardware abstraction library comes with a license that is not compatible with GPL, nor does it qualify as an Open Source license due to its restrictive nature in using it on microcontrollers not manufactured by ST Microelectronics. We have the same problem with the hardware abstraction library used by the LPC176x port, but we are taking steps to fix it. I believe you can generate BSD or Apache v2 licensed versions of the STM32 HAL using STM32Cube, I did it few years ago, though I don't remember how exactly;
  • I doesn't feel right having target specific code under the sensors/ directory. I couldn't come with a good alternative yet;
  • Do no use -fcommon gcc flag, global variables should not be instantiated on header files, instantiate them on a .c file and use the extern attribute on headers. We already force -fno-common here:
    set(COMMON_FLAGS "-fno-common -fno-builtin -ffunction-sections -fdata-sections -fno-strict-aliasing -fmessage-length=0")
    so to make the compiler behaviour consistent between different versions.

As we discussed previously, we will merge this on the stm32-support branch for now, then we need to harmonise this with the devel branch (that has diverged substantially). Also, please keep in mind that there will be substantial changes to the openMMC in the near future to fulfil our desire to fix some design issues and fix some long standing issues: #110.

@gustavosr8 is our new intern that will start working on the openMMC project shortly, so now we will have someone dedicated to help on this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants