PWM Makes My Head Hurt

[microPaul]

I'm trying to do some basic stuff with PWM, and although it sorta works, I don't think its working the way I think it should (based on the docs).

I'm using an AVR128DB32 on a homebrew board. I've got a 24 Mhz crystal on PA0 PA1, but for these tests I'm running on the internal 24 MHz clock. My serial console is on PF4 PF5.

Here's my test code:

`
#define Serial0 Serial2

void setup() {
// for the DB Nano the serial port is UART2 ALT-1 - MTX PF4, MRX PF5 - swap(1)
// for the DD Nano the serial port is UART0 ALT-3 - MTX PD4, MRX PD5 - swap(3)
Serial.swap(1); // UART2 pinout option 1 (MTX PF4, MRX PF5)
Serial.begin(57600, SERIAL_8N1);
Serial.printf("_test_analog_write_PWM_230514-01\n\n");

//PORTMUX.TCAROUTEA = 3;
//PORTMUX.TCAROUTEA = PORTMUX_TCA01_bm | PORTMUX_TCA00_bm;
Serial.printf("show value of PORTMUX.TCAROUTEA 0x%02X\n", PORTMUX.TCAROUTEA);

}

void loop() {
uint8_t lapCtr = 0;

while(1) {

analogWrite(PIN_PA2, 120);
delay(750);
analogWrite(PIN_PA2, 240);
delay(750);
Serial.printf("show value of PORTMUX.TCAROUTEA 0x%02X\n", PORTMUX.TCAROUTEA);
Serial.printf("redoing loop, Count=%d\n", ++lapCtr);
}
}
`

First question is: "how to I know which timer the DX Core is using for PWM?" I assume that the default PWM timer is TCA0, but I don't see in the docs where it says explicitly that the DX core will default to TCA0 for PWM.

How would I cause the DX core to use some other timer for PWM?

Another thing I notice is that my test code works fine for the A ports (I tested only A2, A3 and A5) but the value I find in PORTMUX.TCAROUTEA is 0x03, which should mean (from the data sheet) that port D is used for the PWM outputs from TCA0. Why am I getting PWM output on the A port when PORTMUX.TCAROUTEA is 0x03? Is some timer other than TCA0 providing the PWM function? If so, which timer is it? If I set the value of PORTMUX.TCAROUTEA to 0x02 (which should put PWM on the C port) I find that PWM stays on the A port.

Which leads to the question that started my looking at all this. How do I get the PWM signals to appear on the D port?

thanks,

Paul

[pcfreak1201]

Hi Paul, did you read this?
https://github.com/SpenceKonde/DxCore/blob/master/megaavr/extras/Ref_Timers.md

[microPaul]

I did, thank you. And I've re-read it again this evening. I must say that in many ways Spence's documentation is better than Microchips, as to the detail it provides. But I think I'm getting lost in a bit of that detail. I think I need some basic examples (and once I get my understanding of how to use PWM I'd be happy to offer a couple of basic examples).

I don't see on the page you referenced a statement that says what the default timer will be for PWM if I don't do any portmux changes and simply have a line in the code that says "analogWrite(PIN_PA2, 127);" I don't know which timer I'm going to end up using. It seems like TCA0 would be that timer, but it appears that when I make changes to PORTMUX.TCAROUTEA that it has no effect on which PORT the PWM appears on. For example, if my program executes "analogWrite(PIN_PA2, 120);" I can see a PWM signal on PA2. But if I read the value of PORTMUX.TCAROUTEA I find that the value is 0x03, which I think would point to the D port. I didn't set the value PORTMUX.TCAROUTEA, it seems that the core initialized it to 0x03, so that's what I read for the value of PORTMUX.TCAROUTEA. So why would I get PWM on A2 if the core set PORTMUX.TCAROUTEA to 0x03? if PORTMUX.TCAROUTEA is set to 0x03 then shouldn't I get no PWM signal until I do something like "analogWrite(PIN_PD2, 120)"?

Thanks,

[SpenceKonde]

It makes my head hurt too!

I'll try to clarify this

I did think it specified the priority order:

1. If TCA0 is pointed at the pin, we use that.
2. If the part has TCA1 and that's pointed at the pin, we use that.
3. Now we give in and check the digital_pin_to_timer array (this doesn't list TCA channels since they are so widespread.
   a. If it could have a TCD pointed at it, we will discover it at this time; the table entries in this case specify both the TCD AND the mux option on DxCore. so if we got a TCD there, we also know the mux option and test if that's equal to the TCD mux. If it is we used that.
   b. If there is a TCB in the table, and it's not the one used for millis, we will use that as a last resort. The pins used for these timers are chosen such that there are no cases where both a TCD and TCB can output on the same pin (I'm not sure if there even are any pins that that could be). Even folks affiliated with microchip freely admit that TCB sucks for PWM - you get 8-bit pwm with no independent prescaler out of a 16-bit timer? Really? Anyway, during init() we set all non-millis TCB timers to pwm mode; we check that they are in PWM mode before using them. If they are not, we treat the timer as unavailable because it;s been reconfigured to do something else. Right now, you are getting PWM from TCB0 on PA2
4. Finally, if there are no timers on the pin, we replicate the behavior of the stock core, against my better judgement (I think it should be a compile error if the pin is constant - I forget if I do that for analogWrite or just analogRead), and I don't think it should do anything to the pin configuration if it can't do PWM - but I didn't write the API), and set the pin HIGH if the argument was 128 or more and LOW otherwise.

Note that:

