I am trying to set a flag to trigger a software interrupt by using the statement PCIFR |= (1<<PCIF0); unsuccessfully. Datasheet says "PCIF0 becomes set (one)" when an interrupt is triggered. It appears that I cannot do this in code. It may have to do with attempting to set a flag connected with a pin that has been defined as an input. Datasheet indicates PCIF0 is R/W, however.

My ISR function works properly when a button on PCINT0 is pressed and released. But the software attempt does not work.

In a related question/observation, the Atmel Studio 7 debug IO Window View shows the PCIFR bits as all clear (zero) even when the button triggered interrupt functions properly (while single stepping). I would have thought the bit would light up (red) on the screen indicating the change. Occasionally (1 out of 5 interrupts or so), it will go red indicating a One in the value. And I think that means flag was set but I've also seen the opposite.

The attached file demonstrates my program/problem. This code distills the problem to the minimum of code to demonstrate the issue.

Hope I did this right. Thanks a bunch to the contributors to this forum. It has been very helpful in my quest to learn.

No, you cannot do that in code. Writing a 1 to most AVR interrupt flags is how you reset or clear that flag.

The usual strategy is to use a separate pin connected to the interrupt input to pull the interrupt low and create the interrupt by means of hardware. Its a little tricky - you have to switch that pin between INPUT and OUTPUT with the associated PORT bit low. That will do it.

Obviously an external change of an input pin will trigger the interrupt.
But writing a change to an output pin will also trigger.
So you can effectively create a SWI (software interrupt)
.
Normally you want to clear an interrupt flag. But for simulation or software testing, creating an interrupt can let you test the ISR().
.
David.

The others have explained how to do it, but the question is - why do you want to do it? Interrupts are a double edged sword, so you want to use them wisely. Detecting external switch changes using interrupts is really not the best or most reliable method. Interrupts are good if you want microsecond level response. Real switches are in the order of 10's of milliseconds. Most applications need a time tick for timing, so a timer set up to interrupt at a regular rate, say 10ms, can be used for timing and to poll and debounce switch inputs.
Creating a software interrupt to do crude task switching is also not a really good idea. If you want pre-emptable tasks, use something like freertos. If you want something simple, look in the tutorials section for my tut on multi-tasking.

I did this and it works. Attached is the demo code that uses PB3 to drive the hardware interrupt from software. As Jim said flipping PB3 between input and output took me a little while to figure out. Plus resistors are necessary to prevent PB3's output current from overwhelming the input pin (PB0).

The others have explained how to do it, but the question is - why do you want to do it? .... If you want pre-emptable tasks, use something like freertos. If you want something simple, look in the tutorials section for my tut on multi-tasking.

The Why I am doing this is for sake of the batteries and sleep interrupt. My story: The sample code I provided is a part of a larger program that remotely monitors a nightly rental property on the Oregon coast that is managed by others. The device is an EEPROM/RTC/MCU combo. Door openings and closings are logged for validation of income statements. I manage the bounce issue by using a delay & confirm technique, admittedly also crude. The device is in a closet with no power, so I've elected to use batteries and the device only wakes and records on opening & closing the door.

Thanks Kartman for the response. And thanks for all your other responses as well. I've been reading the material from David Prentice, you, and Jim Wagner for years and learning much. It has taken me a while to learn enough to understand the content... a work in progress.

The Why I am doing this is for sake of the batteries and sleep interrupt. My story: The sample code I provided is a part of a larger program that remotely monitors a nightly rental property on the Oregon coast that is managed by others. The device is an EEPROM/RTC/MCU combo. Door openings and closings are logged for validation of income statements. I manage the bounce issue by using a delay & confirm technique, admittedly also crude. The device is in a closet with no power, so I've elected to use batteries and the device only wakes and records on opening & closing the door.

Waking from sleep is a very valid reason to use pin interrupts.

But what does that have to do with forcing a software interrupt? I have scores of production apps with pin interrupts (pin change and/or "external interrupts") and cannot remember ever having code to force "software interrupt".

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Excellent input. Forced now to think of a better way, I'm going to try to write a subroutine that will pickup on the condition I was trying use to trigger a software interrupt. Only this will rearrange my flowchart and involve some code rewrite that was probably needed anyway. But it is a simpler solution than the hardware/software driven solution needing a second-pin interrupt (that I now have working!) Well, that is the price of learning and probably to your point.

Thanks for your input on this and your other numerous posts that I have read for some time. This forum could be renamed "The University" for all it's educational value (and great professors!)

The use of the interrupt to wake is valid, however, you should poll the input a number of times after wakeup to filter out transients and to debounce as well. How long does it take to open/close the door? Any detection substantially less than this is most likely a transient.

Thanks for the ref to the multi-tasking tutorial. I found it. Well laid out description of how to make single threaded processing act in a multi-tasking fashion. I have marked this for referral should I get a project as complicated as presented. I also found the compendium of all tutorials on this forum. What a treasure.

Spent some looking an Freertos and couldn't get my head around it although I get the sense that it is an abstraction to the nuts-and-bolts that I'm playing with now. But with the help of your comments and others I am off running and rewriting my program entirely avoiding the software interrupt that kicked off this thread.

But what does that have to do with forcing a software interrupt? I have scores of production apps with pin interrupts (pin change and/or "external interrupts") and cannot remember ever having code to force "software interrupt".

I've often read about this ability of AVR to do a "software interrupt" using a pin but for the life of me I can think of no practical reason why it would ever be required. At the point you would invoke the software interrupt why do you not simply just call the target code synchronously anyway? A CALL direct is going to be a lot fewer cycles than an interrupt vector to get to the same place ?!? So in what circumstance would you ever need it?

And yes I am aware of other micros with SWIs that, for example, use that as an entry point to "OS services" but usually that is done for one of two reasons: (1) it's a more concise and possibly faster OS entry mechanism and (2) often it goes through some kind of "mode switch" - perhaps switching a bank of "user registers" to "OS registers" so a very quick switch of context to OS operation can be made

The AVR offers no such advantages. So why would it ever be desirable to use this mechanism? There has to be something I've been missing all these years!

Yes, agreed and thank you. I have rewritten the code to call the target code as you and theusch have indicated. My reason for attempting the SWI was to maintain a parallel treatment of several variables. But even that logic was a bit twisted and has resulted in the rewrite.

Question about the "Mark Solution" button: Is this something the moderators determine, or do I? And may I select buttons for multiple responses as everybody lead me to my solution? The forum user guide didn't speak to this.

A (stupid to my mind) design decision by the author of this site's software means that Moderators don't get to see [Mark as Solution] so the only person who can ever do it (and most don't which is why moderators should have been allowed to!) is the author of the thread in the first place. So as you look at the thread you need to make an informed choice as to which of all the posts (which can include your own) comes closest to being the solution then you click [Mark as solution] on the one you choose. You only get to pick one.

The very fact that I had to explain that perhaps illustrates why the current system is "sub optimal".

Funny, when I mentioned the 'parallel treatment of variables' it was my way of short-cutting an entire three paragraphs of babble I wrote that I replaced with that phrase to spare all who might read it. But to briefly explain: Originally, I had a logical flow that had been changed, and changed again, and eventually became tangled and tripped on itself. But I finally reached a conclusion that Wagner, ,theusch, Prentice, Kartman, and yourself were leading me in the direction of abandoning my flawed-and-devolved logic and accepting that I was attempting the impossible! Better for me to learn than fall on my sword while... tripping. I'm an enthusiast-hobbyist on the uptake. So I thank you again.

Fantastic help on the sub-optimal 'Mark as Solution' button. I agree with you. Allowing the knowledge-seeking perpetrator to issue judgement is probably not the wise thing to do. Therefore I will 'Mark as Solution' in the fashion of my next post. However, in appreciation of the forum architect there are probably other factors that I have not imagined.