ENEA OSE Epsilon for ARM Board Support Package User’s Manual

AR

M B

SP

Enea Embedded Technology

2

4

OSE Epsilon for ARM

Board Support Package

Users Manual

EArmBspUG 4.6

AR

M B

SP

OSE /OSE Epsilon for ARM - BSP Users Manual

CopyrightCopyright (C) 2005 by Enea Embedded Technology. All rights reserved. No part of this publication may be reproduced, transmitted, stored in a retrieval system, or translated into any language or computer language, in any form or by any means, electronic, mechanical, optical, chemical or otherwise, without the prior written permission of Enea Embedded Technology. If, however, your only means of access is electronic, permission to print one paper hard copy is hereby granted. The software described in this document is furnished under a licence agreement or a non-disclosure agreement. The software may be used or copied only in accordance with terms of agreement.

DisclaimerEnea Embedded Technology makes no representations or warranties with respect to the contents hereof and specifically disclaims any implied warranties of merchantability or fitness for any particular purpose. Further, Enea Embedded Technology reserves the right to revise this publication and to make changes from time to time in the contents hereof without obligation to Enea Embedded Technology to notify any person of such revision or changes.

TrademarksOSE is a registered trademark of Enea Embedded Technology.

Boa

rd S

uppo

rt P

acka

ge

Users Manual / 4.6 Content 3

2

4

Content1 Introduction 5

2 BSP Concept 72.1 Board setup 82.2 Timer for BSP 82.3 OSE BIOS for BSP 8

2.3.1 biosInstall 92.3.2 biosOpen 92.3.3 biosCall 92.3.4 biosInit 9

2.4 Device drivers for BSP 9

3 Device Driver 113.1 Device Driver usage 123.2 Device Driver Functions 123.3 Device Driver Public Functions 13

3.3.1 _biosentry 143.3.2 _functions 153.3.3 _init 163.3.4 _intr 16

3.4 Device Driver Static Functions 173.4.1 ddDevClass 183.4.2 ddDevInfo 193.4.3 ddUnitInfo 203.4.4 ddOpen 213.4.5 ddStart 233.4.6 ddClose 243.4.7 ddGetConf 243.4.8 ddSetConf 253.4.9 ddWrite 273.4.10 ddRead 283.4.11 ddSimInt 293.4.12 ddAbortWrite 303.4.13 ddAbortRead 31

3.5 Device Driver Client Call Back Functions 323.5.1 dcAlloc 333.5.2 dcFree 333.5.3 dcHandleEX 333.5.4 dcHandleRX 343.5.5 dcHandleTX 35

4 Supported Boards 374.1 ARM Evaluator-7T Board 38

4.1.1 Board Setup 404.1.1.1 Files 404.1.1.2 Processes 404.1.1.3 Start Handlers 40

AR

M B

SP

4 Content Users Manual / 4.6

4.1.1.4 Configuration 404.1.2 ELDM Serial Driver 41

4.1.2.1 Files 414.1.3 On-Chip PPP Serial Driver 41

4.1.3.1 Files 414.1.3.2 Processes 414.1.3.3 Start Handlers 414.1.3.4 Configuration 41

4.1.4 LED Driver 424.1.4.1 Description 424.1.4.2 Files 42

4.2 Atmel AT91EB01 434.2.1 Board Setup 43


4.2.2 ELDM Serial Driver 444.2.2.1 Files 44

4.2.3 LED Driver 444.2.3.1 Files 44

4.3 Atmel AT91EB55 454.3.1 Board Setup 45


4.3.2 ELDM Serial Driver 464.3.2.1 Files 46

4.3.3 LED Driver 464.3.3.1 Files 46

Index 47

AR

M B

SP

Users Manual / 4.6 Introduction 5

2

4

1 IntroductionOSE Epsilon for ARM includes Board Support Packages (BSPs) for numerous boards in order to simplify development and decrease start-up times. The BSP includes various general components such as timer support (where needed by the kernel), interrupt handling and device drivers.All BSPs contain at least one serial driver and, for boards having an ethernet controller, a corresponding ethernet driver. All drivers included in the BSP are delivered in full source code and must be compiled by the customer.When writing a BSP for a board not supported by OSE, it is recommended to carefully study the header files of the delivered BSP.This manual is primarily intended for system designers and application developers who are implementing board setup and device drivers or writing applications that use the BSP. To be able to follow the configuration syntax in this manual the reader should have knowledge of C programming.This manual describes:

BSP Concept on page 7 gives an introduction into OSE Epsilon for ARM, BSP concept.

Device Driver on page 11 gives a detailed description of the OSE Epsilon for ARM device driver architecture.

Supported Boards on page 37 describes the boards supported by the OSE Epsilon for ARM board support package.

For specific information about the actual release of OSE Epsilon for ARM, see the Release Notes.For applications based on the OSE Epsilon for ARM system, the reader is referred to the OSE Epsilon for ARM, kernel manuals. Reading these manuals will give an understanding of realtime system design in general and the different mechanisms of the OSE concept in particular.If you are not familiar with the OSE Epsilon for ARM kernel, it is recommended that the OSE Epsilon for ARM Kernel product manuals be read first.

AR

M B

SP

6 Introduction Users Manual / 4.6

Boa

rd S

uppo

rt P

acka

ge

Users Manual / 4.6 BSP Concept 7

2

4

2 BSP ConceptThe OSE Epsilon for ARM BSP concept is designed to give software engineers a head start for developing software for standard hardware, as well as to provide a platform for those who will write a BSP for hardware that is not currently supported by OSE Epsilon for ARM. To create a BSP with OSE Epsilon for ARM, you need to include four system components described in the following sections:

Board setup on page 8describes board setup and initialization, executed normally in the context of the OSE Epsilon for ARM start handlers. These functions are called before the kernel has started.

Timer for BSP on page 8 describes the timer for boards where there is no internal system timer implemented in the CPU.

OSE BIOS for BSP on page 8 describes the OSE BIOS concept

Device drivers for BSP on page 9

All of these components are necessary to start OSE and to support I/O for on-board devices. Since the BSP is delivered as source files, the application writer is given full control to over the code to customize the BSP if so desired.

AR

M B

SP

8 Board setup Users Manual / 4.6

2.1 Board setupThis is some of the first code executed after a board reset. The purpose of this code is to bring the board to a state where OSE can access memory and devices. On most boards this includes setting up caches/memory, initiating the interrupt controller, masking all interrupts and initiating the on-board devices. This part of a BSP is highly board dependent.

2.2 Timer for BSPWhen the OSE kernel has started, it requires a system timer in order to do pre-emptive multitasking and handle delays. Some CPUs have their own internal system timers, which OSE supports. Where such isnt present, the BSP sets up a timer that generates an interrupt at a regular time interval, called the system tick. When the interrupt is generated, the interrupt service routine makes a system call to tick().

2.3 OSE BIOS for BSPThe OSE BIOS is a mechanism that makes it possible to register software modules with the kernel that can later be accessed by the user. In the BSP concept the BIOS is used to attach device drivers to the kernel at start-up. A BIOS is needed to let the device drivers execute in supervisor mode, thus gaining full access to the CPU, even if the user application runs in user mode.When using the BIOS calls, a transfer to supervisor mode is done. If the calling application process itself is running in supervisor mode, it can call device driver functions directly, thus gaining performance.The OSE BIOS is totally implemented outside the kernel, and the user is free to use it or not. It is however important to note at this point that some OSE Epsilon products, like the INET TCP/IP stack, use the BIOS concept. Device drivers for INET must therefore be designed accordingly.

