IPC@CHIP® RTOS-PPC – API Documentation

Header image

Main page


Programming Environment

In general, the application programmer need not know any of what is stated here. This information is provided only for background information which may assist some developers who are working at a low level to better understand the system.

Topics

Virtual Address Space

The IPC@CHIP® uses the Memory Management Unit (MMU) built into the target computer hardware to provide the virtual address space shown in the following illustration.

MemoryMap.gif




Memory Management

The Memory Management Unit serves two primary purposes:

  1. Translates virtual addresses to physical addresses.
  2. Provides memory access protection based on access rights assigned by the system to the various regions of memory, thereby preventing application programs from harming system memory or memory belonging to other application programs.

As is indicated by the gray regions in the above system address space map, the address translation in many cases is simply one-to-one such that the virtual and physical addresses are one and the same.

All programs execute in the same virtual address space with address translation turned on.

Notes:

The term "virtual address" is used loosely throughout this documentation to refer to what the PowerPC architecture books call the "Effective Address" space, where they need to distinguish between a 32 bit address space (the Effective Address space) and the 52 bit PowerPC Virtual Address space. In this simple embedded system, no swapping of program memory to and from disk is performed during program operation. Operating systems commonly use such schemes to make a system's apparent memory space greater than the amount of actual physical RAM memory present in the system.

The benefit to not page swapping memory during operation, aside from having a simpler system, is that the system's realtime nature is more deterministic. Also, all programs' code and data are present in the same virtual address space at all times (until a program terminates, at which time that program's image will disappear from the address space). All of the application programs share the same point of view.

An object at address 'n' in program A is at that same address in program B. Only the memory access rights (Read/Write or Read-Only) differ between programs.

RTOS / System RAM

The system RAM occupies the lower area of the address space. The @CHIP-RTOS-PPC code and data resides here along with a system heap. The application program's space is allocated from this heap in a series of 4 kByte chunks ("MMU pages") which may or may not be contiguous in the physical memory. However by virtue of the system's MMU page tables, these possibly non-contiguous chunks of system heap space are made to appear contiguous in the virtual address space for use by the application programs.

Execution Privilege

Access Rights

Comment

User Mode

Read-Only

The RTX_MemWindow() API will not grant user write permission to this area.

Supervisor Mode

Read / Write

Write access is allowed here for program operation using the system stacks. Care must be taken to not write anywhere else!

Application Program Space

All application programs are placed in the 256 Mbyte segment starting at virtual address 0x1000,0000 up to 0x1FFF,FFFF. The virtual addresses are assigned to application programs by the system at program launch time in a manor intended to allow the program's heap space to grow during operation. Go here for a more detailed explanation on how the system allocates virtual address space to applications.

Execution Privilege

Access Rights

Comment

User Mode

Read / Write over a program's own space
Read-Only elsewhere (into neighbor programs)

The RTX_MemWindow() API can be used to gain write permission into neighbor programs.

The PROGATTRIB_FREE4ALL program attribute can be set to allow all other programs read/write access to your program's memory.

Supervisor Mode

Read / Write

Supervisor mode has write access into all programs.

The system's performance can be affected adversely if a program performs an excessive number of heap grow system calls. This performance drop will be due to the resulting size of the page tables, which are needed to make noncontiguous blocks of system heap space appear to the application program as one continuous sequence of virtual addresses. To avoid this fragmentation of system memory, the application program designer can adjust the program's heap parameters with the macros setHeapInitialSize and setHeapIncrement.

User Callback Stack Space

The stack space used by system tasks to make callbacks into user mode application code are mapped into this segment of the address space, which starts at virtual address 0x4000,0000. The addressable region will be a small number of 4 kByte pages to cover the task's user mode stack space.

Other tasks cannot execute instructions placed on another task's callback stack. (It is not expected that anyone should ever want to attempt this. But nevertheless, this is a restriction which exists due to the manor the @CHIP-RTOS-PPC handles this area of the virtual address space.)

Execution Privilege

Access Rights

Comment

User Mode

Read-Only

The RTX_MemWindow() API will not grant other tasks access to this area.

Supervisor Mode

-- void --

Callbacks operating in Supervisor mode use the normal system stacks and do not require access to this segment.

Non-Volatile SRAM

The non-volatile SRAM is divided into two parts. The first part is for private use by the system. The part owned by the system lies before the address contained in the gSysPublicData.sramAddr pointer, which marks the border between system and user non-volatile SRAM. The number of bytes SRAM available to the user is indicated in gSysPublicData.sramSize.

Execution Privilege

Access Rights

Comment

User Mode

-- void --

By default, this area is not addressable in user mode. The RTX_MemWindow() API may be used to gain read/write access above the gSysPublicData.sramAddr border.

Supervisor Mode

Read / Write

CAUTION: Writes to locations below the gSysPublicData.sramAddr border must not be made as this can interfere with the system's fault reporting.

External Chip Selects

The void area is available for users to optionally attach their own external memory or hardware. The location of this area in the virtual address space is stated here for reference only and should not be considered part of the API, as this is subject to change in future @CHIP-RTOS-PPC releases. The return value from csSetMode() should instead be used to locate this area.

Execution Privilege

Access Rights

User Mode

Read / Write

Supervisor Mode

Read / Write

Hardware I/O

The system's hardware devices are located in this segment, starting at 0xF000,0000.

CAUTION: Access to the hardware by application programs may interfere with the system's operation.

Execution Privilege

Access Rights

Comment

User Mode

-- void --

By default, this area is not addressable in user mode. The RTX_MemWindow() API may be used to gain read/write to these hardware locations.

Supervisor Mode

Read / Write






Top of page | Main page

Copyright © 2017 Beck IPC GmbH
Generated on Thu Jan 26 16:21:35 2017 by Doxygen 1.6.1