Re: [PATCH 1/2] stm32f100: Add the stm32f100 SoC

[Alexandre IOOSS]

On 6/15/21 10:04 AM, Alistair Francis wrote:
> On Tue, Jun 15, 2021 at 5:50 PM Alexandre IOOSS <erdnaxe@crans.org> wrote:
> > On 6/15/21 9:41 AM, Alistair Francis wrote:
> > > Aren't you missing some timers, like timer[5] 0x4000_0C00?
> > >
> > > Alistair
> >
> > I double-checked using the reference manual and the datasheet and there
> > is not timer[5]:
> > - page 36 of
> > https://www.st.com/resource/en/reference_manual/cd00246267-stm32f100xx-advanced-arm-based-32-bit-mcus-stmicroelectronics.pdf
>
> Strange, https://www.st.com/resource/en/datasheet/stm32f100rc.pdf
> describes Timer 5 and page 282 of the document you linked talks about
> timer 5 as well.
>
> Alistair
>
> > - page 30 of https://www.st.com/resource/en/datasheet/stm32f100cb.pdf
> >
> > I believe ST is skipping numbers to guarantee that timer[n] will have a
> > consistent address on different STM32 SoC.
> >
> > Thanks,
> > -- Alexandre

From what I understand from other STM32F100xx reference manuals:
I am implementing all peripherals in the STM32F100xx reference manual 
which match with what is actually in the STM32F100RB SoC (used in the 
STM32VLDISCOVERY).

STM32F100RC SoC implements more peripherals (more USART, more 
timers...). Adding these peripherals in stm32f100.c means that the 
STM32VLDISCOVERY machine would have peripherals that does not exist on 
the real target. Do we want to avoid that?

Should we keep stm32f100.c with the common subset of peripherals and 
extend it when a machine is using a variant with more peripherals?

I believe this issue is also linked with what Philippe proposed: we 
could abstract STM32 SoC in the same way ATMEGA is abstracted. This 
would make a lot of sense since the STM32 family has a lot of 
similarities and we don't want to bloat QEMU with N times the same code.

Thanks,
-- Alexandre

OpenPGP_signature
Description: OpenPGP digital signature