This is a Markdown Level 1 header

Go ahead and use this readme to write your application report questions

Level 2 Heading

Want to learn more about markdown? Website Title

Code example

import foobar

# returns 'words'
foobar.pluralize('word')

# returns 'geese'
foobar.pluralize('goose')

# returns 'phenomenon'
foobar.singularize('phenomena')

Question Prompts

1. Task Timing and Jitter:

Compare the timing of the LED blink and console print tasks with that of the sensor task.

• How regular is each task’s period in practice? The sensor has very consistent timing, vTaskDelayUntil seems to hold a higher degree of accuracy than previous delay functions. The LED task is also fairly consistent in this application, but it technically has the execution time plus the delay so it could run an irregular pattern. The Print task runs similar to the LED on vTaskDelay, but it gets preempted the most so it likely has the greatest variation.

• For the sensor task (using vTaskDelayUntil), do the sensor readings and alert messages occur at consistent intervals (e.g. every 500 ms)? Yes, the readings were very consistent in the output.

• In contrast, do you observe any drift or variation in the LED blink or print intervals over time? After a run of a minute I didn't have any variations. That said, it feels a little unusual. I know there can be a lot of variation with the Print and LED tasks for the reasons above, I just didn't see it in my time window.

• Explain why vTaskDelayUntil provides a more stable period for the sensor task, referencing how it calculates the next wake-up tick based on an absolute time reference. vTaskDelayUntil is more stable because it's relative to an absolute number of ticks, whereas vTaskDelay is run from the current time, so execution time can vary the total time of the delay.

• What might cause jitter in the LED or print task periods when using vTaskDelay? The most likely factor is either of the tasks being preempted by the sensor task, this would cause a delay. Secondly, the print statements technically have variable execution timing, but for this project I think that's a significantly smaller source of jitter compared to the preemption.

2. Priority-Based Preemption:

Describe a scenario observed in your running system that demonstrates FreeRTOS’s priority-based preemptive scheduling.

• For example, what happens if the console print task is about to print (or even mid-way through printing) exactly when the sensor task’s next period arrives?
• Does the sensor task interrupt the print task immediately, or does it wait?
• Based on your understanding of FreeRTOS, which task would the scheduler choose to run at a moment when both become Ready, and why?
• Provide a brief timeline or example (using tick counts or event ordering) to illustrate the preemption.
  • Note, if you didn’t explicitly catch this in simulation, answer conceptually: assume the print task was running right when the sensor task unblocked – what should happen?)

Let's say we ran that scenario with the print task running/about to run and the sensor task becomes ready. In that case, the scheduler would immediately preempt the print task (including if it's actively running) and run the sensor task to completion. Then it would resume the print task. It'd go something like this (with some made up, easy tick times): 1000 - Print task starts (C=100) 1050 - Sensor task (C=20) unblocks, preempts the print task, runs the sensor task. 1070 - Sensor task completes, Print task resumes. 1020 - Print task completes.

3. Effect of Task Execution Time:

In your design, all tasks have small execution times (they do minimal work before blocking again). Suppose the sensor task took significantly longer to execute (for instance, imagine it performed a complex calculation taking, say, 300 ms of CPU time per cycle).

• How would that affect the lower-priority tasks?
• Discuss what would happen if the sensor task’s execution time sometimes exceeds its period (i.e., it can’t finish its work before the next 500 ms tick).
• What symptoms would you expect to see in the system (e.g. missed readings, delayed LED toggles, etc.)? Relate this to real-time scheduling concepts like missed deadlines or CPU utilization from the RTOS theory (Chapters 3 and 6 of the Harder textbook).
• What options could a system designer consider if the high-priority task started starving lower tasks or missing its schedule (think about reducing workload, adjusting priorities, or using two cores)?

If the sensor task were to run for a lot longer, it would have significantly more effect on the jitter of the print and LED tasks. We would see more irregular periods for both tasks because the sensor keeps preempting them for longer which is just a greater shift on the actual execution plus the delay. If the sensor had runtime longer than its own period, it would start running almost continuously, depending on how often and by how much it missed the deadline. This would likely lead to the LED blinking at irregular intervals and a starved print task (lowest priority). The sensor task itself may be unstable becuase it's running over it's own limits. In this case, it would either have to miss the start of the second iteration, or terminate the first iteration early. I suspect it would finish executing the first iteration and miss the deadline for the second, but either way it would not be an ideal case with likely system failure (Depending on the task importance: Hard, firm, soft). Optimizations could be made by moving the workload across two cores, concurrent tasks could help (not guaranteed). The compute time of the math for the sensor could be reduced. If the task has been missing it's deadline, running for a shorter timeframe would certainly help.

4. vTaskDelay vs vTaskDelayUntil:

• Why did we choose vTaskDelayUntil for the sensor task instead of using vTaskDelay in a simple loop?
• Explain in your own words the difference between these two delay functions in FreeRTOS, and the specific problem that vTaskDelayUntil solves for periodic real-time tasks.
• Consider what could happen to the sensor sampling timing over many iterations if we used vTaskDelay(500 ms) instead – how might small errors accumulate?
• Also, for the LED blink task, why is using vTaskDelay acceptable in that context? (Think about the consequences of slight timing drift for a status LED vs. a sensor sampling task.)

It was preferable to use vTaskDelayUntil for the sensor because it would guarantee stable sampling. vTaskDelay starts a delay relative to the time when it's called, which can lead to drift (execution time + delay, instead of just delay). On the other hand, vTaskDelayUntil delays to a speficied tick count from a reference time so it's an absolute measurement. If we had used vTaskDelay and there was a small execution time variance, it would accumulate over time to be no where near the original rate of sampling. Even 1ms over 1000 cycles is a second of variance, which would be catastrophic for our system. For the LED, vTaskDelay is acceptable because it's not a precise sample like the sensor. It's just blinking on an approximate interval to indicate funcionality.

5. Thematic Integration Reflection:

Relate the functioning of your three tasks to a real-world scenario in one of the thematic contexts (Space Systems, Healthcare, or Hardware Security).

• Describe an example of what each task could represent.
• Explain how task priority might reflect the importance of that function in the real system (e.g. why the sensor monitoring is high priority in a medical device).

Let's say our system is representative of a satelite. The sensor could be measuring light levels to determine if the satelite is passing into earth's shadow. This is important becuase that would indicate a major swing in temperature is coming. Fast changes in temperature is usually not ideal for electronics. So, we want to know when a shift is coming as soon as possible so we can make the necessary adjustments, high priotity. The print statement could be transmitting data to our ground station. We need the data on a fairly regular interval, but slight delays won't compromise the satelite. The LED could just be flashing as a "system is alive and running" flag. Not of great importance but it is informative: low priority.

In the real system, the sensor would be of great importance because if the sensor missed a deadline, a sudden temperature shift could permanently destroy the satelite and that is system failure. The data transmitting is important for future calculations but if it arrives 1ms late, the ground team isn't going to make a course altering decision in that time frame anyway. The LED is of the lowest importance because it's in orbit and we proabably can't see it. But if we could, it would be a nice indicator that everything is still alive and well onboard the satelite.