1 / 39

TI BIOS

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.

MikeCarlo
Télécharger la présentation

TI BIOS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TI BIOS TSK – Task Authoring Dr. Veton Këpuska

  2. Objectives Dr. Veton Këpuska 2

  3. Outline Dr. Veton Këpuska 3

  4. Tasks vs. SWI Dr. Veton Këpuska 3

  5. TSK vs. SWI Dr. Veton Këpuska

  6. 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

  7. 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

  8. SWI vs. TSK * SEM_pend with timeout of 0 is allowed Dr. Veton Këpuska

  9. TSK Scheduling Dr. Veton Këpuska 3

  10. Task Scheduling Dr. Veton Këpuska

  11. 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

  12. 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

  13. 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

  14. TSK Scheduling Dr. Veton Këpuska 3

  15. Semaphores (SEM) Dr. Veton Këpuska

  16. 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

  17. 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

  18. 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

  19. 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

  20. 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

  21. SEM API Summary Mod 11 Dr. Veton Këpuska

  22. TSK Scheduling Dr. Veton Këpuska 3

  23. Task Object Dr. Veton Këpuska

  24. 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

  25. 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

  26. 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

  27. TSK Scheduling Dr. Veton Këpuska 3

  28. Review Dr. Veton Këpuska

  29. 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

  30. TSK API Summary Mod 8 Mod 7 Dr. Veton Këpuska 21

  31. TSK Scheduling Dr. Veton Këpuska 3

  32. Lab Dr. Veton Këpuska

  33. 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

  34. 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

  35. 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

  36. 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

  37. 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

  38. 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

  39. TI BIOS TSK END Dr. Veton Këpuska

More Related