Closed oallaire closed 7 years ago
Olivier, thank you for the PR, but I'm afraid it is impossible to review it, there are too many files.
Please consider the following suggestions:
hw/cortexm
folder must be indented using the given Eclipse formatterWhat board did use the F072 device?
Another suggestion:
Hi!
I removed all generated files. The only thing that is required now is the SVD file from the Keil packs version 1.5.0 for the F0 family.
Where is the XML file for the eclipse CDT formater? I've searched in the QEMU repository, but maybe it's not the correct place to look for it.
I'm sorry for the lengthy pull request. It was touch and go for while since it was my first time playing around with QEMU. I will try to be better organized for the next one.
For the board, I used STM32F0-Discovery to test. I know that it uses a STM32F051, but for now, I didn't need a particular board because my goal was to run unit tests on the initialization of peripherals for MAL.
When I run code on a physical device, I either use a Nucleo with an STM32F072 or a production board I have for a compagnie I work for.
I hope it's not a problem that there is no working board with this MCU for now. I tried the generic board, but I couldn't get it to work.
I'll try to review the changes, but it'll take a few days.
I hope it's not a problem that there is no working board with this MCU for now
the idea to use one board with a different processor is not fortunate, and it'll probably be deprecated in future versions (specifying a --mcu
will be ignored). the reason is that board definitions link some external devices, like LEDs, buttons, to MCU peripherals, which might not be available on different MCUs.
the expected approach is to correctly emulate boards.
My problem is I would like to run unit tests for specific MCUs that do not always have development boards. I have 2 solutions I can think of.
The first would be to create a fake development board based on a similar board (NUCLEO in this case).
The other solution would be to design a simple board where the gerbers are publicly available on github for MAL since the unit tests I want to write are for library.
What do you think?
for the changes to be integrated in the public release, I prefer a real board.
So is the second solution acceptable? I can design a fully working board and use 3D exports for images.
let me rephrase: 'I prefer an existing, well-known, physical board'. NUCLEO is fine.
Ok, I won't do it in this pull request to keep it small, but I will work my way to use the NUCLEO-F072RB development board in subsequent pull requests.
I will work my way to use the NUCLEO-F072RB development board in subsequent pull requests.
better do it right now.
the point is that your board should run a blinky test, like https://github.com/gnuarmeclipse/eclipse-qemu-test-projects/tree/master/f051-disc-blink.
Ok, will get right on it then!
Thanks for all the help on this!
Where is the XML file for the eclipse CDT formater?
I created the NUCLEO-F072RB board. I changed the MCU from STM32F072CB to STM32F072RB to use the actual MCU on the board.
I tested the win64 build with the test project in this pull request: https://github.com/gnuarmeclipse/eclipse-qemu-test-projects/pull/1
Hope I didn't forget anything!
If you confirm that the test passed on both the real board and qemu, we're ready for the merge.
Yes, on both the development board and qemu, the LED has the same behavior. It is also identical for the user and reset button.
it looks functional, the test application blinks the led and both buttons are functional.
thank you for your contribution!
My pleasure.
Thank you for these awesome projects!
I only tested the win64 build in my environment setup.
Most of the files changed were auto-generated by the scripts in /Work/qemu/gnuarmeclipse-qemu.git/gnuarmeclipse/devices/support.
Hope I didn't forget anything!