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 <acas...@gmail.com> 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 <rob...@gmail.com> 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 <raiden0...@gmail.com> 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 <o.svezhins...@indrones.ru.invalid> > 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" <raiden0...@gmail.com> > > > > *Кому:* "undefined" <dev@nuttx.apache.org> > > > > *Отправлено:* пятница, 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 > > > > > > > > > > > > > > >
