XMega Counter/Timer feature lost.

Go To Last Post
29 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just looking at the XMega datasheets, with a view to using an Xmega32 in a new project.
I was initially excited because the I/O ports can be programmed to act as open drain, with external puul-ups, which was exactly what I was after.
However, the set/clear/toggle OCx on compare feature, which I have found incredibly useful in the past(IR remotes, LANC etc.) seems to have been axed!
So now I'll have to manually set or clear the output in the ISR, which doesn't sound too bad, except that I'm hoping to squeeze 8 channels of bi-directional open drain comms onto the one AVR, and the set/clear/toggle OCx on compare allows for totally accurate and jitter free waveform generation. Manually setting or clearing the output will not.

Does anyone know if the event system can be used to set or clear a single output pin?
It doesn't look like it from my reading of the data, but I'd like to be wrong...

Later that same day:
OK, I now see that there is one single event that can be routed to pin 7 of one port. Crap.
Bring back the old style counter compare functions!

I'd use a Mega, but they don't have the open drain output capability(yes, I know you can fake it by setting the PORT bit low and changing the DDR bit, but not in counter compare hardware).

Four legs good, two legs bad, three legs stable.

Last Edited: Thu. Jan 24, 2013 - 08:51 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Timer compare output on port pins is alive and well - see "Port override for Waveform Generation" in the XMEGA A Manual.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiuser wrote:
Timer compare output on port pins is alive and well - see "Port override for Waveform Generation" in the XMEGA A Manual.

- Dean :twisted:


Hi Dean,

Yes, I've seen that, but where are the control bits that allow you to set/clear or toggle OCx?
They seem to have gone.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For set/clear, you can have inverted IO on any pin. That affects both digital in and out and any digital peripheral connected to the pin.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Set and clear settings aren't needed any more, since each I/O pin has an inverter (for "clear on match", you would just enable the pin inverter). As for toggle, I'm not sure what the analog of that is on the XMEGA off the top of my head.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, but I'm not after PWM and if I invert the pin, that will happen immediately, so that's no use, I want to have the pin output change at a precise future time, like I could with the pre-Xmega.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Xmeagre
Are you trying to belittle the XMEGA range? :wink:
Quote:
using an Xmega32
The numbers and letters AFTER the 32 are important to know. There maybe some difference in timer modes with different types of Xmegas.

I have been delving into the Xmega for a month now, the only thing I know for sure is that "I know nothing, NOTHING". Whatever you knew about the Mega chips throw out the window (or linux ... :? ) and start again.

edit I guess you have seen "15.6.3 Port Override for Waveform Generation" this is for the AU Xmegas, maybe the same with other versions.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have used the XMega256 already in a product, but this the first time I've wanted to use the set/clear on counter compare. I'm fairly convinced that it has disappeared.
I know that I can have 4 PWM channels per counter, and that they are buffered, but that doesn't help me, as they all have to run off the same counter, and thus have the same MAX period.
With the old system, I could leave the counter free running, and have separate counter compares that would affect OCxA and OCxB. I think I'm going to have to set/clear manually in the ISR now, which is a bit worrying, as there will potentially be 8 ISRs vying for attention.

Four legs good, two legs bad, three legs stable.

Last Edited: Sun. Jan 20, 2013 - 12:46 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

From the ATMega64(L) data sheet:
This is what I can't find in any of the Xmega data.

Attachment(s): 

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm using the FREQ mode (frequency mode, same as CTC??) with the CCA register.

Under 14.12.2 CTRLB – Control register B

Quote:
• Bit 7:4 – CCxEN: Compare or Capture Enable
Setting these bits in the FRQ or PWM waveform generation mode of operation will override the
port output register for the corresponding OCn output pin.
so looks like you can do it, everything is pretty blurry for me at the moment and I haven't been drinking...maybe that's the problem. :roll:

Looks like you set or clear the invert bit depending on the action required on compare, no idea about toggling though.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Surely changing the invert bit will invert the output immediately?
Also, I don't want FREQ mode, or CTC, I just want to set or clear an output pin when a the counter matches the compare value.
I don't know why this is so difficult to explain:
What I'm after is to have counter timer x free running, from 0 to 6555, then resetting to 0
Four separate compare channels that can be programmed to set or clear four separate outputs in hardware at four separate times in the future. Once the appropriate ISRs kick in, they can read the compare registers, add a value that equates to the time in the future that the output pin needs to change the next time, and exit. Ad infinitum. Rock solid, no jitter. No relationship between the four channels except that they share the same counter.
But as I keep saying, I think Atmel have disposed of this functionallity in the Xmega, which is a shame, as it would have worked brilliantly with the open drain capability of the output pins.

John

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You mean, for example, something like this?

#include 
#include 

// 123 Hz symmetric sq.wave on OC1A, 456 Hz on OC1B
#define OCR1AINC (F_CPU/8/2/123)
#define OCR1BINC (F_CPU/8/2/456)

ISR(TIMER1_COMPA_vect)
{
    OCR1A += OCR1AINC;
}
ISR(TIMER1_COMPB_vect)
{
    OCR1B += OCR1BINC;
}

