Best way to read from a sensor that doesn't have interrupt pin and requires some time before the measurement is ready
Asked Answered
M

2

2

I'm trying to interface a pressure sensor (MS5803-14BA) with my board (NUCLEO-STM32L073RZ).

According to the datasheet (page 3), the pressure sensor requires some milliseconds before the measurement is ready to be read. For my project, I would be interested in the highest resolution that requires around 10 ms for the conversion of the raw data.

Unfortunately, this pressure sensor doesn't have any interrupt pin that can be exploited to see when the measurement is ready, and therefore I temporarily solved the problem putting a delay after the request of new data.

I don't like my current solution, since in those 10 ms I could put the mcu working on something else (I have several other sensors attached to my board), but without any interrupt pin, I'm not sure about what is the best way to solve this problem.

Another solution came into my mind: Using a timer that triggers every say 20 ms and performs the following operations:

1.a Read the current value stored in the registers (discarding the first value)
1.b Ask for a new value

In this way, at the next iteration I would just need to read the value requested at the end of the previous iteration.

What I don't like is that my measurement would be always 20 ms old. Until the delay remains 20 ms, it should be still fine, but if I need to reduce the rate, the "age" of the reading with my solution would increase.

Do you have any other idea about how to deal with this?

Thank you.

Note: Please let me know if you would need to see my current implementation.

Mcilwain answered 25/4, 2018 at 18:11 Comment(6)
i2c or spi? If i2c it will acknowledge if ready. In the SPI mode it changes the state of SDO line when the conversion is ready. You do not have to guess.Aleasealeatory
Hi, thank you for your reply. I'm using I2C. Concerning the acknowledge you talk about: I'm not sure to have understood. Could you explain more? Thank you very much.Mcilwain
All is in the DS.Aleasealeatory
Datasheet link appears to be dead or I'd try to help...nevermind...was just suuuuuper slow to load for some reason.Valdovinos
Alek, I've read the entire datasheet, and no, it's not exactly "all in the DS" as @PeterJ_01 says. There are some questions left unanswered, such as "what happens in SPI communication [see p10-11] if you pull CSB HIGH during ADC conversion so you can communicate with other SPI devices during that long wait time...will SDO still go HIGH at the end of the conversion?" My hunch is no, it will not, because if CSB is HIGH the sensor doesn't have permission to write to the SPI bus. This means that if you are OK blocking the SPI bus you can wait for SDO to go HIGH...Valdovinos
...(and interrupt on that) before sending the ADC Read command, but if you want to do other SPI commands to other devices during that long conversion time (9ms is very long) you need to do something like my answer below implements. Otherwise, if you accidentally send the ADC Read command too soon, per the datasheet (p11), "If the ADC read command is sent during conversion the result will be 0, the conversion will not stop and the final result will be wrong." So, don't make that mistake.Valdovinos
M
0

First of all thank you for your suggestions. I tried to analyze every single possible solution you proposed.

The solution proposed by Peter seemed very interesting but I have to say that, after having gone through the datasheet several times, I don't believe that is feasible. My consideration is based on the following facts.

Using a scope I see that the acknowledge is received right after sending the command for doing conversion. See following image concerning the temperature conversion:

enter image description here

It seems quite clear to me the acknowledge bit right after the command. After that the SDA line (yellow) goes high, therefore I don't see how it is possible that I can exploit that for detecting when the conversion is ready.

Concerning the solution when using SPI, yes, the SDO remains low during the conversion, but I cannot use it: I need to stick with I2C. Furthermore, I have other sensors attached to that SPI bus and I agree with what Gabriel Staples says.

After my consideration I went for the solution proposed by Gabriel Staples (considering that, in order to read pressure value, I also need to read and convert temperature).

My current solution is based on a state machine with 6 states. In my solution, I distinguish between the wait time for the pressure conversion and the wait time for the temperature conversion with the idea the I could try to see how much the pressure reading degrades if I use a less precise temperature reading.

Here is my current solution. The following function is called inside the main while:

