Difference between revisions of "DSDP/RTSC - xdc.platform.ICpuDataSheet"

From Eclipsepedia

Jump to: navigation, search
m
m
Line 22: Line 22:
 
*<tt>ti.sdo.ipc.Sem</tt><br><br>
 
*<tt>ti.sdo.ipc.Sem</tt><br><br>
  
== Sketch<br> ==
+
== Sketch<br> ==
  
The following notes sketch the current thinking.<br>
+
The following notes sketch the current thinking.<br>  
  
ICpuDataSheet would include a map of peripherals, say&nbsp;xdc.platform.IPlatform.Peripheral, were each peripheral would be a structure containing a name, base address, and an arbitrary hash of device specific attributes. <br>
+
ICpuDataSheet would include a map of peripherals, say&nbsp;xdc.platform.IPlatform.Peripheral, were each peripheral would be a structure containing a name, base address, and an arbitrary hash of device specific attributes. <br>  
  
*name would name a RTSC module that identifies the HW peripheral
+
*name would name a RTSC module that identifies the HW peripheral  
*the base address would be a device
+
*the base address would be a device  
*the attrs hash would contain attributes such as interrupt id
+
*the attrs hash would contain attributes such as interrupt id  
 
+
*a instance of the named module
The keys of the peripheral map might be the device-specific names for the peripherials.
+
  
 +
The keys of the peripheral map might be the device-specific names for the peripherials.
  
 +
Since each peripheral is an instance of a module, it can maintain "ownership" information and enforce the constraint that only one package may claim control of the peripheral.&nbsp; This will prevent applications from trying to use HW already managed by high-level packages.
  
 
== Resources  ==
 
== Resources  ==

Revision as of 20:57, 20 July 2009

Contents


Introduction

The current RTSC platform model contains a description of the hardware (HW) as a part of the configuration model.  This part of the model - accessible via Program.cpu - allows portable XDCscript code to reflect on the specific HW and conditionally generate results that are platform-specific.

Although the current HW model provides specific device information and a complete memory map as seen by executing applications, it does not currently provide a way to identify peripherals that are part of the device; e.g., what types of peripherals (timers, serial ports, ADCs, etc.) are present, how many exist, their base addresses, and any device specific attributes associated with these peripherals).

Goals

Extend the platform model to include a notion of a "peripheral" and augment the existing platform packages to include sufficient information to enable "automatic" configuration of peripheral drivers.  Automatic configuration implies:

  • user rarely needs to add configuration statements that are device specific
  • peripheral drivers can get information from the platform model (that is "implied" by the HW platform) sufficient to ensure all software drivers operate properly without conflict
  • the ability to detect conflicting/overlapping "ownership" of peripherals by separate runtime packages

Requirements

Automatic configuration of

  • ti.sysbios timers and
  • ti.sdo.ipc.Sem

Sketch

The following notes sketch the current thinking.

ICpuDataSheet would include a map of peripherals, say xdc.platform.IPlatform.Peripheral, were each peripheral would be a structure containing a name, base address, and an arbitrary hash of device specific attributes.

  • name would name a RTSC module that identifies the HW peripheral
  • the base address would be a device
  • the attrs hash would contain attributes such as interrupt id
  • a instance of the named module

The keys of the peripheral map might be the device-specific names for the peripherials.

Since each peripheral is an instance of a module, it can maintain "ownership" information and enforce the constraint that only one package may claim control of the peripheral.  This will prevent applications from trying to use HW already managed by high-level packages.

Resources

RTSC Platform Model Reference - the reference API for the current platform model