The BIOS mechanism can be described as follows:The BIOS architecture is built with a table in which each device driver installs itself. Each element in the table consists of a string containing the device name and a pointer to the drivers entry point.

biosInit: Clear the table content

biosInstall: Append a new driver to the table

biosOpen: Search for the corresponding driver in the table and return the index

biosCall: Call the drivers entry function.

The bios functions are defined in the files bios.c and bios.h placed in the sourceand include directory of the bsp delivery.

Boa

rd S

uppo

rt P

acka

ge

Users Manual / 4.6 Device drivers for BSP 9

2

4

2.3.1 biosInstallBiosInstall is used by a BSP to install device drivers into the BIOS. A string is used as an identifier. This identifier should be used when later accessing the driver. A call to biosInstall has the following appearance:/* Install device driver for DEC21140 in BIOS. */

long err;

err = biosInstall( "DEC21140", DEC21140_biosentry, 0);

if (err != 0) error(OSE_BSP_EBIOSINSTALL_FAILED);The first parameter to biosInstall is the identifier string and the second is an entry point (a function) that the BIOS should use when calling the driver. The last parameter is a flag that specifies if a client executing in user mode is allowed to open the driver and that this driver supports the OSE device driver specifications. biosInstall may only be called by supervisor processes.

2.3.2 biosOpenWhen an application wants to use the driver, it must first obtain a handle. A call to biosOpen will return a handle. The call can look like this:handle = biosOpen("DEC21140");

This call returns a handle to the driver.

2.3.3 biosCallThe next step is probably to access the driver. This is done through calls to biosCall:err = biosCall (handle, DEVICE_FCOPEN, dco.unit, DEVICE_TSERIAL_PACKET,

&dco, &dcf, &isri);The call to biosCall takes at least two parameters, the first is the handle returned by biosOpen and the second is the function code for the function you want the driver to perform. The rest of the parameters are passed as parameters to the drivers function.

2.3.4 biosInitbiosInit() sets up the BIOS module.

2.4 Device drivers for BSPA device driver consists of a group of functions used to implement a physical or virtual devices functionality for the benefit of a higher level device client (typically an application process or the OS itself). A BSP usually has a serial device driver and an ethernet device driver.For a detailed description of the OSE device driver architecture, see Device Driver on page 11.

AR

M B

SP

10 Device drivers for BSP Users Manual / 4.6

AR

M B

SP

Users Manual / 4.6 Device Driver 11

2

4

3 Device DriverA device driver consists of a group of functions used to implement a physical or virtual devices functionality for the benefit of a higher level device client (typically an application process or the OS itself). A BSP usually has a serial device driver and an ethernet device driver.All OSE drivers share a standardized device driver interface, plus a device type specific interface add-on. The functions in all network device drivers (e.g. serial and ethernet) share the same syntax, and even the same semantics if used in automatic mode.Please consult the source code of the delivered device driver files to get information about using the device driver functions.See also:

Device Driver usage on page 12

Device Driver Functions on page 12

Device Driver Public Functions on page 13

Device Driver Static Functions on page 17

Device Driver Client Call Back Functions on page 32

AR

M B

SP

12 Device Driver usage Users Manual / 4.6

3.1 Device Driver usageIn order to use the device drivers, you must first compile them since they are delivered as source code. Note that many of the interesting settings are configurable at runtime. Once compiled, the module can be linked together to your system.To register the driver module, you must install it in BIOS by issuing a biosInstall() call.Example:long err = biosInstall(,_biosentry,

);

if(err != 0) error(OSE_BSP_BIOSINSTALL_FAILED);

The device driver modules can now be opened with a call to biosOpen() with the devicename as argument.Example:long handle = biosOpen(); if (handle != 0) /* device opened. */

The biosCall function is then used together with the function codes and error codes specified in the file, device.h.Example:int err = biosCall(handle, DEVICE_FCOPEN, );if (err == DEVICE_SUCCESS) /* Open call was successful. */

3.2 Device Driver FunctionsTechnically the device driver is just a collection of OS independent functions used to handle the device hardware. The device driver functions can be divided into two categories: public and static functions. Public functions can be called directly using the function symbol and some may be called through the BIOS.In order not to get symbol collisions the public functions must be uniquely named. As a result, the public functions are prepended with the name of the device driver followed by an underscore. For example, the function _functions() would be named Am79c970a_functions() for the AMD 79c970a Ethernet driver.Static functions can only be called through the BIOS or, if the device client executes in supervisor mode, a function pointer received from the public function _functions().

AR

M B

SP

Users Manual / 4.6 Device Driver Public Functions 13

2

4

3.3 Device Driver Public FunctionsThere are four types of public functions in the device driver (all with the prefix which should be replaced by the name of the device). The public functions are used in the initialization of the driver, interfacing to the BIOS and as interrupt service routines. Please note that though there are only four types of public functions there may be multiple _i functions. For a detailed description of the types of public functions, see:

_biosentry on page 14

_functions on page 15

_init on page 16

_intr on page 16

The two functions _init() and _functions() must be directly accessible or the device driver could only be used through the BIOS. The ISR entry point _i function(s) must be public for those operating systems that cannot dynamically create interrupt processes.Finally, the _biosentry() must also be directly accessible since the symbol is referenced in order to install the driver with the BIOS biosInstall(). Once the device driver is installed it can be initialized by calling _init() through the BIOS.

AR

M B

SP

14 Device Driver Public Functions Users Manual / 4.6

3.3.1 _biosentrySyntax long _biosentry (long arg1,

long, arg2,long, arg3,long, arg4,long, arg5,long, arg6,long, arg7,);

Description _biosentry() is the device driver BIOS handler entry point and is used toaccess the static functions. The first argument, arg1, is referred to as the function codeand contains a constant specifying which function to call in the device driver. The re-maining six arguments, arg2-arg7, are used to pass the arguments to the device driverfunction. _biosentry() must support the following device driver functioncodes:

Tags with a value of 0x4000_0000 and up to 0x7FFF_FFFF are reserved for customeradditions.

Parameters arg1 Device driver function code (DEVICE_FCXXX) signifying whichdevice driver function is being called.

arg2-arg7 These six arguments are parameters to the specified device driverfunction.

Function code Function

DEVICE_FCDEVCLASS ddDevClass

DEVICE_FCINIT _init

DEVICE_FCFUNCTIONS _functions

DEVICE_FCDEVINFO ddDevInfo

DEVICE_FCUNITINFO ddUnitInfo

DEVICE_FCOPEN ddOpen

DEVICE_FCSTART ddStart

DEVICE_FCCLOSE ddClose

DEVICE_FCGETCONF ddGetConf

DEVICE_FCSETCONF ddSetConf

DEVICE_FCWRITE ddWrite

DEVICE_FCREAD ddRead

DEVICE_FCSIMINT ddSimInt

DEVICE_FCABORTWRITE ddAbortWrite

DEVICE_FCABORTREAD ddAbortRead

AR

M B

SP

Users Manual / 4.6 Device Driver Public Functions 15

2

4

Return Value The return value of the device driver or DEVICE_EUNKNOWN if the BIOS handle orfunction code was invalid.

