ISRs

Go To Last Post
63 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi freaks, I'm intending to use interrupts in my code, quite often triggering ISRs i.e every 25us, and every 10ms( the main program will be interrupted quite often).

To the point: I have done some research on the use of the "volatile", and atomic block/force on/restore state. And that protection is needed during "set and test",

shared variables and more than 8-bit data.

1. For "set and test", must we always install the atomicity for data that is not shared in ISR (data is 8bit only)?

2. Assuming the run-time of the "atomic block(force_ON){}" is more than 10ms, say 100ms, will the atomic block at one point allow servicing of the 10ms ISR?

   N//B it is mandatory/safe the 10ms and the 25us ISRs to be serviced to achieve the intended purpose.

3. A single line in c is always/mostly divisible when viewed in assembly scope. Assuming the single is not shared in ISR in any way, is it safe to ignore atomicity.

4. Do we need a "volatile" on a const data type that is only used in ISR?

 

Short and precise responses, please!

 

Crazy generation

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

The basic issue of atomicity is like two kids trying to share the same toy. It depends on who gets it, when. 

 

1. unless data is shared with the isr, no protection is necessary.

2. the general idea is that you do not disable interrupts for longer than is necessary - in your case where you have strict timing requirements, less is better.

3. if the isr doesn't share the same variable, then there is not an issue

4. no

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you. Precisely answered!
But now I have to face how to work with this timing.

Crazy generation

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What are you doing that needs a 25us interrupt?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Phase angle control of AC, after every 10ms trigger, I keep udating on delay time in steps of 25us

Crazy generation

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Also, keep in mind that at 25us, jitters & latency effects will be more pronounced, on a relative basis.  This may or may not matter, depending upon your needs.  Is this an important consideration for you?

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Never mind.  Bad math.  S.

Last Edited: Mon. Mar 23, 2020 - 08:32 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Derick22 wrote:
Phase angle control of AC, after every 10ms trigger, I keep udating on delay time in steps of 25us

 

Isn't that what you use a hardware timer for? Set the delay time you want and deal with it when the attached ISR fires.

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

Last Edited: Mon. Mar 23, 2020 - 08:31 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Derick22 wrote:

2. Assuming the run-time of the "atomic block(force_ON){}" is more than 10ms, say 100ms, will the atomic block at one point allow servicing of the 10ms ISR?

   N//B it is mandatory/safe the 10ms and the 25us ISRs to be serviced to achieve the intended purpose.

The idea isn't that you do:

while(1) {
    ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {
        local_copy = read_wide_variable;
        do_very_long_work(local_copy);
    }
}

but:

while(1) {
    ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {
        local_copy = read_wide_variable;
    }
    do_very_long_work(local_copy);
}

so the bit where you disable interrupts and "block" the entire system from running is only for the few opcodes involved in "read_wide_variable" and only lasts a microsecond or two, if even that. Do not put do_very_long_work() inside the blocked section

Last Edited: Mon. Mar 23, 2020 - 08:44 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's how I did it many years ago. I used 4us resolution. The zero cross went into the capture pin and used one compare channel to sequence through 4 channels of phase control dimming. Chews up a lot of cpu though.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

it is as it determines the resolution of AC power control. I was worried from the start of this 20us ISR, maybe I slightly adjust it to 100us or 300us.(what do u think can be safe)

NB: the main program will do several things including ADC sensing, some PID, etc

Is there an alternative approach - I mean for phase control.

Crazy generation

Last Edited: Mon. Mar 23, 2020 - 09:54 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I noted this after being assured of my other worries at the beginning. Thank you still.

Crazy generation

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This sounds great but I noted that some us needed to be delayed (around 200-600us depending on the situation) for the triggered pulse. This approach will force me to introduce the _delay(..us);  the ISR before turning OFF the triggered pin. delays are discouraged in ISRs.

Crazy generation

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

No "real" software uses _delay*() functions. If you want something timed use a timer. Do not (in time critical code) hold inside software delay loops and DEFINITELY never delay inside an ISR !

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

what was the speed of your CPU?

Crazy generation

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

true, my code is "real" as we speak, but time resource demanding. im worried on behaviour of the 20us ISR.

Crazy generation

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I haven't seen anything in this thread that says which AVr or how fast it is going but let's assume a "fast" AVR running at 20MHz so the cycle time is 50ns. So you have 400 cycles between each 20us interrupt. What are you doing that requires more than 400 cycles?

 

Of course my assumption here is 20MHz. If it's really 1MHz then you have 1/20th of the cycles - so just 20 cycles per interrupt. That is not even enough to get into/out of an ISR.

 

So if you really need such a fast interrupt rate you want to be sure you are running the AVR as fast as it can possibly go.

 

I do wonder if whatever it is you need to do has to be done by an interrupt though? AVRs have many hardware facilities that can take the workload off the CPU.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

8MHz. It was working pretty hard. Fade calcs were 24bit. I used a enc28j60 ethernet chip as it used spi and wasn't worried about timing - I couldn't use the usart at any reasonable speed as the overhead for managing the phase control could chew a chunk of cpu time every zero crossing.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

At 8MHz the cycle time is 125ns. In 20us you have 160 cycles between interrupts. That's probably "do-able" as long as you don't do anything "compute heavy" in the ISR. But there may not be a lot of time left over for doing anything else.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Noted, I plan to work with mega328 at internal 8Mhz.

For this application, the 20us interrupt appears mandatory though I want to adjust the delay to 100us instead. will this suffice?

I predict danger but whatever comes, I have a DHT22 sensor, sure this will be compromised.

Crazy generation

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And by the way, I plan to pull down the INT0 with a 2k2 resistor. I hope this will be okay and the 104Cap is not needed.

I tried the DDR&=~(1<<INT0pin), PORTD|=(1<<INT0pin), I mean internal pull-up but the simulation did not work.

Crazy generation

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What relevance does int0, a pulldown resistor and a 104Cap have? You need to give us some context.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

what do you need to do with 50kHz ?

 

As people here know I would do this in ASM, and there you can make 16 bit variables in registers Atomic by using movw instructions (my guess is that you only have 1 or 2 (16 bit) variables from the fast ISR ) 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 to prevent false triggering of the 10ms ISR generated from mains

Crazy generation

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why int0? Using the input capture feature give more precise timing. You need to filter the zero crossing signal. I do further filtering in software and use a phase locked loop technique to recover the ZX.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do you mean INT0 will not work? what should be done to make it work? will the 104 cap filter?

I'm not conversant with the input capture feature. If the hardware is filtering why complicate the software, its already a burden.

Crazy generation

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

what do you need to do with 50kHz ?

 

They don't. They seem determined to do this the hard way. Atmel gave us 8- and 16-bit hardware timers so that we don't have to mess around with pointlessly fast ISRs.

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

We have little idea of your circuit, so it is hard for us to give you a concise answer.
Of course int0 will ‘work’, but by the time the isr has activated and your isr code actually executes, a variable amount of time has passed. The input capture copies the current timer value into the icp register, so you can precisely time from zx.
Why filter in software? Many reasons - mainly a much steeper filter response and the ability to track mains variations. You’d be surprised how much the mains varies cycle to cycle. Then there’s transients andmains signaling that can upset things as well.

As i said earlier, i have done four phase control outputs using one timer. One output is even easier.

I’d also suggest using a bme280 sensor - it uses i2c so it doesn’t require precise timing. It is also far superior to the dht11.

Last Edited: Mon. Mar 23, 2020 - 01:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Derick22 wrote:
2. Assuming the run-time of the "atomic block(force_ON){}" is more than 10ms, say 100ms, will the atomic block at one point allow servicing of the 10ms ISR?
No.  Preventing interrupts is the whole point of ATOMIC_BLOCK.

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

nice ideal precision of the input capture sounds great but another whole chapter for me. will try to look into that.

but let me focus on int0 for now. I'm going to try with hardware filter, this will offload the CPU and because also don't have the filter SW.

will also look into the bme280 sensor.

Thanks for this idea.

 

Crazy generation

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm not sure if this is relevant here (I still feel lack of info).

