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 > > > > > >