void MS5803_update()
{
  static uint32_t tStart; // us; start time

  switch (sensor_state)
  {
    case MS5803_REQUEST_TEMPERATURE:
    {
        MS5803_send_command(MS5803_CMD_ADC_CONV + TEMPERATURE + baro.resolution);
        tStart = HAL_GetTick();
        sensor_state = MS5803_WAIT_RAW_TEMPERATURE;
        break;
    }

    case MS5803_WAIT_RAW_TEMPERATURE:
    {
        uint32_t tNow = HAL_GetTick();
        if (tNow - tStart >= conversion_time)
        {
            sensor_state = MS5803_CONVERTING_TEMPERATURE;
        }
        break;
    }

    case MS5803_CONVERTING_TEMPERATURE:
    {
        MS5803_send_command(MS5803_CMD_ADC_READ);
        uint8_t raw_value[3]; // Read 24 bit
        MS5803_read_value(raw_value,3);
        temperature_raw = ((uint32_t)raw_value[0] << 16) + ((uint32_t)raw_value[1] << 8) + raw_value[2];
        sensor_state = MS5803_REQUEST_PRESSURE;
        break;
    }

    case MS5803_REQUEST_PRESSURE:
    {
        MS5803_send_command(MS5803_CMD_ADC_CONV + PRESSURE + baro.resolution);
        tStart = HAL_GetTick();
        sensor_state = MS5803_WAIT_RAW_PRESSURE;
        break;
    }

    case MS5803_WAIT_RAW_PRESSURE:
    {
        uint32_t tNow = HAL_GetTick();
        if (tNow - tStart >= conversion_time)
        {
            sensor_state = MS5803_CONVERTING_PRESSURE;
        }
        break;
    }

    case MS5803_CONVERTING_PRESSURE:
    {
        MS5803_send_command(MS5803_CMD_ADC_READ);
        uint8_t raw_value[3]; // Read 24 bit
        MS5803_read_value(raw_value,3);
        pressure_raw = ((uint32_t)raw_value[0] << 16) + ((uint32_t)raw_value[1] << 8) + raw_value[2];

        // Now I have both temperature and pressure raw and I can convert them
        MS5803_updateMeasurements();

        // Reset the state machine to perform a new measurement
        sensor_state = MS5803_REQUEST_TEMPERATURE;
        break;
    }
  }
}

I don't pretend that my solution is better. I just post it in order to have an opinion from you guys. Note: I'm still working on it. Therefore I cannot guarantee is bug-free!

For PeterJ_01: I could agree that this is not strictly a teaching portal, but I believe that everybody around here asks questions to learn something new or to improve theirselves. Therefore, if you believe that the solution using the ack is better, it would be great if you could show us a draft of your idea. For me it would be something new to learn.

Any further comment is appreciated.

Mcilwain answered 28/4, 2018 at 17:6 Comment(6)
Not the address transmitting is stretched.Aleasealeatory
@Alek, it makes sense to me that the ack bit comes immediately right after the "Convert" command, as that's what I expected, but what about right after the "ADC Read" command? I still expect the ack bit to come immediately, but I wonder: If you do a "Convert" command immediately followed by an "ADC Read" command, what happens? Does the ack bit not come until the data is ready (forcing "clock stretching", or does it just give you bad data, or something else?Valdovinos
@Alek, also, I believe that every good question is a valuable opportunity to teach something, and no good answer can exist without also being a good example of teaching (it is by definition not a good answer otherwise, and probably hardly even qualifies as an "answer" at all), and that's how I try to conduct myself online in general: I try to help others and teach them what they need to know to have a complete answer, just as I hope others will do for me when I have a question. I've also witnessed a lot of really good teaching on Stack Overflow in general and think most users agree w/me.Valdovinos
Follow-up: did you ever try it?Valdovinos
@Gabriel: I didn't try it yet. I had to move to another project. But I will take care of testing that as soon as possible.Mcilwain
I look forward to an answer. Thanks!Valdovinos
V
6

How to do high-resolution, timestamp-based, non-blocking, single-threaded cooperative multi-tasking

This isn't a "how to read a sensor" problem, this is a "how to do non-blocking cooperative multi-tasking" problem. Assuming you are running bare-metal (no operating system, such as FreeRTOS), you have two good options.

First, the datasheet shows you need to wait up to 9.04 ms, or 9040 us. enter image description here

Now, here are your cooperative multi-tasking options:

  1. Send a command to tell the device to do an ADC conversion (ie: to take an analog measurement), then configure a hardware timer to interrupt you exactly 9040 us later. In your ISR you then can either set a flag to tell your main loop to send a read command to read the result, OR you can just send the read command right inside the ISR.

  2. Use non-blocking time-stamp-based cooperative multi-tasking in your main loop. This will likely require a basic state machine. Send the conversion command, then move on, doing other things. When your time stamp indicates it's been long enough, send the read command to read the converted result from the sensor.

Number 1 above is my preferred approach for time-critical tasks. This isn't time-critical, however, and a little jitter won't make any difference, so Number 2 above is my preferred approach for general, bare-metal cooperative multi-tasking, so let's do that.