int main(void)
{
    // OC-pins output
    DDRD = (1<<4) | (1<<5);
    // Timer 1 in normal mode (0)
    // Toggle A,B at comp.match
    TCCR1A = (1<<COM1A0) | (1<<COM1B0);
    OCR1A = OCR1AINC;
    OCR1B = OCR1BINC;
    // Enable comp.match interrupts
    TIMSK1 = (1<<OCIE1A) | (1<<OCIE1B);
    // Presc. 1:8 for 1us tick
    TCCR1B = (1<<CS11);
    sei();
    
    while(1)
        ;
}
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Pretty much, yes, but I wouldn't use the toggle.
Its a serial format, I don't know the proper name, but it's used in various places.
Basically, alls bit start by pulling the line low, all bits are the same length(except the start bit, in this case). The code distinguishes between one and zero based on the length of time the line remains pulled low.
So I don't want a continuous waveform.

I have been thinking about this, and I think I will have to do the following:
"Shadow" an eight bit port in RAM.
Write all the Output Compare ISRs so that they simply read their bit of the shadow, write it to the port, signal that they've done so and return. All the heavy lifting can be done in the main program.
That way, I shouldn't have a big problem with jitter and latency when all eght channels are sending at once. I can write the ISRs in assembler to keep them lean.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My suggestion is to use compare match(s) as trigger source(s) for DMA channel(s) and moving appropriate bytes to PORTx_OUTSET/OUTCLR/OUTTGL registers for set/clear/toggle operation of desired pins. In this method, waveform generation pins are not used necessarily and several pins can be changed by each compare channel trigger.

Ozhan KD
Knowledge is POWER

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the suggestion, it could work, but not for 8 channels.
Even if it did work, I don't believe that the DMA method would be totally jitter free.

Since Dean seems to be ignoring this thread now, I assume that means I'm right about the lack of this feature in the Xmegas, so I'll go with my method proposed above.

John

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry, I wasn't ignoring it - I don't know the answer off the top of my head, and didn't have time to ask around today. Tell you what, send me an email to dean_patrick.camera@
and I'll chase it up for you.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, thanks.

John

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Poor Dean, hard to be the only genius around, everyone relies on him... :wink:

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've responded directly to John via email - but to help others searching for this in the future:

The exact functionality of the old MEGA timers does not have a direct analog in the new XMEGA's streamlined timer/counter modules -- the SET/CLEAR functionality is replaced by the port pin inverter, and the possibility of implementing crazy protocols using the CTC mode dynamic clear/set/toggle bits wasn't a consideration when the module was redesigned.

That said, the AWEX module may be of use when coupled with a timer and DMA to produce synchronized signals.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Toggling a pin on compare match is a very useful feature in MEGA timers, when using normal mode. By addition of 2 or 3 independent OCRx_ADD to compare registers in compare ISRs, 2 or 3 independent frequencies can be generated by a single timer (I have designed a 3 axis motion controller by using this method). From this point of view, MEGA timers are more powerful than XMEGA timers and this is not a good news for XMEGA designers.

Ozhan KD
Knowledge is POWER

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Dean, although I take issue with the term "crazy".
Most IR remotes that I've ever had cause to examine use a similar scheme, as do DiSEqC(although modulated), and CEC. There are probably many more that I'm not aware of, as it is a very robust protocol that resynchs on each bit and can mitigate data-slicing problems when used with RF.
Having said that, Dean has been extremely helpful and patient, and I have modified the thread title in recognition of this.

John

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You could use another timer per pin with the minimum period to toggle a pin on an event. That's assuming you have enough timers (the XMegas are great for the # of timers, but in my experience they get used quickly).

Jeff Nichols

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is only one pin toggle event, as far as I understand.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I went back and reread your original post. I'm still hazy on the details of what exactly you're trying to do but I think now that my suggestion may not help you.

Basically, you can use a timer as an event->pin toggle converter. It comes at the expense of 1 clock cycle, but at least this is deterministic. You'd need all 8 event channels for the 8 outputs, but you won't find the required 10 timers on any current XMega (at least not that I've seen).

Jeff Nichols

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

although I take issue with the term "crazy".

I'll second that. While "crazy" is a strong word, same period for all bits with a longer on-time for "1" and shorter for "0" is not rare or even unusual IME. (As with John, I've forgotten the name...) It allows two sides to communicate without strict clock rate limits (assuming the receiver can analyze the period. When clock rate is fairly well known, the period can almost be ignored. I have several apps where I trigger on the rising edge of the incoming signal and simply sample e.g. 1ms later.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry, "crazy" is just my own brand of lingo - I didn't mean to imply the idea was actually crazy, just outside the strict definition of "timer".

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I didn't mean to imply the idea was actually crazy, just outside the strict definition of "timer".

Well, I'd question that explanation as well. Why >>couldn't<< a timer be used as described to generate the pulse train? How else would you accomplish this not-rare task, then?

Now, I've also used the "leapfrog" approach to generate separate frequencies for each compare channel on an AVR8 by using "toggle on compare match", free-running a timer, and adjusting the compare match value every trip by +n. Apparently that would be just as difficult with an Xmega as the feature is apparently "lost".

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

To generate a single pulse train like that I'd expect PWM would be the way to go. Generating multiple streams from a single timer seems to be the part that can't be done.

Jeff Nichols

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
"crazy" is just my own brand of lingo
These older guys don't understand..it's like "sick" or very good. :-)

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly