390 likes | 626 Views
TI BIOS. TSK – Task Authoring. Objectives. 2. Outline. 3. Tasks vs. SWI. 3. TSK vs. SWI. Scheduler States: TSK vs. SWI. TSK. SWI. Created. Created. Inactive. Ready. 1. 2. post. Posted. when highest priority. Ready. 1. 2. Blocked. preempted. completed.
E N D
TI BIOS TSK – Task Authoring Dr. Veton Këpuska
Objectives Dr. Veton Këpuska 2
Outline Dr. Veton Këpuska 3
Tasks vs. SWI Dr. Veton Këpuska 3
TSK vs. SWI Dr. Veton Këpuska
Scheduler States: TSK vs. SWI TSK SWI Created Created Inactive Ready 1 2 post Posted whenhighestpriority Ready 1 2 Blocked preempted completed whenhighestpriority preempted Running 1 2 pend Running 1 2 Terminated Dr. Veton Këpuska
Tasks Are: • Ready to Run when Created • by BIOS startup if specified in GCONF • by TSK_create() in dynamic systems (mod 11) • Preemptive • Blocked when Pending on an unavailable resource • Returned to Ready state when resource is posted • May be Terminated when no longer needed Dr. Veton Këpuska
SWI vs. TSK * SEM_pend with timeout of 0 is allowed Dr. Veton Këpuska
TSK Scheduling Dr. Veton Këpuska 3
Task Scheduling Dr. Veton Këpuska
DSP/BIOS Scheduler HWI Hardware Interrupts • HWI priorities set by hardware • Fixed number, preemption optional Foreground Hard R/T SWI Software Interrupts • 14 SWI priority levels • Any number possible, all preemptive Priority TSK Tasks • 15 TSK priority levels • Any number possible, all preemptive Background IDL Background • Continuous loop • Non-realtime in nature Soft R/T Dr. Veton Këpuska
DSP/BIOS Scheduler • All TSKs are preempted by all SWIs and HWIs • All SWIs are preempted by all HWIs • Preemption amongst HWI is determined by user • In absence of HWI, SWI, and TSK, IDL functions run in a loop Dr. Veton Këpuska
post swi1 post swi2 post sem2 post swi2 return return return return post sem1 post sem2 return return return pend sem2 pend sem2 pend sem2 interrupt pend sem1 pend sem1 interrupt interrupt interrupt Thread Preemption Example HWI SWI 2 SWI 1 TSK 2 TSK 1 IDL Events over time Dr. Veton Këpuska
TSK Scheduling Dr. Veton Këpuska 3
Semaphores (SEM) Dr. Veton Këpuska
Task Code Topology:SEM Posting • Initialization (runs once only) • Processing loop - option: termination condition • Wait for resources to be available • Perform desired DSP work... • Shutdown (runs once - at most) Void taskFunction(…) { /* Prolog */ while (‘condition’) { SEM_pend(); /* Process */ } /* Epilog */ } Dr. Veton Këpuska
Task Code Topology:SEM Posting • TSK can encompass three phases of activity • SEM can be used to signal resource availability to TSK • SEM_pend() blocksTSK until next buffer is available Dr. Veton Këpuska
Semaphore Pending: SEM_pend() Pend SEM_pend(&sem,timeout) Count > 0 true false yes Decrement count timeout = 0 no Semaphore Structure: • Non-negative 16-bit counter • Pending queue (FIFO) timeoutexpires Block task SEM posted Return FALSE Return TRUE Dr. Veton Këpuska
Semaphore Post: SEM_post() Post SEM_post(&sem) Taskpending on sem? Ready first waiting task False True Increment count Semaphore Structure: • Non-negative count • Pending queue (FIFO) Task switch will occur if higher priority task is made ready Return Dr. Veton Këpuska
Creation of SEM Object Creating a new SEM Obj • right click on SEM mgr • select “Insert SEM” • type object name • right click on new SEM • select “Properties” • indicate desired • User Comment (FYI) • Initial SEM count varmySem = SEM.create("mySem"); mySem.comment = "my SEM"; mySem.count = 0; Dr. Veton Këpuska
SEM API Summary Mod 11 Dr. Veton Këpuska
TSK Scheduling Dr. Veton Këpuska 3
Task Object Dr. Veton Këpuska
Static Creation of TSK Creating a new TSK • right click on TSK mgr • select “Insert TSK” • type TSK name • right click on new TSK • select “Properties” • indicate desired • priority • stack properties • function • arguments • etc Dr. Veton Këpuska
Task Object Concepts... myTsk Task object: • Pointer to task function • Priority: changable • Pointer to task’s stack • Stores local variables • Nested function calls • Makes blocking possible • Interrupts run on the system stack • Pointer to text name of TSK • Environment: pointer to user defined structure: structmyEnv TSKstack C fxn, eg: bkFIR inst2 structmyEnv TSKstack TSK_setenv(TSK_self(),&myEnv); hMyEnv =TSK_getenv(&myTsk); Dr. Veton Këpuska
TSK Object typedefstructTSK_Stat{ TSK_Attrsattrs; // task attributesTSK_Mode mode; // running, blocked...Ptr sp; // stack ptrsize_t used; // stack max } TSK_Stat; typedefstructTSK_Obj { // from TSK.h KNL_Objkobj; // kernel objectPtr stack; // used w TSK_delete() size_tstacksize; // ditto Intstackseg; // stack alloc’n RAM String name; // printable name Ptrenviron; // environment pointerInterrno; // TSK_seterr()/_geterr()Boolexitflag; // FALSE for server tasks } TSK_Obj, *TSK_Handle; typedef struct TSK_Attrs { Int priority; // task priority Ptr stack; // stack supplied size_t stacksize; // size of stack Int stackseg; // stack alloc’n seg Ptr environ; // environment pointer String name; // printable name Bool exitflag; // server tasks = false Bool initstackflag; // FALSE: no stack init } TSK_Attrs; structKNL_Obj {// from KNL.h QUE_Elem ready; // ready/sem queue QUE_Elem alarm; // alarm queue elemQUE_Elemsetpri; // set priority queue QUE_Handle queue; // task's ready queue Int priority; // task priority Uns mask; // 1 << priority Ptr sp; // current stack ptrUns timeout; // timeout value Int mode; // blocked, ready, ... STS_Obj *sts; // for TSK_deltatime()Boolsignalled; // woken by sem or t-out }; typedef struct TSK_Config { Int STACKSEG; Int PRIORITY; size_t STACKSIZE; Fxn CREATEFXN; Fxn DELETEFXN; Fxn EXITFXN; Fxn SWITCHFXN; Fxn READYFXN; } TSK_Config; Dr. Veton Këpuska
TSK Scheduling Dr. Veton Këpuska 3
Review Dr. Veton Këpuska
TSK API Summary • Most TSK API are used outside the TSK so other parts of the system can interact with or control the TSK • Most TSK API are to allow: • TSK scheduler management (Mod 7) • TSK monitor & debug (Mod 8) • Dynamic creation & deletion of TSK (Mod 11) • TSK author usually has no need for any TSK API within the TSK code itself Mod 11 Dr. Veton Këpuska
TSK API Summary Mod 8 Mod 7 Dr. Veton Këpuska 21
TSK Scheduling Dr. Veton Këpuska 3
Lab Dr. Veton Këpuska
Lab 5: Task Thread - TSK BIOS\Labs\HW BIOS\Labs\Work HWI12 isrAudio pInBuf[bkCnt]=MCBSP_readMCBSP_write(pOutBuf[bkCnt]) if(bkCnt=2*BUF) {QUE_put(&from DevQbufs) SEM_post(&mySem)bkCnt=0;} AudioIn (48 KHz) ADCAIC33 McBSPDRR mcbsp.c DACAIC33 McBSPDXR AudioOut (48 KHz) tskProcBuf BIOS\Labs\Algos procBuf while() SEM_pend(&mySem) for (i =0, i<HIST; i ++) pIn[i]=pPriorIn[2*BUF-HIST]; if( sw0 == 1 ) FIR(in[pIn-HIST],out[pOut]) else {pOut[i]=pIn[i]} FIR.c FIR Code coeffs.c Coefficients Dr. Veton Këpuska
Lab 5: Task Thread - TSK • Begin with the SWI-based buffered system • Modify SWI to run as TSK; add SEM_pend and while loop • TCF: remove SWI obj, add TSK and SEM objs • Modify HWI to post SEM instead of SWI • Build, load, test, verify performance Dr. Veton Këpuska
Lab 5 : Summary In the TCF file: • replace the processing SWI with a TSK • create a SEM In audio.c: • In the isrAudio (HWI) function: • Post a SEM instead of the SWI • In the procBuf (TSK) function • Add a while loop and SEM_pend to the remaining code in procBuf() • Build, download, run, and verify the correct operation of the new solution • Optionally, copy the solution files to C:\BIOS\mySols\05 Dr. Veton Këpuska
Lab 5: Procedure Overview Below are the steps required to adapt the SWI-based processing thread to a TSK-based version. • If necessary, start CCS and open the solution from lab 4. Build the project and verify it performs properly • In myWork.tcf : • Replace the SWI that called procBuf with a TSK named tskProcBuf • Create a SEM named semBufRdy • In isr.c • Replace the SWI_post() with a SEM_post() of semBufRdy Dr. Veton Këpuska
Lab 5: Procedure Overview • In proc.c • Add a while(1) loop around all the iterative code in procBuf. • Add a SEM_pend on the newly created semaphore as the first line of the while loop • Having completed the adaptation steps you can now: • Build, load, run, and verify the correct operation of the new solution • (optional) Relocate the initialization of the messages and toDevQ to the prolog of the TSK. While not required, this makes the TSK a more complete (and instantiable) component • Using windows explorer, copy all files from C:\BIOS\Labs\Work to C:\BIOS\mySols\05 Dr. Veton Këpuska
Lab Details HWI – based lab 3 Observations: • Moving from SWI to TSK showed results within 0.1% of being the same • So… the ‘extra overhead’ of TSK vs. SWI doesn’t really amount to much at all, and could easily be countered by a small increase in buffer size, which will have much greater effect than thread type SWI – based lab 4 TSK – based lab 5 Dr. Veton Këpuska
TI BIOS TSK END Dr. Veton Këpuska