Glitch-free PWM in split mode

[Azmisov]

As you may know, TCA0's normal mode is buffered, preventing glitches when changing PWM values. I was playing around with ways to do software buffering when TCA0 is in split mode, and it was actually fairly simple. Feel free to use however you like. This was for Attiny424, and unfortunately that is the only AVR I have; if someone wants to throw together a library that works for all AVR's, be my guest. Also if you have any ideas for improvements, I'd love to hear them.

Usage:

• smooth_pwm::init: very similar to init_TCA0()
• smooth_pwm::ready: check that we can write new PWM values to the buffer
• write updates to smooth_pwm::WO array
• smooth_pwm::update: triggers flushing the buffers to TCA0 registers in a glitch free manner

namespace smooth_pwm{

bool can_update = false;
uint8_t timer_mask = 0b0'111'0'111;
uint8_t WO[6] = {0,0,0,0,0,0};

void init(){
	// setup ports
	PORTA.DIR |= 0b111'000;
	PORTB.DIR |= 0b111;
	// TCA0 in split mode cannot output always high;
	// 255 (high) will be handled by output driver when enabled
	PORTA.OUT |= 0b111'000;
	PORTB.OUT |= 0b111;

	// setup timer
	TCA0.SPLIT.CTRLD = TCA_SPLIT_ENABLE_bm;
	// TOP = 254; 255 is set by disabling PWM output on pin (CTRLB)
	TCA0.SPLIT.LPER =
	TCA0.SPLIT.HPER = 254;
	TCA0.SPLIT.CTRLB = timer_mask;
	TCA0.SPLIT.CTRLA = TCA_SPLIT_CLKSEL_DIV1024_gc | TCA_SPLIT_ENABLE_bm;

	can_update = true;
}

/** Buffered WO values have been committed, and can now be safely accessed */ 
inline ready(){
	while (!can_update);
}

/**
 * Marks WO buffered values as updated; values will be committed on the next CLK_TCA wave;
 * Make sure to call ready() prior to udpating the buffered values
 */
void update(){
	can_update = false;
	// values that are 255 use output driver
	// TODO: you could also check if any are != 255 or 0, to set the "standby enable" bit
	timer_mask = 0;
	for (uint8_t i=0; i<6; i++){
		if (WO[i] != 255)
			timer_mask |= 1 << (i + (i >= 3));
	}
	// enable LUNF interrupt for committing the changes
	TCA0.SPLIT.INTFLAGS = 1;
	TCA0.SPLIT.INTCTRL = 1;
}

/**
 * Commits buffered analog values to the timer, avoiding any glitching. Glitching is
 * most evident when new_cmp >= CNT > old_cmp (note, CNT is counting down), and so the comparison
 * gets missed and the PWM is low for new_cmp extra CLK_TCA cycles. We assume high/low byte timer
 * have same period and same count, so LUNF/HUNF interrupts would occur at same time. TCA0.SPLIT.L/HCNT
 * will be 254 when this runs, assuming:
 * - the interrupt runs fast enough to keep up with the scaled CLK_TCA
 * - no long running interrupt delayed this one
 * - interrupts didn't get disabled
 * Each of those cases, you may see a glitch with high CMP values still. Conveniently, the controller
 * seems to check if CNT == CMP *after* this interrupt runs, so the one risky case where
 * 254 (new_cmp) >= 254 (CNT) > 253 (old_cmp or smaller), won't give you a glitch.
 */
ISR(TCA0_LUNF_vect){
	// commit PWM changes
	TCA0.SPLIT.CTRLB = timer_mask;
	TCA0.SPLIT.LCMP0 = WO[0];
	TCA0.SPLIT.LCMP1 = WO[1];
	TCA0.SPLIT.LCMP2 = WO[2];
	TCA0.SPLIT.HCMP0 = WO[3];
	TCA0.SPLIT.HCMP1 = WO[4];
	TCA0.SPLIT.HCMP2 = WO[5];
	// disable interrupt
	TCA0.SPLIT.INTCTRL = 0;
	can_update = true;
}

}

