Why use a flag, when you can just use an ATTINY

[kolbep]

Was having a discussion with somebody today,
he is into hobby electronics, and is designing his own Arduino Based GSM Controller (with a Sim module).
He is just waiting for his boards to come from China, then he will solder it together, and try it out.

One thing he said is that he has a problem, if the Arduino is receiving information (communicating) with the GSM module, and somebody triggers one of the inputs, that it does not do anything to process that trigger.

He has not used interrupts before, so I told him that an Interrupt is one way to do it,
another way is that while it is receiving / processing data from the GSM Module, he must have a line in that processing loop, that checks if a trigger input was activated, and set a flag. Then once it has finished dealing with the GSM Comms, it can act on that flag (if it is set).

He then told me about his solution that he implemented. He 'just' put an ATTINY there to monitor the trigger inputs, and then pass it on to the ATMEGA 328.......  So Basically using the ATTINY as a flag variable!

Oh Well, Could have saved himself a few rand on each unit.....

[zapta]

He should learn how to represent his tasks using state machines and polling. A loop that reads an entire line is bad since it holds the CPU.

[dannyf]

Generally it is a good idea to use interrupts for that kind of tasks.

However, it is up to the programmers to implement something he is comfortable with
.

Having said that, the arduino crowd is generally more interrupt averse.

[bitseeker]

ATTiny = trigger co-processor 

[wraper]

You should call him ignorant money burner. Instead of learning a thing he throws the money on the non existing problem.

[zapta]

You should call him ignorant money burner. Instead of learning a thing he throws the money on the non existing problem.

Still much better than this one https://www.eevblog.com/forum/projects/nand-only-freq-counter/

[obiwanjacobi]

That is the spirit of today: use an ARM processor that runs linux (RaspberyPI) to read a humidity sensor...   

But then again: you cannot fault anyone for not knowing something.

He should try make a V2 and fix his mistake. Then he will actually learn something.

[zapta]

He learned using an ATTYNY as a peripheral.

[Kalvin]

Co-opreative, run to completion tasker implementing state machines. Pretty simple and runs very nicely inside Arduino's small Flash and RAM. Easy to debug too as only one "thread" is running at a time.

[tszaboo]

Once I had to capture some microsecond long trigger inputs with an Atmega328. We were only making 5 from this board, I decided to write everything with arduino. I was also an ignorant bum, setting up registers, looking at datasheet, that is no fun.
So what I did: I put an RS Flip flop, to capture that trigger, and wasted 3 free GPIO pins, instead of one, and it was like a single EURO cost increase for the company.

[Kalvin]

Capturing the input can be done using polling (in a task implemented as a state machine) or using an interrupt which sets a flag-variable when the input pin changes state to "button pressed". 

[dannyf]

fix his mistake

assuming it is a mistake - which i'm not convinced.

[tszaboo]

Capturing the input can be done using polling (in a task implemented as a state machine) or using an interrupt which sets a flag-variable when the input pin changes state to "button pressed".

polling: trigger too fast
interrupt: boooring!

[nuno]

Interrupts are actually not that simple to use for button reading; less problems polling them. Switch bounce can give you interrupt bursts - this is fixable, but by the time you have it fixed, polling would be simpler and easier and have a "deterministic behavior" (including not potentially interfering with other functionality running on the same program).

There are other situations where polling is a winner compared to interrupts, usually because of the "interrupt burst" problem.

[zapta]

Interrupts are actually not that simple to use for button reading; less problems polling them. Switch bounce can give you interrupt bursts - this is fixable, but by the time you have it fixed, polling would be simpler and easier and have a "deterministic behavior" (including not potentially interfering with other functionality running on the same program).

There are other situations where polling is a winner compared to interrupts, usually because of the "interrupt burst" problem.

Yet another example where simple is good.

[dannyf]

"because of the "interrupt burst" problem."

For most mcus, that's minor - I think I did a calculation a short while ago and at 1mips that's less than 10 percent of processing power.

Pls, RC denounce in my view should always be there.

[Xenoamor]

You can always make a sample hold analogue circuit.

I'm surprised he knows how to figure out interUC communication and control and not interrupts though

On a more interesting note though is it possible to have a pin trigger the port interrupt flag setting the interrupt bit BUT not actually trigger an interrupt from it? You could then check the port register for the interrupt bit later and clear it

[dannyf]

"You can always make a sample hold analogue circuit.

I'm surprised he knows how to figure out interUC communication and control and not interrupts though"

That's what he seems to be doing. Otherwise, he will have to use the attiny to I terrupt the arduino, which misses the point.

[dannyf]

"BUT not actually trigger an interrupt from i"

Yes. Just don't enable the IOC interrupt. The IOC flag serves as the flag for the pin change event, kind of a software flip flop.

Btw, a timer can be configured as an external interrupt or a pcint pin.

[Xenoamor]

"BUT not actually trigger an interrupt from i"

Yes. Just don't enable the IOC interrupt. The IOC flag serves as the flag for the pin change event, kind of a software flip flop.

Awesome thanks. I've always just hopped into the interrupt, set a flag and buggered off. I can see this being useful for time critical stuff though as there's no interrupt priority options

[KL27x]

Capturing the input can be done using polling (in a task implemented as a state machine) or using an interrupt which sets a flag-variable when the input pin changes state to "button pressed". 

