To improve flight dynamics, separate the gyro task from the scheduler.

[and-sh]

Current Behavior

The gyro task goes through the common scheduler. As a result, with a set frequency of 6400 Hz, the actual frequency varies from 4000 to 6000 Hz. This disrupts the reading of new data and filtering at the gyro frequency.

Desired Behavior

Reading gyro at gyro frequency.

Suggested Solution

void FAST_CODE NOINLINE scheduler(void)
{
    // Cache currentTime
    const timeUs_t currentTimeUs = micros();

//gyro task
static timeUs_t prevGyroDiv,GyroDiv;
GyroDiv=currentTimeUs / GyroTaskmkS;
if(GyroDiv != prevGyroDiv){
 gyroUpdate(void);
prevGyroDiv=GyroDiv;
}

//other tasks

    // The task to be invoked
    cfTask_t *selectedTask = NULL;
    uint16_t selectedTaskDynamicPriority = 0;
    bool forcedRealTimeTask = false;

    // Update task dynamic priorities
    uint16_t waitingTasks = 0;
    for (cfTask_t *task = queueFirst(); task != NULL; task = queueNext()) {
        // Task has checkFunc - event driven
        if (task->checkFunc) {
....

Who does this impact? Who is this for?

Mainly for small drones 5 inch and less.

Additional context

In my case gyro task takes about 15mks and it rather will not affect other tasks behavior .

[and-sh]

On the oscilloscope it looks terrible. The frequency became closer to the set one, but the phase is random. It looks like fifo will have to be done after all

[and-sh]

It fly fine

[and-sh]

I left it like this for now. Not optimal but work

void FAST_CODE NOINLINE scheduler(void)
{

// gyro task
    GyroDiv = (uint32_t) micros();
    GyroMod = GyroDiv % 159;
    GyroDiv = GyroDiv / 159;  // 1/6400

    if((PrevGyroDiv != GyroDiv) || (GyroMod <10))
    {
        IMUUpdate();
        PrevGyroDiv=GyroDiv;
    }

//all other tasks

// Cache currentTime
    const timeUs_t currentTimeUs = micros();