Errors DEVICE_EUNKNOWN Invalid BIOS handle or function code (arg1) is unknown.

Restrictions None.

3.3.2 _functionsSyntax const structs DdFuncs _functions

(void);Description _functions() is used to retrieve a set of function pointers from the device

driver in order to access the static functions directly. The return value is a pointer to astructure containing pointers to the static functions.

struct DdFuncs{

DevErr(*ddDevInfo) (DevTag * tagdList);DevErr(*ddUnitInfo) (U32 unit, DevTag *

taguList);DevErr(*ddOpen) (U32 unit, U32 deviceType,

void *dcObjects,const structDcFuncs * dcFuncs, struct ISRInfo *isrInfo);

DevErr(*ddStart) (U32 unit);DevErr(*ddClose) (U32 unit);DevErr(*ddGetConf) (U32 unit, DevTag *

tagcList);DevErr(*ddSetConf) (U32 unit, DevTag *

tagcList);DevErr(*ddWrite) (U32 unit, void *buf,

U32 * buflen);DevErr(*ddRead) (U32 unit, void *buf,

U32 * buflen);DevErr(*ddSimInt) (U32 unit);DevErr(*ddAbortWrite) (U32 unit);DevErr(*ddAbortRead) (U32 unit);

};Note that the device client must be in supervisor mode not only when calling _functions() but also to directly call any of the device driver functions. Howev-er, if the BIOS interface is used the device client does not need to be in supervisor modesince the process enters supervisor mode during the BIOS call.

Parameters None.

Return Value A pointer to a structure containing device driver function pointers.

Errors None.

Restrictions None.

AR

M B

SP

16 Device Driver Public Functions Users Manual / 4.6

3.3.3 _initSyntax void _init (void);

Description _init() initializes the hardware and disables the device hardware inter-rupts for the unit(s) that the driver supports. _init() is normally called inthe boot phase (start handler) when interrupts are disabled. At a later stage, external in-terrupts will be enabled in the cpu, so its important to make sure all potential interruptrequesters have been disabled.

Note that this function initializes all the units, i.e. it only has to be called once per driver.Calling _init() an additional time will completely and instantly reset thedriver, i.e. any memory allocated by open units is lost. Therefore, repeated calling ofthis function is only useful for complete system reboots.

This function could also be used to clear and set necessary global device driver varia-bles. Typically _init() may only initialize variables and stop ongoing in-terrupts and DMA transfers. No other device driver functions may be used before thisfunction has been called.

Parameters None.

Return Value None.

Errors None.

Restrictions Since the driver is not opened, no device client call-back functions may be used.

3.3.4 _intrSyntax void _intr (void);

Description _i() is the device driver interrupt service routine. Device driversthat are going to be used in interrupt mode must have one _intr() func-tion per interrupt vector the hardware can generate interrupt on. The number of ISRsdepends on the hardware and number of units that the driver supports. Some deviceshave one vector per unit and others have only one vector servicing multiple units. Thereceive and transmit done interrupt may have the same (combined) interrupt serviceroutine or different, again depending on the hardware.

Parameters None.

Return Value None.

Errors None.

Restrictions None.

AR

M B

SP

Users Manual / 4.6 Device Driver Static Functions 17

2

4

3.4 Device Driver Static FunctionsThe static functions form the main body of the device driver. The reason they are called static is because they cannot be accessed directly. In order to call a static device driver function the client has to either use the BIOS or function pointers retrieved by the public function _functions(). If the device client calls the static functions directly it has to execute in supervisor mode to be able to access the memory properly.For a detailed description of each static function, see:

ddDevClass on page 18

ddDevInfo on page 19

ddUnitInfo on page 20

ddOpen on page 21

ddStart on page 23

ddClose on page 24

ddGetConf on page 24

ddSetConf on page 25

ddWrite on page 27

ddRead on page 28

ddSimInt on page 29

ddAbortWrite on page 30

ddAbortRead on page 31

Static functions are declared in the DdFuncs structure (see _functions on page 15) except for ddDevClass(), which verifies that a BIOS module is a device driver according to this API. Two functions, ddDevInfo() and ddUnitInfo() are used to retrieve information about the device driver.A device driver is opened with ddOpen() and started with ddStart(). The driver can only be stopped by closing it with ddClose(). Before starting a driver, it may have to be configured with ddGetConf() and ddSetConf().Five functions deal with reading and writing data, most are only needed in manual mode. ddWrite() is used in all modes to write data to the link. In manual mode, ddRead() has to be used to request incoming packets. ddSimInt() is used in polled mode to simulate an interrupt since no interrupts are generated by the device. Finally, input and output may be aborted with ddAbortRead() and ddAbortWrite() respectively.

AR

M B

SP

18 Device Driver Static Functions Users Manual / 4.6

Static functions are usually executed in the device client's context, except for the code, including call-back functions (e.g.dcHandleTX()) that is executed in the device driver's interrupt context. None of the static functions may be called unless the device driver has been initialized with _init() first. Furthermore, the device client should call the device driver functions with interrupts enabled in the cpu. The static functions can disable interrupts internally at the source if needed.

3.4.1 ddDevClassSyntax U32 ddDevClass(void);

Description This function is used to verify that a BIOS module is a device driver compliant with thisAPI. ddDevClass() returns a constant which was initially set to a random value. The re-turn value should be compared to the current DEVICE_CLASS constant (defined in de-vice.h).

Parameters None.

Return Value The DEVICE_CLASS constant.

Errors None.

Restrictions This function is only accessible using biosCall().

AR

M B

SP


2

4

3.4.2 ddDevInfoSyntax DevErr ddDevInfo (DevTag *tagdList);

Description ddDevInfo() is used to retrieve information about a device driver. The caller must spec-ify which information should be retrieved by supplying corresponding tags. Each tagspecifies which option to retrieve and is followed by extra storage for the return valueof the option, a tag parameter. tagdList points to an array of tags, which must be termi-nated with the terminator tag DEVICE_TAGEND.

Valid device information tags:

DEVICE_TAGD_NAME

Return the device name in the specified buffer. The buffer must beminimum 32 characters large.

DEVICE_TAGD_VERSION

Returns the device version constant

DEVICE_VERSION

which is used to identify which interface version the driver supports.

DEVICE_TAGD_UNITLO

Returns the lowest numbered unit.

DEVICE_TAGD_UNITHI

Returns the highest numbered unit.

DEVICE_TAGD_OPENALL

Returns 1 if the client must open all units at once. This might be need-ed by some old hardware where the units cannot be operated separate-ly. If the units may be opened independently of each other then 0 isreturned.

DEVICE_TAGERRPTR

This tag's parameter is a pointer to a DevTag variable that will containa pointer to the tag that was unknown or had an invalid value. If noinvalid tag was detected in the tag list, the variable will be untouched.

DEVICE_TAGEND

This tag signifies the end of the taglist.

Tags with a value of 0x80000000 and above are reserved for customer additions.

Parameters tagdList Pointer to an array of tags.

Return Value DEVICE_SUCCESS

if device information taglist was successfully parsed else an errorcode.

Errors DEVICE_EINVALID_TAG

AR

M B

SP


Unknown device information tag. If an error pointer was supplied bythe tag DEVICE_TAGERRPTR it's value is set to point to the erro-neous tag field.

Restrictions None.