The problem here is he is using some GPS code that is using interrupt. And he may have downloaded it from somewhere without actually wanting to dig in and modify it.

You would have to begin to understand it in order to add any additional interrupt handling that would definitely not interfere with anything timing sensitive. At least figure out how to make his interrupt lower priority. Not that checking a button state takes much time unless u screw up.

Of course if his Atmega has pins with IOC flags, he wouldn't even need to do that.

If he can redesign a pcb faster than to learn and write any of this new code.... that doesn't mean he is doing it wrong. He could be really great at designing pcbs, lol.


Or maybe he wrote all his GPS code, himself. And it is so borked and complicated that it is easier for him to leave it alone and work around it!!!

I'm surprised he knows how to figure out interUC communication and control and not interrupts though

Why not? It could be as simple in this case as one pin logic level read and a second line for reset signal. Or even just a read... he could be using the attiny as an array of one shot monostable multivibrators which hold the pin state for greater than the duration of the GPS interrupt.

Or... maybe he just used a preexisting arduino routine for I2C?

Interrupts are actually not that simple to use for button reading; less problems polling them. Switch bounce can give you interrupt bursts - this is fixable, but by the time you have it fixed, polling would be simpler and easier and have a "deterministic behavior" (including not potentially interfering with other functionality running on the same program).

There's a right place and time for everything. I recall an example of a faulty remote doorbell used to illustrate this I/O interrupt "problem." Faulty circuit caused the interrupt to retrigger, making the doorbell restart itself, indefinitely, not even finishing the first note of the song. In a case like this, interrupt was probably used to conserve battery power - to wake the ucontroller from sleep state. And the easy solution (for this "problem" would be for the ISR to turn itself off when it is serviced. And for the main program loop to turn it back on.... after the music/chime was over! Of course this doesn't fix the faulty circuit. So now you get to listen to the whole song over and over. So I dunno why this was ever used as an example in the first place.

Sometimes, interrupts are going to be a precious commodity for doing things that are wayyy faster and timing sensitive than human input. Sometimes ucontrollers are used to detect a doorbell being pressed.

To a lot of us, the button press problem is trivial. And if someone were making 1 million of these things, our knowledge would be valuable. If only these kind of situations were more common. LOL

[nuno]

A button press is not that trivial as an unexperienced person may think the 1st time . It can be debounced in hw, but why add hw when you can do it all in sw? I can think of only the case of very low power or "critical" systems (avoid abrupt transitions on the hw, filtering the input from spikes... but in this case I still think sw deboucing, as add on, is useful as the denouncing timings can be easily adjusted / optimized).
Another similar source of interrupt bursts are comparator outputs (many uC have hw filtering to help with this, but each application has its own requirements).

Other cases are not that trivial as a button press, such as KL27x's doorbell example. Sometimes the problem is such that the CPU spends too much time servicing (continuous) interrupt bursts. I remember a problem on a system running an embedded realtime linux controlling optical network traffic, with an ASIC raising interrupts for a bunch of events. The system would become unresponsive when the QA guys attenuated the signal to that point where the poor ASIC spent its time changing its decision - signal is ok! no it's not! signal ok! no it's not! and so own (you get the picture). I fixed this one with the "disable interrupt, re-enable sometime later" technique, I couldn't go with polling due to signal loss maximum reaction time requirements.

[dannyf]

the CPU spends too much time servicing (continuous) interrupt bursts.

How much is too much?

[dannyf]

is it possible to have a pin trigger the port interrupt flag setting the interrupt bit BUT not actually trigger an interrupt from it?

Here is an example, on a 12f675 but practically identical principle for any other mcu.

Code: [Select]

mcu_init();     //initialize the mcu
IO_IN(IN_DDR, IN); //in pin as input
IO_SET(WPU, IN); nGPPU = 1; //in with weak pull-up
IN_PORT; GPIF = 0; //clear gpif
GPIE = 0; IO_SET(IOC, IN); //enable ioc on IN, no interrupt enabled, however.
IO_OUT(OUT_DDR, OUT); //out pin as output

while (1) {
if (GPIF) { //ioc has taken place
IN_PORT; GPIF = 0; //clear the flag
IO_FLP(OUT_PORT, OUT); //flip output
}
delay_ms(100); //waste some time
}

It sets up IN pin on IN_PORT to enable IOC (interrupt on change) but have the actual interrupt disabled (by clearing GPIE). So there would not be any interrupt when a change of state occurs on the IN pin.

In the loop, instead, we poll GPIF to see if a change of state has taken place. If it has, we clear the flag, and then flip a pin.

The delay simulates other tasks that you may have in the main loop.

If this scheme works, we should expect we should expect a state change to be remembered by the GPIF flag, even if the mcu is busy doing something; once the mcu frees up (in this case, from the delay_ms() routine), it will process the GPIF flag.

Here is the simulation, showing exactly the kind of behaviors described above.

[dannyf]

the basic principle (that a flag will be set even if the corresponding interrupt is disabled) works for other peripherals: for example, the timer flag will be set if the timer overflows, even if the timer interrupt is disabled.

This can make some interesting applications.

For example, the arduino guy discussed earlier can totally utilize the PCINT or EINT to "remember" the change of state without enabling the respective interrupts, saving him some money with the attiny.