PWM

David Ramirez said:

I have a question charge in the TACCR0 register a period and in the TACCR1 a cycle useful in the case where useful cycle is equal to the period sends a logical one but that generates some kind of inconvenience?

While this may be inconvenient, it is conforming with the mathematical/physical definition of a PWM: neither 0% nor 100% DC do have a 'frequency' or 'cycle time'. Both are just a static voltage and therefore no PWM at all. :)

Jens-Michael Gross said:

While this may be inconvenient, it is conforming with the mathematical/physical definition of a PWM: neither 0% nor 100% DC do have a 'frequency' or 'cycle time'. Both are just a static voltage and therefore no PWM at all. :)

The point is that there are many PWM applications where 0% and 100% duty cycles may be needed like PWM DAC. So I see this as convenience, not opposite. If you don't like 0% or 100% output - don't use it. As simple as that.

Hi thanks for the answer

I  that in the development of the application in the past tense made PSEL | = 0x01 or P1SEL | = BIT1 to the pwm and the cycles P1SEL | = 0x00; but are three periods of the wave and not canto switch but put you TA0CCR0 = X TA0CCR1 = x with the same period to avoid delay in switching and avoid the problem I have but according to what I've seen is to be careful to match the two periods.

Lo siento, no entiendo su pregunta. ¿Habla usted español?

Hablo chino. A menudo utilizo translate.google.com. Es muy útil.

我說中國。我經常使用 translate.google.com。這是非常有用的。

Ilmars said:

The point is that there are many PWM applications where 0% and 100% duty cycles may be needed

However, with simply writing a single value to the CCRx register, there's no way for the hardware to tell 0% from 100%. You may write a value > CCR0, so the PWM generation never gets trigger A (TAR==CCRx) and stays on trigger B (TAR->0). Depending on outmode, this will give you either 0% (set/reset) or 100% (reset/set) DC. But if you write 0 to CCRx, both trigger fire at the same moment (TAR->0) and it is undefined which one wins (a racing condition, maybe different results on every MSP or even on the same MSP depending on temperature ort clock speed).

So by simply writing a value to CCRx, you can get either 100% or 0% DC (and of course anything between), but not both. The other one requires specific handling.

David Ramirez said:

P1SEL | = 0x00;

David Ramirez said:

PSEL | = 0x01 or P1SEL | = BIT1

For the rest of your post, sorry, I don't get what you want to say.

Hi

I want to say is that in my application I in some occasions need put the pin of the microcontroller in 1 or 0 but then get a PWM but the first thing I did was change the P1SEL to make in 0 pin of purpose general and then 1 to remove the PWM but did not work well so my question is if I can place the period of the PWM equal to the useful of the PWM cycle?

Thanks

Jens-Michael Gross said:

If you change TACCR1 to 0, then both actions take place at the same time, and it is a racing condition which one will win. It isn't defined nor is guaranteed by experience, that teh 'right' one will win.

It's interesting. Perhaps I missed something but I do not recall any explicitly documented behavior of timer compare unit glitches for both CCR = 0 and CCR = timer_overflow. Meaning if there's no documented exception then both are valid. Please advise.

Hello thank you for your answers in the test that I did tell me note that putting the CCR1 in 0 or CCR1 = CCR0 as such is not 1 0 0 but at a value close the best way of doing Weddings is camber 0 OUTMOD PSEL to remove a logical 1 or 0

Ilmars said:

Perhaps I missed something but I do not recall any explicitly documented behavior of timer compare unit glitches for both CCR = 0 and CCR = timer_overflow.

Like connecting two output pins for increased current and then programming both for opposite logic levels. Two valid operations, stupid idea to do both at the same time, and the datasheet doesn't tell which will be the output logic level (or voltage) in this case.

Jens-Michael Gross said:

So when, as in this case of x=y=0, a is !=b, then this is undocumented behaviour. Not a glitch, simply an 'it makes no sense and outcome is undocumented' case.

I still do not agree with you that every PWM set/reset logic shall be made like you described - using dumb latch, prone to race conditions. So if they may differ, then those differences shall be documented. Especially if there's simple logic solution how to avoid it - OR'ed all the bits of CCR enables CCR comparator output (when CCR==0 then comparator output is ignored). BTW Microchip did this in midrange PIC.

Ilmars said:

I still do not agree with you that every PWM set/reset logic shall be made like you described

Of course a PWM hardware could be made where you write the frequency in one register and the DC (0 to 100 or 0 to 1000 or 10000 for 0.1%/0.01% resolution) in another and it produces the desired output.

However, the MSP timers can be used for far more and more complex things than PWM only, with the drawback of the described ambiguity between 0% and 100%. And the need to write a second register for 0% DC then.