3.4.3 ddUnitInfoSyntax DevErr ddUnitInfo (U32 unit, DevTag * tagdList);

Description ddUnitInfo() is used to retrieve information about a specific device driver. The callermust, in addition to the unit number, specify which information should be retrieved bysupplying corresponding tags. Each tag specifies which option to retrieve and is fol-lowed by extra storage for the value of the option. taguList points to an array of tags,which ends with the terminator tag - DEVICE_TAGEND.

Valid unit information tags:

DEVICE_TAGU_DEVTYPES

Returns a U32 with the supported driver type (DEVICE_TXXX).This option is used to identify that the unit is a driver of the desiredtype. If the unit supports more than one device type these types willbe returned in different tags.

DEVICE_TAGU_INUSE

Returns a non zero value if the unit is open else zero. A unit may notbe opened again without closing it first.

DEVICE_TAGU_MAX_MTU

Return the hardware limitation on maximum transfer unit - MTU (inbytes).

DEVICE_TAGU_MAX_MRU

Return the hardware limitation on maximum receive unit - MRU (inbytes).

DEVICE_TAGU_NUMDEVTYPES

Return the number of supported device types.

DEVICE_TAGERRPTR

This tag's parameter is a pointer to a DevTag variable where the driverwill put the pointer to any tag that is unknown or has an invalid value.If no invalid tag is detected in the tag list, the variable will be un-touched.

DEVICE_TAGEND



AR

M B

SP


2

4

Parameters unit Which unit to retrieve information from.

taguList Pointer to an array of tags.


if device information taglist was successfully parsed else an errorcode.

Errors DEVICE_EILLEGAL_UNIT

An illegal unit number was specified.

DEVICE_EINVALID_TAG

Unknown unit information tag. If an error pointer variable was sup-plied by the tag DEVICE_TAGERRPTR it is set to point to the erro-neous tag field.

Restrictions None.

3.4.4 ddOpenSyntax DevErr ddOpen (U32 unit, U32 deviceType,

void *dcObjects, const struct DcFuncs *dcFuncs, struct ISRInfo *isrInpfo);

Description A device driver unit must be opened before it can be started. ddOpen() opens one unitand initializes it. The function call argument unit specifies which unit to open and de-viceType the desired device type. Valid device types are defined in the device specificheader files, e.g. serdev.h, ethdev.h. ddOpen() may use the call-back function dcAlloc()if memory is needed for buffer descriptors etc.

A device client opening a device driver must implement up to five call-back functions(dcAlloc, dcFree, dcHandleEX, dcHandleRX and dcHandleTX). The functions are usedby the device driver to allocate and free memory dynamically, report errors and asyn-chronously deliver input and output packets to the device client. Pointers to the call-back functions must be saved in a DcFuncs structure which is passed on to ddOpen. Inpolled mode will no interrupts be generated by the device. By calling ddSimInt thedcHandleEX and dcHandleTX will be executed and any outstanding events will be han-dled.

struct DcFuncs{ void *(*dcAlloc)(void *dcObjects,

U32 buflen);void (*dcFree) (void *dcObjects,

void *buf);void (*dcHandleEX) (void *dcObjects,

DevErr errorCode);void (*dcHandleRX) (void *dcObjects,

void *buf, U32 buflen, U32 numFR);void (*dcHandleTX) (void *dcObjects,

void *buf, U32 buflen, U32 numFW);};

AR

M B

SP


dcObjects is a void pointer which is passed on to ddOpen() only to be returned in all ofthe call-back functions. This may be very handy when handling multiple units with thesame call-back functions etc. The last argument to ddOpen() is a pointer to an ISRInfostructure that is filled in by the device driver. The device driver returns informationabout each interrupt service routine and it is then up to the device client to decide whatto do with the information. If the device client is using OSE Delta, it can create interruptprocess(es) which will handle the device interrupts.

struct ISRInfo{ /* Number of elements valid in the */

/* ISR array below. */U32 numISRs;

struct{ /* Entrypoint for the Interrupt */

/* Service Routine. */void (*entrypoint) (void);

/* Priority this interrupt operates *//* on. */U32 priority; /* 0 highest. */

/* The stack size (in bytes) that *//* this ISR needs. */U32 stacksize;

/* The hardware interrupt vector *//* number. */S32 vector;

}ISR[4]; /* A maximum of four ISR's */

/* per unit. */};If a NULL pointer is passed instead of isrInfo pointing to a structure, then the device isopened in polled mode, i.e. no ISRs are needed.

Parameters unitWhich unit to open.

deviceType The desired device type of the unit.

dcObjects A pointer to client specific object which is passed on to the call-backfunctions unmodified.

dcFuncs A pointer to a structure containing pointers to the device client func-tions.

isrInfo A pointer to an ISR information structure that is filled in by the driver.


if the unit was successfully opened or else an error code giving an in-dication why the open failed.


AR

M B

SP


2

4


DEVICE_EILLEGAL_DEVTYPE

An illegal device type was specified. The device does either not sup-port or implement the specified device type.

DEVICE_EALREADY_OPENED

The unit is already opened. An opened unit may not be reopened un-less it is closed first.

DEVICE_EFUNCTION_NOT_AVAILABLE

This obscure error code is used when the driver does not implement afunctionality that the device client requested. For example, if the driv-er does not support polled mode and ddOpen requests polled modethis error code is returned.

DEVICE_EDEVICE_NOT_FOUND

No hardware device was found when the driver was initialized.

DEVICE_EHARDWARE_ERROR

Hardware did not perform as expected.

DEVICE_ENO_BUFFERS

Driver cannot be started because no buffers are available, i.e. dcAl-loc() returned NULL.

Restrictions ISRInfo structure supports a maximum of four ISRs per unit. ddOpen may not changeddSetConf parameters.

3.4.5 ddStartSyntax DevErr ddStart (U32 unit);

Description A device driver must first be opened and then started before it can be used. The functioncall ddStart() starts a device driver unit.

Once started, ddWrite() may be used to write data to the device and the call-back func-tions dcHandleRX() and dcHandleTX() will be called as data is received or transmitted(interrupt mode only).

There is no function ddStop() to stop a device driver. The only way to stop a device isto use ddClose() which will automatically stop it. Then when the driver shall be restart-ed, it has to be opened and started once more.

Parameters unitWhich unit to start.


if the unit was successfully started or else an error code giving an in-dication why start failed.


AR

M B

SP



DEVICE_ENOT_OPENED

Device is not opened and cannot be used until opened.

DEVICE_EALREADY_STARTED

The unit is already started. A started unit may not be started again un-less it is closed and reopened first.

DEVICE_ENO_BUFFERS

Driver cannot be started because no buffers are available, i.e. dcAl-loc() returned NULL.

Restrictions None.

3.4.6 ddCloseSyntax DevErr ddClose (U32 unit);

Description ddClose() closes down a device driver unit. In interrupt mode input and output in proc-ess is aborted by ddClose() calling ddAbortRead() and ddAbortWrite(). Memory allo-cated with dcAlloc() is returned to the device client by calling dcFree(). All ddSetConfparameters has to be set to their default value.

Parameters unit Which unit to close.


if the unit was successfully closed or else an error code giving an in-dication why close failed.



DEVICE_ENOT_OPENED

Device is not open.

Restrictions None.

3.4.7 ddGetConfSyntax DevErr ddGetConf (U32 unit, DevTag * tagcList);