Here's a sample program to demonstrate the principle of time-stamp-based bare-metal cooperative multi-tasking for your specific case where you need to:

  1. request a data sample (start ADC conversion in your external sensor)
  2. wait 9040 us for the conversion to complete
  3. read in the data sample from your external sensor (now that the ADC conversion is complete)

Code:

enum sensorState_t 
{
    SENSOR_START_CONVERSION,
    SENSOR_WAIT,
    SENSOR_GET_CONVERSION
}

int main(void)
{
    doSetupStuff();
    configureHardwareTimer(); // required for getMicros() to work

    while (1)
    {
        //
        // COOPERATIVE TASK #1
        // Read the under-water pressure sensor as fast as permitted by the datasheet
        //
        static sensorState_t sensorState = SENSOR_START_CONVERSION; // initialize state machine
        static uint32_t task1_tStart; // us; start time
        static uint32_t sensorVal; // the sensor value you are trying to obtain 
        static bool newSensorVal = false; // set to true whenever a new value arrives
        switch (sensorState)
        {
            case SENSOR_START_CONVERSION:
            {
                startConversion(); // send command to sensor to start ADC conversion
                task1_tStart = getMicros(); // get a microsecond time stamp
                sensorState = SENSOR_WAIT; // next state 
                break;
            }
            case SENSOR_WAIT:
            {
                const uint32_t DESIRED_WAIT_TIME = 9040; // us
                uint32_t tNow = getMicros();
                if (tNow - task1_tStart >= DESIRED_WAIT_TIME)
                {
                    sensorState = SENSOR_GET_CONVERSION; // next state
                }
                break;
            }
            case SENSOR_GET_CONVERSION:
            {
                sensorVal = readConvertedResult(); // send command to read value from the sensor
                newSensorVal = true;
                sensorState = SENSOR_START_CONVERSION; // next state 
                break;
            }
        }

        //
        // COOPERATIVE TASK #2
        // use the under-water pressure sensor data right when it comes in (this will be an event-based task
        // whose running frequency depends on the rate of new data coming in, for example)
        //
        if (newSensorVal == true)
        {
            newSensorVal = false; // reset this flag 

            // use the sensorVal data here now for whatever you need it for
        }


        //
        // COOPERATIVE TASK #3
        //


        //
        // COOPERATIVE TASK #4
        //


        // etc etc

    } // end of while (1)
} // end of main

For another really simple timestamp-based multi-tasking example see Arduino's "Blink Without Delay" example here.

General time-stamp-based bare-metal cooperative multi-tasking architecture notes:

Depending on how you do it all, in the end, you basically end up with this type of code layout, which simply runs each task at fixed time intervals. Each task should be non-blocking to ensure it does not conflict with the run intervals of the other tasks. Non-blocking on bare metal means simply "do not use clock-wasting delays, busy-loops, or other types of polling, repeating, counting, or busy delays!". (This is opposed to "blocking" on an operating-system-based (OS-based) system, which means "giving the clock back to the scheduler to let it run another thread while this task 'sleeps'." Remember: bare metal means no operating system!). Instead, if something isn't quite ready to run yet, simply save your state via a state machine, exit this task's code (this is the "cooperative" part, as your task must voluntarily give up the processor by returning), and let another task run!

Here's the basic architecture, showing a simple timestamp-based way to get 3 Tasks to run at independent, fixed frequencies withOUT relying on any interrupts, and with minimal jitter, due to the thorough and methodical approach I take to check the timestamps and update the start time at each run time.

1st, the definition for the main() function and main loop:

int main(void)
{
    doSetupStuff();
    configureHardwareTimer();

    while (1)
    {
        doTask1();
        doTask2();
        doTask3();
    }
}

2nd, the definitions for the doTask() functions:

