??? 08/12/08 09:27 Read: times |
#157417 - Probably debugging on PC Responding to: ???'s previous message |
I have been thinking about doing all debugging in a simulated environment on a PC. Input stimuli either from a pre-generated text file, a dialog or using a cable from the target hardware.
The debugging would not happen at the same speed as in the real target, but I have already put down limitations when it comes to speed. The virtual machines would be limited to either sample the current value of I/O as often as it manages, or have a FIFO with the last n samples taken at fixed times by the host. I whould be able to dedicate 40-50% of the host capacity for running virtual machines and then the virtual machines will have to settle for whatever they manages to do in that time. If all I/O is done using function calls instead of reading/writing global variables, then the code to use a stimuli file can be completely hidden in a framework, allowing most C compiler/debugger with the same int sizes to be used. Taking outside stimuli or allowing asynchronous events such as interrupts or signals would require creative coding of the framework, possibly with threads, or that the debugger supports plugins or is modified. Running in the actual hardware would probably limit the user to debug output on a 115200 baud port. If I go for emulating an existing processor architecture, then I would of course be able to run such a simulation on a PC too. There exists gcc + gdb for the AVR, so gdb could be modified to simulate not just an AVR chip but a virtual AVR chip with peripherials corresponding to the intended interface between the host processor and the virtual machines. Or it might be possible to do a "network debug session" where gdb uses a serial link and debugs the application directly in the target hardware. |
Topic | Author | Date |
Virtual or existing architecture for emulation | 01/01/70 00:00 | |
Additional info about host/usage | 01/01/70 00:00 | |
How about MIPS? | 01/01/70 00:00 | |
VHDL | 01/01/70 00:00 | |
take a look at the content | 01/01/70 00:00 | |
I think 8 or 16 bit is optimum | 01/01/70 00:00 | |
Maybe you should start with an ARM chip | 01/01/70 00:00 | |
I2L sounds interesting | 01/01/70 00:00 | |
It's probably best to check with the maintainers | 01/01/70 00:00 | |
Doesn't seem to be a C to I2L | 01/01/70 00:00 | |
The LLVM Compiler Infrastructure | 01/01/70 00:00 | |
Since there's help available ... | 01/01/70 00:00 | |
With the low price of 8-bit single chip MCUs... | 01/01/70 00:00 | |
Slave processors not an alternative | 01/01/70 00:00 | |
Users | 01/01/70 00:00 | |
Probably debugging on PC | 01/01/70 00:00 | |
Are you really going to do that! | 01/01/70 00:00 | |
Existing building blocks helps | 01/01/70 00:00 | |
It hasn't been done for you but ... | 01/01/70 00:00 | |
When I was in school ... | 01/01/70 00:00 |