Normalize configuration of HAL/STM32 targets #17904
Conversation
Add additional testing and resolve issues compiling with TMCStepper. Add a variable to declare the version of framework-arduinoststm32. Upgrade framework-arduinoststm32 to 4.107 Remove previously unused ldscript filenames from board.json files.
|
I’ll give this a test on a BTT002 after some sleep 🙂 |
|
I'll give it a shot now on my SKR Pro 1.1 with TMC2208 UART, BLTouch, i2C External EEPROM and RGB LEDs. -William |
|
Building on SKR Pro 1.1 with 2209's right now will test |
|
Compiled OK, fixed the bootloop, i2c EEPROM not working, trying to determine if something else happened to it though. :) -William |
|
Movement works, Heating works, Layer cooling fan works, BLTouch works, LEDs work. Just trying to figure out what happened to my EEPROM. |
|
Everything is working as expected, printing a test cube right now. SD Eeprom is fine. SKR Pro 1.1 with 2209's |
|
I just ran a quick test print on a BTT002 (Prusa MK3S, TMC2209, PINDA V2, 2004 character LCD) and everything worked as expected. |
|
A little update on this. I have succeeded in getting timers to work with the framework updated to 4.10800, but unfortunately their SoftwareSerial appears to be broken again. I can still make it work with our own copy of SoftwareSerial, but deleting those files was my main motivation for wanting to go to 4.10800! I will need a bit more time with the new framework to make sure I understand the changes. The two main changes I wanted from it was setting timer interrupt priorities and fixing SoftwareSerial, and at the moment is is seeming like both of those items may not be working as intended. I don't think that should hold up this PR, though. @thinkyhead do you want to choose which of the new test files remain enabled, or do you want me to push a change to disable some of them? I'd like to keep the actual test files intact even if we don't enable them, since they are useful to test that environments remain buildable during refactors like this one. |
|
using bugfix2.0 from just now with the changes here has unfortunately caused the SKR pro 1.1 to go back into boot loops. :( -William |
…s/PR/STM32_Normalize_Rebase # Conflicts: # .github/workflows/test-builds.yml
|
Good news, disabling M115 Reporting has resolved the boot loop! Thanks for the help. -William |
…s/PR/STM32_Normalize_Rebase
That's great! I went ahead and merged in the latest bf2 changes, which include the fix for that. |
|
Note that once the PlatformIO extension for VSCode catches up, we will be able to use the |
If they are still completed in the same amount of time as the existing brood, then I don't mind keeping them all. I think it would be fine to merge them all, and only if they become problematic disable a few. |
thinkyhead
added
A: STM32
PR: Improvement
T: HAL & APIs
All the new ones are just simple sanity checks that build quite quickly. They were pretty useful for making sure the variants for each platform weren't broken. |
|
Before this is merged, what's the latest with the ststm32 platform / framework version and SoftwareSerial? |
@thinkyhead, I'm glad you asked, I was about to ask you how you want to proceed on this. The latest platform (1.8) still has some timer issues. I have it working, but it requires a small increase of code in One issue is already fixed post-1.8, and I've posted a PR for the other. Once we have a new framework release with those changes, we can delete our SoftwareSerial implementation and some workarounds from We have two choices right now.
If you'd like to upgrade now I can easily put together a PR for that, so that people could start testing it. It is possible there could be issues with PWM or other features I didn't notice. These are the two framework changes we need to be able to eliminate our SoftwareSerial: |
|
Yes, please, there's no time like the present. And nothing makes me happier than getting rid of HAL code. I especially want to get past these obscure and hard to track timer issues and have full control over them. To that end, it would help to have more detailed commentary in the HALs to make clear why all the parameters and timer indexes and so on are set to their chosen values. The HAL has reached a point where it's a bit of an API now, so the choice remains whether to stick the HALs in a namespace or make a HAL class… |
Add additional testing and resolve issues compiling with TMCStepper.
Add a variable to declare the version of framework-arduinoststm32.
Upgrade framework-arduinoststm32 to 4.10700
Remove previously unused ldscript filenames from board.json files.
Description
This improves consistency for environments using HAL/STM32. By adding a variable for the framework version and extending test coverage, future version changes will be simpler and safer.
I am upgrading to framework version 4.10700 and not all the way to 4.10800 because some timer issues have to be fixed to be compatible with 4.10800.
I've verified the following functionality with an SKR Pro on my bench. I have not tested actual prints or other hardware. Hopefully others could help try out the change.
Functionality I verified with my SKR Pro on the bench:
Benefits