[mosqu-ito]

These are the kinds of posts I like to see, worked examples of using peripheral x to achieve goal y. Do you have a silly scope? It would be sweet to see some sample waveforms, before and after your software buffering.

[Azmisov]

I don't have a scope unfortunately... have it on my shopping list but haven't got around to shopping yet. (But if you hook up an LED, the glitchy vs non-glitchy PWM will be immediately obvious when animating the brightness)

[mosqu-ito]

A really cheap scope will cost you less than a single probe for a fancy scope. So rather than research them all for fear of wasting money, just go ahead and "waste" money on any of those real cheapies. You might be surprised at how useful even the cheapest of them is. I would steer you away from the screenless kind (used with a PC) only because you're less likely to use it if there are extra steps involved. But that doesn't mean that a USB connection for PC software isn't good, it is, because sometimes you'll want a bigger view, and more importantly, the ability to save and retrieve views for comparison.

[SpenceKonde]

You cannot get glitch free pwm in split mode. That is an explicit sacrifice that the mode makes In order do double the number of pwm outputs A near future version will give tools submenus to switch the analog Write mediated pwm a) between a few sets of pins chosen for each pincount to prioritize one thing or another and b) and a set that turns off split mode, and uses it in buffered mode. This may also unlock a few function calls to turn off analogWrite() (would error 8f known at compiletime that it was a that pin, else do nothing) and enable a group of of functions tht will go into the megaTinyCore library and let you change the TOP and and use as many bits as you want as long as you're OK with the frequency of the output. That menu option will also include options for using tcd on woa and wob for the no -split-mode setting. Note that on a 1- series the two tcd outputs are glitch free (with the caveat of having to analogWrite() them both to 0 or 255, which leaves the timer in control of the pin; digital Write has to briefly disable the timer because the selection of which channels are output can't be changed while it is enabled

…

____________ Spence Konde Azzy’S Electronics New products! Check them out at tindie.com/stores/DrAzzy GitHub: github.com/SpenceKonde ATTinyCore: Arduino support for almost every ATTiny microcontroller Contact: ***@***.***

On Tue, Sep 27, 2022, 22:39 Isaac Nygaard ***@***.***> wrote: I don't have a scope unfortunately... have it on my shopping list but haven't got around to shopping yet. — Reply to this email directly, view it on GitHub <#833 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTXEW5XNM3EQZ3RCL2QTJLWAOVUXANCNFSM6AAAAAAQXFCZSY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** .com>

[Azmisov]

Yeah, this code can only guarantee glitch free if CLK_TCA has a big enough division such that all ISR's can run before the next TCA clock cycle. So... at least 64+ division. Maybe writing the LUNF interrupt handler in asm would help. In any case, it's running very smoothly for my use case and no noticeable glitches.

[SpenceKonde]

I think you get only 63 because you need it all ready before the timer next ticks.

You lose 10 right off the bat for entering and exiting the interrupt..

53 left.

Now let's imagine we do a normal ISR, that means the prologue will consist of push push in push eor to save r0, save r1, save sreg, and zero r1. 5 clocks there

And the epilogue, pop out pop pop reti. that's 7 more (I counted the reti in the 10 above.

You will need a register you can ldi into, which mean 3 more clocks 1 in prologue one in epilogue

38 left.

naive implementation would be to lds, and sts the 6 values in sequence, taking 30 clocks.
then ldi your upper register, and sts it to the intflags, for 3 more clocks.

Now you also need an efficient way to signal to the ISR that there are values to update, so you think "Oh super, I'll just store a value in memory and clear it. loading it with LDS and writing 0 back to it with STS is 5 clocks though. implying that a naive but not stupid way to do it will work. barely. But you also need to compare it, and branch over something to skip the ISR if it's not set.
That's 1 for the comparison and 1 for the branch. You're are -2

