Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
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.

List of 20 messages in thread
TopicAuthorDate
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      

Back to Subject List