stm32: Update Makefile to allow external BOARD directory to be specified #4097
Conversation
|
ps. please let me know it there's already a different way to achieve this goal already in the codebase! |
|
This approach looks ok. For a custom board I usually just add a new board directory to "boards/", but it would be nicer to keep custom code completely outside this repo. I don't know of any existing way to do it. Note that Travis CI build fails, not sure why. |
ports/stm32/Makefile
Outdated
| HAL_DIR=lib/stm32lib/STM32$(MCU_SERIES_UPPER)xx_HAL_Driver | ||
| USBDEV_DIR=usbdev | ||
| #USBHOST_DIR=usbhost | ||
| FATFS_DIR=lib/oofatfs | ||
| FATFS_DIR=$(TOP)/lib/oofatfs |
There was a problem hiding this comment.
Why is this changed? Is it necessary?
There was a problem hiding this comment.
Same as previous comment, already removed
ports/stm32/Makefile
Outdated
| MCU_SERIES_UPPER = $(shell echo $(MCU_SERIES) | tr '[:lower:]' '[:upper:]') | ||
| CMSIS_DIR=lib/stm32lib/CMSIS/STM32$(MCU_SERIES_UPPER)xx/Include |
There was a problem hiding this comment.
Why this change? Note that CMSIS_MCU_HDR also depends on CMSIS_DIR and would need to be updated too.
There was a problem hiding this comment.
Yeah I've already removed this, mistakenly thought I needed this with an earlier superproject structure.
|
Yep the goal is keeping custom board files in a separate git so not too need them in the boards folder in a fork. When I say I've already removed those two commented bits above... I thought the cleaner commit had already been pushed (before I left the office) but clearly that didn't work. The travis fail has been resolved, new commit will be pushed by tomorrow morning. |
b160095 to
c7bc721
Compare
|
I keep a bunch of boards in separate git repositories and just clone them from inside the boards directory. They don't need to be submodules or anything like that. For example, see the 4th paragraph of this page: https://github.com/dhylands/G30DEV |
|
Ah yeah, not a bad workaround to get it working! The advantage of keeping the board definition in a super-project with micropython as a submodule is you then have controlled traceability of which git revision of each works together. ps. I've removed the extra unnecessary (and broken) changes from the commit. |
|
Thanks for updating, merged in 670a2a3 |
I'm working towards a pattern of simplifying use of micropython with custom boards and/or custom libraries that aren't suitable for submission to mainline micropython.
Currently these things generally require modifying (and typically forking) micropython to add board definitions etc.
This PR makes it easy to add a custom board definition outside of the micropython tree, keeping the micropython submodule clean and official.
Example usage is loosely described here: https://github.com/andrewleech/micropython/wiki/Customised-Micropython-projects
Once I've got external c modules running as well (likely similar to #3871, it'll be a separate PR though) I'll publish a clean example project.
As background info, for our use of micropython in a medical product, it's mandated that we can describe and test a clean interface between:
For a good introduction to the definitions and requirements of open source SOUP from a medical perspective, see: https://blog.cm-dm.com/post/2013/05/16/Got-SOUP-Part-4-Open-Source-Software
This is great for me, because that means that for any changes that can/should live in the micropython codebase, I can and should submit them back to master. The alternative is me trying to manage a SOUP that's a mixture of external and internal code with no clear boundary between them - not good for certification.
As far as this PR is concerned, we have a custom PCB which is running micropython. While the individual drivers needed to run this generally make sense to push up (eg. sdram driver) the actual board definition does not belong in master micropython.
Hence the desire to keep it external to a micropython submodule, ideally without needing yet another fork of micropython :-)