I'm not sure the vendor specific timers are properly implemented in QEMU.
SysTick, as the system timer, is certainly implmented and functional, but the other timers... I don't know.
> how can I help to get it working
first check if the TIM* peripherals are there, and if there are any callbacks implemented.
Yes, my SysTick timer works great
Yes, it looks like there is support for TIM10. `gnu-mcu-eclipse/devices/support/STM32F40x/tim10.c`
I'll have a more in depth look tomorrow (after some much needed Zzzzzz).
I took a look and the folder you saw has the definitions generated automatically from the json, but the TIM peripherals are not yet in the build (/hw/cortexm/stm32).
what you need to do is to create a new file, like /hw/cortexm/stm32/tim.c, and copy/paste the definitions from the file you identified; use the gpio.c as inspiration.
it is not rocket science, it is quite mechanical.
once the definitions are there, you should be able to read/write the timer registers, even if no actions will be triggered.
in the next step you should add the callbacks, to implement the timer functionality, using the SysTick as inspiration.
it might take you a few days of work, but I think it is a very useful experience.
my secret thought is to rework the Cortex-M support in QEMU, to make it even more automated, and I would really need your help to discuss the details and choose the best solutions.
from my point of view, QEMU is a major component of a development environment, since it is a very convenient way to run semi-hosted unit tests.
FYI, while developing the µOS++ framework, which also includes a scheduler, I guess in only about 10% of tests I used a physical board; the rest was almost equally split between QEMU and the synthetic posix platform (macOS in my case, but Linux is also ok; windows would be a very important addition).
for the next release of µOS++ I plan to do the same, just that everything will be automated with xpm and xbld, and the tests should run on Travis, with each commit.
if you're interested in a development environment with advanced testability features, you're welcomed to the team!
OK. I'll take a look and be inspired by the the files you mentioned. I'll see how I get on. Guess I will have to bite the bullet and get a QEMU build env going.
Yes, QEMU should be a major component of dev env. It's the closest thing to running on real hardware, but can be accelerated and scaled up too.
I'm just tackling deficiencies as I find them. It's not very methodical at this stage - just the obvious ones (no blinking LED is easy to spot).
Does QEMU have UART support? Can attach a uart to TCP port, or a real serial port, etc? A TCP port could work (or socket?) and some kind of bridging software could be used to connect to real serial ports on the PC if needed (I think the bridge software already exists? COM0COM and friends?)
> get a QEMU build env going
yeah, right, it is not easy, but I don't think you can make any progress without it.
since we are both macOS users, I can not recommend Linux to you, but the truth is that for this kind of portable projects, Linux is probably the most convenient development platform.
the tools used by the builds are grouped in what I call 'XBB - the xPack Build Box' (https://github.com/xpack/xpack-build-box ).
to create the mac binary you do not need docker, you need a custom homebrew instace (and tex, if you want to generate the manuals too).
as with all my projects, there are build scripts to create the mac XBB: https://github.com/xpack/xpack-build-box/tree/master/macos
these build scripts are intended to run on an old macOS 10.10, to make the binaries usable on older macs too, but I guess they also run on a more recent mac.
once you have XBB installed, you should be able to build the qemu mac distribution: https://github.com/gnu-mcu-eclipse/qemu-build
there is a --debug option, that generates a debugable binary.
from here the only remaining trick is how to debug the binary.
unfortunately I do not have a document explaining it, since it took me several attempts to make it possible, and I still do not know if I found the best way... :-(
if necessary we can try together to find a convenient way, and possibly document the result.
> QEMU should be a major component of dev env. It's the closest thing to running on real hardware, but can be accelerated and scaled up too.
yes, but in addition it allows to run unit tests on CI servers, including Travis, which, for me at least, is a crucial feature.
> Does QEMU have UART support?
yes, QEMU does have all sort of UART support.
I added the stm32/usart.c file, but the guy who offered to contribute the actual implementation did not complete it, so now it is only partial.
I do not have very much experience with how usarts work in qemu, but most of the other platforms have usarts, so I guess it shouldn't be very complicated to implement them correctly for smt32 too. I remember there is a qemu fork that already did this, it might have been merged to master in the mean time.
perhaps this would be a good step before implementing the timers from scratch.
The one annoying thing about the WIndows version of QEMU is that console/stdout doesn't work (not when I last tried). I think this is QEMU upstream and I've tried lots of things to get something working but failed. I don't know why this is the case, when it works well on Linux and even little old macOS.
I'm ok working with Linux.
I think you run Docker containers. On Win 10 Docker uses the native windows hypervisor and doesn't need VirtualBox (if I recall correctly). I have VB installed anyway, so whatever works.
> I'm ok working with Linux.
well, personally, I'm an old Unix guy (mainly BSD), so I kind of avoided Linux; running some scripts is ok, but actively editing and debugging... I don't know...
I'd first try to recreate the development environment on mac, and if this is not realistic I'd consider the virtual Ubuntu box.
> I think you run Docker containers.
yes, for the linux/windows binaries, the build is performed inside Docker containers. for mac it runs natively.
> On Win 10 Docker uses the native windows hypervisor and doesn't need VirtualBox
never tried this, but based on the bad experience with running Docker on macOS, I'd not be very optimistic.
but the real limitation is that the build scripts were designed to start the Docker scripts from a bash environment, and I don't know how realistic is to expect them to run on Windows, be it WSL or msys2.
however since my experience with linux/windows is limited, any solution that you are comfortable with should be fine, even if this requires small changes to the scripts.
> The one annoying thing about the WIndows version of QEMU is that console/stdout doesn't work (not when I last tried).
I'm not sure what you mean. This is the copied from the Eclipse console, running on Windows 10 x64:
GNU MCU Eclipse 64-bits QEMU v2.8.0-4 (qemu-system-gnuarmeclipse.exe). Board: 'STM32F4-Discovery' (ST Discovery kit for STM32F407/417 lines). Device: 'STM32F407VG' (Cortex-M4 r0p0, MPU, 4 NVIC prio bits, 82 IRQs), Flash: 1024 kB, RAM: 128 kB. Command line: 'f4b-lto' (7 bytes). Cortex-M4 r0p0 core initialised. GDB Server listening on: 'tcp::1234'... Cortex-M4 r0p0 core reset. Other event 0x302 ... connection accepted from ipv6 host. Execute 'mon system_reset'. Cortex-M4 r0p0 core reset. PRIGROUP unimplemented Other event 0x302 Hello ARM World! System clock: 168000000 Hz [led:green on] [led:orange on] [led:red on] [led:blue on] [led:green off] [led:orange off] [led:red off] [led:blue off] Second 1 [led:green on] [led:green off] Second 2 [led:orange on] [led:orange off] Second 3 [led:red on] Graphic window closed. Quit.
Was QEMU run via Eclipse or directly from the Windows "Command Prompt"?
The setup I was trying to work with was Jenkins running on a Windows 7 box. I wanted to convert the PC based unit tests to build with arm-gcc and then run in on QEMU directly (no eclipse), capturing the console output. Simple semi-hosting hello world tests worked with Linux and macOS, but not Windows version of QEMU.
> Was QEMU run via Eclipse
> I'll stick with macOS dev env forQEMU if it's all native
yes, it's all native.
the only mystery we need to figure out is how to run debug sessions. last time when I did this was via Xcode, but there were some details that I remember only vaguely, like some commands to make the debugger not stop on each interrupt (actually signal).
gdb from Eclipse should also be possible, but I remember there were some small problems with it, so I went to Xcode.
Xcode was never my favourite. it is a powerful tool, but it favours Apple tools (Objective-C, now Swift), which I'm not very familiar with, thus I would say it has too many weirdnesses.
but running debug sessions shouldn't be mission impossible.
FreeBSD and NetBSD never rocked my boat, though OpenBSD did interest me. Not sure why now - probably lack of architectures supported, etc. Debian package management and software install via network repos (without rebuilding everything from sources) was a real winner for me. I started with Slackware and then Red Hat, but Debian fitted my needs and philosophy of truly open software. I'm probably moving to the Ubuntu camp, because I can get more up to date software more easily than with Debian proper.
Anyway, I'll stick with macOS dev env forQEMU if it's all native. No need to create more headaches than necessary at this stage
I have code that uses `TIM1_UP_TIM10_IRQHandler`, which toggles/blinks the blue LED. It works ok no a real STM32F4-Disco board, but the LED doesn't blink in QEMU.
It could be that I don't have things set up properly for GNU MCU Eclipse. I've had a quick look and things look ok, but I need to delve further.
Anyway I though I'd quickly ask to see if the `TIM1_UP_TIM10_IRQHandler` is known to work or not. If yes, I'll dig deeper. If not, then how can I help to get it working?