// Task 1: Let's run this one at 100 Hz (every 10ms)
void doTask1(void)
{
    const uint32_t DT_DESIRED_US = 10000; // 10000us = 10ms, or 100Hz run freq
    static uint32_t t_start_us = getMicros();
    uint32_t t_now_us = getMicros();
    uint32_t dt_us = t_now_us - t_start_us;

    // See if it's time to run this Task
    if (dt_us >= DT_DESIRED_US)
    {
        // 1. Add DT_DESIRED_US to t_start_us rather than setting t_start_us to t_now_us (which many 
        // people do) in order to ***avoid introducing artificial jitter into the timing!***
        t_start_us += DT_DESIRED_US;
        // 2. Handle edge case where it's already time to run again because just completing one of the main
        // "scheduler" loops in the main() function takes longer than DT_DESIRED_US; in other words, here
        // we are seeing that t_start_us is lagging too far behind (more than one DT_DESIRED_US time width
        // from t_now_us), so we are "fast-forwarding" t_start_us up to the point where it is exactly 
        // 1 DT_DESIRED_US time width back now, thereby causing this task to instantly run again the 
        // next time it is called (trying as hard as we can to run at the specified frequency) while 
        // at the same time protecting t_start_us from lagging farther and farther behind, as that would
        // eventually cause buggy and incorrect behavior when the (unsigned) timestamps start to roll over
        // back to zero.
        dt_us = t_now_us - t_start_us; // calculate new time delta with newly-updated t_start_us
        if (dt_us >= DT_DESIRED_US)
        {
            t_start_us = t_now_us - DT_DESIRED_US;
        }

        // PERFORM THIS TASK'S OPERATIONS HERE!

    }
}

// Task 2: Let's run this one at 1000 Hz (every 1ms)
void doTask2(void)
{
    const uint32_t DT_DESIRED_US = 1000; // 1000us = 1ms, or 1000Hz run freq
    static uint32_t t_start_us = getMicros();
    uint32_t t_now_us = getMicros();
    uint32_t dt_us = t_now_us - t_start_us;

    // See if it's time to run this Task
    if (dt_us >= DT_DESIRED_US)
    {
        t_start_us += DT_DESIRED_US;
        dt_us = t_now_us - t_start_us; // calculate new time delta with newly-updated t_start_us
        if (dt_us >= DT_DESIRED_US)
        {
            t_start_us = t_now_us - DT_DESIRED_US;
        }

        // PERFORM THIS TASK'S OPERATIONS HERE!

    }
}

// Task 3: Let's run this one at 10 Hz (every 100ms)
void doTask3(void)
{
    const uint32_t DT_DESIRED_US = 100000; // 100000us = 100ms, or 10Hz run freq
    static uint32_t t_start_us = getMicros();
    uint32_t t_now_us = getMicros();
    uint32_t dt_us = t_now_us - t_start_us;

    // See if it's time to run this Task
    if (dt_us >= DT_DESIRED_US)
    {
        t_start_us += DT_DESIRED_US;
        dt_us = t_now_us - t_start_us; // calculate new time delta with newly-updated t_start_us
        if (dt_us >= DT_DESIRED_US)
        {
            t_start_us = t_now_us - DT_DESIRED_US;
        }

        // PERFORM THIS TASK'S OPERATIONS HERE!

    }
}

The code above works perfectly but as you can see is pretty redundant and a bit irritating to set up new tasks. This job can be a bit more automated and much much easier to do by simply defining a macro, CREATE_TASK_TIMER(), as follows, to do all of the redundant timing stuff and timestamp variable creation for us:

