Embedded System Tutorial File I/O

From Embedded Systems Learning Academy
Revision as of 01:06, 10 May 2014 by Preet (talk | contribs)

Jump to: navigation, search

In this project, we will attempt to "combine" all the FreeRTOS knowledge into a single assignment.


After completing the assignment, you will get a sensor of how the CPU is utilized, and how to use a new FreeRTOS event group API. All together, you should acheive a better sense of designing your tasks and using the File I/O for debugging purposes.


Assignment

Please follow the steps precisely in order to complete the objectives of the assignment. If you use the C++ FreeRTOS framework, it should make the assignment significantly easy.


  1. Create a producer task that takes 1 light sensor value every 1ms.
    • Collect the average of the 100 readings.
    • Write average value every 100ms (avg. of 100 samples) to the sensor queue.
    • Use medium priority for this task
  2. Create a consumer task that pulls the data off the sensor queue
    • Use infinite timeout value during queue receive API
    • Open a file (sensor.txt), and append the data to an output file on the SD card.
    • Save the data in this format: printf("%i, %i\n", time, light)"
    • Just leave the file in "open" mode, such that it will flush the data after enough data is written rather than flushing it upon each write, which will consume a lot of CPU.
    • Use medium priority for this task
  3. At the end of the loop of each task, set a bit using FreeRTOS event group API.
    • At the end of each loop of the tasks, set a bit using the xEventGroupSetBits()
    • Task 1 should set bit1, Task 2 should set bit2 etc.
  4. Create a watchdog task that monitors the operation of the two tasks.
    • Use high priority for this task.
    • Every sixty seconds, save the CPU usage info to a file named "cpu.txt". See terminal command "infoHandler" for reference. Open the file, write the file, and close it immediately so the data is immediately flushed.
    • Use a timeout of 1 second, and wait for all the bits to set. If there are two tasks, wait for bit1, and bit2 etc.
    • If you fail to detect the bits are set, that means that the other tasks did not reach the end of the loop.
    • In the event of failed to detect the bits, append a file (stuck.txt) with the information about which task may be "stuck"
    • Open the file, append the data, and close the (stuck.txt) file to flush out the data immediately.
  5. Create a terminal command to "suspend" and "resume" a task by name.
    • "task suspend task1" should suspend a task named "task1"
    • "task resume task2" should suspend a task named "task2"
  6. Run the system, and under normal operation, you will see a file being saved with sensor data values.
    • Plot the file data in Excel to demonstrate.
  7. Suspend the producer task. The watchdog task should display a message and save relevant info to the SD card.
  8. Let the system run for a while, and note down the CPU usage in your text file.
  9. Change the ADC sensor implementation
    • Modify the source code of "adc.h" by not using ADC polling mode.
    • Instead of "trigger ADC", "wait for completion", and "read value", modify it to this:
      Upon ADC initialization, enable ADC interrupt, and create a binary semaphore.
      The ADC interrupt should "give" the semaphore upon completion of the ADC.
      Note that you need to read the ADC data register in order to clear the interrupt before you exit the ISR.
      After triggering the ADC, wait for ADC semaphore using xSemaphoreTake(), and then read the value.
  10. After changing the ADC behavior, let the system run for a while, and note down the CPU usage again.

What you created is a "software watchdog". This means that in an event when a loop is stuck, or a task is frozen, you can save relevant information such that you can debug at a later time.