Attiny3216 ; TimerA "Example 1: 16-bit PWM in single mode, dual slope with interrupt" seems not to work in my case ...

[trimarco232]

Hi All,
I have the (your) following code
Attiny3216 ; 20Mhz ; millis() on timerB0
the programming is through an usb - serial converter (whit a shottkey) , no bootloader

#if defined(MILLIS_USE_TIMERA0)||defined(__AVR_ATtinyxy2__)
#error "This sketch takes over TCA0, don't use for millis here.  Pin mappings on 8-pin parts are different"
#endif

#define led_onboard 8  //(PB1)

unsigned int DutyCycle=0;

void setup() {
  // We will be outputting PWM on PB0
  pinMode(PIN_PB0, OUTPUT); //PB0 - TCA0 WO0, pin7 on 14-pin parts
  TCA0.SPLIT.CTRLA=0; //disable TCA0 and set divider to 1
  TCA0.SPLIT.CTRLESET=TCA_SPLIT_CMD_RESET_gc|0x03; //set CMD to RESET, and enable on both pins.
  TCA0.SPLIT.CTRLD=0; //Split mode now off, CMPn = 0, CNT = 0, PER = 255
  TCA0.SINGLE.CTRLB=(TCA_SINGLE_CMP0EN_bm|TCA_SINGLE_WGMODE_DSBOTTOM_gc); //Dual slope PWM mode OVF interrupt at BOTTOM, PWM on WO0
  TCA0.SINGLE.PER=0xFFFF; // Count all the way up to 0xFFFF
  // At 20MHz, this gives ~152Hz PWM
  TCA0.SINGLE.CMP0=DutyCycle;
  TCA0.SINGLE.INTCTRL=TCA_SINGLE_OVF_bm; //enable overflow interrupt
  TCA0.SINGLE.CTRLA=TCA_SINGLE_ENABLE_bm; //enable the timer with no prescaler

pinMode(led_onboard, OUTPUT);
  
}

void loop() { // Not even going to do anything in here
if(DutyCycle > 1) digitalWriteFast(led_onboard, HIGH); ///
  
}

ISR(TCA0_OVF_vect) { //on overflow, we will increment TCA0.CMP0, this will happen after every full cycle - a little over 7 minutes.
  TCA0.SINGLE.CMP0=DutyCycle++; // Because we are in Dual Slope Bottom mode, OVF fires at BOTTOM, at end, not TOP, in middle of the pulse.
  TCA0.SINGLE.INTFLAGS=TCA_SINGLE_OVF_bm; //Always remember to clear the interrupt flags, otherwise the interrupt will fire continually!
}

with the code
if(DutyCycle > 0) digitalWriteFast(led_onboard, HIGH); ///
the led is flashing

but with the code
if(DutyCycle > 1) digitalWriteFast(led_onboard, HIGH); ///
it doesn't

it looks like the timer stops after the first interrupt (or the interrupt triggers only one time)
don't now what happens, can you please help me ?

[SpenceKonde]

blink
Euhm.... Am I missing something., or did I seriously write that code?

void loop() { // Not even going to do anything in here
if(DutyCycle > 1) digitalWriteFast(led_onboard, HIGH); /// 
}

with nothing writing the pin LOW is will only result in a flashing light idf something forcesthe part into a reset loop.... Should be CHANGE instead of HIGH

[trimarco232]

sorry, its my english ...
I wanted to say the LED does not light
of course this part of the code is mine
the problem is that the timer A stops after the Interrup has fired one time ; then the variable DutyCycle doesn't increment anymore

with the code
if(DutyCycle > 0) digitalWriteFast(led_onboard, HIGH); ///
the led is lighthing

but with the code
if(DutyCycle > 1) digitalWriteFast(led_onboard, HIGH); ///
it doesn't

thank you for reply

[hmeijdam]

Change

unsigned int DutyCycle=0;

to

volatile unsigned int DutyCycle=0;

[trimarco232]

that was it !
let's go forward and try to understand the reason why later
great thanks hmeijdam !

[hmeijdam]

You are looking at the variable DutyCycle in the main loop, while the value of that variable is changed in another function (your ISR). By declaring it volatile, you make the value of the variable accessible by the different functions. Without declaring it volatile the value is only available within the function itself. So within the ISR (where it is incremented) and within the loop (where it will stay "0" forever).