/// @brief      A function-like macro to get a certain set of events to run at a desired, fixed 
///             interval period or frequency.
/// @details    This is a timestamp-based time polling technique frequently used in bare-metal
///             programming as a basic means of achieving cooperative multi-tasking. Note 
///             that getting the timing details right is difficult, hence one reason this macro 
///             is so useful. The other reason is that this maro significantly reduces the number of
///             lines of code you need to write to introduce a new timestamp-based cooperative
///             task. The technique used herein achieves a perfect desired period (or freq) 
///             on average, as it centers the jitter inherent in any polling technique around 
///             the desired time delta set-point, rather than always lagging as many other 
///             approaches do.
///             
///             USAGE EX:
///             ```
///             // Create a task timer to run at 500 Hz (every 2000 us, or 2 ms; 1/0.002 sec = 500 Hz)
///             const uint32_t PERIOD_US = 2000; // 2000 us pd --> 500 Hz freq
///             bool time_to_run;
///             CREATE_TASK_TIMER(PERIOD_US, time_to_run);
///             if (time_to_run)
///             {
///                 run_task_2();
///             }
///             ```
///
///             Source: Gabriel Staples 
///             https://mcmap.net/q/21042/-best-way-to-read-from-a-sensor-that-doesn-39-t-have-interrupt-pin-and-requires-some-time-before-the-measurement-is-ready/50032992#50032992
/// @param[in]  dt_desired_us   The desired delta time period, in microseconds; note: pd = 1/freq;
///                             the type must be `uint32_t`
/// @param[out] time_to_run     A `bool` whose scope will enter *into* the brace-based scope block
///                             below; used as an *output* flag to the caller: this variable will 
///                             be set to true if it is time to run your code, according to the 
///                             timestamps, and will be set to false otherwise
/// @return     NA--this is not a true function
#define CREATE_TASK_TIMER(dt_desired_us, time_to_run)                                                                  \
{ /* Use scoping braces to allow multiple calls of this macro all in one outer scope while */                          \
  /* allowing each variable created below to be treated as unique to its own scope */                                  \
    time_to_run = false;                                                                                               \
                                                                                                                       \
    /* set the desired run pd / freq */                                                                                \
    const uint32_t DT_DESIRED_US = dt_desired_us;                                                                      \
    static uint32_t t_start_us = getMicros();                                                                          \
    uint32_t t_now_us = getMicros();                                                                                   \
    uint32_t dt_us = t_now_us - t_start_us;                                                                            \
                                                                                                                       \
    /* See if it's time to run this Task */                                                                            \
    if (dt_us >= DT_DESIRED_US)                                                                                        \
    {                                                                                                                  \
        /* 1. Add DT_DESIRED_US to t_start_us rather than setting t_start_us to t_now_us (which many */                \
        /* people do) in order to ***avoid introducing artificial jitter into the timing!*** */                        \
        t_start_us += DT_DESIRED_US;                                                                                   \
        /* 2. Handle edge case where it's already time to run again because just completing one of the main */         \
        /* "scheduler" loops in the main() function takes longer than DT_DESIRED_US; in other words, here */           \
        /* we are seeing that t_start_us is lagging too far behind (more than one DT_DESIRED_US time width */          \
        /* from t_now_us), so we are "fast-forwarding" t_start_us up to the point where it is exactly */               \
        /* 1 DT_DESIRED_US time width back now, thereby causing this task to instantly run again the */                \
        /* next time it is called (trying as hard as we can to run at the specified frequency) while */                \
        /* at the same time protecting t_start_us from lagging farther and farther behind, as that would */            \
        /* eventually cause buggy and incorrect behavior when the (unsigned) timestamps start to roll over */          \
        /* back to zero. */                                                                                            \
        dt_us = t_now_us - t_start_us; /* calculate new time delta with newly-updated t_start_us */                    \
        if (dt_us >= DT_DESIRED_US)                                                                                    \
        {                                                                                                              \
            t_start_us = t_now_us - DT_DESIRED_US;                                                                     \
        }                                                                                                              \
                                                                                                                       \
        time_to_run = true;                                                                                            \
    }                                                                                                                  \
}

Now, there are multiple ways to use it, but for the sake of this demo, in order to keep the really clean main() loop code which looks like this:

int main(void)
{
    doSetupStuff();
    configureHardwareTimer();

    while (1)
    {
        doTask1();
        doTask2();
        doTask3();
    }
}

Let's use the CREATE_TASK_TIMER() macro like this. As you can see, the code is now much cleaner and easier to set up a new task. This is my preferred approach, because it creates the really clean main loop shown just above, with just the various doTask() calls, which are also easy to write and maintain:

// Task 1: Let's run this one at 100 Hz (every 10ms, or 10000us)
void doTask1(void)
{
    bool time_to_run;
    const uint32_t DT_DESIRED_US = 10000; // 10000us = 10ms, or 100Hz run freq
    CREATE_TASK_TIMER(DT_DESIRED_US, time_to_run);
    if (time_to_run)
    {
        // PERFORM THIS TASK'S OPERATIONS HERE!
    }
}

// Task 2: Let's run this one at 1000 Hz (every 1ms)
void doTask2(void)
{
    bool time_to_run;
    const uint32_t DT_DESIRED_US = 1000; // 1000us = 1ms, or 1000Hz run freq
    CREATE_TASK_TIMER(DT_DESIRED_US, time_to_run);
    if (time_to_run)
    {
        // PERFORM THIS TASK'S OPERATIONS HERE!
    }
}

// Task 3: Let's run this one at 10 Hz (every 100ms)
void doTask3(void)
{
    bool time_to_run;
    const uint32_t DT_DESIRED_US = 100000; // 100000us = 100ms, or 10Hz run freq
    CREATE_TASK_TIMER(DT_DESIRED_US, time_to_run);
    if (time_to_run)
    {
        // PERFORM THIS TASK'S OPERATIONS HERE!
    }
}

Alternatively, however, you could structure the code more like this, which works equally as well and produces the same effect, just in a slightly different way:

#include <stdbool.h>
#include <stdint.h>

