Fast PWM with Arduino, the inputs outputs don't work

[ypatidisioannis]

Hello to the community!

I am using ATTINY85 and I am programming it through the AVRISP using an Arduino UNO.

This is the code I am using :

include <avr/io.h> #include <avr/interrupt.h>

void setup() {

PORTB = 0; //Reset values on port B

// After setting up the timer counter, // set the direction of the ports to output DDRB |= (1<<PB1) | (1<<PB0) | (1<<PB3); // Set the direction of PB1 to an output

// PLLCSR - PLL control and status register: // PLL is a clock multiplier - multiplies system 8 MHz by 8 to 64 MHz // PLL is enabled when:PLLE bit is enabled, // CKSEL fuse is programmed to 0001. This clock is // switched off in sleep modes! PLLCSR |= (1<<PLLE); // PLL enable

// Wait until the PLOCK bit is enabled // before allowing the PCK to be enabled //WaitForPLOCK(); //unsigned int i = 0;

while ((PLLCSR & (1<<PLOCK)) == 0x00) { // Do nothing until plock bit is set }

PLLCSR |= (1<<PCKE); // Enable asynchronous mode, sets PWM clock source

TCCR1 = (1<<CTC1) | // Enable PWM (1<<PWM1A) | // Set source to pck (0<<(CS13)) | (0<<(CS12)) | (1<<(CS11)) | (1<<(CS10)) | // Clear the pin when match with ocr1x (1<<COM1A1); GTCCR = (1<<PWM1B) | (1<<COM1B1);

// Set PWM TOP value - counter will count and reset // after reaching this value // OCR1C // 100 kHz 159 // 80 kHz 199

OCR1C = 199;

// Enable Timer1 OVF interrupt TIMSK = (1<<OCIE1A) | (1<<TOIE1);

sei();

OCR1A = 190; //chaning th FR }

void loop() { PORTB |= (1 << PB3); delay(500); PORTB &= ~(1 << PB3); delay(500); }

the problem is that when I use the PWM my rest of the outputs do not work . Any idea why is this happening?

[SpenceKonde]

Uhm..... I do not see a Timer1 OVF ISR anywhere there? Yet you have that interrupt enabled. Without an ISR supplied, when it hits the timer1 overflow, it will jump to BADISR which jumps to the reset vector.... without executing reti (hey don't look at me, that's how avr-gcc handles it - there isn't really any better way available since there is no error reporting facility anyway - one could make it slightly less grotesquely broken, but "completely broken" behavior is IMO the only correct result of code that is triggering an interrupt for which no ISR is provided (most likely either it was enabled on accident, or the ISR name misspelled in your case - I'm not sure what you were hoping would happen when you enabled an interrupt but didn't provide said interrupt...) it then proceeds to execute the sketch until hitting an sei(), at which point interrupts will be reenabled, and the (still set) overflow flag triggers the bad ISR again.

And in this case you would get your PWM output, since timer1 doesn't depend CPU state, and execution doesn't survive after each reset far enough into the program where the timer1 config routines would disrupt it.

Also, we're in Arduino Land, the init() function called before setup() has already enabled interrupts when setup() is called (which you know because millis() and delay() work in setup, and they both depend on interrupts being enabled). If this wasn't done, I would expect the PWM waveform to be wrong too

[SpenceKonde]

Oh, and even with an ISR provided. you rely on the millis()/delay() timekeeping, but this line breaks millis (and delay - they use same timekeeping mechanics - delay() is actually just a busy-wait loop that checks micros() continually, and every 1000 uS that pass, it decrements the delay counter) ;

TIMSK = (1<<OCIE1A) | (1<<TOIE1);

disables the millis timer interrupt, which is controlled by the TOIE0 bit of TIMSK.

Note that if you tell the core to disable millis, it pulls in a different definition of delay() (based on cycle counting, not that this will help if you're calling a non-existent ISR

But if you tell it to manage millis, all bets are off if you remove millis out from under it..

[SpenceKonde]

To clarify above

If this wasn't done, I would expect the PWM waveform to be wrong too

If there wasn;t an init() function that enables interuprts before setup is called I would expect the PWM waveform to be wrong due to timer1 getting reconfigured before the first time the timer0 overflows triggering the crash outlined above.

All issues can be explained by bugs in user code. Closing as no response from originator and problems appear to be in user code.