https://www.arduino.cc/reference/en/language/variables/variable-scope-qualifiers/volatile/

A variable should be declared volatile whenever its value can be changed by something beyond the control of the code section in which it appears, such as a concurrently executing thread. In the Arduino, the only place that this is likely to occur is in sections of code associated with interrupts, called an interrupt service routine.

[trimarco232]

ok,
I have put a LED on my board thanks to a free pin of attiny3216 ; useful
I had to put the code <digitalWriteFast(led_onboard, HIGH);> outside of the ISR because it didn't work inside ; there is probably a good reason for this, too

[hmeijdam]

You can put it inside the ISR. If that does not work, something else is causing an issue.

This works just fine.

#if defined(MILLIS_USE_TIMERA0)||defined(__AVR_ATtinyxy2__)
#error "This sketch takes over TCA0, don't use for millis here.  Pin mappings on 8-pin parts are different"
#endif

#define led_onboard 8  //(PB1)

volatile unsigned int DutyCycle = 0;

void setup() {
  // We will be outputting PWM on PB0
  pinMode(PIN_PB0, OUTPUT); //PB0 - TCA0 WO0, pin7 on 14-pin parts
  TCA0.SPLIT.CTRLA = 0; //disable TCA0 and set divider to 1
  TCA0.SPLIT.CTRLESET = TCA_SPLIT_CMD_RESET_gc | 0x03; //set CMD to RESET, and enable on both pins.
  TCA0.SPLIT.CTRLD = 0; //Split mode now off, CMPn = 0, CNT = 0, PER = 255
  TCA0.SINGLE.CTRLB = (TCA_SINGLE_CMP0EN_bm | TCA_SINGLE_WGMODE_DSBOTTOM_gc); //Dual slope PWM mode OVF interrupt at BOTTOM, PWM on WO0
  TCA0.SINGLE.PER = 0xFFFF; // Count all the way up to 0xFFFF
  // At 20MHz, this gives ~152Hz PWM
  TCA0.SINGLE.CMP0 = DutyCycle;
  TCA0.SINGLE.INTCTRL = TCA_SINGLE_OVF_bm; //enable overflow interrupt
  TCA0.SINGLE.CTRLA = TCA_SINGLE_ENABLE_bm; //enable the timer with no prescaler
  pinMode(led_onboard, OUTPUT);
}

void loop() { // Not even going to do anything in here
}

ISR(TCA0_OVF_vect) { //on overflow, we will increment TCA0.CMP0, this will happen after every full cycle - a little over 7 minutes.
  TCA0.SINGLE.CMP0 = DutyCycle++; // Because we are in Dual Slope Bottom mode, OVF fires at BOTTOM, at end, not TOP, in middle of the pulse.
  TCA0.SINGLE.INTFLAGS = TCA_SINGLE_OVF_bm; //Always remember to clear the interrupt flags, otherwise the interrupt will fire continually!
  if (DutyCycle > 1) digitalWriteFast(led_onboard, HIGH);
}

Oh and BTW, as now the change of the variable DutyCycle and the if-statement are in the same function again, you don't need to declare it volatile anymore.

Or declare it at all :-)

#if defined(MILLIS_USE_TIMERA0)||defined(__AVR_ATtinyxy2__)
#error "This sketch takes over TCA0, don't use for millis here.  Pin mappings on 8-pin parts are different"
#endif

#define led_onboard 8  //(PB1)

void setup() {
  // We will be outputting PWM on PB0
  pinMode(PIN_PB0, OUTPUT); //PB0 - TCA0 WO0, pin7 on 14-pin parts
  TCA0.SPLIT.CTRLA = 0; //disable TCA0 and set divider to 1
  TCA0.SPLIT.CTRLESET = TCA_SPLIT_CMD_RESET_gc | 0x03; //set CMD to RESET, and enable on both pins.
  TCA0.SPLIT.CTRLD = 0; //Split mode now off, CMPn = 0, CNT = 0, PER = 255
  TCA0.SINGLE.CTRLB = (TCA_SINGLE_CMP0EN_bm | TCA_SINGLE_WGMODE_DSBOTTOM_gc); //Dual slope PWM mode OVF interrupt at BOTTOM, PWM on WO0
  TCA0.SINGLE.PER = 0xFFFF; // Count all the way up to 0xFFFF
  // At 20MHz, this gives ~152Hz PWM
  TCA0.SINGLE.INTCTRL = TCA_SINGLE_OVF_bm; //enable overflow interrupt
  TCA0.SINGLE.CTRLA = TCA_SINGLE_ENABLE_bm; //enable the timer with no prescaler
  pinMode(led_onboard, OUTPUT);
}

