Copyright © 2004 Texas Instruments. All rights reserved. 1.Introduction 2.Real-Time System Design...

Copyright © 2004 Texas Instruments. All rights reserved.

1. Introduction2. Real-Time System Design Considerations3. Hardware Interrupts (HWI)4. Software Interrupts (SWI)5. Task Authoring (TSK)6. Data Streaming (SIO) 7. Multi-Threading (CLK, PRD)8. BIOS Instrumentation (LOG, STS, SYS, TRC)9. Static Systems (GCONF, TCONF)10. Cache (BCACHE)11. Dynamic Systems (MEM, BUF)12. Flash Programming (HexAIS, Flashburn)13. Inter-Thread Communication (MSGQ, ...) 14. DSP Algorithm Standard (XDAIS)15. Input Output Mini-Drivers (IOM) 16. Direct Memory Access (DMA)17. Review

DSP/BIOS System Integration Workshop

1

TT TOTOTechnical Training Technical Training

OrganizationOrganization

Objectives

Semaphores (SEM) have been used in prior chapters to synchronize threads, and are a common approach in many systems.

While there are times that the SEM is a good choice, there are other situations in which their use can lead to problems. In this chapter, a variety of inter-thread communication and synchronization examples will be considered employing a variety of BIOS thread comm API, including:

LCK MBX

QUE ATM

MSGQ

2



OverviewATM Atomic FxnsSEM SemaphoreLCK Lock MBX MailboxQUE QueueMSGQ Message Queue

Inter-Thread Comm & Synch

3



Critical Section Resource Protection Pass a copy of resources to 2nd thread

No possibility of conflict, allows both to use concurrently Doubles storage requirements, adds copy time

Assign concurrent threads to the same priority – FIFO+ No possibility of conflict, no memory/time overhead, easy - Forces involved threads to be same priority

Disable interrupts during critical sections+ Needed if a hardware interrupt shares data- Affects response time of all threads in the system

Disable SWI/TSK scheduler during critical section+ Assures one SWI/TSK to finish with resource before another begins- Affects the response times of all other SWIs

Raise priority of SWI/TSK during critical section* Set priority to highest priority which may access the resource+ Equal priority SWIs/TSKs run in FIFO order, avoiding competition- Can affect response times of SWIs/TSKs of intervening priority

Use atomic functions on shared resources+ Imposes minimal jitter on interrupt latencies- Only allows minimal actions on shared resources

Regulate access rights via Semaphores + No conflict or memory/time overhead of passing copy- Multiple semaphore schemes can introduce problems

4





5



DSP/BIOS Atomic Functions

Allows thread to manipulate variables without interrupt intervention

Are C callable functions optimized in assembly

Allows reliable use of global variables shared between SWI and HWI

ATM_dec ATM_inc

- Good for inter-thread counters

ATM_clear ATM_set

- Counters - to start/restart

- Generic pass of value between threads

ATM_and ATM_or

- Perform boolean op’s on shared variables

- Good for event flags, etc

a

TSK

...

x = x+1;

LD reg, x

ADD reg, 1

ST x, reg

...HWI...for(x...)x = 0;...

x

10

11?

10 / 0

11

6





7



time

BB

AA

A and B same priority, A is ready before B

SEM_pend(semObj)

SEM_post(semObj)

Priority=1

Priority=1

time

Synchronization Semaphore

B higher priority than A, B is ready before A

BB

AA

SEM_pend(semObj)block!

SEM_post(semObj) preempted!Precondition for B

Depends on ANot dependent on APriority=2

Priority=1

8



Not dependent on A

Not dependent on A

Semaphores and Priority

BB

AA

Both B and C depend on A B pends on the semaphore first, then C When A posts, B runs first because it pended first Semaphores use a FIFO Queue for pending tasks!

SEM_pend(&semObj)block!

SEM_post(&semObj) preempted!

Precondition for B and C

Depends on APriority=1

Priority=1

time

CC

SEM_pend(&semObj)block!

Priority=2

interrupt!

9



Mutual Exclusion Semaphore Two or more tasks need concurrent access to a serial reusable resource Mutual exclusion using semaphore

Initialize semaphore count to 1 pend before accessing resource - lock out other task(s) post after accessing resource - allow other task(s)

Problems may occur when tasks compete for more than one resource Priority inversion Deadlock

Void task0() { SEM_pend(&semMutex);

`critical section`SEM_post(&semMutex); }

Void task0() { SEM_pend(&semMutex);

`critical section`SEM_post(&semMutex); }

Void task1(){ SEM_pend(&semMutex);

`critical section`SEM_post(&semMutex);

}

Void task1(){ SEM_pend(&semMutex);

`critical section`SEM_post(&semMutex);

}

Task1Task1

Task0 Task0

SEM_pend(&semMutex)

SEM_pend(&semMutex)block!

SEM_post(&semMutex)preempted!

SEM_post(&semMutex)Priority=2

Priority=1

10



Priority Inversion

A

B

C

D

A

B

interrupt!

Post(mutex)preempted

Time

Priority

lower

higherpost (mutex)Pend(mutex) blocks

InitiallyMutex = 1

Pend(mutex)

High-priority tasks block while waiting for lower-priority tasks to relinquish semaphore

“The failure turned out to be a case of priority inversion”

— Mars Pathfinder Flight Software Cognizant Engineer11



Inversion Solution: Priority Inheritance

A

Apend(mutex)

Interruptreadies B

B

time

Priority

lower

higher

setpri(A,newpri)

post(mutex), setpri(A,oldpri)

C

D

A

pend(mutex)

post(mutex)

Elevate task priority before calling accessing resource

Lower task priority after accessing resource

Question: Do we even need to use semaphore in this situation? No

Do not use TSK_yield() if semaphore is removed 12

Deadlock

static Void TaskA() { SEM_pend(&res_1);

// use resource1Task_A may get stuck hereSEM_pend(&res_2);// use resource2

SEM_post(&res_1); SEM_post(&res_2);}

static Void TaskA() { SEM_pend(&res_1);

// use resource1Task_A may get stuck hereSEM_pend(&res_2);// use resource2

SEM_post(&res_1); SEM_post(&res_2);}

static Void TaskB(){ SEM_pend(&res_2);

// use resource2Task_B may get stuck hereSEM_pend(&res_1);// use resource1SEM_post(&res_2);SEM_post(&res_1);

}

static Void TaskB(){ SEM_pend(&res_2);

// use resource2Task_B may get stuck hereSEM_pend(&res_1);// use resource1SEM_post(&res_2);SEM_post(&res_1);

}

Also known as deadly embrace Tasks cannot complete because they have blocked each other TaskA and TaskB require the use of resource 1 and 2. Neither task will release a resource until it is completed

Conditions for deadlock to occur: Mutual exclusion : Access to shared resource protected with mutual exclusion SEM Circular pend: Circular chain of tasks hold resources that are needed by others in the

chain (cyclic processing) Multiple pend and wait: Tasks lock more than one resource at a time Preemption: Tasks needing mutual exclusion are at a different priorities

13



Deadlock: Detect, Recover, Eliminate Difficult to detect

May happen infrequently Use timeouts in blocking API; monitor timeout via SYS_error Monitor SWI with implicit STS

Recover is not easy Reset the system Rollback to a pre-deadlock state

Solution Careful design Rigorous testing

Eliminating Deadlock: Remove one of these conditions Mutual exclusion: Make resources sharable Circular pend: Set a particular order Multiple pend and post: Lock only one resource at a time or all resources

that will be used (starvation potential) Preemption: Assign tasks that need mutual exclusivity to the same priority

Better: Use more sophisticated BIOS API

14




LCK_create LCK_pend

LCK_delete LCK_postLCK API


15



Nested Semaphore Calls: LCK

Void Task_A() { SEM_pend(&semUser); funcInner(); SEM_post(&semUser);}

Void Task_A() { SEM_pend(&semUser); funcInner(); SEM_post(&semUser);}

Void funcInner(){

SEM_pend(&semUser);// use resource guarded by semSEM_post(&semUser);

}

Void funcInner(){

SEM_pend(&semUser);// use resource guarded by semSEM_post(&semUser);

}

Unrecoverableblocking call

Void Task_A() { LCK_pend(&lckUser); funcInner(); LCK_post(&lckUser);}

Void Task_A() { LCK_pend(&lckUser); funcInner(); LCK_post(&lckUser);}

Void funcInner(){

LCK_pend(&lckUser);// use resource guarded by lckLCK_post(&lckUser);

}

Void funcInner(){

LCK_pend(&lckUser);// use resource guarded by lckLCK_post(&lckUser);

}

Use of SEMaphore with nested pend yields permanent block

Use of LCK (Lock) with nested pend avoids blockout

BIOS MEM Manager and selected RTS functions internally use LCK, can cause TSK switch

16




