Interaction with peripherals, DMA, disruptions from ISR’s etc, and I’m with tekkineet. One category is for fairly generic algorithms, and this works best with just compiling the code as a PC program and debugging it with whatever IDE you’re happy with.Īnother category is microcontroller specific code. Posted in ARM Tagged arm, arm cortex, qemu Post navigationįor me debugging falls into several categories. The code is made to work with Eclipse, although we bet it will work with other IDEs, too. You can write debug messages to a UART, but you can use semihosting to write to a file descriptor on the host computer. The interrupt handling is reportedly not very high-fidelity. You don’t get floating point M4 instructions, for example. You can see a decidedly simple video example from of blinking a virtual LED in the video below, although you might like to mute your audio before playing it. They have plans to support several popular boards from TI, Freescale, and others, but no word on when that will happen. The tool supports boards like the Maple - which means it should support bluepill, along with popular boards such as the Nucleo, some discovery boards, and several from Olimex. It allows you to run and debug embedded Cortex-M devices in an emulated environment on a host computer. QEMU is probably the best-known program that allows a CPU to run code targeting a different CPU, but - by default - it targets desktop, laptop, and server-class machines, not tiny embedded boards.
If you are emulating the same kind of computer you are on then the process is simpler, but it is possible to run, say, ARM code on an x86 (or vice versa) but with possibly slower performance than running natively. We run Windows in a VM and do kernel development in a VM, too. With the advent of super powerful desktop computers, many developers make use of some sort of virtual or psuedo-virtual machines (VM).
0 kommentar(er)