Well, that is damned close isnt it?
Let's look at how we could improve that.

First off, we have 4 magic registers called the GPIORs (or GPR.GPRn's on Dx and later - my cores make GPIOR an alias for them on Dx-series and classic AVRs where they were called GPIOn instead of GPIORn and on the Dx-series so GPIORn works everywhere.

GPIOR0 is used to track reset cause (we always check and clear the reset flags literally as soon as we have initialized enough that we can see if a number is equal to zero every time the code that runs after reset is executed. It checkes to make sure that at least one reset flag is set, clears the reset flags and then if what it found was 0, that means a dirty reset or wild pointer or an interrupt that doesn't exist was the cause of ending up at the initialization code again. That is to say, a reset has NOT occurred, but rather a "dirty reset" where due to a defect in the code execution wound up at the reset vector. That's a bad thing. Since all API implementation and libraries assume that at startup the chip has successfully reset, so registers hold their reset values until set otherwise, the assumptions of the whole core are violated, and we can make no assumptions about what the behavior of the system would be if we were to continue like that, though the principle of entropy suggests that the chances of the behavior not being wrong are effectively nil. So continuing is a non-starter. Instead, we immediately issue a software reset command, to get a clean reset. The only problem with this is that when we do have a clean reset, we are forced to clear the reset flags (only a POR clears reset flags other than PORF- maybe BOR clears everything other than BORF and PORF - thus we would not be able to tell the difference between a clean power on reset, and a dirty reset, unless we clear the flags). But user code might want to use those reset flags. So at startup, assuming we don't detect a dirty reset, after clearing the reset flags, we also output the value held in the reset flag register to GPIOR0 (this means one or more of the 6 low bits will be set). If using tuned internal oscillator clocking option, the two highest bits get used later in initialization to report error conditions:
If there are no tuning values, because the tuning sketch as not been run on the part with the current base oscillator selected, one of the bits is set to indicate that. That means any tuned clock speeds will be crude guesses and much less accurate. And the other bit indicates (if we do have tuning values) "According to the tuning data, the chip is incapable of reaching that speed (oscillator wouldn't go that high or low at it's maximum or minimum calibration), or that when we did some basic math, we got crazy numbers and/or crashed, indicating that it was unstable when running at that speed" (first option happens occasionally trying for 30 or 32 MHz from 20 MHz base oscillator, or the slowest speed that the oscillator is tuned to with either nominal frequency, while the second option is not uncommon when choosing the fastest tuned speed - 30 for 1-series of 32 for 2-series, particular on the non-extended temp spec parts, or if you are running below 5V or lack proper decoupling capacitors).

All that use of GPIOR0 happens before setup runs, and none of the other GPIOR's (GPOIR1-3) are touched by the core - so any of them could be used for what I describe below. If GPIOR0 is used it should be set to 0 in setup, after you've looked at it to see the reset cause (or ignored it because like 99.99% of the world aren't much concerned with it). If using a tuned oscillator option with it, you really ought to check the two high bits - one of them is a warning flag that you forgot to tune the thip, and the other is a "so sorry, this chip cannot do what you asked, and that's why timekeeping is blatantly hosed" bit. Most people don't care the reset reason except when debugging suspicious resets, and few people use tuning. So most people would just have to make sure that if using GPIOR0, they set it to 0 in setup, and everyone could use any other GPIOR without taking any action (provided that their own code isn't making use of it. Which is very rare. I sometimes use the GPIORs myself, but very few people do; any author of a library that doesn't clearly document use of a GPIOR should be hunted down and beaten up for his sins. Anyway...

Each of these is a 1 byte register, and does nothing on it's own, they're located in main address spaceat addresses below 0x0020 - that is, within the coveted low I/O space. Why do we care in this case?

Well, they get SBI and CBI, single clock instructions that set or clear a bit, for one thing (this is how digitalWriteFast() works - the other 28 low IO registers are the VPORT registers to control pins). That means that GPIOR0 |= 0x01; is a single clock, as is GPIOR0 &= ~(0x01).

Better still, there's a Skip next instruction If Bit in Io Set/Clear (sbrs/sbrc). And the SREG is unchanged. So now let's reimagine our isr
First we look at the 7 clock lds, cpi, sts breq sequence that checks if there;s anything to do here. Dedicating a bit in a GPIOR lets us do sbrc to skip the branch over the rest of the code. and clearing the bit costs just 1 clock cycle, that saves us 4 clocks, so we're 2 clocks in black again.

HUZZAH!!

But it gets better
Remember that we used lds, sts sequences to read and write the buffered values?
Those don't change SREG. So we aren't changing SREG, and we are neither changing nor depending on what's in r1, and since we need n upper register to ldi the intflag we need to clear into, we don't even need to have r0.

So get the ISR naked, and thing can move faster...
sbis the status bit,
reti immediately following that, so it will spend just 11 clocks in the case that there is nothing to do here before resuming the interrupted code.
If the reti is skipped, then after that (on the third clock cycle after the ISR has started, and after 2 clocks on top of the miniumum overhead ( skip-if's take 2 clocks if thy skip the instruction)), we push our favorite upper register onto the stack, (1 clock)
then 30 clocks for the lds/sts stack (using that register as the temporary register we load into and store from) - same 30 clocks
Then 3 clocks (ldi, sts) to clear the interrupt flag, end by clearing the flag in the GPIOR (1 more clock), pop the register we were using to restore it, (2 clocks) and reti.

That's 3 + 30 + 1 + 2 +10 (overhead including reti). 46 clocks.

Another approach - this time, after pushing that upper register, we then also push r28, 29, 30 and 31. (4 clocks). We LDI values into them so one points to the array in SRAM containing the buffered values, and the other points to the start of the TCA peripheral. (4 more clocks)
now, that read-write*6 sequence takes 3 clocks each (being an ldd and std each) for 18 - we save 2 clocks per, then another clock when we clear the intflags with std instead of sts. But then before we can reti, we have to pop those 4 registers - EIGHT CLOCKS. So that method actually turns out to be a loser within ISR context, because we're spending 16 clock cycles to save just 13.

If that we re NOT an ISR.... we could just pass in the addresses as operands to the asm (we'd use the X and Z registers, X for the sram with buffered duty cycles, since we'd be accessing them in order and could read with ld X+, since we only need displacement on the register we're using to access the TCA registers - because we want to use the same pointer to clear the intflags that we're using to write the duty cycles, In the best case non-isr context, it would still save 13 clocks, while costing just 4 for the LDI's, net of 9. If we used Y there, to meet the constraints the compiler would almost certainly end up needing to push (2 clocks) and pop (4 clock) the values in Y - that's because while X (r26 and r27) and Z (r30, r31) are call used, meaning that any called function is permitted to shit on them, Y is call saved, and the function needs to save and restore it.

So 46 clocks is currently my best guess for the execution time of an asm implementation of that, so it is viable, with 18 clocks to spare. But no prescaler lower than 64 could work, and I don't see any ways to further rev it up.

[Azmisov]

Don't you just care about the time taken until the TCA0 registers are set? Cleanup/return/disable interrupt can all happen on the second CLK_TCA cycle. Also some other random ideas for speedup (with compromises):

• split it into LUNF and HUNF interrupts and offset HCNT by 128; can halve the number of CMP registers to load/write at the expense of having high/low PWM pins unsynchronized
• if you don't need synchronization, you could set just one pin's PWM per interrupt (six interrupts to update all)
• limit your PWM to 255-N, the greater N the more time you can spend on the interrupt (and you can get rid of the CTRLB write)

The next smallest CLKSEL division is 16, so practically only the last one is going to do any good.

By the way, some questions for learning assembly on the AVR's: any good resources to learn besides the instruction set datasheet? also why GCC can't optimize all ISR's to be naked, since it presumably knows which registers it is modifying and can be picky about which to save/restore?