Featured Articles
Announcing Pi
Technical Specifications
Raspberry Pi FAQs
Win a Pi
GPIO Pinout
Raspberry Pi Wishlist
Comparison Chart
Quiz
Group Actions
Engagement
  • Author Author: Jan Cumps
  • Date Created: Date Created
  • Views 1007 views
  • Likes 8 likes
  • Comments 2 comments
Related
Recommended

Add a competing ADC Task to the Multi-core FreeRTOS SMP Project with the Raspberry Pi Pico

Jan Cumps
Add a competing ADC Task to the Multi-core FreeRTOS SMP Project with the Raspberry Pi Pico

FreeRTOS Symmetric Multiprocessing (SMP) is a recent version of the RTOS that can schedule tasks across multiple controller cores. It's currently in test phase, and they have a version for the RP2040. In this blog post, I add a second ADC task to my own little SMP project in VSCode. It will compete with the task from the previous blog for the ADC peripheral.
image
Prerequisite is that you are able to run the temperature task from the previous post.

Separate source files

Up till now, I've added everything in the project to main.c. For this exercise, let's start with dedicated c and header files.

v5vtask.h

#ifndef __V5VTASK_H
#define __V5VTASK_H

#include "FreeRTOS.h"
#include "task.h"

#define V5V_TASK_PRIORITY       (tskIDLE_PRIORITY +1)
#define V5V_TASK_FREQUENCY_MS (5000 / portTICK_PERIOD_MS)

/*******************************************************************************
* Function Prototypes
********************************************************************************/
void prv5vTask(void *pvParameters);

#endif // __V5VTASK_H

v5vtask.c

#include "FreeRTOS.h"
#include "semphr.h"
#include "task.h"

#include <stdio.h>
#include "pico/stdlib.h"

#include "v5vtask.h"

#include "hardware/adc.h"


// handles
extern SemaphoreHandle_t xADCMutex;

void prv5vTask(void *pvParameters) {

   (void)pvParameters;
    TickType_t xNextWakeTime;

    /* Initialise xNextWakeTime - this only needs to be done once. */
    xNextWakeTime = xTaskGetTickCount();

    // Make sure GPIO is high-impedance, no pullups etc
    adc_gpio_init(29); // gpio29 is adc0
    for (;;)
    {
        xSemaphoreTake(xADCMutex, portMAX_DELAY);

        // switch to the temperature mux if needed
        if (adc_get_selected_input() != 3)
        {
            adc_select_input(3);
        }
        // 12-bit conversion, assume max value == ADC_VREF == 3.3 V
        const float conversion_factor = 3.3f / (1 << 12);
        uint16_t result = adc_read();
        xSemaphoreGive(xADCMutex);
        printf("Raw value: 0x%03x, voltage: %f V\n", result, result * conversion_factor);
        xTaskDelayUntil(&xNextWakeTime, V5V_TASK_FREQUENCY_MS);
    }
}

Because the task changes an ADC setting (the active channel), it's possibly conflicting with what the temperature task from the previous blog did. The mutex we created, solves this possible interference.

The expected result is 5V measured over a divide by 3 network: VSYS * (R6/(R5+R6)) = 1.67 V

image

The actual results confirm this:
image

In main.c, we have to make a few changes:

#include "v5vtask.h"

// ...

// handles
SemaphoreHandle_t xADCMutex;

// ...

    /* Configure the hardware ready to run the demo. */
    prvSetupHardware();

    xTaskCreate(prvBlinkTask, "blink", configMINIMAL_STACK_SIZE, NULL, mainBLINK_TASK_PRIORITY, NULL);
    xTaskCreate(prvTemperatureTask, "temperature", configMINIMAL_STACK_SIZE, NULL, mainTEMPERATURE_TASK_PRIORITY, NULL);
    xTaskCreate(prv5vTask, "v5vtask", configMINIMAL_STACK_SIZE, NULL, V5V_TASK_PRIORITY, NULL);
    /* Create a mutex type semaphore. */
    xADCMutex = xSemaphoreCreateMutex();

    /* Start the tasks and timer running. */
    vTaskStartScheduler();

// ...

The semaphore handler is no longer static. We can't share static between two c source files.

Because we added a new source file, the CMake file needs an update:

add_executable(project0
        source/main.c
        source/v5vtask.c
        )

If you 'd like to see possible corruption between the tasks, schedule them at different frequencies and comment out the take and return of the mutex. You may see that the temperature task reads the adc channel 3 or vice versa...

Show All Blog Posts

  • I'm parking the subject for a moment. My goal is to learn multi-core RTOS. And the next topic is one I'll have to read-up for

    • 1: "what is the impact to an RTOS design, if a low-priority task can run together with a high-priority one?"
    • 2: "how do I run critical code, that can't be interrupted?"

    These have never been a scenario in single-core RTOS. 

    • 1: Any job running at a given time was always the highest priority one that needed runtime.
    • 2: nothing (even interrupts) were running when a critical code section was active

    There are solutions for both. Raw (block these new possibilities - for backward compatibility) or Nice (deal with the new situations and possibilities).
    The Raw option is easier for migrating existing code that assumes those single-core perks.
    The Nice option allows for more functionality running at the same time and maximises the multi-core advantages. But at increased complexity and book-keeping.