![]() |
![]() |
![]() |
||||
![]() |
|
|||
1. How does PromICEs Analysis Interface provide source-level debugging? Grammar Engine pioneered the virtual UART for monitor-based debugging. When a monitor-based debugger is used without the PromICE, a small program residing on the target (the monitor) communicates with the host software via a serial port on the target. The host software provides a debugging environment which typically allows source code to be displayed, the ability to single step through code, and the setting of software breakpoints to stop the operation of the program, allowing the examination of registers or watch-points. When PromICE is introduced into the development environment, the I/O of the monitor is re-routed from the targets serial port to a specific memory location. This I/O is read by circuitry in PromICEs Analysis Interface and transferred to the host via the serial port, where it is recognized as standard host-target communication from the monitor. 2. What features does PromICE add when used with a monitor-based debugger? While PromICE does not add any specific new features, it does make a monitor-based debugger operate much more efficiently. PromICE allows: Eliminates use of the targets serial port for debugging by using PromICEs AI channel, a serial port on the target does not need to be dedicated for debugging. This frees it for use in the application. In addition, it eliminates conflicts between a debugger and serial device drivers provided for the application by an RTOS on the embedded target. Speeds up development by providing fast downloads rather than downloading over a targets serial port, ultra fast downloads can be performed on any target via PromICEs parallel port or over an Ethernet network. In fact the entire compile-load reset-test cycle can be automated, as PromICE can be loaded from a batch file and will hold the target in reset while firmware is being loaded, and allow the target to run when PromICE begins emulating system memory. No code relocation and extra SRAM is required Typically, a monitor-based debugger requires a monitor burned in ROM and the entire application downloaded and run out of SRAM. This may require adding SRAM to a prototype board to test and debug a configuration that may never ship in the final product design. PromICE allows the testing of code in the products final configuration: loaded in ROM and executes in ROM. PromICEs write line allows setting software breakpoints even when code is in "ROM", or in this case, PromICEs emulation memory. 3. What can I use the AI channel for besides source-level debugging? Besides support for source level debuggers, the AI channel can be established on the host using a terminal emulation program. Much like the 'printf' method of debugging, an application can send data via the AI channel indicating execution progress or program status. You can also pass commands to the target when you have a custom monitor running on it. This simple but powerful debugging method can be instrumental in bringing up new hardware or locating where in a program a problem is occurring. 4. What debuggers and processors does PromICE currently support? Click here for a list of debuggers currently supported or under development for source level debugging via a virtual UART. 5. The debugger Im using is not listed or Im writing my own debugger. Can I port PromICE to it? If you simply want to use the AI channel to read and write data between target and host, the protocols and procedures required are documented in the PromICE manual. If you want to fully integrated PromICE and its features into a debugger or other application, a DLL that controls PromICE is being developed, and a Software Development Kit with a complete PromICE API will be available in the near future. Contact Grammar Engine for details. |
||||
|
||||
Grammar Engine Inc. Copyright
2001 © All Rights Reserved
|
||||
Site Design by Web
Junkies
|