On Thu, Nov 13, 2014 at 5:48 PM, Liviu Ionescu <i...@livius.net> wrote: > > On 13 Nov 2014, at 02:11, Alistair Francis <alistai...@gmail.com> wrote: > >> I am trying to model the Netduino Plus 2 (STM32F4xx - Cortex-M4) board... >> upstreamed to mainline by using the Netduino 2 board (STM32F2xx - >> Cortex-M3). > > ok, great work! > > however, I'm more interested in a more systematic approach; before going into > the devices of a specific board, I would like to know that (in order) > - the core Cortex-M is properly supported, then > - the specific Cortex-M0/0+/3/4/(7) are supported (system devices, debug > registers, etc), then > - the STM families STM32F[012347] are supported, then > - specific devices like STM32F405/STM32F205/etc are supported (well, at a > certain degree, at least run the CMSIS SysInit() init code), and then > - implement board peripherals. > > can you confirm that your code properly runs the CMSIS SysInit() code, and > that using SysTick in the application properly sets the timer frequency, > based on the actual processor clock setting?
I haven't looked into CMSIS or using SysTick, so I can't confirm that they work. I don't have any experience with using either, so I can't really be of much help with those. Although they both look more like CPU functionality rather then board/machine functionality, I have focused on the board, SoC and peripherals, not on the CPU. > > in my GNU ARM Eclipse plug-ins I have C/C++ project templates for most STM > processor families; the results are simple but fully functional Blinky > projects, using SysTick for time reference and trace_printf() via > semi-hosting or SVD; my first priority is to be able to run these projects on > QEMU, and this requires, in addition to system peripherals, only a GPIO port, > so it must be is relatively easy to implement. > I have implementations for the more important system peripherals in the STM32F2xx/4xx SoC families, including GPIO. You are welcome to use those if you want >> All of my work can be seen at: https://github.com/alistair23/qemu. >> Some of it is specific for my use case (it is aimed as a learning tool >> for a University class) so if you need any help understanding what I >> did just ask and I am happy to help. > > thank you, I appreciate it. > >> Support for the Cortex-M4 would >> be great so I will help where I can. > > up to now I fixed the semihosting/gdb issues, and prepared a version that can > be easily integrated into Eclipse, with a debug plug-in planned to handle > everything automatically, in the same manner I handle J-Link and OpenOCD. > > for the mid-term, I plan to use a systematic approach and try to define the > Cortex-M/STM32F generic code, up to F4 (F7?), even if I'll probably leave > many issues open, to be implemented in detail later. > > if you want to join, you're more than welcome. > I'll keep an eye on your work and help where I can. As I mentioned above my use case is more aimed at higher level machine/peripherals support > --- > > as suggested by Peter, I'm currently reorganising my patches to make them > less specifica, to be applied to the master branch (to be submitted soon). > Sounds good Thanks, Alistair > > regards, > > Liviu >
