-
Notifications
You must be signed in to change notification settings - Fork 3k
[STM32F7] Modify folder structure #3649
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
Conversation
The other advantage is to remove the copies of linker files and startup files. |
/morph test-nightly |
@mbed-bot: TEST HOST_OSES=ALL |
/morph export-build |
Full OS5 non regression session with NUCLEO_F767ZI, DISCO_F746NG and NUCLEO_F746ZG done. |
Result: SUCCESSYour command has finished executing! Here's what you wrote!
Outputmbed Build Number: 95 All exports and builds passed! |
Result: FAILUREYour command has finished executing! Here's what you wrote!
|
That failure was my fault, sorry! Rerunning now. /morph test-nightly |
[Build 1235] |
Please do not make the folder names longer! Long folder names will start breaking builds on IAR, because Windows doesn't tolerate the long folder names. This is already now a challenge with Jenkins jobs. |
Result: FAILUREYour command has finished executing! Here's what you wrote!
OutputTest failed! |
@geky same spurious failure with the NCS36510 timer. /morph test-nightly |
Result: SUCCESSYour command has finished executing! Here's what you wrote!
OutputAll builds and test passed! |
Hi @JanneKiiskila , is it still ok with this PR, or is it already blocking ? |
They can't fix it. It's an Windows OS level issue. Can we consider moving out the TARGET_ out of the 2nd level path names or is there some mbed-cli dependency on that? |
Thanks @JanneKiiskila , this is a valid point. From the mcu tree perspective, this change makes sense to minimize the code duplication. however, we hit here the problem with very long file paths. We need to think about the targets hierarchy, how to structure MCU families. This PR contains a nice example of how one family (F7) is structured |
@JanneKiiskila is this already causing issues now? Can you change your folder structure at all in CI to be shorter? The change @adustm seems fairly reasonable (a change of +/- 5 characters it seems?) and more organized. |
@0xc0170 |
At some point if this is a problem we should consider TGT_ in place of TARGET which would save even more paths. This removes 4 characters per depth or sub folder. Seems good to me, @JanneKiiskila is there something currently broken by this? If not thoughts on the above proposal before marking this ready for merge? |
Another thought. If the top level dir is e.g. TARGET_STM , do we need 'STM' in any child directories ? |
in this case I suggest TARGET_F7 (no more 'STM32'), so basically TGT_F7 Who will be a volonteer ? Kind regards |
Hello @sg- Kind regards |
Ports for Upcoming Targets Fixes and Changes 3432: Target STM USBHOST support ARMmbed/mbed-os#3432 3181: NUCLEO_F207ZG extending PeripheralPins.c: all available alternate functions can be used now ARMmbed/mbed-os#3181 3626: NUCLEO_F412ZG : Add USB Device +Host ARMmbed/mbed-os#3626 3628: Fix warnings ARMmbed/mbed-os#3628 3629: STM32: L0 LL layer ARMmbed/mbed-os#3629 3632: IDE Export support for platform VK_RZ_A1H ARMmbed/mbed-os#3632 3642: Missing IRQ pin fix for platform VK_RZ_A1H ARMmbed/mbed-os#3642 3664: Fix ncs36510 sleep definitions ARMmbed/mbed-os#3664 3655: [STM32F4] Modify folder structure ARMmbed/mbed-os#3655 3657: [STM32L4] Modify folder structure ARMmbed/mbed-os#3657 3658: [STM32F3] Modify folder structure ARMmbed/mbed-os#3658 3685: STM32: I2C: reset state machine ARMmbed/mbed-os#3685 3692: uVisor: Standardize available legacy heap and stack ARMmbed/mbed-os#3692 3621: Fix for #2884, LPC824: export to LPCXpresso, target running with wron ARMmbed/mbed-os#3621 3649: [STM32F7] Modify folder structure ARMmbed/mbed-os#3649 3695: Enforce device_name is valid in targets.json ARMmbed/mbed-os#3695 3723: NCS36510: spi_format function bug fix ARMmbed/mbed-os#3723
Description
ST team has noticed that STM32F746 and STM32F756 should not have the same startup files (the F756 has a few more interrupts).
The folder F746_756 makes no more sense.
We have thought about introducing a TARGET_STM32F7[device] folder between TARGET_STM32F7 and TARGET_[platform]
With this new folder structure we can share files for several platforms that uses the same STM32 device. For instance, NUCLEO_F746ZG and DISCO_F746NG has the same STM32F746xG devices.
I will create the same kind of modifications in other families
Status
READY
Migrations
NO
TESTS:
I have passed tests-integration-basic on NUCLEO_F746ZG / NUCLEO_F756ZG / DISCO_F769NI / DISCO_F746NG / NUCLEO_F767ZI for GCC_ARM / ARM / IAR
It's OK