Remove HAL/STM32_F4_F7

[sjasonsmith]

Description

This removes HAL/STM32_F4_F7. It is likely this was not working at all, but our intent is to support all STM32 boards through HAL/STM32 moving forward. We already have examples of working F0, F1, F4, and F7 boards in that HAL, so removing this HAL is a step toward unification.

Several boards are impacted by these changes. In most cases I suspect they already did not work. If there are issues, they can be addressed in follow-up PRs.

Boards explicitly impacted:

• THE BORG - I don't think this actually exists so I am removing it entirely. @Spawn32 seems to have gone silent on GitHub for the past two years.
• REMRAM - I also don't know how available this is. This was the target of the STM32F7 environment, which I renamed to REMRAM_V1. Perhaps @hasenbanck can comment on the state of this board. It will likely need work to continue to work properly, even though I left the environment present.
• STM32F4 - This was probably a DISCO development board. This is likely unimportant at this point, but I did not delete it. Perhaps @ktand can comment on whether it is still important.
• BEAST - Appears to actually be an F1 dev board. I suspect it was already broken, because it pointed to the wrong environment. Perhaps @victorpv can share whether they think it still has value.

Benefits

Eliminates a HAL to maintain!

Configurations

N/A

Related Issues

N/A

[sjasonsmith]

I have not yet tested this at all. I posted the PR so that I can make sure CI is happy with the changes. We will of course have to test with some boards already using HAL/STM32 to be sure they are not broken.

[ktand]

The purpose of the STM32F4 was to serve as a template for F4 boards. As far as I'm concerned it can be removed.

[sjasonsmith]

I found two more boards which were using the STM32F4 environment, although I suspect they did not actually work with it. My best guess is that they were being used from inside the Arduino IDE, and not using platformIO definitions.

Lerdge K - @xC0000005, did this actually work with the STM32F4 PlatformIO environment? The other Lerge boards have custom environments.

VAKE403D - @madmattco was this actually working with the STM32F4 PlatformIO environment?

[xC0000005]

Lerdge K should be building as a minor extension of the lerdge base, not using the F4 HAL, just setting the firmware name.

…

On Nov 15, 2020, at 3:34 PM, Jason Smith ***@***.***> wrote: I found two more boards which were using the STM32F4 environment, although I suspect they did not actually work with it. My best guess is that they were being used from inside the Arduino IDE, and not using platformIO definitions. Lerdge K - @xC0000005 <https://github.com/xC0000005>, did this actually work with the STM32F4 PlatformIO environment? The other Lerge boards have custom environments. VAKE403D - @madmattco <https://github.com/madmattco> was this actually working with the STM32F4 PlatformIO environment? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#20153 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHVGS4KUUQ67XUX5YEFWWUDSQBQQTANCNFSM4TWN6IIA>.

[sjasonsmith]

Lerdge K should be building as a minor extension of the lerdge base, not using the F4 HAL, just setting the firmware name.

Oh, I see it has its own LERDGEK environment. I'll fix that in pins.h. Thanks!

[sjasonsmith]

Considering the STM32 Framework has a VAKE_F446VE board, it is probably safe to assume that STM32F4 is not the correct PIO environment for the VAKE403D. I'll remove those references, although this will leave the Vake board somewhat stranded until somebody adds a proper PIO environment for it.

[madmattco]

I found two more boards which were using the STM32F4 environment, although I suspect they did not actually work with it. My best guess is that they were being used from inside the Arduino IDE, and not using platformIO definitions.

Lerdge K - @xC0000005, did this actually work with the STM32F4 PlatformIO environment? The other Lerge boards have custom environments.

VAKE403D - @madmattco was this actually working with the STM32F4 PlatformIO environment?

Yes. I was using this with PIO. Did not encounter any problems to report

[sjasonsmith]

Yes. I was using this with PIO. Did not encounter any problems to report

Interesting...without any changes that was using the definitions for a reference board, and not for the VAKE board. Is this something you still work with, that you would be able to attempt to use the board with the newer HAL? If so I could make a best guess at a definition for it, and you could test it.

[madmattco]

Yes. I was using this with PIO. Did not encounter any problems to report

Interesting...without any changes that was using the definitions for a reference board, and not for the VAKE board. Is this something you still work with, that you would be able to attempt to use the board with the newer HAL? If so I could make a best guess at a definition for it, and you could test it.

Not at this time. The developers moved on from this around July of this year. I still have the board but it is not in a functioning state and I do not see any updates coming from them in the near future.

[sjasonsmith]

@madmattco I actually assumed you were one of the developers since you had contributed its information! Thanks for providing some info about it.

[madmattco]

@madmattco I actually assumed you were one of the developers since you had contributed its information! Thanks for providing some info about it.

Sadly not. I was one of the beta testers. Although, I have actually never seen anyone else talk about using one. VaE told me there were 10 prototype boards. I had number 2.

[hasenbanck]

Hi. REMRAM was never a target of the STM32_F4_F7 when I developed it, since I helped to write the generic STM32 HAL for explicitly supporting REMRAM. The design of the board is finished, but I don't develop for it anymore. There seems to be still a webshop to sell the PCB to potential customers.

[victorpv]

BEAST - This is indeed a DEV F1/F4 board. I made a prototype I still use. The only F1 HAL I used is the one based on the libmaple/stm32duino. I'm sure the board would work with any HAL as long as the HAL is working, since the board itself is working fine in my printer (also works fine as laser engraver).
I never tested the F4 version of it. The CPU was a mezzanine card plugged into the IO board, so could be upgraded.

[thinkyhead]

What's the gist of the needed sanity checks? Maybe I can whip them together and then we can say farewell to this HAL.

[sjasonsmith]

I think the main thing impacting the remaining HALs is the change to pinsDebug. I’m not sure exactly what that needs for a sanity check. I don’t imagine it will be much.

We’ll need to skim the file list to see if existing HALs changed in any other way. This is the one I remember.

[thinkyhead]

Could we merge all but the pinsDebug changes and then put those changes up as a separate new PR?

[sjasonsmith]

I just looked back and the pinsDebug changes and they seem very low risk. It looks like the code I removed was working around include path issues, which I have to believe have been resolved.

The remaining pinsDebug files both have #error if expected defines for that HAL are missing.

Probably all we need is to be sure there is at least one test for each remaining STM32 HAL that enables PINS_DEBUGGING, to make sure it compiles fine.

I can look at that real quick and push test changes if they aren't already there.