[SAMC] TC in wave generation mode - Page 1
Forum section: electronics / general

author: Simon
author_rank: Unknown
timestamp: January 29, 2020, 07:16:45 pm
content: Looking at the timer counter register description (and to call it description is a huge stretch of the imagination). It is completely not clear how the wave generation mode is activated, if it is the default mode or what the hell is going on. Do I take it that as enabled the counter counts clock ticks and not other stuff and that by enabling capture this switches to pin or event counting?unless capture mode default in CTRLA (CAPTMODE1) means no capture i cannot see how the counter is not always in capture mode. this could bu driven by clock cycles or some other input. COPENx still just decides how the capturing that is not used in waveform generation is to work.it is only CAPTENx that allows disabling of capture that suggests that, i dunno.... maybe the "other" inputs that the counter may be counting stop being counted and the clock is counted instead.

author: ataradov
author_rank: Super Contributor
timestamp: January 29, 2020, 07:48:43 pm
content: Here is example code for D21. For C21 it would be the same, except for the clock initialization part:Code:void pwm_init(void){GPIO_PWM_pmuxen(PORT_PMUX_PMUXE_E_Val);PM_APBCMASK |= PM_APBCMASK_TC3;GCLK_CLKCTRL = GCLK_CLKCTRL_ID(27/*TC3_GCLK_ID*/) |GCLK_CLKCTRL_CLKEN | GCLK_CLKCTRL_GEN(0);TC3->COUNT16.CTRLA.reg =TC_CTRLA_MODE(TC_CTRLA_MODE_COUNT16_Val) |TC_CTRLA_WAVEGEN(TC_CTRLA_WAVEGEN_MPWM_Val) |TC_CTRLA_PRESCALER(TC_CTRLA_PRESCALER_DIV1_Val) |TC_CTRLA_PRESCSYNC(TC_CTRLA_PRESCSYNC_PRESC_Val);TC3->COUNT16.COUNT.reg = 0;TC3->COUNT16.CC.reg = 0x2000; // Top valueTC3->COUNT16.CC.reg = 0x1000; // 50 % duty cycleTC3->COUNT16.CTRLA.reg |= TC_CTRLA_ENABLE;}I don't quite get the remainder of the rant.

author: Simon
author_rank: Unknown
timestamp: January 30, 2020, 07:52:56 am
content: What I can gather from the code is that you are simply setting up some settings and that PWM must be the default mode. Not all of the CTRLA register seems to be the same between the D and the C as one of the lines shows as having an error.My rant? you read the datasheet and tell me where it is clear on the operation in PWM mode. It's like it was an afterthought even though it appears to be the default mode. on the AVR the mode section of the register would set various counter modes or waveform generation modes (more of the latter in fact). Here I am left to assume that the counter is by default clocked.I don't like having to make assumptions, I know the chip are cheap bla bla bla but these are not the cheapest and I chose the SAMC over the entry level ST's as they seem more capable. For example a 16 bit ADC, the cheap STM's only have 10 bit so all you get improvement wise is a faster and wider CPU.it only takes getting one register bit wrong and it does not work.

author: ataradov
author_rank: Super Contributor
timestamp: January 30, 2020, 07:59:42 am
content: There is no "default". I'm explicitly specifying all settings. In this case it is Match PWM mode (TC_CTRLA_WAVEGEN_MPWM_Val). Normal PWM (NPWM) will work just as well here.There is entire section in the datasheet called "Waveform Output Operations".Again, I don't understand your definition of "default". There is no default. You need to tell the timer in what mode it should operate.There is no point in complaining about the documentation. I work with a lot of different MCUs from different vendors, so I read a lot of datasheets. And stuff from Microchip is far from being the worst or even bad. If you have problems here, you will have similar problems with other devices.

author: Simon
author_rank: Unknown
timestamp: January 30, 2020, 08:05:10 am
content: Quote from: ataradov on January 30, 2020, 07:59:42 amThat is the one difference between the C and D, the C does not have that, for the C that line is underlined in red. Your assumption that the TC on the D is the same as the C is not entirely correct. There is a seperate 8 bit waveform generation mode register (35.7.2.9) and all it has is 4 waveform generation modes. So yes there is a default setting as the capture versus compare mode settings are the only indicator of how I would set the counter as counting "something" or counting main clock cycles for the purpose of waveform generation.

author: ataradov
author_rank: Super Contributor
timestamp: January 30, 2020, 08:12:28 am
content: The modes are the same. The setting is just moved from CTRLA to WAVE register. So the constant would be TC_WAVE_WAVEGEN_MPWM_Val.I really expected the code to give you enough of a hint of how to proceed. I was wrong.And I still don't understand the part about default mode.

author: Simon
author_rank: Unknown
timestamp: January 30, 2020, 08:20:33 am
content: There are only waveform settings. 0x0 is the default setting of the register yet it is still a waveform setting. for there to always be a waveform setting in this register or section of register there must be something else that distinguishes between waveform generation and capture modes. I suspect the CAPTENx is the only thing that decides what mode is used? so if i disable the capture mode on that channel it becomes waveform generating once the pin is connected? so much subtlety going on there.

author: ogden
author_rank: Super Contributor
timestamp: January 30, 2020, 08:48:41 am
content: Interesting chat you guys have. For others to follow, it would be helpful to provide pointer(s) to documentation you are referring-to. Disclaimer: never used sam* MCU's nor red datasheets, justopened one. What I understand - as soon as CC output is enabled, it (CC output generation) works in mode which is set in WAVEGEN bits of WAVE register. As "reset" state of this register is 0x0 and it is mode NFRQ, indeed this can be considered as "default mode". So Simon is right to name it so. BTW quality of doc is very good, I did find what I need in a snap.

author: Simon
author_rank: Unknown
timestamp: January 30, 2020, 09:16:16 am
content: well we are referring to the product family datasheets. I get a sense that datasheet writers know what they mean but sometimes don't grasp how someone looking at it for the first time will see it. I came from AVR chips what little i did do on µC's. I know that a 1300 page document is a lot to write but if it's not done the chip will be useless. i have chosen this chip based on the chip itself and not because it happens to be the one made by the company that produces the IDE or setup code generator i like and I am prepared to learn how it works but often the detail is lacking in the datasheet even if they are quite good. Where there are infinite ways this can go wrong and few ways it can go right I prefer them to be more explicit. But then I am probably also on the autistic spectrum so I like to be explicitly told something rather than be left to assume based on some inference based on not saying that it is not so.

author: ogden
author_rank: Super Contributor
timestamp: January 30, 2020, 09:51:21 am
content: Quote from: Simon on January 30, 2020, 09:16:16 amIndeed you have to know basics. For example no ARM MCU datasheet explains how ARM CPU works. For that you have to read ARM docs. Also if logic of registers (by logic) prohibits some operation or combination of modes of operation, they perhaps do not describe that explicitly in comments. Example: they do not tell simple things like "when capture enable bit of Capture&Compare register is not set, then it is in other than capture, thus compare mode". Kinda obvious, huh? That BTW answers your question:Quote from: Simon on January 30, 2020, 08:20:33 am

author: Simon
author_rank: Unknown
timestamp: January 30, 2020, 10:23:29 am
content: That is what I thought. But then why call it capture enable, it's actually mode select, capture or compare which it's clear even to me are mutually exclusive.

author: ogden
author_rank: Super Contributor
timestamp: January 30, 2020, 10:32:06 am
content: Quote from: Simon on January 30, 2020, 10:23:29 amYes, agreed. Those who missed to read first chapter of timer documentation, 35.1 Overview describing only two possible modes of operation, may get confused here

author: Simon
author_rank: Unknown
timestamp: January 30, 2020, 10:40:49 am
content: hehehe, I know there are the two modes, i know it's one or the other. I am just used to the more explicit mode selecting of AVR. The same bit pattern will chose a timer mode, any timer mode be it event counting/timing or waveform generation.

author: snarkysparky
author_rank: Frequent Contributor
timestamp: January 30, 2020, 07:56:28 pm
content: I agree the datasheet is kinda written from the perspective of someone who already knows how to use the thing.I have managed to setup spi / a-d / timers/ interrupt / ports , by direct register writing but it was a tough slog.

author: Simon
author_rank: Unknown
timestamp: January 31, 2020, 04:16:57 pm
content: i take it that a TC pin is an event input and a WO is the waveform output. Again nothing more explicit than what is alluded to in the 35.3 block diagram.

author: ataradov
author_rank: Super Contributor
timestamp: January 31, 2020, 04:23:38 pm
content: What "TC pin"?WO[ x ] are waveform output signals.TC does not take inputs directly from the pins for capture. Instead you need to use event system and route the events from EIC to the TC to perform the capture.

author: Simon
author_rank: Unknown
timestamp: January 31, 2020, 04:33:01 pm
content: So why are some pins (many) marked as TCx and Wx ? I'm sure there is a TC0/WO as well as TC0 and WO on their own.

author: Simon
author_rank: Unknown
timestamp: January 31, 2020, 04:36:01 pm
content: OK i think i get it, it's the TC number and then WO followed by the channel number. so the TCC's also have WO used to describe their outputs.

author: ataradov
author_rank: Super Contributor
timestamp: January 31, 2020, 05:01:12 pm
content: Yes, the full name is TCx/WOy or TCCx/WOy.

author: Simon
author_rank: Unknown
timestamp: February 01, 2020, 09:01:52 am
content: What about table 35.4? that is totally not clear. It appears to suggest that the WO pins are inputs as well. I am sure that they can be if setup via the event system but this appears very misleading.

author: ogden
author_rank: Super Contributor
timestamp: February 01, 2020, 12:16:14 pm
content: Quote from: Simon on February 01, 2020, 09:01:52 amNothing unusual. Pins & internal_signals of microcontroller can be bidirectional. Dunno about SAMC, but some MCU allows to measure voltage of digital output pin meaning pin is logic output *and* ADC input at the same time. The same here - waveform output can be used as input signal/trigger for control logic block of same or another timer (depends on pin mapper capabilities).

author: Simon
author_rank: Unknown
timestamp: February 01, 2020, 12:19:31 pm
content: the multiplexer specifies the pin used by the waveform output. for the input this comes from the event system. To say that the WO pin is an input is misleading as any pin can probably be a source of an event. Or does enabling event on pin bypass all of that and make the one pin an event input.

author: ogden
author_rank: Super Contributor
timestamp: February 01, 2020, 12:57:57 pm
content: After actually checking table in question to me it looks like typo. Pin shall be named "TCx/WO" or like that. Obviously when in peripheral mode, pin changes it's designation depending on CC register mode - capture (TC input) or waveform output (WO) and this is not the case of "bidirectionality" I talked about. This somehow was problem or you just trying to prove that SAMC sux compared to AVR?

author: Simon
author_rank: Unknown
timestamp: February 01, 2020, 01:01:33 pm
content: No i am not trying to prove anything. I have only mentioned the AVR to explain what i have been used to seeing. I am trying to understand why the WO pin is listed as an input when as ataradov said the inputs come from the event system where the event system would setup the pin which i would expect is any pin.

author: Simon
author_rank: Unknown
timestamp: February 01, 2020, 01:08:53 pm
content: although the CTRLA register description sounds like indeed the WO pin could also be the input capture pin:Bits 20, 21 – COPENx Capture On Pin x EnableBit x of COPEN[1:0] selects the trigger source for capture operation, either events or I/O pin input.Value Description0 Event from Event System is selected as trigger source for capture operation on channel x.1 I/O pin is selected as trigger source for capture operation on channel x.

author: Simon
author_rank: Unknown
timestamp: February 01, 2020, 01:09:47 pm
content: I'm guessing there are various events of which one could be a pin state bu there is also a default pin that avoids the event system.

author: ogden
author_rank: Super Contributor
timestamp: February 01, 2020, 02:12:09 pm
content: Quote from: Simon on February 01, 2020, 01:08:53 pmThere is no such thing as WO pin. When you look in the port multiplex table, pin (function) labels are "TCCx/WO", not just "WO".

author: ataradov
author_rank: Super Contributor
timestamp: February 01, 2020, 05:42:39 pm
content: It looks like they actually improved it in SAM C. SAM D series did not have it as an input. In this case it does look like it can capture from an input directly. Hallelujah.SAM D devices could only capture the actual events from the event system. And corresponding table reflects that.

author: Simon
author_rank: Unknown
timestamp: February 01, 2020, 05:47:08 pm
content: Am i right to assume that if i can set the pin high/low in software the pin multiplexing has not taken effect?

author: ataradov
author_rank: Super Contributor
timestamp: February 01, 2020, 05:49:40 pm
content: Yes, if you still have control over the pin via OUTSET/OUTCLR, multiplexing is disabled. When peripherals are connected they take over the corresponding control lines.Although there are examples where you may mistake control over the pin versus control over the pull-up. For example if you enable EIC, you still have control over the pull-up/pull-down resistor if the pin is configured as an input. Externally this can be mistaken for the control over the pin.

author: Simon
author_rank: Unknown
timestamp: February 01, 2020, 05:56:59 pm
content: Well i am trying to set the pin to work with a TC so from what you say I should not be able to toggle it. Do i need to set it as an output or does the peripheral completely take over.

author: ataradov
author_rank: Super Contributor
timestamp: February 01, 2020, 05:59:53 pm
content: All you need to set is PMUX value. TC specifically takes takes over. Although I'm not 100% sure with that new TC in SAM C, given that it also has direct inputs. So I would set it as an output.I generally always explicitly set things as inputs or outputs even when I know that peripheral will take over, since it created a self-documenting code as well.

author: Simon
author_rank: Unknown
timestamp: February 01, 2020, 06:03:44 pm
content: OK, just trying to make sure I do't create a conflict

author: Simon
author_rank: Unknown
timestamp: February 01, 2020, 08:17:56 pm
content: 16.8.3 clock generatorThe divisor bits. Apparently gen 2-9 are 8 bits using bits 4:0, so which one is it? I assume a typo that should be 7:0 as 4 is below 7 and I can't see it being 5 bits.

author: ataradov
author_rank: Super Contributor
timestamp: February 01, 2020, 08:22:26 pm
content: I think it should be DIV[7:0]. I'm pretty sure I used more than 5 bits.

author: Lajon
author_rank: Contributor
timestamp: February 02, 2020, 12:58:06 pm
content: Quote from: Simon on February 01, 2020, 08:17:56 pmYes 8 bits. This is corrected in the current revision of the data sheet (which is very recent, from January)./Lars

author: Simon
author_rank: Unknown
timestamp: February 09, 2020, 12:05:42 pm
content: Right I'll look up the latest copy. I have the PWM output working now. I had not enabled the clock in the main clock controller.

author: Simon
author_rank: Unknown
timestamp: February 09, 2020, 12:45:08 pm
content: woah they have dropped over 100 pages. I wonder what changed.