Description ddGetConf() retrieves the current configuration for one unit. The caller must, in addi-tion to the unit number, specify which configuration options should be retrieved by sup-plying corresponding tags. Each tag specifies which option to retrieve and is followedby extra data storage for the value of the option. tagcList points to an array of tags,which must be terminated with the terminator tag DEVICE_TAGEND.

Valid configuration tags depend on the type of device.


AR

M B

SP


2

4

This function can be called at any time by all processes.

Standard tags:

DEVICE_TAGERRPTR


DEVICE_TAGEND



Parameters unit Which unit to get configuration on.

tagcList Pointer to an array of tags.


if unit configuration taglist was successfully parsed else an error code.



DEVICE_ENOT_OPENED

Device is not opened.

DEVICE_EINVALID_TAG

Unknown unit information tag. If an error pointer variable was sup-plied by the tag DEVICE_TAGERRPTR it is set to point to the erro-neous tag field.

Restrictions None.

3.4.8 ddSetConfSyntax DevErr ddSetConf (U32 unit, DevTag * tagcList);

Description ddSetConf() is used to configure a device driver unit. The caller must, in addition to theunit number, specify which configuration options should be modified by supplying cor-responding tags. Each tag specifies which option to modify and is followed by the de-sired value for that option. tagcList points to an array of tags, which must be terminatedwith the terminator tag DEVICE_TAGEND.

Valid configuration tags depend on the type of device.


This function can be called at any time by all processes.

Standard tags:

DEVICE_TAGERRPTR

AR

M B

SP



DEVICE_TAGEND



Parameters unit Which unit to get configuration on.

tagcList Pointer to an array of tags.


if unit configuration taglist was successfully parsed else an error code.



DEVICE_ENOT_OPENED


DEVICE_EALREADY_STARTED

The unit is already started. A unit may not be configured once started.

DEVICE_EINVALID_TAG

Unknown configuration tag. If an error pointer was supplied by thetag DEVICE_TAGERRPTR it's value is set to point to the erroneoustag field.

DEVICE_EINVALID_VALUE

Invalid configuration value. If an error pointer was supplied by the tagDEVICE_TAGERRPTR it's value is set to point to the erroneous tagfield.

Restrictions None.

AR

M B

SP


2

4

3.4.9 ddWriteSyntax DevErr ddWrite (U32 unit, void *buf,

U32 *buflen);Description ddWrite() attempts to write *buflen bytes of data to the unit referenced by unit from the

buffer pointed to by buf. On return *buflen contains the actual number of bytes written.

Most drivers have several buffer descriptors forming a ring that can be used to placetransmit and receive buffers in queue. If there is a unused buffer descriptor at the mo-ment ddWrite() is called, the data buffer information (pointer and length) is stored bythe device driver and placed in queue to be written as soon as the link permits. Posttransmit processing will be called when transmission is finished. If the driver works ininterrupt mode, ddWrite() returns directly and an interrupt will be generated when thepackage has been sent. Otherwise, the driver polls the devices status until the packagehas been sent, and calls for post-transmit processing after that. It is important to notethat updating of the buffer descriptor is done in an atomic manner, and that ddWrite()is fully pre-emptive. In interrupt mode ddWrite() returns directly after buffer descriptorupdating and interrupt enabling, and in polled mode ddWrite may be pre-empted by ahigher priority process under the potentially more time costly poll I/O-accesses.

Post transmit processing is needed to update the buffer descriptor list, and to let the De-vice Client free the used data buffer, which was "borrowed" by the driver to avoid timecostly memory copying.

In interrupt mode, ddWrite() either succeeds in writing the whole buffer or not, i.e. itnever writes partial buffers. Only in polled mode may partial writes occur depending onthe MTU and internal buffering.

Parameters unit Which unit to write on.

buf Pointer to output data.

buflen The U32 pointed to by the buflen parameter should be initialized tothe number of bytes to write. On return it contains the actual numberof bytes written.


if *buflen (actual number of bytes written) was written else an errorcode giving an indication why write failed.



DEVICE_ENOT_OPENED


DEVICE_ENOT_STARTED

Device is not started.

DEVICE_EINVALID_LENGTH

Invalid length. It is not valid to write 0 bytes or a buffer larger thanmaximum transmit unit.

AR

M B

SP


DEVICE_EQUEUE_FULL

The internal output queue in the device driver is full and write failed.For each failed write, the device driver will increment a 'number oftimes write failed' counter which will be passed to the device client(using dcHandleTX()) next time a transmit done interrupt is serviced.The internal counter is set to zero after dcHandleTX() is called.

Restrictions None.

3.4.10ddReadSyntax DevErr ddRead (U32 unit, void *buf,

U32 *buflen);Description ddRead() is only used in polled mode, since interrupt mode automatically delivers data

to the device client by calling dcHandleRX().

In polled mode ddRead() is used to request incoming data. After calling ddRead() thebuffer is owned by the device driver. Once a terminator or *buflen bytes of data is re-ceived, input is disabled and the buffer is returned with the dcHandleRX(). The deviceclient then has to call ddRead() once again to request another packet.

Parameters unit Which unit to read from.

buf Pointer to data storage.

buflen The U32 pointed to by the buflen parameter should be initialized tothe number of bytes to read. On return it contains the actual numberof bytes read.


if ddRead was successfully called else an error code giving an indica-tion what error occurred.



DEVICE_ENOT_OPENED


DEVICE_ENOT_STARTED


DEVICE_EINVALID_LENGTH

Invalid length. It is not valid to read 0 bytes or more bytes than themaximum receive unit.

DEVICE_EQUEUE_FULL

AR

M B

SP


2

4

The internal queue of pending ddRead() requests is full. For eachfailed read, the device driver will increment a 'number of times readfailed' counter which will be passed to the device client (using dcHan-dleRX()) next time a receive interrupt is serviced. This counter is setto zero after dcHandleRX() is called.


ddRead() was called when in interrupt mode (not valid).

Restrictions None.

3.4.11ddSimIntSyntax DevErr ddSimInt (U32 unit);

Description ddSimInt() is used in polled mode only. The function is used to simulate an interrupt fora device. This is done by checking for new TX and RX events and calling the ISR forthe unit.

Parameters unit Which unit to read from.


if ddSimInt was successfully called else an error code explaining thecause of error.



DEVICE_ENOT_OPENED


DEVICE_ENOT_STARTED



Returned if device driver is not opened in polled mode and ddSimInt()therefore is not supported.

Restrictions Device clients may only call ddSimInt() when the unit is opened in polled mode.

AR

M B

SP


3.4.12ddAbortWriteSyntax DevErr ddAbortWrite (U32 unit);

Description ddAbortWrite() aborts the current write and returns the buffer by calling dcHandleTXwith buflen set to the number of bytes that was written before abort.

When ddClose() is called in interrupt mode ddAbortWrite() is automatically called onall pending writes.

Parameters unit Which unit to abort write on.


if ddAbortWrite was successfully called else an error code explainingthe cause of error.



DEVICE_ENOT_OPENED


DEVICE_ENOT_STARTED



ddAbortWrite() was called in polled mode.

Restrictions Device clients may only call ddAbortWrite() when the unit is opened in interrupt mode.

AR

M B

SP


2

4

3.4.13ddAbortReadSyntax DevErr ddAbortRead (U32 unit);