The timers are not defined as a PWM generation module, with the limitation of..., but as a timer module with the option of generating PWM - or other things, as far as the implementation provides the necessary signals.

Ilmars said:

Especially if there's simple logic solution how to avoid it

What's best for one purpose is bad for another. And the MSP hardware is designed to be as flexible as possible. Which of course leaves room for bugs.
You'll always find something to complain about. The question is: what gives least complaints?

Ilmars said:

BTW Microchip did this in midrange PIC.

Jens-Michael Gross said:

And you couldn't do things with the PICs which are easy to do with the MSPs timer. So what?

I am talking here only about lack of documentation, not about lack of hardware features. Microchip (and other manufacturers too) specify behavior of PWM at 0% and 100% duty cycle but TI - does not. And you as an enginer say "So what" ? :D

Hi,

Interestingly, the Timer_A behavior for simultaneous EQU0 and EQUx signals in Set/Reset, Toggle/Reset, Reset/Set, Toggle/Set output modes was exactly defined for the old MSP430x3xx series in SLAU012A, Table 11-2. This old Timer A description is somewhat more detailed than those in the newer 2xx and 5xx user guides and it might be useful to know whether all the extra details are still valid for newer MSPs.

Michal

Ilmars said:

And you as an enginer say "So what"

If a feature is there or not or specified or not in this but in that architecture doesn't matter.
If a feature is specified and doesn't work as specified, it of course  does matter.
But if it isn't specified, it isn't specified.
And as an engineer, I do not rant that it isn't specified, I either do an experiment that tells me the true story, and live with the risk that my results may be void with the next silicon revision, or I use a workaround that uses specified features.

Whining "I want this feature this way and want TI to document it" is futile.

And after all, the timer registers are named 'CCxx' and not 'PWMxx'. Which is a clear indication that the primary design is as a capture/compare unit, not as a PWM generation unit. And the two jobs aren't 100% exchangeable.

Michal H. Tyc said:

Timer_A behavior[...] was exactly defined for the old MSP430x3xx series in SLAU012A,

