Start
• A
Solution? •
Best
of Both Worlds •
Two
Approaches •
A
Win32 Compatible RTOS
• Development
Process •
Scalability
•
Software
& Sources
DEVELOPMENT
PROCESS
The
software development process begins with RTTarget-32,
and proceeds in a manner that doesn’t intrude
into the compiler’s normal development cycle.
The compiler with its linker and run-time system libraries
is used in the same way as for native Win32 development
(see Figure 3).
|
Figure 3—This diagram
illustrates creating a binary program image
file with standard Win32 compilers and the
On Time Embedded RTOS.
|
Both
the compiler’s command-line tools and IDE can
be used. A library is supplied to make RTTarget-32’s
Win32 and non-Win32 API available to the application.
Other RTOS components are supplied as additional libraries.
RTTarget-32’s
locator processes a standard Win32 .EXE file and a
target hardware configuration file. The various components
of the .EXE are located (and possibly separated into
RAM and ROM areas).
The
locator includes boot code and required DLLs into
the program image and generates a single application
image file that can be burned into an EPROM or placed
on a boot disk. During development, the application
is located by downloading over a serial link under
the control of the cross debugger or a download utility.
RTTarget-32
consists of:
- configurable
target boot code
- bootdisk
utility
- locator
- target-resident
debug monitor for remote debugging
- download
utility and debugger
- Win32
emulation library providing approximately 160 Win32
API functions
- serial
I/O library
RTTarget-32
supports Borland C/C++, C++ Builder, and Delphi as
well as Visual C++ and Watcom C/C++. The cross debugger
is based on Borland’s TD32 and supports source-level
remote debugging of Borland, Microsoft, and Watcom
programs. Integration into the Microsoft Visual Studio
and Borland IDEs permits use of those environments’
debuggers as well.
The
debugger supports embedded-systems development (interrupt
handling, port I/O, etc.). State-of-the-art data compression
and caching allow fast downloading.
Another
feature is the efficient use of the memory management
and debugging facilities of ’386 and higher CPUs.
RTTarget-32 can use paging for memory protection,
RAM remapping, and uncommitted memory.
When
memory protection is enabled, critical system data
structures such as descriptor tables are inaccessible
to the application code. Writing to read-only data
areas is not permitted and triggers an exception.
RAM
remapping can be used to combine fragmented memory
regions to larger consecutive regions (e.g., conventional
and extended memory on PC-compatible systems) or consecutive
virtual regions consisting of both RAM and ROM can
be created.
Uncommitted
memory enables an application to differentiate between
reserving and using (committing) address space. Most
C/C++ run-time systems rely heavily on uncommitted
memory so it must be supported by the OS for efficient
memory management.
Of
course, access to physical memory for DMA or memory-mapped
devices is supported by assigning appropriate access
rights for these memory regions (either statically
in the locate process or dynamically at runtime).
The
CPU’s debug registers, in combination with paging,
enable the implementation of powerful debugging features
and can remove the need to use ICEs. Any invalid memory
reference triggers an exception. Within the debugger,
the offending instruction is highlighted and the cause
of the problem can be investigated.
Debug
registers are used to implement hardware breakpoints
(e.g., break on a write cycle at a specific address).
Hardware breakpoints can be set in ROM or RAM and
don’t change the program’s run-time behavior.