Description ddAbortRead() aborts the currently pending read requests and returns the buffers bycalling dcHandleRX() with buflen set to the number of bytes that was read before abort.This function is only needed in manual interrupt mode.

It is neither valid nor needed to call ddAbortRead() when in automatic mode since therecan be no pending ddRead() requests.

When ddClose() is called in interrupt mode ddAbortRead() is automatically called onall pending read requests.

Parameters unit Which unit to abort read on.


if ddAbortRead was successfully called else an error code explainingthe cause of error.



DEVICE_ENOT_OPENED


DEVICE_ENOT_STARTED



ddAbortRead() was called in polled or automatic mode.

Restrictions Device clients may only call ddAbortRead() when the unit is opened in manual mode.

AR

M B

SP

32 Device Driver Client Call Back Functions Users Manual / 4.6

3.5 Device Driver Client Call Back FunctionsThe device client, which is the application that uses a device driver, must implement up to five call-back functions in order to successfully use the driver. Two of the functions, dcAlloc and dcFree, are needed to dynamically allocate and free memory independently of the operating system whereas the other three are implemented for maximum performance.The three dcHandleX() functions are used to report errors, return transmitted packets, and asynchronously deliver incoming packets to the device client. Even if polled mode is used, the dcHandleX() functions must be implemented since they are called when using the function ddSimInt.The device client call-back functions may be called in the device client's own context or in the context of any the device driver's interrupt processes. As a result care should be taken when handling buffers and their process ownership.When using OSE, the system call restore() will most likely be needed in order to send or free a buffer since it may be owned by the device driver or the device client.For a detailed description of the call-back functions, see:

dcAlloc on page 33

dcFree on page 33

dcHandleEX on page 33

dcHandleRX on page 34

dcHandleTX on page 35

AR

M B

SP

Users Manual / 4.6 Device Driver Client Call Back Functions 33

2

4

3.5.1 dcAllocSyntax void dcAlloc (void *dcObjects, U32 buflen);

Description dcAlloc() is used by the device driver to request a block of memory of size buflen. De-pending on the system used to allocate the memory, dcAlloc() may fail if there is nomore memory, or buflen exceeds the maximum allocation size. dcAlloc() is normallycalled from either ddOpen() or ddStart() to allocate memory for buffer descriptors orfrom interrupt context to allocate memory storage for input packets. Since dcAlloc() ex-ecutes in the context of the calling process, the buffers may be allocated by differentprocesses. The buffer returned must be long word (U32) aligned.

Parameters dcObjects Pointer to client specific object.

buflen Number of bytes to allocate.

Return Value Pointer to a buffer of minimum size buflen or NULL if no memory is available or buflenis too large.

Restrictions None.

3.5.2 dcFreeSyntax void dcAlloc (void *dcObjects, void *buf);

Description dcFree() releases a previously allocated block. The second argument buf is a pointer toa block previously allocated by dcAlloc(). When using OSE, dcFree() probably has tocall restore() before free_buf() to guarantee buffer ownership before returning the buff-er to the operative system. When a device driver is closed with ddClose, it will returnall allocated memory by calling dcFree().


buf Pointer to a buffer previously allocated by dcAlloc().

Return Value None.

Restrictions None.

3.5.3 dcHandleEXSyntax void dcHandleEX (void *dcObjects,

DevErr errorCode);Description When an error is discovered during interrupt processing dcHandleEX() is used to asyn-

chronously report this error to the device client. After receiving an asynchronous errorreport, the device client must close and reopen the driver to assure that it is workingproperly. The error codes are defined in device.h. This function may also be used to re-port status changes.


errorCode Error code.

Return Value None.

Restrictions dcHandleEX() may not call any of the device driver functions (ddXXX()).

AR

M B

SP


3.5.4 dcHandleRXSyntax void dcHandleRX (void *dcObjects,

void *buf, U32 buflen, U32 numFailedReads);

Description dcHandleRX() is used in interrupt mode to asynchronously deliver incoming packets tothe device client. The first argument dcObjects is the same dcObjects pointer that thedevice driver received when it was opened with ddOpen(). buf points to the incomingpacket and buflen is equal to the number of bytes received. The buffer that buf pointsto was allocated by the driver using the dcAlloc() call-back. The last argument, num-FailedReads, is a counter equal to the number of times ddRead() failed since the lastdcHandleRX() call. The device driver clears its numFailedReads counter after eachdcHandleRX() call.

Note that in manual mode dcHandleRX() will not be called automatically, i.e. each suc-cessful ddRead() request results in one dcHandleRX() being called when data arrives.


buf Pointer to a buffer (retrieved either from ddRead() or dcAlloc()) con-taining the received data.

buflen Number of bytes received.

numFailedReadsThe current number of failed read requests.

Return Value None.

Restrictions None.

AR

M B

SP

Users Manual / 4.6 Device Driver Client Call Back Functions 35

2

4

3.5.5 dcHandleTXSyntax void dcHandleRX (void *dcObjects,

void *buf,U32 buflen,U32 numFailedWrites);

Description dcHandleTX() is used in interrupt mode to asynchronously return packets sent withddWrite() to the device client after the packet is written to the link.

The first argument dcObjects is the same dcObjects pointer that the device driver re-ceived when it was opened with ddOpen(). buf points to the written packet (the samebuffer that was delivered with ddWrite()) and buflen is equal to the number of bytes thatwere written. Since dcHandleTX() is only used in interrupt mode where no partialwrites are possible buflen will always be equal to the buflen ddWrite() was called with.

The last argument, numFailedWrites, is a counter equal to the number of timesddWrite() failed since the last dcHandleTX()call. The device driver clears its num-FailedWrites counter after each dcHandleTX() call.


buf Pointer to the buffer previously supplied in ddWrite().

buflen Number of bytes transmitted.

numFailedWritesThe current number of failed write requests.

Return Value None.

Restrictions None.

AR

M B

SP


Boa

rd S

uppo

rt P

acka

ge

Users Manual / 4.6 Supported Boards 37

2

4

4 Supported BoardsBoards supported are described in the following sections:

ARM Evaluator-7T Board on page 38

Atmel AT91EB01 on page 43

Atmel AT91EB55 on page 45

AR

M B

SP

38 ARM Evaluator-7T Board Users Manual / 4.6

4.1 ARM Evaluator-7T BoardEvaluator-7T offers an easy, affordable introduction to the ARM family of processor related products. It is ideal for new customers and students who want to evaluate and get acquainted with an ARM CPU and its software tools. Based on the ARM7TDMI microcontroller the Evaluator-7T supports the full range of ARM 7 instructions including THUMB instructions and can operate at speed of up to 50 MHZ.Features of the ARM Evaluator-7T Evaluation Board:

Easy to set-up and use

Compact and affordable

Supports ARM. Multi-ICE, JTAG debugger

Extendable as all the microcontroller signals are accessible

Boa

rd S

uppo

rt P

acka

ge

Users Manual / 4.6 ARM Evaluator-7T Board 39

2

4

Evaluator-7T Board Spec:

Samsung KS32C50100 Microcontroller

512K FLASH EEPROM boot ROM

512K+ 32bit wide SRAM

Up to 50 MHZ operation

4 individual LED's

Four dip switches

7-Segment LED display

2 9-pin D-Sub serial connector

System reset switch

Core reset switch

Interrupt switch

