|
µC/Probe Communication Protocols
You are here : Micrium
: Products : µC/Probe : Communication Protocols
How µC/Probe Works
µC/Probe is a one-of-a-kind tool that allows you to use your Windows PC to read and write the variables that make up your embedded application. In order to provide this service, µC/Probe needs access to the executable file corresponding to your application. This file, which µC/Probe uses to determine your variables' memory addresses, must comply with one of the following formats: ELF/DWARF, IEEE-695, or CDF (Chip Definition File).
In addition to an executable file that relates variable names to memory addresses, µC/Probe needs a means of communicating with your embedded system. Accordingly, you must select the protocol that will facilitate communication between µC/Probe and your embedded device. Currently, µC/Probe supports the below communication protocols:
RS-232C and RS-485
µC/Probe can interface with a target processor using a UART. This means that µC/Probe can work with virtually ANY microprocessor on the market (8-, 16-, 32- and 64-bit CPUs, as well as DSPs).
The target requires resident code to interface to the Windows application. However, Micriµm provides ports (in source form) for a number of popular target platforms. You can easily adapt one of these ports to new target CPUs and UARTs.
Note that µC/Probe can also work with an RS-485 interface since it is the same communication protocol. |
|
TCP/IP
µC/Probe can interface with a processor using TCP/IP, assuming that the target is running a TCP/IP stack. µC/Probe works with any TCP/IP stack that supports the BSD V4 socket interface.
|
|
USB
µC/Probe can interface with a processor using USB, assuming that the target is running a USB-Bulk device stack (available from Micriµm). |
|
JTAG
µC/Probe can interface with an ARM processor (ARM7, ARM9, or ARM11) using a J-Link (a type of JTAG adapter), through the ARM Debug Communication Channel (DCC).
The µC/Probe target-resident code (provided in source form) doesn't interfere at all with the application when used with an RTOS like µC/OS-II (or any other RTOS) because this code is placed in the RTOS's idle task. In other words, the DCC is monitored when no application tasks are running. |
|
|