• PWM on official cores counts from 0 to 255. This is not compatible with the Arduino API, which the Aruduino team didn't seem to notice (and in any event on classic AVRs often can't be changed without unacceptable sacrifices on Timer0). Why? Well, really it's quite simple math. How many values can the second argument of analogWrite have? 256. 0-255. When a timer is counting to 0-255, how many states can it be in? Well, there's constant low (digitalWrite(pin,LOW) or analogWrite(pin,0) (see next note), then 255 levels of PWM - or constant high (digitalWrite(pin,HIGH)/analogWrite(pin,255); That's 257. How to we request one of 257 states with 256 values of the parameter? It's impossible. Hence, counting up to 255 means that there inevitably will be a "glitch" where instead of 1/256th, duty cycle difference between two adjacent values of the second argument it's 2/256ths. That's a problem - not an academic one either. The people who are driving PWM such that the it goes from 254/256ths to 256/256 duty cycle, you won't notice it (certainly not with an LED) but at the other end, when we go from 0 to 2/256 instead of 1/256, it is VERY noticible, the steps are already too big there, because the eye is not linear - so either people who do active high or people who do active low will have difference between the dimmest other than off, and off twice as large as the other and for non-led applications the glitch at the other end might be a problem. What's more, if the TCA is used for millis timekeeping, it is very hard to prevent drift of millis due to the math involved. And so, we have the timers count to 254 giving 255 steps, one of which even in PWM mode would be either 100% or 0% (again, I forget which and don;t feel like checking). and a glitch free flow between 1 and 255, since now 254 non-0, non-100% duty cycles are available and the full on and full off bring us to - 256, the same number of distinct values that can be taken by the second parameter of analogWrite.
• On TCD we do more to bring that unruly timer to heel: the highest prescale you can get without having to use the sync prescaler is 32. But wait, it;'s a 12 bit timer! so to keep the timer close to the target speed of 1k, we set top to 509 or in extreme cases 1019 (256-1 = 255. Now turn each tick into 2 or 4 (for 510 or 1020), then subtract 1 because zero is a number), and likewise multiply what the user passes in (okay, no we use shifts like any sane person would). In fact, if you need particularly low frequencies you can write . We also, to prevent any possible disruption from the necessary enable and disable cycle of TCD do something even weirder on DxCore and high-flash tinyAVR: On TCD, it is easy to use the CMPASET and CMBPSET registers to get output that is never set. We do that for analogWrite(TCD pin, 0 or 255). In the case of a low, we're done, if we want a high, we set a bit, go through the rest of the stupid rigmarole involved in setting up TCD, then if that flag was set we needed a constant high, we invert the pin, and if not, we make sure it isn't inverted). That means you can analogWrite() both channels 0, and then generate PWM on them without one channel glitching when the other was turned on or off.
• The defaults for various pincounts are specified explicitly family+pincount specific document. I'm adding some content to these too. Will upload a little later today. The DA and DB parts of the core long predate the runtime portmux magic (which isn't particularly magical, we're just trading flash and speed for features like usual, but it was mostly a good bargain) - Just because you can now change the portmux at runtime does not mean that we discontinued writing what we believe to be the most generally useful option to PORTMUX registers (for one thing, it would have broken everyone's existing code, since we always moved TCA0 off port A on DxCore before we supported live change of PORTMUX. and only in the case of 20-pin parts is PORTA the best choice for the TCA mux

That's also when I discovered the erratum involving the port override behavior - apparently that's definitely getting a datasheet clarification on DD (the pins now do override direction and don't need to be set output, but do not on the DA/DB. I don't know what they'll do about the DA/DB regarding that when they finally give us our long, long overdue silicon revision. (Whenever that is - we might all be long dead, shivering in frozen-over hell by then). They seem to have been setting a precedent of marking things as errata readily instead of saying "That's how it is" so I wouldn't be surprised if they marked it as errata + clarification just like the TCA restart behavior - clarification to state what it's intended to do and errata to say "well it doesn't do that yet.

[microPaul]

Spence, thanks for this detailed explanation. But I'm still feeling kinda dense. So let me as a few questions that may seem very elementary.

I'm using version 1.5.6 DxCore on an AVR128DB32 test board with VCC at 5 volts.

If I run this code

void setup() { analogWrite(PIN_PA2, 127); } void loop() {}
(and I don't know why GitHub removes newlines from my code when I use the Add Code feature).

So with the program above running and if I monitor pin PA2 with an old school analog D'Arsonval movement DC voltmeter (the total meter resistance is about 50K on the 5V scale, so there's very little loading) I see a voltage of about 2.5 volts. So all of that is good, just what I would expect.

Based on the data sheet, looking at the table in section "3.1 I/O Multiplexing", if I'm getting PWM output on PA2 then I assume that I'm getting it from the "0, WO2" output from TCA0 (and not from the "0, WO" output from TCB0). And yet, if I look at the value stored in PORTMUX.TCAROUTEA, I find that the Core has set that to a value of 0x03 (I assume the Core set it to that value because I didn't set it and the device data sheet says that the reset value of PORTMUX.TCAROUTEA is 0x00). So if PORTMUX.TCAROUTEA is set to 0x03 then why do I get a PWM output on PA2? If I get any PWM, shouldn't I get output on PD2 if PORTMUX.TCAROUTEA is 0x03?

My end goal is to have PWM output on PD2. But when I run the follow program:

void setup() { analogWrite(PIN_PD2, 127); } void loop() {}

I do not get a PWM output on PD2 (nor is there PWM on PA2). Again, in this case I find that the Core has set the value of PORTMUX.TCAROUTEA to 0x03.

So what DX Core commands would I need to use to get a PWM output on PD2?

Thanks,

Paul