Bootstrap loader in FLASH Boot ROM

Angel debug monitor in FLASH Boot ROM

MicroHAL in FLASH Boot ROM

JTAG connector that is fully MultiICE compatible including reset and hot-swap capability.

See also:

Board Setup on page 40

ELDM Serial Driver on page 41

On-Chip PPP Serial Driver on page 41

LED Driver on page 42

AR

M B

SP


4.1.1 Board SetupThis is some of the first code executed after a board reset. The purpose of this code is to bring the board to a state where OSE Epsilon for ARM can access memory and devices. On most boards this includes setting up memory, initiating the interrupt controller, masking all interrupts and initiating the on-board devices.

4.1.1.1 FilesLinker Command Files

evaluator7T.txt ARM ADS/RCVTevaluator7T.lnk GNU GCCevaluator7T.xcl IAR Embedded Workbench

System and Board Initialization Files

crt0.s ARM ADS/RCVTcrt0.S GNU GCCcrt0.s79 IAR Embedded Workbench

Interrupt Handler Files

inthdlr.s ARM ADS/RCVTinthdlr.S GNU GCCinthdlr.s79 IAR Embedded Workbench

Timer Initialization Files

timer_setup.s ARM ADS1.1 and GNU GCCtimer_setup.S GNU GCCtimer_setup.s79 IAR Embedded Workbench

4.1.1.2 Processes

There are no OSE processes used in the board setup.

4.1.1.3 Start HandlersTimer Initialization

The following start handler is included in the timer initialization file:

TimerSetup

4.1.1.4 Configuration

There is no need for any entry in the osarm.con configuration file for the board setup. All initialization is done in the startup functions and handlers.

Boa

rd S

uppo

rt P

acka

ge

Users Manual / 4.6 ARM Evaluator-7T Board 41

2

4

4.1.2 ELDM Serial DriverThese are very simple straight forward serial drivers used mainly for the Epsilon Local Debug Module (eldm). This eldm allows you to connect the OSE Illuminator system level debugger to an OSE Epsilon system.This driver does not follow the OSE Epsilon device driver concept.

4.1.2.1 FilesFile Name Development Environment

eldm_uart.s ARM ADS1.1 and GNU GCCeldm_uart.S GNU GCCeldm_uart.s79 IAR Embedded Workbench

4.1.3 On-Chip PPP Serial DriverThis is a serial drivers for the on-chip serial controller following the OSE Epsilon device driver concept used mainly for INET PPP.


devuart.h Alldevuart.c Alldevuart.sig Alluart.c All

4.1.3.2 Processes

The following interrupt processes are included in uart.c:uart0_rxirquart1_rxirqgdma0_irq

4.1.3.3 Start Handlers

The following start handler is included in devuart.c:

devuart_init


You have to define the following lines in the configuration file osarm.con for this driver:Interrupt processes:

INT_PROC uart0_rxirqINT_PROC uart1_rxirqINT_PROC gdma0_irq

Start handlers:START_HANDLER devuart_init

AR

M B

SP


4.1.4 LED Driver

4.1.4.1 Description

Some boards have an LEDs or an array of LEDs which can be controlled by the user software.


led.h Allled.c All

Boa

rd S

uppo

rt P

acka

ge

Users Manual / 4.6 Atmel AT91EB01 43

2

4

4.2 Atmel AT91EB01The Atmel AT91EB01 board is replaced by the Atmel AT91EB40 board which is fully supported by this OSE Epsilon for ARM board support package.The AT91EB40 Evaluation Board enables real-time code development and evaluation. It supports the AT91x40 series with its various memory options.The board consists of an AT91R40807 (ARM7TDMI) processor together with several peripherals:

Two serial ports

Reset button

Three applicative buttons (FIQ, TIOB0, IRQ0)

Three LEDs (TIOA0, TIOA1, TIOB0)

512K bytes 16-bit SRAM (upgradable to 2048K bytes)

128K bytes 16-bit Flash (of which 64K bytes is available for user software)

20-pin JTAG interface connector



Linker Command Filesat91eb01.txt ARM ADS1.1at91eb01.lnk GNU GCCat91eb01.xcl IAR Embedded Workbench

System and Board Initialization Filescstartup.s ARM ADS1.1cstartup.s79 IAR Embedded Workbenchcrt0.S GNU GCC


inthdlr.s ARM ADS1.1 inthdlr.s79 IAR Embedded Workbenchinthdlr.S GNU GCC


timer_setup.s ARM ADS1.1 timer_setup.s79 IAR Embedded Workbenchtimer_setup.S GNU GCC

AR

M B

SP

44 Atmel AT91EB01 Users Manual / 4.6

4.2.1.2 Processes




TimerSetup


There is no need for any entry in the osarm.con configuration file for the board setup. All initialization is done in the startup funcions and handlers.

4.2.2 ELDM Serial DriverThese are very simple straight forward serial drivers used mainly for the Epsilon Local Debug Module (eldm). This eldm allows to connect the OSE Illuminator system level debugger to an OSE Epsilon system.This driver is not following the OSE Epsilon device driver concept.


eldm_uart.s ARM ADS1.1 eldm_uart.s79 IAR Embedded Workbencheldm_uart.S GNU GCC

4.2.3 LED DriverSome boards have a LEDs or an array of LEDs which can be controlled by the user software.


led.h Allled.c All

Boa

rd S

uppo

rt P

acka

ge

Users Manual / 4.6 Atmel AT91EB55 45

2

4

4.3 Atmel AT91EB55The AT91EB55 Evaluation Board enables real-time code development and evaluation. It supports the AT91M55800A.The board consists of an AT91M55800A (ARM7TDMI), together with several peripherals:

Two serial ports

Reset push button

An indicator which memorizes a reset appearance

Memory clear for the reset indicator

Four user-defined push buttons

Eight LEDs

256K byte of 16-bit SRAM (upgradable to 1 MB)

2M bytes of 16-bit Flash (of which 1 MB is available for user software)

4M bytes of Serial Data Flash (upgradeable to 16 MB)

64K bytes of E 2 PROM with I 2 C access

32K bytes of SPI E 2 PROM

2 x 32 pin EBI expansion connector

3 x 32 pin I/O expansion connector

20-pin JTAG interface connector



Linker Command Filesat91eb01.txt ARM ADS1.1at91eb01.lnk GNU GCCat91eb01.xcl IAR Embedded Workbench

System and Board Initialization Filescstartup.s ARM ADS1.1 cstartup.s79 IAR Embedded Workbenchcrt0.S GNU GCC


AR

M B

SP

46 Atmel AT91EB55 Users Manual / 4.6

inthdlr.s ARM ADS1.1inthdlr.s79 IAR Embedded Workbenchinthdlr.S GNU GCC


timer_setup.s ARM ADS1.1timer_setup.s79 IAR Embedded Workbenchtimer_setup.S GNU GCC

4.3.1.2 Processes




TimerSetup


There is no need for any entry in the osarm.con configuration file for the board setup. All initialization is done in the startup funcions and handlers.

4.3.2 ELDM Serial DriverThese are very simple straight forward serial drivers used mainly for the Epsilon Local Debug Module (eldm). This eldm allows to connect the OSE Illuminator system level debugger to an OSE Epsilon system.This driver is not following the OSE Epsilon device driver concept.