#define TASK1_PD_US (10000)     // 10ms pd, or 100 Hz run freq 
#define TASK2_PD_US (1000)      // 1ms pd, or 1000 Hz run freq 
#define TASK3_PD_US (100000)    // 100ms pd, or 10 Hz run freq 

// Task 1: Let's run this one at 100 Hz (every 10ms, or 10000us)
void doTask1(void)
{
    // PERFORM THIS TASK'S OPERATIONS HERE!
}

// Task 2: Let's run this one at 1000 Hz (every 1ms)
void doTask2(void)
{
    // PERFORM THIS TASK'S OPERATIONS HERE!
}

// Task 3: Let's run this one at 10 Hz (every 100ms)
void doTask3(void)
{
    // PERFORM THIS TASK'S OPERATIONS HERE!
}

int main(void)
{
    doSetupStuff();
    configureHardwareTimer();

    while (1)
    {
        bool time_to_run;

        CREATE_TASK_TIMER(TASK1_PD_US, time_to_run);
        if (time_to_run)
        {
            doTask1();
        }

        CREATE_TASK_TIMER(TASK2_PD_US, time_to_run);
        if (time_to_run)
        {
            doTask2();
        }

        CREATE_TASK_TIMER(TASK3_PD_US, time_to_run);
        if (time_to_run)
        {
            doTask3();
        }
    }
}

Part of the art (and fun!) of embedded bare-metal microcontroller programming is the skill and ingenuity involved in deciding exactly how you want to interleave each task and get them to run together, all as though they were running in parallel. Use one of the above formats as a starting point, and adapt to your particular circumstances. Message-passing can be added between tasks or between tasks and interrupts, tasks and a user, etc, as desired, and as required for your particular application.

Here's an example of how to configure a timer for use as a timestamp-generator on an STM32F2 microcontroller.

This shows functions for configureHardwareTimer() and getMicros(), used above:

// Timer handle to be used for Timer 2 below
TIM_HandleTypeDef TimHandle;

// Configure Timer 2 to be used as a free-running 32-bit hardware timer for general-purpose use as a 1-us-resolution
// timestamp source
void configureHardwareTimer()
{
    // Timer clock must be enabled before you can configure it
    __HAL_RCC_TIM2_CLK_ENABLE();

    // Calculate prescaler
    // Here are some references to show how this is done:
    // 1) "STM32Cube_FW_F2_V1.7.0/Projects/STM32F207ZG-Nucleo/Examples/TIM/TIM_OnePulse/Src/main.c" shows the
    //    following (slightly modified) equation on line 95: `Prescaler = (TIMxCLK/TIMx_counter_clock) - 1`
    // 2) "STM32F20x and STM32F21x Reference Manual" states the following on pg 419: "14.4.11 TIMx prescaler (TIMx_PSC)"
    //    "The counter clock frequency CK_CNT is equal to fCK_PSC / (PSC[15:0] + 1)"
    //    This means that TIMx_counter_clock_freq = TIMxCLK/(prescaler + 1). Now, solve for prescaler and you
    //    get the exact same equation as above: `prescaler = TIMxCLK/TIMx_counter_clock_freq - 1`
    // Calculating TIMxCLK:
    // - We must divide SystemCoreClock (returned by HAL_RCC_GetHCLKFreq()) by 2 because TIM2 uses clock APB1
    // as its clock source, and on my board this is configured to be 1/2 of the SystemCoreClock.
    // - Note: To know which clock source each peripheral and timer uses, you can look at
    //  "Table 25. Peripheral current consumption" in the datasheet, p86-88.
    const uint32_t DESIRED_TIMER_FREQ = 1e6; // 1 MHz clock freq --> 1 us pd per tick, which is what I want
    uint32_t Tim2Clk = HAL_RCC_GetHCLKFreq() / 2;
    uint32_t prescaler = Tim2Clk / DESIRED_TIMER_FREQ - 1; // Don't forget the minus 1!

    // Configure timer
    // TIM2 is a 32-bit timer; See datasheet "Table 4. Timer feature comparison", p30-31
    TimHandle.Instance               = TIM2;
    TimHandle.Init.Period            = 0xFFFFFFFF; // Set pd to max possible for a 32-bit timer
    TimHandle.Init.Prescaler         = prescaler;
    TimHandle.Init.ClockDivision     = TIM_CLOCKDIVISION_DIV1;
    TimHandle.Init.CounterMode       = TIM_COUNTERMODE_UP;
    TimHandle.Init.RepetitionCounter = 0; // NA (has no significance) for this timer

    // Initialize the timer
    if (HAL_TIM_Base_Init(&TimHandle) != HAL_OK)
    {
        // handle error condition
    }

    // Start the timer
    if (HAL_TIM_Base_Start(&TimHandle) != HAL_OK)
    {
        // handle error condition
    }
}

