On Tue, Jun 15, 2021 at 7:15 PM Alexandre IOOSS <erdn...@crans.org> wrote: > > > > On 6/15/21 10:04 AM, Alistair Francis wrote: > > On Tue, Jun 15, 2021 at 5:50 PM Alexandre IOOSS <erdn...@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).
Ah, my mistake. The STM numbering always confuses me. > > 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? Yep, this is fine as is. > > 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. I agree. That's the best way forward and I think it's a good goal. We don't have to block this series on that though. If you would like to work on a shared abstraction that would be great :) Once the IRQs are fixed: Reviewed-by: Alistair Francis <alistair.fran...@wdc.com> Alistair > > Thanks, > -- Alexandre >
