Re: Addition of STM32H7 MCU's
Hi Kian, All the steps are documented here: https://nuttx.apache.org/docs/12.3.0/contributing/index.html If you face some issue, please let me know. BR, Alan On Thu, Jan 18, 2024 at 10:14 AM Kian Karas (KK) wrote: > Hi Robert, Community > > We have NuttX running on an STM32H723VE, but haven't tested all > peripherals. We also did some initial work on an STM32H730, but this has > hardly been tested. > > What is the best way to share the STM32H723VE support with the community? > It needs some reviewing. I am concerned we could have broken stuff for > other MCUs in the familly, but I can't test this. > > @Robert: if you are in a hurry, send me an email directly and I'll respond > with a patch. > > Regards > Kian > > From: Robert Turner > Sent: 18 January 2024 03:30 > To: dev@nuttx.apache.org > Subject: Re: Addition of STM32H7 MCU's > > Nah not internal cache. The SRAM sizes for H723/5 are different from any of > those defined in arch/arm/include/stm32h7/chip.h > Suspect we need to get these correct as other files use these defs also, > such as stm32_allocateheap.c > Is Jorge's PR the one merged on Jul 12 (8ceff0d)? > Thanks, > Robert > > On Thu, Jan 18, 2024 at 2:56 PM Alan C. Assis wrote: > > > Hi Robert, > > Thank you for the explanation! Is it about internal cache? > > > > Looking at > > > https://www.st.com/en/microcontrollers-microprocessors/stm32h7-series.html > > I can see that H723/5 shares mostly everything with H333/5. > > I only tested NuttX on STM32H743ZI and STM32H753BI (I and Jorge added > > support to this few weeks ago). > > > > Please take a look at Jorge's PRs, probably if you fix the memory in the > > linker script and the clock tree for your board NuttX will work fine on > it. > > > > BR, > > > > Alan > > > > On Wed, Jan 17, 2024 at 10:25 PM Robert Turner wrote: > > > > > Apologies, I should have been more specific, I was referring to parts > in > > > the family which are not currently covered, such as the STM32H723xx > which > > > we use. The RAM sizes definitions in chip.h for > > > CONFIG_STM32H7_STM32H7X3XX/CONFIG_STM32H7_STM32H7X5XX are incorrect for > > > the STM32H723xx and STM32H725xx. > > > BR, > > > Robert > > > > > > On Thu, Jan 18, 2024 at 1:28 PM Alan C. Assis > wrote: > > > > > > > Robert, > > > > STM32H7 family is already supported. > > > > > > > > Look at arch/arm/src/stm32h7 and equivalent at boards/ > > > > > > > > BR, > > > > > > > > Alan > > > > > > > > On Tuesday, January 16, 2024, Robert Turner > wrote: > > > > > > > > > Did anyone finish supporting the broader STM32H7xx family? If so, > is > > it > > > > > close to being mergeable or sendable as a patch? > > > > > > > > > > Thanks, > > > > > Robert > > > > > > > > > > On Fri, Sep 8, 2023 at 10:33 PM raiden00pl > > > wrote: > > > > > > > > > > > > You're right, but not entirely) For example, chips of different > > > > > subseries > > > > > > have different interrupt vector tables. Those. The > > stm32h7x3xx_irq.h > > > > file > > > > > > lists interrupt vectors for the RM0433, but not for the RM0455 or > > > > > > RM0468. Although > > > > > > some chips from all these series have 7x3 in the name. > > > > > > > > > > > > I think they are the same (not checked, intuition tells me so). > But > > > > some > > > > > > peripherals are not available on some chips and then the > > > > > > corresponding interrupt line is marked RESERVED, or its the same > > > > > peripheral > > > > > > but with upgraded functionality (QSPI/OCTOSPI) or > > > > > > for some reason ST changed its name to confuse devs. There should > > be > > > no > > > > > > conflict between IRQ lines. > > > > > > > > > > > > > Even if it duplicates 90% of the file it is better than > #ifdefing > > > the > > > > > > > stm32h7x3xx_irq.h file. AKA ifdef rash! > > > > > > > > > > > > One file approach can be done with only one level of #ifdefs, one > > > level > > > > > of > > > > > > #ifdefs doesn't have a ne
Re: Addition of STM32H7 MCU's
Yes, this commit https://github.com/apache/nuttx/commit/8ceff0d BR, Alan On Wed, Jan 17, 2024 at 11:31 PM Robert Turner wrote: > Nah not internal cache. The SRAM sizes for H723/5 are different from any of > those defined in arch/arm/include/stm32h7/chip.h > Suspect we need to get these correct as other files use these defs also, > such as stm32_allocateheap.c > Is Jorge's PR the one merged on Jul 12 (8ceff0d)? > Thanks, > Robert > > On Thu, Jan 18, 2024 at 2:56 PM Alan C. Assis wrote: > > > Hi Robert, > > Thank you for the explanation! Is it about internal cache? > > > > Looking at > > > https://www.st.com/en/microcontrollers-microprocessors/stm32h7-series.html > > I can see that H723/5 shares mostly everything with H333/5. > > I only tested NuttX on STM32H743ZI and STM32H753BI (I and Jorge added > > support to this few weeks ago). > > > > Please take a look at Jorge's PRs, probably if you fix the memory in the > > linker script and the clock tree for your board NuttX will work fine on > it. > > > > BR, > > > > Alan > > > > On Wed, Jan 17, 2024 at 10:25 PM Robert Turner wrote: > > > > > Apologies, I should have been more specific, I was referring to parts > in > > > the family which are not currently covered, such as the STM32H723xx > which > > > we use. The RAM sizes definitions in chip.h for > > > CONFIG_STM32H7_STM32H7X3XX/CONFIG_STM32H7_STM32H7X5XX are incorrect for > > > the STM32H723xx and STM32H725xx. > > > BR, > > > Robert > > > > > > On Thu, Jan 18, 2024 at 1:28 PM Alan C. Assis > wrote: > > > > > > > Robert, > > > > STM32H7 family is already supported. > > > > > > > > Look at arch/arm/src/stm32h7 and equivalent at boards/ > > > > > > > > BR, > > > > > > > > Alan > > > > > > > > On Tuesday, January 16, 2024, Robert Turner > wrote: > > > > > > > > > Did anyone finish supporting the broader STM32H7xx family? If so, > is > > it > > > > > close to being mergeable or sendable as a patch? > > > > > > > > > > Thanks, > > > > > Robert > > > > > > > > > > On Fri, Sep 8, 2023 at 10:33 PM raiden00pl > > > wrote: > > > > > > > > > > > > You're right, but not entirely) For example, chips of different > > > > > subseries > > > > > > have different interrupt vector tables. Those. The > > stm32h7x3xx_irq.h > > > > file > > > > > > lists interrupt vectors for the RM0433, but not for the RM0455 or > > > > > > RM0468. Although > > > > > > some chips from all these series have 7x3 in the name. > > > > > > > > > > > > I think they are the same (not checked, intuition tells me so). > But > > > > some > > > > > > peripherals are not available on some chips and then the > > > > > > corresponding interrupt line is marked RESERVED, or its the same > > > > > peripheral > > > > > > but with upgraded functionality (QSPI/OCTOSPI) or > > > > > > for some reason ST changed its name to confuse devs. There should > > be > > > no > > > > > > conflict between IRQ lines. > > > > > > > > > > > > > Even if it duplicates 90% of the file it is better than > #ifdefing > > > the > > > > > > > stm32h7x3xx_irq.h file. AKA ifdef rash! > > > > > > > > > > > > One file approach can be done with only one level of #ifdefs, one > > > level > > > > > of > > > > > > #ifdefs doesn't have a negative impact on code quality (but > > > > > > it's probably a matter of individual feelings). > > > > > > For IRQ and memory map (and probably DMAMUX), the approach with > > > > separate > > > > > > files may make sense but for peripheral definitions > > > > > > I don't see any benefit in duplicating files. > > > > > > > > > > > > pt., 8 wrz 2023 o 12:01 > > > > napisał(a): > > > > > > > > > > > > > You're right, but not entirely) For example, chips of different > > > > > subseries > > > > > > > have different interrupt vector tables. Those. The > > > stm32h7x3xx_irq.h > > > &
Re: Addition of STM32H7 MCU's
Hi Robert, Community We have NuttX running on an STM32H723VE, but haven't tested all peripherals. We also did some initial work on an STM32H730, but this has hardly been tested. What is the best way to share the STM32H723VE support with the community? It needs some reviewing. I am concerned we could have broken stuff for other MCUs in the familly, but I can't test this. @Robert: if you are in a hurry, send me an email directly and I'll respond with a patch. Regards Kian From: Robert Turner Sent: 18 January 2024 03:30 To: dev@nuttx.apache.org Subject: Re: Addition of STM32H7 MCU's Nah not internal cache. The SRAM sizes for H723/5 are different from any of those defined in arch/arm/include/stm32h7/chip.h Suspect we need to get these correct as other files use these defs also, such as stm32_allocateheap.c Is Jorge's PR the one merged on Jul 12 (8ceff0d)? Thanks, Robert On Thu, Jan 18, 2024 at 2:56 PM Alan C. Assis wrote: > Hi Robert, > Thank you for the explanation! Is it about internal cache? > > Looking at > https://www.st.com/en/microcontrollers-microprocessors/stm32h7-series.html > I can see that H723/5 shares mostly everything with H333/5. > I only tested NuttX on STM32H743ZI and STM32H753BI (I and Jorge added > support to this few weeks ago). > > Please take a look at Jorge's PRs, probably if you fix the memory in the > linker script and the clock tree for your board NuttX will work fine on it. > > BR, > > Alan > > On Wed, Jan 17, 2024 at 10:25 PM Robert Turner wrote: > > > Apologies, I should have been more specific, I was referring to parts in > > the family which are not currently covered, such as the STM32H723xx which > > we use. The RAM sizes definitions in chip.h for > > CONFIG_STM32H7_STM32H7X3XX/CONFIG_STM32H7_STM32H7X5XX are incorrect for > > the STM32H723xx and STM32H725xx. > > BR, > > Robert > > > > On Thu, Jan 18, 2024 at 1:28 PM Alan C. Assis wrote: > > > > > Robert, > > > STM32H7 family is already supported. > > > > > > Look at arch/arm/src/stm32h7 and equivalent at boards/ > > > > > > BR, > > > > > > Alan > > > > > > On Tuesday, January 16, 2024, Robert Turner wrote: > > > > > > > Did anyone finish supporting the broader STM32H7xx family? If so, is > it > > > > close to being mergeable or sendable as a patch? > > > > > > > > Thanks, > > > > Robert > > > > > > > > On Fri, Sep 8, 2023 at 10:33 PM raiden00pl > > wrote: > > > > > > > > > > You're right, but not entirely) For example, chips of different > > > > subseries > > > > > have different interrupt vector tables. Those. The > stm32h7x3xx_irq.h > > > file > > > > > lists interrupt vectors for the RM0433, but not for the RM0455 or > > > > > RM0468. Although > > > > > some chips from all these series have 7x3 in the name. > > > > > > > > > > I think they are the same (not checked, intuition tells me so). But > > > some > > > > > peripherals are not available on some chips and then the > > > > > corresponding interrupt line is marked RESERVED, or its the same > > > > peripheral > > > > > but with upgraded functionality (QSPI/OCTOSPI) or > > > > > for some reason ST changed its name to confuse devs. There should > be > > no > > > > > conflict between IRQ lines. > > > > > > > > > > > Even if it duplicates 90% of the file it is better than #ifdefing > > the > > > > > > stm32h7x3xx_irq.h file. AKA ifdef rash! > > > > > > > > > > One file approach can be done with only one level of #ifdefs, one > > level > > > > of > > > > > #ifdefs doesn't have a negative impact on code quality (but > > > > > it's probably a matter of individual feelings). > > > > > For IRQ and memory map (and probably DMAMUX), the approach with > > > separate > > > > > files may make sense but for peripheral definitions > > > > > I don't see any benefit in duplicating files. > > > > > > > > > > pt., 8 wrz 2023 o 12:01 > > > napisał(a): > > > > > > > > > > > You're right, but not entirely) For example, chips of different > > > > subseries > > > > > > have different interrupt vector tables. Those. The > > stm32h7x3xx_irq.h > > > > file > > > > > > li
Re: Addition of STM32H7 MCU's
Nah not internal cache. The SRAM sizes for H723/5 are different from any of those defined in arch/arm/include/stm32h7/chip.h Suspect we need to get these correct as other files use these defs also, such as stm32_allocateheap.c Is Jorge's PR the one merged on Jul 12 (8ceff0d)? Thanks, Robert On Thu, Jan 18, 2024 at 2:56 PM Alan C. Assis wrote: > Hi Robert, > Thank you for the explanation! Is it about internal cache? > > Looking at > https://www.st.com/en/microcontrollers-microprocessors/stm32h7-series.html > I can see that H723/5 shares mostly everything with H333/5. > I only tested NuttX on STM32H743ZI and STM32H753BI (I and Jorge added > support to this few weeks ago). > > Please take a look at Jorge's PRs, probably if you fix the memory in the > linker script and the clock tree for your board NuttX will work fine on it. > > BR, > > Alan > > On Wed, Jan 17, 2024 at 10:25 PM Robert Turner wrote: > > > Apologies, I should have been more specific, I was referring to parts in > > the family which are not currently covered, such as the STM32H723xx which > > we use. The RAM sizes definitions in chip.h for > > CONFIG_STM32H7_STM32H7X3XX/CONFIG_STM32H7_STM32H7X5XX are incorrect for > > the STM32H723xx and STM32H725xx. > > BR, > > Robert > > > > On Thu, Jan 18, 2024 at 1:28 PM Alan C. Assis wrote: > > > > > Robert, > > > STM32H7 family is already supported. > > > > > > Look at arch/arm/src/stm32h7 and equivalent at boards/ > > > > > > BR, > > > > > > Alan > > > > > > On Tuesday, January 16, 2024, Robert Turner wrote: > > > > > > > Did anyone finish supporting the broader STM32H7xx family? If so, is > it > > > > close to being mergeable or sendable as a patch? > > > > > > > > Thanks, > > > > Robert > > > > > > > > On Fri, Sep 8, 2023 at 10:33 PM raiden00pl > > wrote: > > > > > > > > > > You're right, but not entirely) For example, chips of different > > > > subseries > > > > > have different interrupt vector tables. Those. The > stm32h7x3xx_irq.h > > > file > > > > > lists interrupt vectors for the RM0433, but not for the RM0455 or > > > > > RM0468. Although > > > > > some chips from all these series have 7x3 in the name. > > > > > > > > > > I think they are the same (not checked, intuition tells me so). But > > > some > > > > > peripherals are not available on some chips and then the > > > > > corresponding interrupt line is marked RESERVED, or its the same > > > > peripheral > > > > > but with upgraded functionality (QSPI/OCTOSPI) or > > > > > for some reason ST changed its name to confuse devs. There should > be > > no > > > > > conflict between IRQ lines. > > > > > > > > > > > Even if it duplicates 90% of the file it is better than #ifdefing > > the > > > > > > stm32h7x3xx_irq.h file. AKA ifdef rash! > > > > > > > > > > One file approach can be done with only one level of #ifdefs, one > > level > > > > of > > > > > #ifdefs doesn't have a negative impact on code quality (but > > > > > it's probably a matter of individual feelings). > > > > > For IRQ and memory map (and probably DMAMUX), the approach with > > > separate > > > > > files may make sense but for peripheral definitions > > > > > I don't see any benefit in duplicating files. > > > > > > > > > > pt., 8 wrz 2023 o 12:01 > > > napisał(a): > > > > > > > > > > > You're right, but not entirely) For example, chips of different > > > > subseries > > > > > > have different interrupt vector tables. Those. The > > stm32h7x3xx_irq.h > > > > file > > > > > > lists interrupt vectors for the RM0433, but not for the RM0455 or > > > > > RM0468. Although > > > > > > some chips from all these series have 7x3 in the name. > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > *От:* "raiden00pl" > > > > > > *Кому:* "undefined" > > > > > > *Отправлено:* пятница, 8 сентября 2023 г., 12:52 > > > > > > *Тема:* Re: Addition of STM32H7 MCU's > > >
Re: Addition of STM32H7 MCU's
Hi Robert, Thank you for the explanation! Is it about internal cache? Looking at https://www.st.com/en/microcontrollers-microprocessors/stm32h7-series.html I can see that H723/5 shares mostly everything with H333/5. I only tested NuttX on STM32H743ZI and STM32H753BI (I and Jorge added support to this few weeks ago). Please take a look at Jorge's PRs, probably if you fix the memory in the linker script and the clock tree for your board NuttX will work fine on it. BR, Alan On Wed, Jan 17, 2024 at 10:25 PM Robert Turner wrote: > Apologies, I should have been more specific, I was referring to parts in > the family which are not currently covered, such as the STM32H723xx which > we use. The RAM sizes definitions in chip.h for > CONFIG_STM32H7_STM32H7X3XX/CONFIG_STM32H7_STM32H7X5XX are incorrect for > the STM32H723xx and STM32H725xx. > BR, > Robert > > On Thu, Jan 18, 2024 at 1:28 PM Alan C. Assis wrote: > > > Robert, > > STM32H7 family is already supported. > > > > Look at arch/arm/src/stm32h7 and equivalent at boards/ > > > > BR, > > > > Alan > > > > On Tuesday, January 16, 2024, Robert Turner wrote: > > > > > Did anyone finish supporting the broader STM32H7xx family? If so, is it > > > close to being mergeable or sendable as a patch? > > > > > > Thanks, > > > Robert > > > > > > On Fri, Sep 8, 2023 at 10:33 PM raiden00pl > wrote: > > > > > > > > You're right, but not entirely) For example, chips of different > > > subseries > > > > have different interrupt vector tables. Those. The stm32h7x3xx_irq.h > > file > > > > lists interrupt vectors for the RM0433, but not for the RM0455 or > > > > RM0468. Although > > > > some chips from all these series have 7x3 in the name. > > > > > > > > I think they are the same (not checked, intuition tells me so). But > > some > > > > peripherals are not available on some chips and then the > > > > corresponding interrupt line is marked RESERVED, or its the same > > > peripheral > > > > but with upgraded functionality (QSPI/OCTOSPI) or > > > > for some reason ST changed its name to confuse devs. There should be > no > > > > conflict between IRQ lines. > > > > > > > > > Even if it duplicates 90% of the file it is better than #ifdefing > the > > > > > stm32h7x3xx_irq.h file. AKA ifdef rash! > > > > > > > > One file approach can be done with only one level of #ifdefs, one > level > > > of > > > > #ifdefs doesn't have a negative impact on code quality (but > > > > it's probably a matter of individual feelings). > > > > For IRQ and memory map (and probably DMAMUX), the approach with > > separate > > > > files may make sense but for peripheral definitions > > > > I don't see any benefit in duplicating files. > > > > > > > > pt., 8 wrz 2023 o 12:01 > > napisał(a): > > > > > > > > > You're right, but not entirely) For example, chips of different > > > subseries > > > > > have different interrupt vector tables. Those. The > stm32h7x3xx_irq.h > > > file > > > > > lists interrupt vectors for the RM0433, but not for the RM0455 or > > > > RM0468. Although > > > > > some chips from all these series have 7x3 in the name. > > > > > > > > > > > > > > > > > > > > -- > > > > > *От:* "raiden00pl" > > > > > *Кому:* "undefined" > > > > > *Отправлено:* пятница, 8 сентября 2023 г., 12:52 > > > > > *Тема:* Re: Addition of STM32H7 MCU's > > > > > > > > > > From what I'm familiar with STM32H7, all chips use the same > registers > > > and > > > > > bit definitions. > > > > > Therefore, keeping definitions for different chips in different > files > > > > > doesn't make sense in my opinion. > > > > > The only problem is that some chips support some peripherals while > > > others > > > > > do not. But this can be > > > > > solved using definitions from Kconfig, where we define the > supported > > > > > peripherals anyway, using > > > > > `select STM32H7_HAVE_xxx`. In that case, it's possible to have only > > one > > > > > version of files with hardware > > > > > definitions (ir
Re: Addition of STM32H7 MCU's
Apologies, I should have been more specific, I was referring to parts in the family which are not currently covered, such as the STM32H723xx which we use. The RAM sizes definitions in chip.h for CONFIG_STM32H7_STM32H7X3XX/CONFIG_STM32H7_STM32H7X5XX are incorrect for the STM32H723xx and STM32H725xx. BR, Robert On Thu, Jan 18, 2024 at 1:28 PM Alan C. Assis wrote: > Robert, > STM32H7 family is already supported. > > Look at arch/arm/src/stm32h7 and equivalent at boards/ > > BR, > > Alan > > On Tuesday, January 16, 2024, Robert Turner wrote: > > > Did anyone finish supporting the broader STM32H7xx family? If so, is it > > close to being mergeable or sendable as a patch? > > > > Thanks, > > Robert > > > > On Fri, Sep 8, 2023 at 10:33 PM raiden00pl wrote: > > > > > > You're right, but not entirely) For example, chips of different > > subseries > > > have different interrupt vector tables. Those. The stm32h7x3xx_irq.h > file > > > lists interrupt vectors for the RM0433, but not for the RM0455 or > > > RM0468. Although > > > some chips from all these series have 7x3 in the name. > > > > > > I think they are the same (not checked, intuition tells me so). But > some > > > peripherals are not available on some chips and then the > > > corresponding interrupt line is marked RESERVED, or its the same > > peripheral > > > but with upgraded functionality (QSPI/OCTOSPI) or > > > for some reason ST changed its name to confuse devs. There should be no > > > conflict between IRQ lines. > > > > > > > Even if it duplicates 90% of the file it is better than #ifdefing the > > > > stm32h7x3xx_irq.h file. AKA ifdef rash! > > > > > > One file approach can be done with only one level of #ifdefs, one level > > of > > > #ifdefs doesn't have a negative impact on code quality (but > > > it's probably a matter of individual feelings). > > > For IRQ and memory map (and probably DMAMUX), the approach with > separate > > > files may make sense but for peripheral definitions > > > I don't see any benefit in duplicating files. > > > > > > pt., 8 wrz 2023 o 12:01 > napisał(a): > > > > > > > You're right, but not entirely) For example, chips of different > > subseries > > > > have different interrupt vector tables. Those. The stm32h7x3xx_irq.h > > file > > > > lists interrupt vectors for the RM0433, but not for the RM0455 or > > > RM0468. Although > > > > some chips from all these series have 7x3 in the name. > > > > > > > > > > > > > > > > -- > > > > *От:* "raiden00pl" > > > > *Кому:* "undefined" > > > > *Отправлено:* пятница, 8 сентября 2023 г., 12:52 > > > > *Тема:* Re: Addition of STM32H7 MCU's > > > > > > > > From what I'm familiar with STM32H7, all chips use the same registers > > and > > > > bit definitions. > > > > Therefore, keeping definitions for different chips in different files > > > > doesn't make sense in my opinion. > > > > The only problem is that some chips support some peripherals while > > others > > > > do not. But this can be > > > > solved using definitions from Kconfig, where we define the supported > > > > peripherals anyway, using > > > > `select STM32H7_HAVE_xxx`. In that case, it's possible to have only > one > > > > version of files with hardware > > > > definitions (irq, peripherals) and guard the optional functionalities > > > with > > > > `#ifdef CONFIG_STM32H7_HAVE_xxx`. > > > > Moreover, I think this can be done for all stm32 families, but it's a > > lot > > > > of work that no one has undertaken > > > > so far (I tried, but failed ;) ) > > > > > > > > I understand that code duplication is often not bad, but in the case > of > > > > stm32 it is a bit too high. It's partly ST's fault > > > > because of how they release their manuals. The user must spend a lot > of > > > > time to come to the conclusion > > > > that the only thing that changes in the other version of the chip is > > the > > > > chip code number in the reference manual :) > > > > > > > > > > > > pt., 8 wrz 2023 o 11:11 napisał(a): > > > > > > > > > Hi, all > > > > > > > > > >
Re: Addition of STM32H7 MCU's
Robert, STM32H7 family is already supported. Look at arch/arm/src/stm32h7 and equivalent at boards/ BR, Alan On Tuesday, January 16, 2024, Robert Turner wrote: > Did anyone finish supporting the broader STM32H7xx family? If so, is it > close to being mergeable or sendable as a patch? > > Thanks, > Robert > > On Fri, Sep 8, 2023 at 10:33 PM raiden00pl wrote: > > > > You're right, but not entirely) For example, chips of different > subseries > > have different interrupt vector tables. Those. The stm32h7x3xx_irq.h file > > lists interrupt vectors for the RM0433, but not for the RM0455 or > > RM0468. Although > > some chips from all these series have 7x3 in the name. > > > > I think they are the same (not checked, intuition tells me so). But some > > peripherals are not available on some chips and then the > > corresponding interrupt line is marked RESERVED, or its the same > peripheral > > but with upgraded functionality (QSPI/OCTOSPI) or > > for some reason ST changed its name to confuse devs. There should be no > > conflict between IRQ lines. > > > > > Even if it duplicates 90% of the file it is better than #ifdefing the > > > stm32h7x3xx_irq.h file. AKA ifdef rash! > > > > One file approach can be done with only one level of #ifdefs, one level > of > > #ifdefs doesn't have a negative impact on code quality (but > > it's probably a matter of individual feelings). > > For IRQ and memory map (and probably DMAMUX), the approach with separate > > files may make sense but for peripheral definitions > > I don't see any benefit in duplicating files. > > > > pt., 8 wrz 2023 o 12:01 napisał(a): > > > > > You're right, but not entirely) For example, chips of different > subseries > > > have different interrupt vector tables. Those. The stm32h7x3xx_irq.h > file > > > lists interrupt vectors for the RM0433, but not for the RM0455 or > > RM0468. Although > > > some chips from all these series have 7x3 in the name. > > > > > > > > > > > > -- > > > *От:* "raiden00pl" > > > *Кому:* "undefined" > > > *Отправлено:* пятница, 8 сентября 2023 г., 12:52 > > > *Тема:* Re: Addition of STM32H7 MCU's > > > > > > From what I'm familiar with STM32H7, all chips use the same registers > and > > > bit definitions. > > > Therefore, keeping definitions for different chips in different files > > > doesn't make sense in my opinion. > > > The only problem is that some chips support some peripherals while > others > > > do not. But this can be > > > solved using definitions from Kconfig, where we define the supported > > > peripherals anyway, using > > > `select STM32H7_HAVE_xxx`. In that case, it's possible to have only one > > > version of files with hardware > > > definitions (irq, peripherals) and guard the optional functionalities > > with > > > `#ifdef CONFIG_STM32H7_HAVE_xxx`. > > > Moreover, I think this can be done for all stm32 families, but it's a > lot > > > of work that no one has undertaken > > > so far (I tried, but failed ;) ) > > > > > > I understand that code duplication is often not bad, but in the case of > > > stm32 it is a bit too high. It's partly ST's fault > > > because of how they release their manuals. The user must spend a lot of > > > time to come to the conclusion > > > that the only thing that changes in the other version of the chip is > the > > > chip code number in the reference manual :) > > > > > > > > > pt., 8 wrz 2023 o 11:11 napisał(a): > > > > > > > Hi, all > > > > > > > > I would like to start working on developing support for STM32H735 > > > > microcontrollers in NuttX OS, but I found some strange things in the > > > > principle of configuring this series of microcontrollers. > > > > > > > > Microcontrollers of the H7 series are divided into several subseries, > > > each > > > > united by one reference manual: > > > > - STM32H723/733, STM32H725/735 and STM32H730 (RM0468) > > > > - STM32H745/755 and STM32H747/757 (RM0399) > > > > - STM32H742, STM32H743/753 and STM32H750 (RM0433) > > > > - STM32H7A3/7B3 and STM32H7B0 (RM0455) > > > > > > > > But some header files in arch/arm/include/stm32h7 are designated as > > > > stm32h7x3xx_irq.h or stm32h7x5xx_irq.h, although they are only for > the > > > H743 > > > > or H745 series respectively, not for H723 or H735. And such a > > > discrepancy > > > > is also present in other source code files that belong to the H7 > > series. > > > > > > > > Maybe it's worth fixing this somehow? Will this break anything > > > important? > > > > > > > > > > > > Oleg Svezhinskiy > > > > > > > > > >
Re: Addition of STM32H7 MCU's
Did anyone finish supporting the broader STM32H7xx family? If so, is it close to being mergeable or sendable as a patch? Thanks, Robert On Fri, Sep 8, 2023 at 10:33 PM raiden00pl wrote: > > You're right, but not entirely) For example, chips of different subseries > have different interrupt vector tables. Those. The stm32h7x3xx_irq.h file > lists interrupt vectors for the RM0433, but not for the RM0455 or > RM0468. Although > some chips from all these series have 7x3 in the name. > > I think they are the same (not checked, intuition tells me so). But some > peripherals are not available on some chips and then the > corresponding interrupt line is marked RESERVED, or its the same peripheral > but with upgraded functionality (QSPI/OCTOSPI) or > for some reason ST changed its name to confuse devs. There should be no > conflict between IRQ lines. > > > Even if it duplicates 90% of the file it is better than #ifdefing the > > stm32h7x3xx_irq.h file. AKA ifdef rash! > > One file approach can be done with only one level of #ifdefs, one level of > #ifdefs doesn't have a negative impact on code quality (but > it's probably a matter of individual feelings). > For IRQ and memory map (and probably DMAMUX), the approach with separate > files may make sense but for peripheral definitions > I don't see any benefit in duplicating files. > > pt., 8 wrz 2023 o 12:01 napisał(a): > > > You're right, but not entirely) For example, chips of different subseries > > have different interrupt vector tables. Those. The stm32h7x3xx_irq.h file > > lists interrupt vectors for the RM0433, but not for the RM0455 or > RM0468. Although > > some chips from all these series have 7x3 in the name. > > > > > > > > ------ > > *От:* "raiden00pl" > > *Кому:* "undefined" > > *Отправлено:* пятница, 8 сентября 2023 г., 12:52 > > *Тема:* Re: Addition of STM32H7 MCU's > > > > From what I'm familiar with STM32H7, all chips use the same registers and > > bit definitions. > > Therefore, keeping definitions for different chips in different files > > doesn't make sense in my opinion. > > The only problem is that some chips support some peripherals while others > > do not. But this can be > > solved using definitions from Kconfig, where we define the supported > > peripherals anyway, using > > `select STM32H7_HAVE_xxx`. In that case, it's possible to have only one > > version of files with hardware > > definitions (irq, peripherals) and guard the optional functionalities > with > > `#ifdef CONFIG_STM32H7_HAVE_xxx`. > > Moreover, I think this can be done for all stm32 families, but it's a lot > > of work that no one has undertaken > > so far (I tried, but failed ;) ) > > > > I understand that code duplication is often not bad, but in the case of > > stm32 it is a bit too high. It's partly ST's fault > > because of how they release their manuals. The user must spend a lot of > > time to come to the conclusion > > that the only thing that changes in the other version of the chip is the > > chip code number in the reference manual :) > > > > > > pt., 8 wrz 2023 o 11:11 napisał(a): > > > > > Hi, all > > > > > > I would like to start working on developing support for STM32H735 > > > microcontrollers in NuttX OS, but I found some strange things in the > > > principle of configuring this series of microcontrollers. > > > > > > Microcontrollers of the H7 series are divided into several subseries, > > each > > > united by one reference manual: > > > - STM32H723/733, STM32H725/735 and STM32H730 (RM0468) > > > - STM32H745/755 and STM32H747/757 (RM0399) > > > - STM32H742, STM32H743/753 and STM32H750 (RM0433) > > > - STM32H7A3/7B3 and STM32H7B0 (RM0455) > > > > > > But some header files in arch/arm/include/stm32h7 are designated as > > > stm32h7x3xx_irq.h or stm32h7x5xx_irq.h, although they are only for the > > H743 > > > or H745 series respectively, not for H723 or H735. And such a > > discrepancy > > > is also present in other source code files that belong to the H7 > series. > > > > > > Maybe it's worth fixing this somehow? Will this break anything > > important? > > > > > > > > > Oleg Svezhinskiy > > > > > >
Re: Addition of STM32H7 MCU's
> You're right, but not entirely) For example, chips of different subseries have different interrupt vector tables. Those. The stm32h7x3xx_irq.h file lists interrupt vectors for the RM0433, but not for the RM0455 or RM0468. Although some chips from all these series have 7x3 in the name. I think they are the same (not checked, intuition tells me so). But some peripherals are not available on some chips and then the corresponding interrupt line is marked RESERVED, or its the same peripheral but with upgraded functionality (QSPI/OCTOSPI) or for some reason ST changed its name to confuse devs. There should be no conflict between IRQ lines. > Even if it duplicates 90% of the file it is better than #ifdefing the > stm32h7x3xx_irq.h file. AKA ifdef rash! One file approach can be done with only one level of #ifdefs, one level of #ifdefs doesn't have a negative impact on code quality (but it's probably a matter of individual feelings). For IRQ and memory map (and probably DMAMUX), the approach with separate files may make sense but for peripheral definitions I don't see any benefit in duplicating files. pt., 8 wrz 2023 o 12:01 napisał(a): > You're right, but not entirely) For example, chips of different subseries > have different interrupt vector tables. Those. The stm32h7x3xx_irq.h file > lists interrupt vectors for the RM0433, but not for the RM0455 or RM0468. > Although > some chips from all these series have 7x3 in the name. > > > > -- > *От:* "raiden00pl" > *Кому:* "undefined" > *Отправлено:* пятница, 8 сентября 2023 г., 12:52 > *Тема:* Re: Addition of STM32H7 MCU's > > From what I'm familiar with STM32H7, all chips use the same registers and > bit definitions. > Therefore, keeping definitions for different chips in different files > doesn't make sense in my opinion. > The only problem is that some chips support some peripherals while others > do not. But this can be > solved using definitions from Kconfig, where we define the supported > peripherals anyway, using > `select STM32H7_HAVE_xxx`. In that case, it's possible to have only one > version of files with hardware > definitions (irq, peripherals) and guard the optional functionalities with > `#ifdef CONFIG_STM32H7_HAVE_xxx`. > Moreover, I think this can be done for all stm32 families, but it's a lot > of work that no one has undertaken > so far (I tried, but failed ;) ) > > I understand that code duplication is often not bad, but in the case of > stm32 it is a bit too high. It's partly ST's fault > because of how they release their manuals. The user must spend a lot of > time to come to the conclusion > that the only thing that changes in the other version of the chip is the > chip code number in the reference manual :) > > > pt., 8 wrz 2023 o 11:11 napisał(a): > > > Hi, all > > > > I would like to start working on developing support for STM32H735 > > microcontrollers in NuttX OS, but I found some strange things in the > > principle of configuring this series of microcontrollers. > > > > Microcontrollers of the H7 series are divided into several subseries, > each > > united by one reference manual: > > - STM32H723/733, STM32H725/735 and STM32H730 (RM0468) > > - STM32H745/755 and STM32H747/757 (RM0399) > > - STM32H742, STM32H743/753 and STM32H750 (RM0433) > > - STM32H7A3/7B3 and STM32H7B0 (RM0455) > > > > But some header files in arch/arm/include/stm32h7 are designated as > > stm32h7x3xx_irq.h or stm32h7x5xx_irq.h, although they are only for the > H743 > > or H745 series respectively, not for H723 or H735. And such a > discrepancy > > is also present in other source code files that belong to the H7 series. > > > > Maybe it's worth fixing this somehow? Will this break anything > important? > > > > > > Oleg Svezhinskiy > > >
RE: Addition of STM32H7 MCU's
You're right, but not entirely) For example, chips of different subseries have different interrupt vector tables. Those. The stm32h7x3xx_irq.h file lists interrupt vectors for the RM0433, but not for the RM0455 or RM0468. Although some chips from all these series have 7x3 in the name. От: "raiden00pl" Кому: "undefined" Отправлено: пятница, 8 сентября 2023 г., 12:52 Тема: Re: Addition of STM32H7 MCU's >From what I'm familiar with STM32H7, all chips use the same registers and bit definitions. Therefore, keeping definitions for different chips in different files doesn't make sense in my opinion. The only problem is that some chips support some peripherals while others do not. But this can be solved using definitions from Kconfig, where we define the supported peripherals anyway, using `select STM32H7_HAVE_xxx`. In that case, it's possible to have only one version of files with hardware definitions (irq, peripherals) and guard the optional functionalities with `#ifdef CONFIG_STM32H7_HAVE_xxx`. Moreover, I think this can be done for all stm32 families, but it's a lot of work that no one has undertaken so far (I tried, but failed ;) ) I understand that code duplication is often not bad, but in the case of stm32 it is a bit too high. It's partly ST's fault because of how they release their manuals. The user must spend a lot of time to come to the conclusion that the only thing that changes in the other version of the chip is the chip code number in the reference manual :) pt., 8 wrz 2023 o 11:11 napisał(a): > Hi, all > > I would like to start working on developing support for STM32H735 > microcontrollers in NuttX OS, but I found some strange things in the > principle of configuring this series of microcontrollers. > > Microcontrollers of the H7 series are divided into several subseries, each > united by one reference manual: > - STM32H723/733, STM32H725/735 and STM32H730 (RM0468) > - STM32H745/755 and STM32H747/757 (RM0399) > - STM32H742, STM32H743/753 and STM32H750 (RM0433) > - STM32H7A3/7B3 and STM32H7B0 (RM0455) > > But some header files in arch/arm/include/stm32h7 are designated as > stm32h7x3xx_irq.h or stm32h7x5xx_irq.h, although they are only for the H743 > or H745 series respectively, not for H723 or H735. And such a discrepancy > is also present in other source code files that belong to the H7 series. > > Maybe it's worth fixing this somehow? Will this break anything important? > > > Oleg Svezhinskiy >
RE: Addition of STM32H7 MCU's
The way to fix it is to fully name the files that are *different* by replacing the x with the part number’s digit E.G. stm32h7x3xx_irq.h -> stm32h723xx_irq.h The top level inclusion file will have the ifdef logic to include the correct part based on chip selection: See https://github.com/apache/nuttx/blob/master/arch/arm/include/stm32h7/irq.h#L70-L84 Even if it duplicates 90% of the file it is better than #ifdefing the stm32h7x3xx_irq.h file. AKA ifdef rash! David *From:* o.svezhins...@indrones.ru.INVALID *Sent:* Friday, September 8, 2023 5:16 AM *To:* dev@nuttx.apache.org *Subject:* Addition of STM32H7 MCU's Hi, all I would like to start working on developing support for STM32H735 microcontrollers in NuttX OS, but I found some strange things in the principle of configuring this series of microcontrollers. Microcontrollers of the H7 series are divided into several subseries, each united by one reference manual: - STM32H723/733, STM32H725/735 and STM32H730 (RM0468) - STM32H745/755 and STM32H747/757 (RM0399) - STM32H742, STM32H743/753 and STM32H750 (RM0433) - STM32H7A3/7B3 and STM32H7B0 (RM0455) But some header files in arch/arm/include/stm32h7 are designated as stm32h7x3xx_irq.h or stm32h7x5xx_irq.h, although they are only for the H743 or H745 series respectively, not for H723 or H735. And such a discrepancy is also present in other source code files that belong to the H7 series. Maybe it's worth fixing this somehow? Will this break anything important? Oleg Svezhinskiy
Re: Addition of STM32H7 MCU's
>From what I'm familiar with STM32H7, all chips use the same registers and bit definitions. Therefore, keeping definitions for different chips in different files doesn't make sense in my opinion. The only problem is that some chips support some peripherals while others do not. But this can be solved using definitions from Kconfig, where we define the supported peripherals anyway, using `select STM32H7_HAVE_xxx`. In that case, it's possible to have only one version of files with hardware definitions (irq, peripherals) and guard the optional functionalities with `#ifdef CONFIG_STM32H7_HAVE_xxx`. Moreover, I think this can be done for all stm32 families, but it's a lot of work that no one has undertaken so far (I tried, but failed ;) ) I understand that code duplication is often not bad, but in the case of stm32 it is a bit too high. It's partly ST's fault because of how they release their manuals. The user must spend a lot of time to come to the conclusion that the only thing that changes in the other version of the chip is the chip code number in the reference manual :) pt., 8 wrz 2023 o 11:11 napisał(a): > Hi, all > > I would like to start working on developing support for STM32H735 > microcontrollers in NuttX OS, but I found some strange things in the > principle of configuring this series of microcontrollers. > > Microcontrollers of the H7 series are divided into several subseries, each > united by one reference manual: > - STM32H723/733, STM32H725/735 and STM32H730 (RM0468) > - STM32H745/755 and STM32H747/757 (RM0399) > - STM32H742, STM32H743/753 and STM32H750 (RM0433) > - STM32H7A3/7B3 and STM32H7B0 (RM0455) > > But some header files in arch/arm/include/stm32h7 are designated as > stm32h7x3xx_irq.h or stm32h7x5xx_irq.h, although they are only for the H743 > or H745 series respectively, not for H723 or H735. And such a discrepancy > is also present in other source code files that belong to the H7 series. > > Maybe it's worth fixing this somehow? Will this break anything important? > > > Oleg Svezhinskiy >
