Pin Change Interrrupt restarting attiny85

Ok, sorry for my imprecise wording, but I also did not understand from what you wrote first that you meant I had written an incorrect ISR vector.

I changed PCINT1_vect to PCINT0_vect and now it is doing what it is supposed to do.

Ugh... So much time over a single digit.

Thanks to everyone who helped, but particularly @6v6gt and @GolamMostafa.

Why have you changed PCINT1 to PCINT0 -- because doing so makes your program to wrok? Who has told you to do that?

I think you cannot disable BOD by codes; you have to chacek the fuse bits and chnage the fuse bits as needed to disable BOD.

To avoid possble hassle, it is recommended to start the TC1 afetr all intializations.

OCR1C = 194;
TIMSK |= (1<<TOIE1); // Enable OCRA interrupt on Timer 1 TOIE1  OCIE1A
TCCR1 |= (1<<PWM1A);
TCCR1 |=(1<<CS13);

Well, I didn't quite understand what you meant by

So, I went back to the datasheet and looked at the interrupt vectors again (page 48). There is only one interrupt vector for pin change interrupts, and that is PCINT0_vect. Apparently that handles all pin change interrupts. I had gotten confused because the datasheet doesn't say there that PCINT0_vect handles all pin change interrupt, and the next paragraph talks about enabling PCINT[5:0], so I had thought that the vector name would be the same as the bit to enable it.

I did a quick google search to confirm this and found this website that said the same thing. This was the relevant sentence, " A pin change interrupt on the ATtiny85 will look for a logical change on a PCINT pin (PCINT0-PCINT5), and if it finds one will set the pin change interrupt flag and call the PCINT0 interrupt vector."

Once I read that, I thought that must be what you were trying to tell me. I made the quick change and it worked. I'm still using PCINT1, but now it is actually calling a vector that it recognizes.

You're right. I just reread that section and this only disables it during sleep. It is disabled when burning the bootloader already. I was basically grasping at straws here.

Good tip. Thanks.

Anyway, it is a very interesting project any may have applications in wild life photography or maybe even sport. Please do a write up or publish a link to it here when it is complete. I'm sure it will be of more general interest.
You'll probably still have some work to do if these devices are to be battery operated. You can add a pin change interrupt simply to wake the (receiver) device from sleep mode but the remaining logic can stay more or less the same. You may also want to get rid of the blocking during the camera shutter activity.

So, the data sheet has told you to chnage PCINT1 to PCINT0.

Yes

There are six pinChangeInterrupts viz., PCINT0 - PCINT5. For any interrupt, the MCU is always vectored to an address which could have this logical name: PCINT. For some reasons, the name is given PCINT0. In the ISR(), polling is made to determine the source of interrupt.

How have you determined that OCR1C = 194 will produce produce 40Hz PWM signal? Do you know the equation of the wave? Is it single or double slope operation?

It is in fast PWM mode, which is a single slope operation. The formula, which is on p. 87 of the data sheet like I noted in my comment, is

EDIT: Ok, to be fair, Microsoft Copilot probably wrote the original version of the comment for the emitter code. Maybe I don't sound too much like a robot, but I do plan on noting the rest of the needed page numbers in the comments to help me retrace my steps if needed.

fpwm = ftck / (OCR1C + 1)

But since the timer clock is the system clock divided by the prescaler

ftck = fck / PSR

then

fpwm = fck /(PSR * (OCR1C + 1))

Solving first for PSR and putting in the max OCR1C

PSR = fck / (fpwm * 256)
PSR = 1000000 / (40 * 256) = 97.7

Since that's between 64 and 128, I set the prescaler to 128 and solved for OCR1C

OCR1C = fck / (fpwm * PSR) - 1
OCR1C = 1000000 / (40 * 128) - 1 = 194.3

I may be new to microcontrollers, but I do understand algebra :smile:

Thanks for helping me sift through my code @GolamMostafa, and you're welcome to continue to if you want to, but I'm considering this issue resolved and moving on to think about power consumption as @6v6gt mentioned. I've got some research to do before I can know what questions to ask there, so I'll likely drop off monitoring this thread.

Thank you very much for replying elegantly to all my questions and wish your good journey in the field of Microcontroller Architecture and Programming.

After a few more snags, I have things up and running. I ended up switching from Timer1 to the watchdog timer so I could enter shutdown mode while it's not having to do anything.

Here's a link to a fuller description with everything incorporated in case anyone is interested to see how this turned out.