Skip to content
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

[STM32L4] Modify folder structure #3657

Merged
merged 2 commits into from
Feb 7, 2017
Merged

Conversation

adustm
Copy link
Member

@adustm adustm commented Jan 27, 2017

Description

ST team has noticed that STM32L476 and STM32L486 should not have the same startup files (the L486 has a few more interrupts).
The folder L476_L486 makes no more sense.

We have thought about introducing a TARGET_STM32L4[device] folder between TARGET_STM32L4 and TARGET_[platform]
With this new folder structure we can share files for several platforms that uses the same STM32 device. For instance, NUCLEO_L476RG and DISCO_L476VG has the same STM32L476xG devices.

I will create the same kind of modifications in other families

Status

READY

Migrations

NO

TESTS:

I have passed tests-integration-basic on the 3 L4 platforms.

@adbridge adbridge changed the title [STM32L4] Modify forder structure [STM32L4] Modify folder structure Jan 30, 2017
Copy link
Contributor

@bridadan bridadan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Found a few changes that seem unintentional, would you mind double checking?

define symbol __size_cstack__ = 0x4000;
define symbol __size_heap__ = 0x8000;
define symbol __size_cstack__ = 0x8000;
define symbol __size_heap__ = 0xa000;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this an intentional modification? Were the old values incorrect?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I have discussed with @jamike who wrote the previous values, and we agreed that it used to be a typo

"supported_toolchains": ["ARM", "uARM", "IAR", "GCC_ARM"],
"inherits": ["Target"],
"detect_code": ["0827"],
"device_has": ["ANALOGIN", "ANALOGOUT", "CAN", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
"macros": ["TRANSACTION_QUEUE_SIZE_SPI=2","USBHOST_OTHER"],
"device_has": ["ANALOGIN", "ANALOGOUT", "CAN", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH", "STDIO_MESSAGES", "TRNG"],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was the addition of SPI_ASYNCH and TRNG intentional here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, L486 and L476 are supposed to get the exact same devices modules, except when it will be about HW encryption :)

@adustm
Copy link
Member Author

adustm commented Jan 31, 2017

Hi @bridadan
Thanks for the review. I answered to the intended modifications you have seen.
Cheers

Copy link
Contributor

@bridadan bridadan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for clarifying @adustm, I guess I'm just paranoid 😄

LGTM

@bridadan
Copy link
Contributor

@mbed-bot: TEST

HOST_OSES=ALL
BUILD_TOOLCHAINS=ALL
TARGETS=ALL

@bridadan
Copy link
Contributor

/morph test

@mbed-bot
Copy link

Result: SUCCESS

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 1481

All builds and test passed!

@mbed-bot
Copy link

[Build 1242]
SUCCESS: Building succeeded and tests were run! Be sure to check the test results

@adustm
Copy link
Member Author

adustm commented Feb 6, 2017

Hi @bridadan
I've seen that you've eventually removed the 'ready for merge' tag. Could you let me know what is missing there ?
Kind regards
Armelle

@0xc0170
Copy link
Contributor

0xc0170 commented Feb 6, 2017

I've seen that you've eventually removed the 'ready for merge' tag. Could you let me know what is missing there ?

waiting for jenkins CI to complete. It was green but not reported here on github

@sg- sg- merged commit 98ed807 into ARMmbed:master Feb 7, 2017
@adustm adustm deleted the STM32L4_folderstruc branch February 7, 2017 17:36
aisair pushed a commit to aisair/mbed that referenced this pull request Apr 30, 2024
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants