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