But I have a project that decode a 433MHz receiver. I don't have time to decode on the fly, so when it goes low first time (start) then the timer ISR record the next 600 samples, it set a flag when done, and then the main slowly can decode.  

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I forgot this, do we need 'volatile' on a variable used only within one ISR, the value is declared globally. I thought of declaring it within the ISR but not sure about the behavior of such.

 

Btw, I have tested the INTO and it is working perfect so far.

Crazy generation

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If a variable is used only within an ISR, why would it be  declared globally ?!

 

If you want it to retain state, make it local & static.

 

EDIT

 

 I thought of declaring it within the ISR but not sure about the behaviour of such

What, exactly, is the uncertainty ?

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Wed. Mar 25, 2020 - 10:16 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Derick22 wrote:
I thought of declaring it within the ISR
Eh??

 

The whole point of volatile (in this context) is where you have something shared between two paths of code. That simply could not happen with something declared/defined inside the ISR itself. That is something like:

int count;

ISR(SOMETHING_vect) {
    static int count;
    
    count++;
}

int main(void) {
    while (1) {
        if (count == 10) {
            // stuff
        }
    }
}

could not work as there are two different "count"s in this. The only way something like this could work is:

volatile int count;

ISR(SOMETHING_vect) {
    count++;
}

int main(void) {
    while (1) {
        if (count == 10) {
            // stuff
        }
    }
}

Now there is one "count". The fact that it is made volatile means that the read/test code in main() won't be tempted to read it just once outside the loop (as it might do for optimisation) but it will be forced to re-read it every time around the loop - which is the whole point of using volatile because it really means "you may not be able to see it but this could change at any time so you can't assume you know the value"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ISR(The NT0_vect)

{

  
    static uint8_t  cycles;   // this type of initialization is uncommon to me, will this work?

   cycles++;       // this is the only time I make use of (process) the variable, nowhere else in the program

     if(cycles>process_cycle)
     {
         
     }

}

Crazy generation

Last Edited: Wed. Mar 25, 2020 - 11:31 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The uncertainty of declaring a variable without initialization, doing something like static int count = 0; inside the ISR will affect the intended purpose.

 

Crazy generation

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

See Tip #1 (in my signature, below) for how to properly post source code:

ISR(The NT0_vect)
{
	static uint8_t  cycles;   // this type of initialization is uncommon to me, will this work?

	cycles++;                // this is the only time is I make use of the variable, nowhere else in the program

	if(cycles>process_cycle)
	{

	}
}

 

That's not an initialisation - that's just a definition.

 

But, because it is static, it will be initialised to zero.

 

This is all perfectly standard 'C' stuff.

 

EDIT

 

See this recent thread on the use & meaning of static in 'C':

 

https://www.avrfreaks.net/forum/life-time-and-scope-static-variable

 

Post #2 there illustrates exactly what you are doing

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Wed. Mar 25, 2020 - 11:32 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Derick22 wrote:
declaring a variable without initialization, doing something like static int count = 0;

But that would be declaring a variable with initialisation ?!

 

Perhaps time to brush-up on your 'C' - here are some 'C' learning & reference resources:

 

http://blog.antronics.co.uk/2011...

 

BTW: note that whitespace costs nothing, but makes your code a whole lot easier to read:

if( cycles > process_cycle )

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Wed. Mar 25, 2020 - 11:37 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Noted and thanks

Crazy generation

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just to be clear. If the variable in question "belongs" to the ISR and nothing outside the ISR will never need to access it then define it within the ISR. If it's something that must persist from one invocation of the ISR to the next then make it "static". But if it is something that is updated in the ISR then read by code outside the ISR (something invoked from main()) then it needs to be defined at the global level and further it must be "volatile".

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You need to read up on the scope of variables in C !

 

And have in mind if speed matter (of the ISR) write the code so you can avoid use volatile variables. (or at least minimise the use)   

 

 

Last Edited: Wed. Mar 25, 2020 - 12:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:
You need to read up on the scope of variables in C !

Indeed. Also the lifetime of variables.

 

