AVR Freaks

Reviewing customer's requirements, is there any special reason for not using a display instead of LED?
.
I think displaying absolute value such as exact pressure value or a percentage of value in the form of digits are more definite and user friendly,
"slow blink" or "fast blink" are relative expresions and depends on the judgment of users and may increase the ambiguity.

The number (just a byte) to be communicated between

threads is the time between the next two toggles.

If the transmitting thread is fast enough,

some transmitted bytes will go unused.

I do not see a problem with that.

 

This 'trick' (not really) is to compute (now - last_toggle_ms), and compare the result of that to the computed half-period for the LED.  If now and last_toggle_ms are the same unsigned type, the result will also be unsigned, and therefore always positive.

 

Imagine a 16-bit tick, so 0-65,535 ms.  Next imagine that the most recent toggle was at 65,530 ms.  Now imagine that ten ticks later, the current systick rolls over and ends up at 4.  So the expression (now - last_toggle_ms) is the expression (4 - 65530).  As you noted, this is negative.  However, since both operands are unsigned, so is the results of the expression.  Recall numerous threads on integer promotion and signedness.  The negative value is "converted by repeatedly adding or subtracting one more than the maximum value that can be represented in the new type until the value is in the range of the new type."  So although 4-65,530 as a signed result is -65,526, the value 65,536 is added, and we get 10... exactly what you would expect.  You don't have to do this addition.  In fact, neither does the compiler, nor the hardware.  It is simply a means for the standard to define the behaviour of two's complement arithmetic overflow and underflow.

 

It should work as advertised.  If the pressure stays the same, then the computed LED period stays the same.  Time, however, marches on.  With each pressure sample (though identical to the last), the delta between the current time and the time the LED was last toggled still increases.  When that delta exceeds the computed half-period, you toggle the LED and store the new last-toggled time.

 

EDIT:  typo

If you want the sensor range of 0-16,383 to translate to 1 to 10 Hz, then yes you want the 16,383 to translate to 50 ms for a full-period of 100 ms, but dividing by 327 won't get you that.  Or rather, it will for the max sensor value, but for lower sensor values the half-period will be shorter, meaning the frequency will be higher than 10 Hz, the opposite of what you're after.

 

A sensor value of 16,383 maps to an LED frequency of 10 Hz, which is a half-period of 50 ms.

A sensor value of 0 maps to an LED frequency of 1 Hz, which is a half-period of 500 ms.

 

Maybe the simplest approach is to just do a simple linear transformation:

int32_t map(
    const int32_t x,
    const int32_t in_min,
    const int32_t in_max,
    const int32_t out_min,
    const int32_t out_max)
{
  return (x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min;
}

Then you call it something like:

    half_period = map(pressure, 0, 16383, 500, 50);

 

I've tested my suggested approach in #2 and #4 with an LED and a pot as a substitute sensor, and it works as expected.  With a 500 ms period it's a little hard to throw the pot from one end to the other at the right time to see the LED half-period foreshortened, but if I change the range to 0.1 Hz - 10 Hz (5000 ms - 50 ms), then it's a little more obvious.

 

Note that the map() function returns a signed integer, and it's arguments are signed as well (this is necessary to handle negative-slope linear transformations such as yours).  Either assign it to an unsigned variable, or cast it to an unsigned type before using it in the comparison expression in the if().

 

You might want to prototype something like that for yourself and see how interactive it is (hint - it isn't). Study after study shows that once the delay between the 'action' and the 'reaction' exceeds 100ms then the system is seen as unresponsive, and systems that require interactive adjustments become unusable.

The blinky thread goes something like this:

if(time has passed toggle_time) {
    toggle();
    toggle_time+=half_period; 
}

The sensor thread updates half_period.

If the blinky thread is actually an ISR,

toggle_time is an IO register and the if can be omitted.

The speed at which the senser thread can

update half_period does not matter much.

Short answer, yes:

while (1)
{
    typeof(tick) tick_local;
    ATOMIC_BLOCK(RESTORE_STATE)
    {
        tick_local = tick;
    }
    if (tick_local <= 15000)
    {
        //do something
    }
    else
    {
        break;
    }
}

 

Long answer, if you can otherwise guarantee that tick will not be accessed by the other thread, no.  The use of ATOMIC_BLOCK() is a conventional way to make that guarantee.

 

For your example of <= 15000, imagine that tick currently has a value of 14847.  That's a hexadecimal value of 0x39FF.  Now your code begins to evaluate the conditional expression (tick <= 15000) by reading the 16-bit tick.  It does so by first reading the low byte into a register, and that's 0xFF.  Now the timer interrupt breaks in and increments the 16-bit value by one, leaving it as 0x3A00 and then returning to the point of interruption.  That point is where your code left off, and the next thing it does is read the high byte of tick, which is now 0x3A.  The combined read value of tick is 0x3AFF, or 15103 decimal.  That is not <= 15000, so the while() loop exits prematurely, since the actual time is 14848.  In effect, the loop was exited 152 ms early.  Whether or not this is a problem for your code, only you can answer.  It may not cause a problem locally, but the 152 ms offset could have a knock-on effect to later code.  Again, only you can answer that.
 

Good catch.  I hadn't looked carefully enough at the code to see that the ADC was being handled via interrupt.

 

The code in #21 is just a test with a pot standing in for the I2C pressure sensor, but it bears mentioning in case the real app code suffers from a similar issue.

 

In my own test code I simply polled ADSC and fetched ADC in the main thread.