On Tue, Apr 14, 2020 at 9:11 PM Gregory Nutt <spudan...@gmail.com> wrote:
> > > In reading about the STM32G4 family, someplace on the STmicro website, > this > > introductory page: > > > > > https://www.st.com/en/microcontrollers-microprocessors/stm32g4-series.html > > > > suggests that there's a "high degree of compatibility" with the stm32f3 > > series. > > > > I opened the datasheet for one of the stm32f3 parts we support > side-by-side > > with a datasheet for one of the stm32g4, and just scrolling through them, > > it seems the g4 has a lot more in terms of peripherals, including a high > > resolution timer (HRTIM), more analog, more communication, various math > > accelerators... > > Most STM32's, certainly F4, have HRTIM. Large number of peripherals is > not a big issue; the issue is if the IP is the same for a give instance > of the peripheral. How do you know whether the IP is the same? By which, I mean: Is there a better way than to study both datasheets and manually look for differences? More below... The F3 is not a good point of comparison. It is like the F1 with a > Cortex-M4. There will be a lot of differences compared to any > contemporary parts. Compare instead with one of the F4's. I bet you > find they are not so different. I'll look at that in the morning. More below... There are differences in STM32 peripherals already in > arch/arm/src/stm32. If only a couple of peripherals differ, then they > can still cohabitate. > > STM32L1 is supported in that directory and, in that case, I think it was > a mistake. The L1 is far too different from the other members supported > there (F1, F2, F3, F4). If I had it to do over, I would put L1, F1+F3, > and L2+L4 in three directories. That is, I admit, my fault. I did all > of those ports (at least initially) except for the L1. It might be worthwhile to refactor that, if it will make supporting other P/Ns easier and simplify the code. I haven't studied it in detail yet but as I get further into this, I'll keep that possibility in mind. Thanks, Nathan