eldm_uart.s ARM ADS1.1 eldm_uart.s79 IAR Embedded Workbencheldm_uart.S GNU GCC

4.3.3 LED DriverSome boards have a LEDs or an array of LEDs which can be controlled by the user software.


led.h Allled.c All

Users Manual / 4.6 Index 47

AR

M B

SPIndex

Symbols_biosentry 14_functions 15_init 16_intr 16

AARM Evaluator-7T Board 38AT91EB40 43AT91M55800A 45AT91R40807 43Atmel AT91EB01 43Atmel AT91EB55 45

BBIOS 12biosInstall 12biosOpen() 12Board setup 7, 8BSP Concept 7

CCall Back Functions 32

DdcAlloc 33dcFree 33dcHandle 32dcHandleEX 33dcHandleRX 34dcHandleTX 35ddAbortRead 31ddAbortWrite 30ddClose 24ddDevClass 18ddDevInfo 19ddGetConf 24ddOpen 21ddRead 28ddSetConf 25ddSimInt 29ddStart 23ddUnitInfo 20ddWrite 27Device driver 7, 11Device Driver Functions 12Device driver interface 11Device hardware 12

DEVICE_CLASS 18DEVICE_EALREADY_OPENED 23DEVICE_EALREADY_STARTED 24, 26DEVICE_EDEVICE_NOT_FOUND 23DEVICE_EFUNCTION_NOT_AVAILABLE

23, 29, 30, 31DEVICE_EHARDWARE_ERROR 23DEVICE_EILLEGAL_DEVTYPE 23DEVICE_EILLEGAL_UNIT 21, 22, 23, 24,

25, 26, 27, 28, 29, 30, 31DEVICE_EINVALID_LENGTH 27, 28DEVICE_EINVALID_TAG 19, 21, 25, 26DEVICE_EINVALID_VALUE 26DEVICE_ENO_BUFFERS 23, 24DEVICE_ENOT_OPENED 24, 25, 26, 27, 28,

29, 30, 31DEVICE_ENOT_STARTED 27, 28, 29, 30, 31DEVICE_EQUEUE_FULL 28DEVICE_EUNKNOWN 15DEVICE_FCABORTREAD 14DEVICE_FCABORTWRITE 14DEVICE_FCCLOSE 14DEVICE_FCDEVCLASS 14, 18DEVICE_FCDEVINFO 14DEVICE_FCFUNCTIONS 14DEVICE_FCGETCONF 14DEVICE_FCINIT 14DEVICE_FCOPEN 14DEVICE_FCREAD 14DEVICE_FCSETCONF 14DEVICE_FCSIMINT 14DEVICE_FCSTART 14DEVICE_FCUNITINFO 14DEVICE_FCWRITE 14DEVICE_FCXXX 14DEVICE_SUCCESS 19, 21, 22, 23, 24, 25, 26,

27, 28, 29, 30, 31DEVICE_TAGD_NAME 19DEVICE_TAGD_OPENALL 19DEVICE_TAGD_UNITHI 19DEVICE_TAGD_UNITLO 19DEVICE_TAGD_VERSION 19DEVICE_TAGEND 19, 20, 25, 26DEVICE_TAGERRPTR 19, 20, 25DEVICE_TAGU_DEVTYPES 20DEVICE_TAGU_INUSE 20DEVICE_TAGU_MAX_MRU 20DEVICE_TAGU_MAX_MTU 20

Users Manual / 4.6 Index 48

AR

M B

SPDEVICE_TAGU_NUMDEVTYPES 20DEVICE_VERSION 19

II/O 7Initialization 13Internal system timer 8Interrupt controller 8Interrupt handling 7Interrupt service routine 13ISR 16

NNULL 23

PPublic functions 12

RRegister the driver 12Reset 8

Sstart handler 7Static functions 12Supported Boards 37System tick 8System timer 7

TTimer 7, 8

Content1 Introduction2 BSP Concept2.1 Board setup2.2 Timer for BSP2.3 OSE BIOS for BSP2.3.1 biosInstall2.3.2 biosOpen2.3.3 biosCall2.3.4 biosInit

2.4 Device drivers for BSP

3 Device Driver3.1 Device Driver usage3.2 Device Driver Functions3.3 Device Driver Public Functions3.3.1 _biosentry3.3.2 _functions3.3.3 _init3.3.4 _intr

3.4 Device Driver Static Functions3.4.1 ddDevClass3.4.2 ddDevInfo3.4.3 ddUnitInfo3.4.4 ddOpen3.4.5 ddStart3.4.6 ddClose3.4.7 ddGetConf3.4.8 ddSetConf3.4.9 ddWrite3.4.10 ddRead3.4.11 ddSimInt3.4.12 ddAbortWrite3.4.13 ddAbortRead

3.5 Device Driver Client Call Back Functions3.5.1 dcAlloc3.5.2 dcFree3.5.3 dcHandleEX3.5.4 dcHandleRX3.5.5 dcHandleTX

4 Supported Boards4.1 ARM Evaluator-7T Board4.1.1 Board Setup4.1.1.1 Files4.1.1.2 Processes4.1.1.3 Start Handlers4.1.1.4 Configuration

4.1.2 ELDM Serial Driver4.1.2.1 Files

4.1.3 On-Chip PPP Serial Driver4.1.3.1 Files4.1.3.2 Processes4.1.3.3 Start Handlers4.1.3.4 Configuration

4.1.4 LED Driver4.1.4.1 Description4.1.4.2 Files

4.2 Atmel AT91EB014.2.1 Board Setup4.2.1.1 Files4.2.1.2 Processes4.2.1.3 Start Handlers4.2.1.4 Configuration


4.2.3 LED Driver4.2.3.1 Files

4.3 Atmel AT91EB554.3.1 Board Setup4.3.1.1 Files4.3.1.2 Processes4.3.1.3 Start Handlers4.3.1.4 Configuration


4.3.3 LED Driver4.3.3.1 Files

Index

/ColorImageDict > /JPEG2000ColorACSImageDict > /JPEG2000ColorImageDict > /AntiAliasGrayImages false /DownsampleGrayImages true /GrayImageDownsampleType /Bicubic /GrayImageResolution 300 /GrayImageDepth -1 /GrayImageDownsampleThreshold 1.50000 /EncodeGrayImages true /GrayImageFilter /DCTEncode /AutoFilterGrayImages true /GrayImageAutoFilterStrategy /JPEG /GrayACSImageDict > /GrayImageDict > /JPEG2000GrayACSImageDict > /JPEG2000GrayImageDict > /AntiAliasMonoImages false /DownsampleMonoImages true /MonoImageDownsampleType /Bicubic /MonoImageResolution 1200 /MonoImageDepth -1 /MonoImageDownsampleThreshold 1.50000 /EncodeMonoImages true /MonoImageFilter /CCITTFaxEncode /MonoImageDict > /AllowPSXObjects false /PDFX1aCheck false /PDFX3Check false /PDFXCompliantPDFOnly false /PDFXNoTrimBoxError true /PDFXTrimBoxToMediaBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXSetBleedBoxToMediaBox true /PDFXBleedBoxToTrimBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXOutputIntentProfile () /PDFXOutputCondition () /PDFXRegistryName (http://www.color.org) /PDFXTrapped /Unknown

/Description >>> setdistillerparams> setpagedevice

Documents

ENEA OSE Epsilon for ARM Board Support Package User’s Manual