// Get the 1 us count value on Timer 2.
// This timer will be used for general purpose hardware timing that does NOT rely on interrupts.
// Therefore, the counter will continue to increment even with interrupts disabled.
// The count value increments every 1 microsecond.
// Since it is a 32-bit counter it overflows every 2^32 counts, which means the highest value it can
// store is 2^32 - 1 = 4294967295. Overflows occur every 2^32 counts / 1 count/us / 1e6us/sec
// = ~4294.97 sec = ~71.6 min.
uint32_t getMicros()
{
    return __HAL_TIM_GET_COUNTER(&TimHandle);
}

References:

  1. https://www.arduino.cc/en/tutorial/BlinkWithoutDelay
  2. Doxygen: What's the right way to reference a parameter in Doxygen?
  3. Enum-based error codes for error handling: Error handling in C code
  4. Other architectural styles in C, such as "object-based" C via opaque pointers: Opaque C structs: various ways to declare them

See also:

  1. A full, runnable Arduino example with an even better version of my CREATE_TASK_TIMER() macro from above:
    1. My answer for C and C++, including microcontrollers and Arduino (or any other system): Full coulomb counter example demonstrating the above concept with timestamp-based, single-threaded, cooperative multi-tasking
  2. My answer: Arduino: fill array with values from analogRead()
