Embedded Development Tools collection includes all the ancillary tools necessary for cross development of microcontroller (MCU) and microprocessor (MPU) embedded devices. These tools included:
The Remedy Debugger evolved into the Remedy IDE and this is what we see today to provide the build and debug environment for Unison Operating System based embedded systems. The build and debug environment consists of an off the shelf IDE from a 3rd party integrated with other Remedy tools and Unison OS. Get more information here.
The Remedy bootloader uses a two stage mechanism to provide field service upgrades. The first step is transferring a new image in S-record or Hex format to the target system. The second step involves flashing and booting the new image, and reverting to the previous image if this new image fails. Get more information here.
Remedy OS Viewer is a tool to display Unison objects in the Remedy IDE environment. It is integrated into the Remedy IDE and provides updated information on operating system objects and system state information at each breakpoint. Get more information here.
Remedy RED provides a time based display, data display and report generation capabilities to users. The Remedy RED Analyzer runs in real time from network data provided by the target system or from a log file. It provides a time based display of target system logged data. Get more information here.
Remedy Power On Self Test (POST)
As a bespoke service, POST and Diagnostics may be quickly generated using a set of standard modules. These modules include basic processor checking, memory checking, external communication testing and more. Please consult the factory for details.
Remedy Checking tools
The Remedy Checking Tools are available at run time to check the stack high water mark and processor utilization. Demonstration examples are included with the standard kernel release along with the tools.
A C/C++ IDE or Integrated Development Environment integrates the editor, compiler tool chain and the debugger into one package. For the past decade or more, this has been the favored approach to debug embedded systems using a cross development approach with either dedicated hardware on the embedded processor and/or an in circuit emulator. Get more information here.
Development in C/C++ is generally done for deeply embedded systems. The reasons for this are:
- ● The language representation maps very well onto peripheral hardware control registers.
- ● Interrupt handlers are well represented using pointers to functions.
- ● Bit manupulations required for control registers are fast and clearly defined.
- ● Weak typing so that it is easy to use one type as another to deal with hardware issues.
- ● Run time polymorphism via function pointers.
The world has changed so much in the past few years as far as C/C++ compilers are concerned. As we have moved towards the web and web based implementations the entire notion of languages, compilation and libraries has changed. The GNU C/C++ compiler has remained relatively static and remains the mainstay of the embedded community. Get more information here.
You don`t have permission to comment here!