!!!Important!!!! PLEASE COMMENT YOUR CODE AS A CONSIDERATION TO ME AND TO REDUCE THE AMOUNT OF TIME I NEED TO SPEND CORRECTING.. CODE THAT IS NOT COMMENTED AND HARD TO READ WILL RESULT IN LOST POINTS!!!!!
Instead of doing a while(1) loop, you may want to use a global flag variable to control your while loop (for example while(run_test) where run_test is initialized to 1 in startup code.) That way, if you want to make changes and restart your tasks, you won't need to manually delete them, you can just set run_test=0 from the shell which will cause your tasks to end execution. (In case you haven't used this feature yet, you can directly modify global variables from the shell... this is really handy for project debugging... see the Shell Chapter of the Vxworks Users Guide for more information.)
"show me counters that increment in wind shell dump" means add counters to your code that increment when semaphore events occur and justify the values you get by comparing them to a windview trace.
You should see one task interrupt the other on a semaphore exchange. Instead of "built-in-print" this should read "use Ctrl->Printscreen."
Before you can write these functions, you need to understand how taskSwitchHookAdd and taskSwitchHookDelete work. Look these functions up in the users guide. Also, look at related links such as taskHookLib (which describes the library) and the Basic OS chapter of the Programmers guide. Be careful about what functions you call from the hook function, only functions specifically mentioned by the taskHookLib may be called from this function. Note that although the function sysTimestampLock is not explicitly listed with taskSwitchHookAdd as a function you may call from your switch hook, it is OK to call this function inside your switch hook.
A few people have had some problems calling sysTimestampEnable in the switch hook. Before using this or any funcion, look up the description in the windview users guide and understand how the function works. Remember that the switch hook occurs in interrupt context, and occurs each time tasks change. You will want to minimize the amount of computation you do in your switch hook function.
To get full credit, you should include the PIT (Programmable Interval Timer) and not simply use tickGet() to get the preempt/dispatch timestamp. tickGet() only has a 1ms resolution and will not work well for timing tasks such as tNetTask. See the sample code referenced in the problem and lookup information about thePIT functions (see the Windview Users Guide in the Tornado/VxWorks Documents page for information about functions such as SysTimestampLock, SysTimestampEnable, etc. The best way to complete this lab is to use both the PIT timer and tickGet(). Use tickGet to get the tick (in this case millisecond) value, and use sysTimestampLock to get the microsecond timestamp between ticks. If you are using only the PIT, You may notice that sometimes your dispatch and preempt times are not what you would expect (dispatch appears to occur after preempt in time, or when subtracting to find the interval you get a negative time.) This is due to the fact that the PIT timer rolls over when the tick value (observed by calling the function tickGet()) is incremented. Therefore, to most corrrectly account for this, you could keep track of BOTH the tickGet() value and the PIT timer (sysTimestamp) value, and use both in your calculations
Another common question is: What is meant by "preempt" and "dispatch" counts? Every time a particular task is passed to your switch hook as the WIND_TCB *pOldTcb, you may consider this a preemption and increment your preempt count for this particular task. Every time this task is passed to your switch hook as the WIND_TCB *pNewTcb, you may consider this a dispatch. Note that by strict definition, to know for sure that a task is being preempted (and not finished with execution) you would need to consult the status member of the WIND_TCB structure. This is not required for this particular problem (but if you want to try it, go for it.) The function taskTcb (listed under the Note section of taskSwitchHookAdd documentation) might be helpful for comparing task TCB structures.. there are several functions in the taskLib library that you may find useful.
To find out about the members of the WIND_TCB structure passed to your switch hook function, you will need to search the tornado source tree. For information about how to do this, see my hints page for searching the Tornado source tree.
If your functions are working correctly, you should find that the tick counts between preempt and dispatch will correspond fairly closely to the execution time you find for these tasks using Windview.
You should be able to come up with an average dispatch time for this task in microseconds. To speed up debugging, first just capture average dispatch time in a second or two until you are fairly certain your code is working.
Your code should show AT LEAST: (include a windshell dump)
1) Number of dispatches/preemptions of tNetTask in 30 seconds.
2) The average dispatch time (execution time per dispatch) calculated by considering the average run time (time between last dispatch and current preempt) averaged across all executions of the task in 30 seconds.
If you are using only the PIT, You may notice that sometimes your dispatch and preempt times are not what you would expect (See problem 5 hints) This is due to the fact that the PIT timer rolls over. If you did not write your code to calcualte based on tickGet() as well as PIT values, you should discard these rollover values when calculating your average. If you didn't write your hook using the PIT timer and used only tickGet(), you will find that your execution times don't make much sense (many times or most of the time the preempt and dispatch will occur on the same tick, giving you an execution time of 0 ticks.. not enough resolution in the tickLib timer to time these executions accurately.)