Valdovinos answered 26/4, 2018 at 0:11 Comment(7)
Ufff,,,, Isn't easier to use the I2C interrupt to have the acknowledge of the data ready or in the SPI mode after the command sent set the SDO connected pin as digital input and wait for the EXTI interrupt instead of this spaghetti method. Loooong answer but the worst method chosen. Waste of timers, over complicated method - generally a very bad answer - a spaghetti style method.Aleasealeatory
You are making some pretty big assumptions here that, according to my study, don't seem correct. I've read the entire datasheet and studied this really good article on I2C (learn.sparkfun.com/tutorials/i2c), and you are under the assumption that the slave is doing "Clock stretching" (see article) and not sending the ACK bit after the ADC Read command until data is actually ready. Not only does the datasheet seem to indicate to the contrary (though it isn't crystal clear), this would unnecessarily tie up the entire I2C bus during a conversion, which is wasteful and blocks other devices.Valdovinos
As for the SPI thing and the SDO line going high after conversion, see my comments under the question at the top of this page: #1) the datasheet isn't clear on this, #2) if this is the case for how it operates when you hold the chip select pin (CSB) LOW during the entire conversion...well...you just blocked other SPI communication during the entire conversion. Sometimes you can't afford to do this, as blocking for 10ms is a long time if you have many SPI devices on the bus.Valdovinos
So, my method works, is fairly simple and straight forward, allows effective cooperative multitasking while only taking a portion of a single timer to operate an infinite number of tasks, and in my opinion is very good code. If you have a better way of doing things, please teach us. I'd like to see your 30 yrs experience (as stated in your profile, with the last 5-10 years of that being "mostly focused on the bare metal embedded programming") in action in an answer you write here as thorough and well-thought-out as mine. Honestly, if you have a better way I'd like to learn it.Valdovinos
Arduino style (which is very similar to the thee starts programming) - and unfortunately it is a very very bad approach in the uC programming. Modesty literally flows from your comments. And BTW it does not have anything in common with multitasking. It should be called. Arduino loop for stm32. And as I see you took all the bad from the arduino.Aleasealeatory
Let me re-emphasize the most important thing I said: if you have something to teach, please share it in an answer. Thank you. Also, please don't read my comments with any tone of sarcasm. That's not how they are intended. Interpret them at face-value.Valdovinos
This is not teaching portal. OP can try it yourself and if he has problems can ask the question.Aleasealeatory
M
0

First of all thank you for your suggestions. I tried to analyze every single possible solution you proposed.

The solution proposed by Peter seemed very interesting but I have to say that, after having gone through the datasheet several times, I don't believe that is feasible. My consideration is based on the following facts.

Using a scope I see that the acknowledge is received right after sending the command for doing conversion. See following image concerning the temperature conversion:

enter image description here

It seems quite clear to me the acknowledge bit right after the command. After that the SDA line (yellow) goes high, therefore I don't see how it is possible that I can exploit that for detecting when the conversion is ready.

Concerning the solution when using SPI, yes, the SDO remains low during the conversion, but I cannot use it: I need to stick with I2C. Furthermore, I have other sensors attached to that SPI bus and I agree with what Gabriel Staples says.

After my consideration I went for the solution proposed by Gabriel Staples (considering that, in order to read pressure value, I also need to read and convert temperature).

My current solution is based on a state machine with 6 states. In my solution, I distinguish between the wait time for the pressure conversion and the wait time for the temperature conversion with the idea the I could try to see how much the pressure reading degrades if I use a less precise temperature reading.

Here is my current solution. The following function is called inside the main while:

void MS5803_update()
{
  static uint32_t tStart; // us; start time

  switch (sensor_state)
  {
    case MS5803_REQUEST_TEMPERATURE:
    {
        MS5803_send_command(MS5803_CMD_ADC_CONV + TEMPERATURE + baro.resolution);
        tStart = HAL_GetTick();
        sensor_state = MS5803_WAIT_RAW_TEMPERATURE;
        break;
    }

    case MS5803_WAIT_RAW_TEMPERATURE:
    {
        uint32_t tNow = HAL_GetTick();
        if (tNow - tStart >= conversion_time)
        {
            sensor_state = MS5803_CONVERTING_TEMPERATURE;
        }
        break;
    }

    case MS5803_CONVERTING_TEMPERATURE:
    {
        MS5803_send_command(MS5803_CMD_ADC_READ);
        uint8_t raw_value[3]; // Read 24 bit
        MS5803_read_value(raw_value,3);
        temperature_raw = ((uint32_t)raw_value[0] << 16) + ((uint32_t)raw_value[1] << 8) + raw_value[2];
        sensor_state = MS5803_REQUEST_PRESSURE;
        break;
    }

    case MS5803_REQUEST_PRESSURE:
    {
        MS5803_send_command(MS5803_CMD_ADC_CONV + PRESSURE + baro.resolution);
        tStart = HAL_GetTick();
        sensor_state = MS5803_WAIT_RAW_PRESSURE;
        break;
    }

    case MS5803_WAIT_RAW_PRESSURE:
    {
        uint32_t tNow = HAL_GetTick();
        if (tNow - tStart >= conversion_time)
        {
            sensor_state = MS5803_CONVERTING_PRESSURE;
        }
        break;
    }

    case MS5803_CONVERTING_PRESSURE:
    {
        MS5803_send_command(MS5803_CMD_ADC_READ);
        uint8_t raw_value[3]; // Read 24 bit
        MS5803_read_value(raw_value,3);
        pressure_raw = ((uint32_t)raw_value[0] << 16) + ((uint32_t)raw_value[1] << 8) + raw_value[2];

        // Now I have both temperature and pressure raw and I can convert them
        MS5803_updateMeasurements();

        // Reset the state machine to perform a new measurement
        sensor_state = MS5803_REQUEST_TEMPERATURE;
        break;
    }
  }
}

I don't pretend that my solution is better. I just post it in order to have an opinion from you guys. Note: I'm still working on it. Therefore I cannot guarantee is bug-free!

For PeterJ_01: I could agree that this is not strictly a teaching portal, but I believe that everybody around here asks questions to learn something new or to improve theirselves. Therefore, if you believe that the solution using the ack is better, it would be great if you could show us a draft of your idea. For me it would be something new to learn.

Any further comment is appreciated.

Mcilwain answered 28/4, 2018 at 17:6 Comment(6)
Not the address transmitting is stretched.Aleasealeatory
@Alek, it makes sense to me that the ack bit comes immediately right after the "Convert" command, as that's what I expected, but what about right after the "ADC Read" command? I still expect the ack bit to come immediately, but I wonder: If you do a "Convert" command immediately followed by an "ADC Read" command, what happens? Does the ack bit not come until the data is ready (forcing "clock stretching", or does it just give you bad data, or something else?Valdovinos
@Alek, also, I believe that every good question is a valuable opportunity to teach something, and no good answer can exist without also being a good example of teaching (it is by definition not a good answer otherwise, and probably hardly even qualifies as an "answer" at all), and that's how I try to conduct myself online in general: I try to help others and teach them what they need to know to have a complete answer, just as I hope others will do for me when I have a question. I've also witnessed a lot of really good teaching on Stack Overflow in general and think most users agree w/me.Valdovinos
Follow-up: did you ever try it?Valdovinos
@Gabriel: I didn't try it yet. I had to move to another project. But I will take care of testing that as soon as possible.Mcilwain
I look forward to an answer. Thanks!Valdovinos

© 2022 - 2024 — McMap. All rights reserved.