+ mailbox message can be any desired structure + semaphore signaling built in (read and write)+ allows multiple readers and/or writers- fixed depth of messaging- copy based – 2 copies made in/out of MBX

MBX_pend

MBX_post

MBX_create

MBX_delete

MBX

NOTE: The MBX API are not related to the mailbox component of the SWI object!


17



Void writer(Void){

MsgObj msg;Int myBuf[SIZE];...msg.addr = myBuf;msg.len = SIZE*sizeof(Int);MBX_post(&mbx, &msg, SYS_FOREVER);...

}

Example: Passing Buffer Info Via Mailbox

Void reader(Void){

MsgObj mail;Int size, *buf;...MBX_pend(&mbx, &mail,SYS_FOREVER);buf = mail.addr;size = mail.len;...

}

typedef struct MsgObj { Int len; Int * addr;};

handle to msg obj

* msg to put/get

timeout

MBX_post - add message to end of mailbox

MBX_pend - get next message from mailbox

block until mail received or timeout

block if MBX is already full

18



Creating Mailbox Objects

MBX.OBJMEMSEG = prog.get(“ISRAM");

var myMBX = MBX.create("myMBX");

myMBX.comment = "my MBX";

myMBX.messageSize = 1;

myMBX.length = 1;

myMBX.elementSeg = prog.get(“IRAM");

Message Object creation via TCONF

hMbx = MBX_create(msgsize, mbxlen, attrs);

MBX_delete(hMbx);

Dynamic Message Object Creation

struct MBX_Attrs { Int segid;

}

Message Object creation via GCONF

Message Size = MADUs per message

Mailbox Length = max # messages queued

19




+ any number of messages can be passed

+ message can be anything desired (beginning with QUE_elem)

+ atomic API are provided to assure correct sequencing

- no semaphore signaling built in


20



msg1 msg2 msg3QUE_Obj

struct MyMessage { QUE_Elem elem; first field for QUE Int x[1000]; array/structure sent not copy based!} Message1;

typedef struct QUE_Elem { struct QUE_Elem *next; struct QUE_Elem *prev;} QUE_Elem;

typedef struct QUE_Elem { struct QUE_Elem *next; struct QUE_Elem *prev;} QUE_Elem;

Queues : QUE QUE message is anything you like, starting with QUE_Elem QUE_Elem is a set of pointers that BIOS uses to manage a double linked list Items queued are NOT copied – only the QUE_Elem ptrs are managed!

QUE_put(hQue,*msg3) add message to end of queue (writer)

*elem = QUE_get(hQue) get message from front of queue (reader)

msg1 msg2 msg3QUE_Obj

How do you synchronize reader and writer?21



QUE API Summary

QUE_put Add a message to end of queue – atomic write

QUE_get Get message from front of queue – atomic read

QUE_enqueue Non-atomic QUE_put

QUE_dequeue Non-atomic QUE_get

QUE_head Returns ptr to head of queue (no de-queue performed)

QUE_empty Returns TRUE if queue has no messages

QUE_next Returns next element in queue

QUE_prev Returns previous element in queue

QUE_insert Inserts element into queue in front of specified element

QUE_remove Removes specified element from queue

QUE_new ….

QUE API Description

QUE_create Create a queue

QUE_delete Delete a queueMod 10

22



“Synchronous QUE” Option

Talker

QUE_put(&myQ,msg);

SEM_post(&myQSem);

Listener

SEM_pend(&myQSem,-1);

msg=QUE_get(&myQ);

23




+ any number of messages can be passed

+ message can be anything desired (beginning with MSGQ_header)+ message notification is user specified (e.g. semaphore, polling, etc.)

+ can be used between all thread types with no API adaptation

+ API unchanged even when going trans-processor !


24



listener thread

MSGQ

“myQ”

MSGQ Concepts (1/4)

MSGQ transactions begin with listener opening a MSGQ Listener’s attempt to get a message results in a block (when

semaphore specified), since no messages are in the queue yet

MSGQ_open( “myQ”, &hQ, ... );

MSGQ_get( hQ, &msg, ... );

25



MSGQ_locate(“myQ”, &hQ, .. );

MSGQ_alloc( poolid, &msg, .. );

msg->myMsg = …;

MSGQ_put( msg, hQ );

talker thread

POOL

listener thread

MSGQ_Header

myMsg

MyMsgqMsg

MSGQ

“myQ”

MSGQ Concepts (2/4)

Talker begins by locating the MSGQ opened by the listener Talker gets a message block from a pool and fills it as desired Talker puts the message into the MSGQ


MSGQ_get( hQ, &msg, ... );

typedef struct MyMsgqMsg {

MSGQ_MsgHeader header;

...

} MyMsg;

26





msg->myMsg = …;

MSGQ_put( msg, hQ );


MSGQ_get( hQ, &msg, ... );eval( msg->myMsg );MSGQ_free( msg );

talker thread

POOL

listener thread

MSGQ_Header

myMsg

MyMsgqMsg

MSGQ

“myQ”

MSGQ Concepts (3/4)

Once talker puts message to MSGQ, listener is unblocked Listener can now read/evaluate received message Listener frees message back to pool

27





msg->myMsg = …;

MSGQ_put( msg, hQ );`



talker thread

POOL

listener thread

MSGQ_Header

myMsg

MyMsgqMsg

MSGQ

“myQ”

MSGQ Concepts (4/4)

The message object manages queuing of messages passed An allocator mechanism is for getting buffers; standard = POOL A transport mechanism can be specified for trans-processor MSGQ

MSGQ APIs

Transports POOL0 POOLN . . .

Msg Pool Msg Pool

28





msg->myMsg = …;

MSGQ_put( msg, hQ );`



Multiprocessor MSGQ

MSGQ MSGQ

“myQ”

MQT MQT

MQTIOM

IOM

MQTIOM

IOM

POOL POOL

MSGQ_locate doesn’t find “myQ” locally

MSGQ Transport (MQT) finds myQ on Proc1

MSGQ_put sends block to MQT

MQT sends data over physical link it manages

free of buffer back to local pool is implemented by MQT

Listener TSK has no knowledge of location of talker

Thread code is unchanged from local processor solution !

SRIO, LINK versions available

talker thread listener thread

29

MSGQ API

MSGQ_locate MSGQ_open

MSGQ_put MSGQ_get

MSGQ_free

MSGQ_close

once per object (either *)

ongoing...

once (or never) per object

writer readerany

MSGQ_alloc

MSGQ_release

MSGQ_getMsgSize() Return the message size from a messageMSGQ_count() Return number of messages in a message queueMSGQ_getMsgId() Return the message ID from a messageMSGQ_getDstQueue() Get destination message queueMSGQ_getSrcQueue() Extract the reply destination from a message

MSGQ_locateAsync() Asynchronously find a message queue (by writer)MSGQ_isLocalQueue() Returns TRUE if local message queueMSGQ_getAttrs() Returns the attributes of a local message queueMSGQ_setMsgId() Sets the message ID in a messageMSGQ_setSrcQueue() Sets the reply destination in a messageMSGQ_setErrorHandler() Set up handling of internal MSGQ errors

30



MSGQ_MsgHeader

typedef struct MSGQ_MsgHeader {

Uint32 reserved[2]; // Transport specific Uint16 srcProcId; // Proc Id for the src message queue Uint16 poolId; // Id of the allocator that allocated the msg Uint16 size; // Size of the allocated msg Uint16 dstId; // Destinaton message queue id Uint16 srcId; // Source message queue id Uint16 msgId; // User specified message id

} MSGQ_MsgHeader, *MSGQ_Msg;

31



MSGQ Notification – Flexible Interface

MSGQ_Attrs attrs; // TSK MSGQ_Queue hQ;

attrs.post = (MSGQ_Post) SEM_postBinary;attrs.pend = (MSGQ_Pend) SEM_pendBinary;

attrs.notifyHandle = (Ptr) hMySem;

MSGQ_open (“myQ”, &hQ, &attrs);

typedef struct MSGQ_Attrs {

Ptr notifyHandleBool (* pend)(Ptr notifyHandle, Uns timeout) // called in MSGQ_getVoid (* post)(Ptr notifyHandle) // called on MSGQ_put

} MSGQ_Attrs

MSGQ_get() and MSGQ_put() don’t specify a signalling mechanism Based on listener thread type, user selects how to signal via MSGQ_open() TSK signalled by SEM_post, SWI by SWI_post. Default is no signal (poll) MSGQ_Attrs structure defines these options as argument for MSGQ_open()

// SWI

SWI_post; SYS_zero; hMySwi;

// poll (default)

FXN_F_nop; SYS_zero;Null;

32



MSGQ Setup

MSGQ config allows user to select:

Number of MSGQ objects present in system

Number of transport mechanisms & processors present

Setup of MSGQ implementation procedure:

Enable MSGQ in the config file : bios.MSGQ.ENABLEMSGQ = true;

Copy and paste the example code on following slide into your C file

Adjust the number of MSGQ objects via NUMMSGQS

Adjust the number of transports via NUMPROCS

Initialize transport objects as per TI provided examples

Initialize MSGQ manager referencing above two object arrays

33



Example Code : MSGQ Setup

initFxn* fxns

paramsobjectprocId

namequeue

notifyHandlependpost

status

MSGQ_Obj msgQueues[NUMMSGQS];

MSGQ_TransportObj transports[NUMPROCS] = {MSGQ_NOTRANSPORT};

MSGQ_Config MSGQ_config = {

msgQueues, // MSGQ obj list ptrtransports, // transports list ptrNUMMSGQS, // # of MSGQsNUMPROCS, // # of transports 0, // 1st MSGQ usableMSGQ_INVALIDMSGQ, // no error handler queuePOOL_INVALIDID}; // allocator id for errors

MSGQ

Obj

0

MSGQ

Obj

N-1

.

.

34



Pool Setup

Pool abstraction allows user to select how message buffers are obtained

Only version offered by TI at present is – essentially – BUF

Other pool implementations can be created based on MEM or custom styles

Setup for BUF implementation procedure:

Enable POOL in the config file : bios.POOL.ENABLEPOOL = true;

Copy and paste the example code on following slide into your C file

Adjust the dimensions of the pools in the #defines

Add or remove pools as required per the style shown

36



Pool Structures

typedef struct POOL_Config {

POOL_Obj *allocators; Uint16 numAllocators;

} POOL_Config;

typedef struct POOL_Obj {

POOL_Init initFxn; // pre-main setup fxn POOL_Fxns *fxns; // alloc, free fxns Ptr params; // setup params Ptr object; // handle (rtn)

} POOL_Obj, *POOL_Handle;

typedef struct STATICPOOL_Params {

Ptr addr; // location of pool size_t length; // total pool size size_t bufferSize; // size of a buffer

} STATICPOOL_Params;

Pool

Obj

0

initFxn*fxnsparamsobject

Pool

Obj

N-1

.

.

#

*

AddrLengthbufferSize

STATICPOOL

Params

POOL_config

STATICPOOL

Params

37



#define NUMMSGS0 4 // Number of msgs per allocator #define MSGSIZE0 64 // must be multiple of 8

enum { // Allocator ID and number of allocators MQASTATICID0 = 0, NUMALLOCATORS };

#pragma DATA_ALIGN(staticBuf0, 8) // As required static Char staticBuf0[MSGSIZE0 * NUMMSGS0];

static MQASTATIC_Params poolParams0 = {staticBuf0, sizeof(staticBuf0), MSGSIZE0};

static STATICPOOL_Obj poolObj0 ;

static POOL_Obj allocators[NUMALLOCATORS] ={ {STATICPOOL_init, (POOL_Fxns *)&STATICPOOL_FXNS, &poolParams0, &poolObj0} };

POOL_Config POOL_config = {allocators, NUMALLOCATORS};

Example Code : Two Pool Setup

#pragma DATA_SECTION(staticBuf0, “myRAM”)

#define NUMMSGS1 8 #define MSGSIZE1 128

MQASTATICID1,

#pragma DATA_ALIGN(staticBuf1, 8) static Char staticBuf1[MSGSIZE1 * NUMMSGS1];

static MQASTATIC_Params poolParams1 = {staticBuf1, sizeof(staticBuf1), MSGSIZE1};

, poolObj1

{STATICPOOL_init, (POOL_Fxns *)&STATICPOOL_FXNS, &poolParams1, &poolObj1}

Two

38

MSGQ Feature Review ❏ Supports zero-copy transfers.

❏ Can send and receive from HWIs, SWIs and TSKs.

❏ Notification mechanism is specified by application.

❏ Timeouts are allowed when receiving messages.

❏ Receiving a message is deterministic when the timeout is zero.

❏ Sending a message is non-blocking.

❏ Readers can determine the writer and reply back.

❏ Messages can reside on any message queue.

❏ Threads can be relocated to another processor with no runtime code changes.

❏ Allows QoS (quality of service) on message buffer pools.

For example, using specific buffer pools for specific message queues.39

ti

Technical TrainingOrganization

40

ITC API Comparison

QUE

SIO

MBX

MSGQ

41



Copyright © 2004 Texas Instruments. All rights reserved. 1.Introduction 2.Real-Time System Design...

Documents

Transcript of Copyright © 2004 Texas Instruments. All rights reserved. 1.Introduction 2.Real-Time System Design...