[2.0.x] STM32F7 HAL using the official STM32 Arduino Core#11750
[2.0.x] STM32F7 HAL using the official STM32 Arduino Core#11750thinkyhead merged 3 commits intoMarlinFirmware:bugfix-2.0.xfrom
Conversation
thinkyhead
force-pushed
the
bf2_STM32F7xx_HAL
branch
6 times, most recently
from
95023f6 to
1cd607c
Compare
|
There are also currently some issues left with my HAL implementation:
|
|
@hasenbanck — Do you want to add your changes onto this PR (by checking out my working branch) or just carry on and wait until everything is nicely integrated into a unified STM32 HAL by @xC0000005 ? |
|
@thinkyhead I think I will add my changes onto this PR. It could act as a reference for @xC0000005 on how to use the official branch. If I solve the open issues before the unified STM32 HAL is integrated, we could think about merging this PR. Can I push my future changes to your branch? |
|
You can submit your changes as PRs to my branch, but not push to it directly. |
thinkyhead
force-pushed
the
bf2_STM32F7xx_HAL
branch
2 times, most recently
from
cbb4f05 to
979ec75
Compare
|
Just wondering what the build strategy with this would be, PlatformIO / ArduinoIDE-beta? Other? |
|
@SJ-Innovation I personally use Arduino (I'm currently not sure of the version) and Eclipse CDT with Sloeber to build this. PlatformIO has currently a blocker as far as I know, since there still needs to be some upstream support for building the official core (but I could be out of the loop on this). But you need to install the official STM32 core for this (https://github.com/stm32duino/Arduino_Core_STM32). The core provides examples on how to configure the IDE. To build for my board, you need to pull my branch though, since my board definition is not yet upstreamed (stm32duino/Arduino_Core_STM32#287). |
|
@hasenbanck Explains why ive spent the last 3 days smashing my head against a wall with PlatformIO then. xD. Ive got everything building with ArduinoIDE1.9-beta with CLion as my primary IDE. Just wasnt sure if i was missing something. Ill take a look into Sloeber, it looks more appropriate for this kind of dev than CLion. Any idea what the blocker with PIO is? Im more than happy to put the work in to fix it if its fixable, any experience youve had would be greatly appreciated for that though. |
|
@SJ-Innovation Sloeber is nice, since I can use the full CDT feature set (like using a J-LINK for debugging). I use symlinks to link to my Marlin sources. I don't have a status on the blocker. It seems that Platform IO simply hasen't targeted the official core yet (stm32duino/Arduino_Core_STM32#262). |
|
Update on the progress of open issues: Following PR are are merged:
Following issues are still open:
|
thinkyhead
force-pushed
the
bugfix-2.0.x
branch
2 times, most recently
from
9d867f9 to
849dea9
Compare
thinkyhead
force-pushed
the
bf2_STM32F7xx_HAL
branch
from
979ec75 to
2b53613
Compare
|
Thanks for the PR to this PR, @hasenbanck ! I'm still unsure whether to merge this PR now, or to wait for the work by @xC0000005, which is supposed to supersede this. In either case, I'll continue to leave this here as a reference for anyone working on STM32F7 stuff. |
|
Hi @thinkyhead, it's fine to not merge this PR yet. But it should definitely act as a reference for @xC0000005. The official STM32 core will soon (sometime in October) have a dedicated hardware timer library, that abstracts the usage of the timers on the STM32 chip. With that change, 95% of the current STM32 HALs will be essentially the same, which should make his work even easier. I will also work "soon" on the Virtual COM Port support, which is the last real blocker for this HAL. |
|
Good news. I'm gratified to hear that the cores are being so actively developed. |
|
I’m a fan of merging now. I’m not working on 3d printing this week because I have no access to my printers, but there’s no reason you couldn’t collapse STM32F4 and F7 together now. It all boils down to the macros here:
https://github.com/xC0000005/Marlin/blob/genericHal2/Marlin/src/HAL/HAL_STM32Fx/HAL_timers_STM32Fx.h <https://github.com/xC0000005/Marlin/blob/genericHal2/Marlin/src/HAL/HAL_STM32Fx/HAL_timers_STM32Fx.h>
I’ve been working on Malyan M200 support using Arduino to build and PIO to edit, and in short, the “unified” HAL is really just passing different timer numbers. But you can do that right now with that header file and a few minor changes.
… On Sep 29, 2018, at 2:53 AM, Nils Hasenbanck ***@***.***> wrote:
Hi @thinkyhead <https://github.com/thinkyhead>, it's fine to not merge this PR yet. But it should definitely act as a reference for @xC0000005 <https://github.com/xC0000005>. The official STM32 core will soon (sometime in October) have a dedicated hardware time library, that abstracts the usage of the timers on the STM32 chip. With that change, 95% of the current STM32 HALs will be essentially the same, which should make his work even easier.
I will also work "soon" on the Virtual COM Port support, which is the last real blocker for this HAL.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#11750 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AeppcVA1tuuw6evjQ-wOwxXi9qgs2SLpks5ufxjtgaJpZM4Wd4Hu>.
|
|
@thinkyhead @xC0000005 Okay, then here is my proposal how we should proceed:
With these changes the HAL should support of F1, F4 and F7 boards fine. Since only RemRam has a board definition in the upstream core as of right now, only it would have a pin file that uses this HAL as of right now. I would propose, that we then port the other boards to the new HAL as we have time. This would enable us to deprecate the other HALs as soon as they are working just as fine. I would offer myself to work with the upstream STM32 core to implement the needed changes and create the board variants. As far as I see, we currently have the following STM32 based boards on the market:
"THE BORG" is still not available yet. So it would be out of scope for my work. |
|
I implemented my proposed changes here: thinkyhead#36 |
|
I'd like to chime in and add a board to that list: GTM32_PRO_VB and the yet to be worked on GTM32_MINI. |
|
Do you not just need the mcu rather than board support upstream, requiring the framework to support any board that has an stm32 mcu seems a bit onerous on the upkeep. |
|
Yes, just the MCU should be enough, I don't know if the F103VET6 that it uses is too different from the F103RET6 that's already in place, though. |
|
@p3p @Phr3d13 You need the support of the core on a board level. Have a look at the upstream resources (https://github.com/stm32duino/wiki/wiki/Add-a-new-variant-(board)) and my example definition (https://github.com/stm32duino/Arduino_Core_STM32/tree/master/variants/REMRAM_V1). MCU support is not enough, since you have to configure stuff like timer, pin definitions and HAL configuration for the board. There are cases were people use different peripherals on the same MCU and these need to be configure these on the board level. But in the end it's the same as we had with STM32generic and also some AVR boards (like Rambo). |
The official STM32 arduino core now supports buffered access to the EEPROM emulated over flash. This makes writing data much more efficient.
thinkyhead
force-pushed
the
bf2_STM32F7xx_HAL
branch
from
e496bc7 to
45bcba8
Compare
|
Do we have pretty high confidence that this is ready to merge now? |
|
Yes. It should be ready to merge. All other improvements should be put in
other PRs and issues.
|
|
@p3p, @Phr3d13, regarding GTM32 Pro please see the discussion in #10898 MCU support is not enough as GTM32 Pro does not have a USB serial (FT232 attached to normal UART is used instead) and uses PA11/PA12 pins for driving Y axis. However, I think that discussing GTM32 Pro (based on STM32F103VET6) is a bit out of context of a pull request called "STM32F7..." |
8 participants
Contributed by @hasenbanck
See https://github.com/hasenbanck/Marlin/commit/f68d4db10792bebda85decc48d06a42f5db5c73d and #7076 (comment)