It was covered in the above-mentioned thread.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In summary:

uint8_t        global_variable;

static uint8_t file_scope_variable;

void function( void )
{
    uint8_t        local_variable;

    static uint8_t static_local_variable;

}

 

  • global_variable is visible throughout the entire program, and endures for the entire life of the program
  • file_scope_variable is visible only within the containing file, and endures for the entire life of the program
  • static_local_variable is visible only within the containing function, and endures for the entire life of the program
  • local_variable is visible only within the containing function, and endures only for the life of that function

 

All of the above is irrespective of whether interrupts are involved or not.

 

'volatile' needs to be added:

  • to global_variable if it is to be shared between ISR and other code anywhere throughout the entire program
  • to file_scope_variable if it is to be shared between ISR and other code - but only within the same file

 

 'volatile' is not needed with static_local_variable or local_variable - because they cannot be shared.

 

None of this has anything to do with atomicity.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
But if it is something that is updated in the ISR then read by code outside the ISR (something invoked from main()) then it needs to be defined at the global level and further it must be "volatile".
Also, main's accesses (R/W) should be atomic.

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

good illustration, simple and clear.

I removed the volatile, moved the variable inside ISR and made appended the 'static' prefix, it worked.

Crazy generation

Last Edited: Wed. Mar 25, 2020 - 06:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Time for Tip #5, then?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As a matter of optimization, a global variable is affected/operated only in the main program, I mean things like variable++,-- etc. Inside an ISRs only conditional tests are done, I mean things like

if(variable>10){//whatever }, does this variable qualify "volatile" really?

Crazy generation

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Derick22 wrote:
As a matter of optimization, a global variable is affected/operated only in the main program, I mean things like variable++,-- etc. Inside an ISRs only conditional tests are done, I mean things like

if(variable>10){//whatever }

Sorry - I have no idea what you mean by that.

 

 

 does this variable qualify "volatile" really?

The rule is very simple: anything that's shared between two "threads" of execution (eg, main loop & ISR) needs to be volatile.

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wot he said.

 

I illustrated the issue in #34 above with:

volatile int count;

ISR(SOMETHING_vect) {
    count++;
}

int main(void) {
    while (1) {
        if (count == 10) {
            // stuff
        }
    }
}

Let's just suppose that "count" in this were not volatile. Now it's still the case that in:

volatile int count;

ISR(SOMETHING_vect) {
    count++;
}

the code generated is still going to need to go to memory, read the current value, add one to it and write it back. But the problem occurs in this bit:

    while (1) {
        if (count == 10) {
            // stuff
        }
    }

So the compiler could look at this small section of code and choose to implement it as:

    while (1) {
        retrieve_count_from_memory()
        test if count==10, if not skip over this {
            // stuff
        }
    }

and that would work just fine as within the while(1) loop it would keep retrieving (the possibly updated by ISR) copy of count and then doing the test. However the compiler (being efficient) may say to itself "why am I doing a retrieve of "count" every time around this while loop. There's nothing in this loop that can change count so why waste time/speed/size in reading it every time?" so it would effectively implement this as:

    retrieve_count_from_memory()
    while (1) {
        test if count==10, if not skip over this {
            // stuff
        }
    }

recognizing that, because it apparently can't change, it's quite justified in only wasting the code/time to read "count" once then just use a cached copy (in a register) for the test each time round the loop. 

 

If meanwhile, in the ISR 'count' was 9 then the interrupt fires and it becomes 10, then nothing in the while() loop will notice this happening as it's still using the old, out of data copy of count from before the while() loop started.

 

You overcome this by adding "volatile" to the variable to say "could change at any moment (it's "volatile") so don't assume you know the value, re-read it every time".

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

the code in #49 has an other problem and that count is an int and therefor need to be atomic protected!!!

 

In this caset: make count static in the ISR and do the check there, and set a flag (volatile global 8 bit) that main should check.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

They (who?) could have probably picked a more descriptive naming standard....instead of calling it volatile, they could have called it must_access.  That would reduce  the uncertainly.  I wonder who actually chose it?

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Pages