void loop() { // Not even going to do anything in here
}

ISR(TCA0_OVF_vect) { //on overflow, we will increment TCA0.CMP0, this will happen after every full cycle - a little over 7 minutes.
  TCA0.SINGLE.CMP0++; // Because we are in Dual Slope Bottom mode, OVF fires at BOTTOM, at end, not TOP, in middle of the pulse.
  TCA0.SINGLE.INTFLAGS = TCA_SINGLE_OVF_bm; //Always remember to clear the interrupt flags, otherwise the interrupt will fire continually!
  if (TCA0.SINGLE.CMP0 > 1) digitalWriteFast(led_onboard, HIGH);
}

[trimarco232]

ok, thanks 👍
digitalWriteFast(led_onboard, HIGH); works in the ISR ... I made somme mistakes ... all my fault

[SpenceKonde]

Glad to hear you got it sorted out. I can't belive I didn't catch the missing volatile. Yeah.

Volatile tells the compiler that it must read the memory location associated with the variable when you want to use it. Even if it thinks it's already got it it in one of the 32 "working registers" that the CPU can directly access (normally it can be like "Oh, I read that variable a dozen lines ago, and it's still in r20, no need to read it again" and it won't generate the code to do that). Likewise, it must write it every time you assign to a volatile variable - otherwise if it knows it will be modifying the value again soon, it won't write out the result until both operations are done. And the compiler can't reorder read or write operations in any way that changes the order that volatile registers are accessed in.

All of the hardware registers that control peripherals (like, in above examples, TCA0.SINGLE.CTRLA and the like are defined to be volatile).

The other "variable hazard" with interrupts is that if you have a variable written OUTSIDE the interrupt which is larger than 1 byte, but which is read inside an interrupt, that interrupt could occur while it's writing the value, and it would read part of the old value and part of the new one; for that case, you briefly disable interrupts while writing the variable (unless, of course, you know that the interrupt will never be enabled then)

[trimarco232]

Yes, I have heard about volatile, but the thing that made me donkey, is that the variable was incremented one time, but not the second one
thank you for the advice about the other "variable hazard" !

[SpenceKonde]

As a human,you would find the ways the compiler finds to optimize things unnatural in the extreme, particularly with regards how different the loop you wrote looks from the loop it created in assembly from that. Things get partially unrolled in weird ways, and the first iteration is usually not the same as subsequent oners

Complicated series of arithmetic also get transformed in wacky ways - I've stared at what it does to micros (because I know about constraints that should make it possible to optimize it further, which would be desirable because people want micros to be accurate, and they want it to return quickly, and they wouldn't be happy if it rolled over at 65535 - all those things are easy if the timer prescaler divides evenly by the system clock because then you can just right shift it to convert ticks to microseconds. But that often isn't the case (it is for 32, and 16, and 8 but not 20). And if you use division, it takes hundreds of clock cycles (there's no hardware division, it's doing the division in software, which is no good for the microseconds function! So I do a series of rightshifts and addition or subtraction (I calculated out the optimum ome on a spreadsheet for all the supported clock speeds. But the source of the value is from a volatile registers, about which the compiler knows nothing - it doesn't know that TOP of the timer isset to 510, so once it's right-shifted it once, it's got an 8-bit value, nor, I don't think, can it recognize that if it subtracts the value from that 9-bit tick total, then shifts it right, it never has to think carry, because the there's no way to get a number that would be large enough to require it.I tried to go in and see if I could optimize it, but I could not recognize how it came up with the assembly it did. Maybe it already optimized it better than I could.... but It couldn't have possibly known about the specific maximum value of that uint16_t.

and in one case, casting something to a uint16_t saved 6 btytes of flash. Casting to uint8_t did not and thje same went for the same cast anywhere else. Black fuckin magic.