Edit: got a copy. It's still online.
You're right, it is way more detailed.
However, the cited table, while indeed giving a defined event for TAR==EQU0/EQUx for x=0, it isn't consistent with the text, which states the event happens when TAR rolls over from TAR=CCR0 to TAR=0.
Then fig. 11-23, which tells that EQU0 is delayed by one cycle in up mode, so in up mode, EQU0 event happens when the timer rolls over to 0. But does EQUx event  for x=0 happen at TAR=0 too?
Experiments have shown that OUTMOD7 on CCR0 gives a pulse (at least on the tested devices, I don't remember whether it was form 1x, 2x, 4x or 5x family), so apparently EQUx for x=0 isn't EQU0 here (unless CCR0=0).
According to table 11-2, it would indeed be possible to just use CCRx for 0 to 100% consistently, as it will reset OUT on CCRx=0 and stay set on CCRx = CCR0+1. However, this isn't documented in the other users guides and therefore cannot be assumed for sure. And is definitely not the case for CCR0 itself.

Jens-Michael Gross said:

Whining "I want this feature this way and want TI to document it" is futile.

Hilarious. Especially knowing that I never said that "I want feature this way". What I want - TI to say that CCR 0% and 100% results are undefined, if true. This will benefit developers having (different) experience with timers from other manufacturers. Am I wrong here?

Jens-Michael Gross said:

And after all, the timer registers are named 'CCxx' and not 'PWMxx'. Which is a clear indication that the primary design is as a capture/compare unit, not as a PWM generation unit. And the two jobs aren't 100% exchangeable.

Using ridiculous argumentation to justify lack of word "agree" in your vocabulary? Anyway thank you for sharing experiment results [OUTMOD7 on CCR0 gives a pulse].

[edited]

slau012a says:

11.5.2 Output Control Block
The output control block prepares the value of the OUTx signal, which is
latched into the OUTx flip-flop with the next positive timer clock edge, as shown
in Figure 11–23 and Table 11–2. The equal signals EQUx and EQU0 are
sampled during the negative level of the timer clock, as shown in Figure 11–23.

Which means that output control block is "race-condition safe" - when output flip-flop is latched, it's input signals are stable (because they change on opposite edge). This is good news. Only question is: why similar chapter of documentation is missing for other parts. Which is not that futile whining at all. It's very sad that every time when somebody points out lack of clarity in TI documentation, we are getting aggression from senior forum members which more or less says "this is all what you can get, stop crying for such a insignificant information". Thing is that maybe for you, JMG, it is not so important to have proper docs (of ADC or timer PWM modes), but it does not universally mean that it's the same for everybody else.

Ilmars said:

I never said that "I want feature this way"

Ilmars said:

What I want - TI to say that CCR 0% and 100% results are undefined, if true.

In the 3x users guide, it is defined. But it doesn't mean this information can be securely used for any other family. There surely is a reason why the very exhaustive documentation form the 3x family wasn't copied to the other user guides if the Timer modules are identical.

What you can do is to file a requiest for clarification. And you might get an authoritative answer. Or not. But everyhting else is just guessing or futile ranting.

Ilmars said:

Using ridiculous argumentation to justify lack of word "agree" in your vocabulary?

Ilmars said:

slau012a says:

I totally agree that with the information in the 3x users guide, for 3x devices, the usage of CCRx ifor PWM generation is consistent and CCRx/(CCR0+1) give the exact duty cycle. I don't know why this information isn't in the other users guides. Nor do I know whether it actually applies to the other families. And as long as I don't know, I can't rely on it. period.

Ilmars said:

Thing is that maybe for you, JMG, it is not so important to have proper docs

Jens-Michael Gross said:

the case of CCRx=0 for double-action mode is undefined. If TI didn't define it,  they didn't define it and that's what you got.

Well, TI did not define CCRx=999 or CCRx=666 either! So, I cannot be sure about ANY value of CCRx.

Jens-Michael Gross said:

Using ridiculous argumentation to justify lack of word "agree" in your vocabulary?

No, I just don't agree if I don't agree. Even though it might be easier.[/quote]

When I know that I am right - I don't care you agree or not.

Jens-Michael Gross said:

And as long as I don't know, I can't rely on it. period.

This is what I am saying but you try to disagree (to what you actually believe). LOL.

[edited]

It would be very helpful that you prove your position with excerpts from TI documentation that in PWM mode CCRx=1 results in defined behaviour but CCRx=0 does not.

Ilmars said:

Well, TI did not define CCRx=999 or CCRx=666 either! So, I cannot be sure about ANY value of CCRx.

No, all values except 0 are covered by the description, as the general case. However, for 0, the description is ambiguous as two independent and contradicting interpretations exist.

Ilmars said:

When I know that I am right - I don't care you agree or not.

Ilmars said:

It would be very helpful that you prove your position with excerpts from TI documentation that in PWM mode CCRx=1 results in defined behaviour but CCRx=0 does not.

Everything that makes any assumption about the case x=0 is either an opinion or an observation and may be void with any new MSP appearing.

Ilmars said:

And as long as I don't know, I can't rely on it. period.

This is what I am saying but you try to disagree (to what you actually believe). LOL.[/quote]Maybe it is what you meant but not what you said. You were going beyond this, not only wanting clarification, but even insisting that undefined situations have to be documented. Which was where I disagreed.

If you say "'A and therefore B" and I say 'B is wrong', this doesn't mean I disagree to A.
Or, in this case, if x=0 is undefined, then I just have to avoid this case and I'm not getting into trouble. It's that simple and could have closed the thread weeks ago.

Jens-Michael Gross said:

The documentation defines two events: a(x) and b(0). Where a == !b. So for any x except x=0, it is defined, for x=0, it is undefined whether event a or b occurs (which are mutually exclusive, as A means OUT=0 and b means OUT=1).

I can't find anything even close to what you say. Excerpt:

Compare Mode
The compare mode is selected when CAP = 0. Compare mode is used to generate PWM output signals or
interrupts at specific time intervals. When TBR counts to the value in a TBCLx:
• Interrupt flag CCIFG is set
• Internal signal EQUx = 1
• EQUx affects the output according to the output mode

Please help to sort it out, teach reading msp430 documentation the way you do.

Ilmars said:

Please help to sort it out, teach reading msp430 documentation the way you do.

not 'MSP documentation' but any documentation. Of any kind (not necessarily technical). Except art, of course.

You already located one of the two statements I was talking about:

Ilmars said:

When TBR counts to the value in a TBCLx:
• Internal signal EQUx = 1
• EQUx affects the output according to the output mode

The other one is the role of TACCR0/TBCL0 in up mode. Now TACCR0 is TACCRx for x==0. However, the described effect on the output is different for EQUx and EQU0 for the double-action output modes. So when x==0, there are apparently two different actions happening at the same time. Now the output cannot be both, set and reset. So one of them must take precendence. But the documentation doesn't say which one, so no result can be safely assumed and this case is undefined.

Now you have three options:

1. you can call for clarification and stall your project until you get one
2. you can make a test and hope that the next batch of devices will exhibit the same behaviour (which isn't guaranteed)
3. you can avoid this condition by writing a workaround, even if this isn't as convenient as it could be.

1+3 are safe, 2+3 are fast, but only option 3 is both, safe and fast. Pick one of the three, but don't assume that things are as you think they should (no matter how sure you are that any other implementation would be stupid) or demand a better documentation just because you don't like the current one.