XMEGA

Go To Last Post
440 posts / 0 new

Pages

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

Quote:

but 14bit A/D

Caleb, Caleb, Caleb--Didn't you read what Uncle Atmel said in the product announcement, in front of God and everyone, nearby to "available now":

Quote:
hardware support for oversampling to increase resolution to 16 bits without extra cost.

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

theusch wrote:
Quote:

Check out slide 13 too.

Where 76% would consider a PIC for their next design, and 32% an AVR?

I think Flylogic.net/blog put the nail in the PIC MCU market honestly.

None of the PICs are secure against "light" attacks.!@!@!@!@!

Want to secure your hardwork? Stay away from Microchip!

Regards

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

The AES/DES hardware crypto instructions are nice welcome too.

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

Yes, Now add a little PKI functionality and people will swarm to the OTS AVR's instead of smartcards.

One final feature they could add immediately is to allow switching between internal clock oscillator and external world via a register setting :).

Regards

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

That is the impression I get actually, that one can move between clock sources on the fly. (at least from a first glance that's how it appears to me)

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

No fricken #$#@??? WOW!!!

Okay Flylogic, tear one down PLEASE!

Regards

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

Quote:
one can move between clock sources on the fly.
A high tech house fly!! What will they think of next.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Are you sure you all have any workbench area left to drop a new STK-600 starter kit on :roll: . I took a quick look at the details on the ATMEL site, the only thing I don't like (and like at the same time) is the Seperate Package boards for each package type. I'm hoping the darn thing ships with one or two types so it's a quick startup.

Now is this really supporting all AVR products, and should I therefore place my beaten up 500 on a shelf for future generations to use?

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

Quote:
Are you sure you all have any workbench area left to drop a new STK-600 starter kit on
YEP, I'm getting rid of the Motorola EVM shortly which takes about 4 times the space of a STK600 :) (it's been sitting on my bench for about 16 years :? )

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

js wrote:
(it's been sitting on my bench for about 16 years Confused )

WOw, it took you 16! years to get rid of Motorola, wonder how long it will take to get rid of Atmel xmegas???

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

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

glitch wrote:
IAR is traditionally the first compiler with support, but the other compilers are sure to follow in short order.

The men from Atmel told me that all the major AVR C compiler writers would have X support pretty much from day one.

For example, I'm assuming Eric/Joerg may have a new avr-libc/WinAVR in the offing fairly shortly?

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

I've been reading the XMega-A manual, and it looks like one of the agendas with this series was to uplevel the quality of the peripherals by a big chunk. Seems like every module is improved over the regular Mega series, and they're specified to avoid the need to have each new chip create gratuitous register-level incompatibilities.

For example, look at the I/O port design. It's got totem pole drive, pullup, pulldown, wire-or, wire-and, and bus-keeper modes. Slew rate control. (Which makes the I2C module handle SMBus a lot better...) More IRQ triggering options; you don't need an external interrupt pin to get active-low triggering, and there are more single edge trigger options too. None of that dodgey side effect dance to trigger pullups.

So the XMega driver codebase is going to be a lot different from the current stuff, but it'll be a lot easier to make it do the right sort of things. Compatibility between chip versions will be better, and so will interoperation with other systems. Even if XMega just means "same old instruction set but all-new peripherals", it's looking to be very nice...

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

rocketman49 wrote:
Are you sure you all have any workbench area left to drop a new STK-600 starter kit on :roll: . I took a quick look at the details on the ATMEL site, the only thing I don't like (and like at the same time) is the Seperate Package boards for each package type. I'm hoping the darn thing ships with one or two types so it's a quick startup.

Now is this really supporting all AVR products, and should I therefore place my beaten up 500 on a shelf for future generations to use?


While the STK500 had something like 10 DIP sockets to accomodate all the DIP packaged AVRs the STK600 requires just one socket for all of them (though you have to put the right "routing card" for the selected device in the middle of the "sandwich" but it's actually a much neater system than the STK500 I think.

The same system allows sockets for other package types to also be added easily (so no more needing boards like STK501)

With the right carriers is supports all the AVR8s, the Xmegas (I obviously didn't get a chance to try that) and the AVR32 UC3 models.

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

theusch wrote:

Quote:
Availability and Pricing.
The first devices, ATxmega128A1 and ATxmega64A1 are both offered in 100-pin TQFP and BGA packages and are available now.

What part of "available now" am I having trouble understanding? I seem to repeatedly have problems with that term, especially when related to Atmel product announcements. Does that mean "Several of our 1M unit customers plus tool developers got a few of the first small engineering batch of working chips. Thus, for them, it is indeed 'available now'."

To me, "available now" means that ordinary people like myself can place an order at the disti and/or the rep, and at least get in line with my order of specific part numbers even if delivery is a ways off.

Well, Lee, have you actually tried to order samples? What did your disti/rep say? ;)

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

nleahcim wrote:

It is a pity that there are no CAN XMEGAs, or any smaller than 44 pins. I would really love to see a "ATXMEGACAN168". That would solve a lot of problems for me.

These are just the first parts out. XMEGA is whole family of parts.

nleahcim wrote:

Lastly, is there GCC support for the XMEGAs? I couldn't find anything on the WinAVR sourceforge page about a new release...

I have mentioned before in different posts on these forums, about an upcoming WinAVR release in Februrary. I've moved that back slightly to the middle of March.

The reason for the release is preliminary support of the XMEGA. :) I haven't been able to officially talk about this until the product was officially announced.

nleahcim wrote:

And the Atmel XMEGA site seems to only talk about IAR.

Maybe I'm just missing it, but where does it say this?

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

Hmmmmmmm

Very nice especially the pico power side of it.
The 12 bits ADC & DAC is very welcome.

Ken

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

Quote:

Well, Lee, have you actually tried to order samples? What did your disti/rep say?

Way ahead of you, EW--read down to:
Quote:
Can't wait. Slathering. Ordered samples from the Atmel Web site today. After all, the announcement said "available now", so I'm getting into line.
;) So "we'll see" after the wheels churn.

Lee

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

Quote:
However, you may be interested in the upcoming ATmega1284P. I don't know the pin-out for this chip, but think mega128, with 128K Flash, 16K RAM, 4K EEPROM and PicoPower.

Judging by the pinout in the RZRaven hardware user's guide, this is nothing more than a doubled Mega644, as the part number would indicate. If it is in DIP the robot people will love it with the bigger SRAM and flash. But not much use as a '128 drop-in. ;)

Lee

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

theusch wrote:

Quote:

It is a pity that there are no CAN XMEGAs, or any smaller than 44 pins. I would really love to see a "ATXMEGACAN168". That would solve a lot of problems for me.

Not having small CAN (on classic and X) seems to be a drawback for me as well, for CAN "sensors" that only need limited pins. And it sure would be nice to have the X features in a Mega48-class. But if they really do come through on the pricing the 44-pin A3/A4 wouldn't be too bad.

It is funny to me that last I checked, the cheapest way to get a CAN connected MCU was to get a very basic MCU and attach it to a Microchip MCP2515. This just seems to me to be a massive hole that Atmel could easily fill. There is also a huge hole in the market for physically small CAN connected MCUs. Last I checked the best out there was either the AT90CAN128 in a 9x9mm QFN package or a Renesas R8C/23 in a 9x9mm LQFP package (I would consider the Renesas part to be smaller as QFNs require essentially all traces to go out away from the center of the part). Too bad it's a Renesas part and I have very little interest in learning yet another new family of parts.

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

EW wrote:
nleahcim wrote:

It is a pity that there are no CAN XMEGAs, or any smaller than 44 pins. I would really love to see a "ATXMEGACAN168". That would solve a lot of problems for me.

These are just the first parts out. XMEGA is whole family of parts.


So are there any plans for anything like what I'm talking about? I've been asking for years for an AT90CAN168 and still haven't seen it - so I guess I'm not keeping my hopes up anymore...
Quote:

nleahcim wrote:

Lastly, is there GCC support for the XMEGAs? I couldn't find anything on the WinAVR sourceforge page about a new release...

I have mentioned before in different posts on these forums, about an upcoming WinAVR release in Februrary. I've moved that back slightly to the middle of March.

The reason for the release is preliminary support of the XMEGA. :) I haven't been able to officially talk about this until the product was officially announced.

nleahcim wrote:

And the Atmel XMEGA site seems to only talk about IAR.

Maybe I'm just missing it, but where does it say this?


Glad to hear about the upcoming release! IAR is talked about, albeit briefly, in AVR1000

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

Digging around in the docs, it appears that STK500 and ATAVRISP2 and similar "serial ISP" tools are dead for the Xmega. So if I get one into my sweaty palm, is it JTAGICE2? STK600? a tool similar to ATAVRISP2?

Drilling down on the devices to ATxmega64A1 http://www.atmel.com/dyn/product... it DOES list the ATAVRISP2 and JTAGICE2 along with STK600 and 'Studio4. Must be a different MkII firmware, then, eh?

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

They could have replaced some of the SPI's with other stuff, like CAN , ETH etc. then the chip would have been great :)

But still a pretty nice chip, looking forward to testing it.

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

Quote:

So are there any plans for anything like what I'm talking about? I've been asking for years for an AT90CAN168 and still haven't seen it - so I guess I'm not keeping my hopes up anymore...

Our wish has come true (but not on Xmega yet): CAN in a 32-pin package, plus other toyz: http://www.avrfreaks.net/index.p...

Lee

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

nleahcim wrote:
This just seems to me to be a massive hole that Atmel could easily fill. There is also a huge hole in the market for physically small CAN connected MCUs. Last I checked the best out there was either the AT90CAN128 ...

You might be interested in the ATmega32C1 then. (QFN32)

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

Quote:
Bit 4:0 - PLLFAC[4:0]: Multiplication Factor
The PLLFAC bits set the multiplication factor for the PLL. The multiplication factor can be in the
range from 1x to 31x. The output frequency from the PLL should not exceed 200 MHz. The PLL
must have a minimum output frequency of 10 MHz.

200MHz/4096 = 48.8kHz?

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

RES wrote:
Quote:
Bit 4:0 - PLLFAC[4:0]: Multiplication Factor
The PLLFAC bits set the multiplication factor for the PLL. The multiplication factor can be in the
range from 1x to 31x. The output frequency from the PLL should not exceed 200 MHz. The PLL
must have a minimum output frequency of 10 MHz.

200MHz/4096 = 48.8kHz?

where did the 4096 come from? I'm not even sure what it is you're trying to say/ask

The minimum input clock is 440KHz (as stated in the documentation) The maximum input clock (to the PLL), if you back calculate from the max multiplier of 31, is 6.45MHz

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

An ATtiny861 has a PLL can run @ 32MHz max., and 10-bit PWM, makes 31.25kHz samplerate, right? :?

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

theusch wrote:

I came across an interesting bit that I've got to dig into further--"locked" I/O configuration, unchangeable by code. Then do we get a way to >>ISP<< the I/O registers, kind of like fuses? Gotta dig further.

No, the I/O is still set by software. But you have a lock bit that is programmable by software, once set, the I/O configuration cannot change. The only way to clear the lock bit would be a reset. The idea is so you can set up your I/O and then protect it from accidental changes later in execution.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

RES wrote:
An ATtiny861 has a PLL can run @ 32MHz max., and 10-bit PWM, makes 31.25kHz samplerate, right? :?

Well nothing on the xmega can actually run at 200MHz. The fastest subsystem clock is at 4x the CPU clock (which has a maximum of 32MHz). However, the timers appear to work off of the periperal clock, which is the same as the CPU clock. Thus your timer is limited to 32MHz operation. (I haven't seen any "high speed" 2x or 4x peripherals yet... though I haven't looked that hard)

[edit]
A quick search of the PDF for "PER2" and "PER4" shows that they only show up in the clock section, and in a block diagram. So it looks like these clocks are currently not used. (though some functions are described in other documents, so they may pop up there) [my guess is that the external bus interface would be a good candidate for the faster clock, though it is not mentioned there]

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

John_A_Brown wrote:
I saw that, but, looking at the DMA trigger information, I was unable to see how a strobe from an external device could be used in the DMA system. I'll look into it further.

John--as far as I can tell streaming to/from an I/O port should be a standard DMA function. Look in the datasheets (actually the A family doc) at the SRCADDR and DESTADDR registers, a 24-bit pointer into the universal address space. PORTn (PINn?) is just one of those addresses. [An interesting very small side note probably insignificant: I don't see a spot in the universal address space for R0-R31, which used to be SRAM address 0. Rarely used it myself, though the compiler did sometimes when a pointer to a register variable was needed.]

Anyway, see the DMA app note AVR1304 http://www.atmel.com/dyn/resourc...
which should have almost the right example in the source code. "Almost" 'cause it is from SRAM streaming to a port. Ignore the interesting cut/paste typo

Quote:
2 Module Overview
This section provides an overview of the basic configuration options and functionality of the DAC. Section 3 then walks you through the basic steps to get up and running, with register descriptions and configuration details.
2.1 DMA Channels
In addition to ...

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

MMMmmm, the ATxmega64A4 looks delicious, I'll definately be looking to get one when it comes out to replace my ATmega644 in my project... so many new things I can do....

Edward

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

Pity it is not pin compatible with other chips :(

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

By the way, I don't think anyone has noted it so far in this thread but did anyone spot the accuracy on the internal oscillator? When Atmel presented the devices to me this is one of the things I thought looked particularly attractive if it meant reliable, crystaless, UART comms (probably accounts for about 5-10% of Freaks traffic!!)

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

Quote:
one of the things I thought looked particularly attractive if it meant reliable, crystaless, UART comms (probably accounts for about 5-10% of Freaks traffic!!)
since no dip packages (yet? ever? never?), I doubt you will see the 'dip'(2 meanings) freaks user using these things, except on pre-made boards that will most likely include a crystal. So the usart traffic count will remain as high as always (I'm a 'dip' user, both meanings). But, looking at the datasheet, I think your FAQ signature will become quite large, and you may have to give the xmega a section of its own.

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

Quote:
Too bad it's a Renesas part and I have very little interest in learning yet another new family of parts.

I like the Renesas series of micros. I haven't used the R8C series, but some of the M16C series seems like it would be comparable to the Xmega. Most of my recent projects have either used Atmel AVR or Renesas M16C or in some cases a combination of both.

One thing that is for sure is that the AVR Freaks forums are much better than the Renesas Rulz forums.

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

While the preliminary XMEGA datasheet doesn't list the accuracy of the internal oscillators, application note AVR1003 ( http://www.atmel.com/dyn/resourc... ) shows the high speed internal oscillators have a factory accuracy of 1% (rather than the typical 10% of AVRs). That's very good news to people who use an external crystal just to have acceptable UART communications at near room temperature. Thanks, Atmel!

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

I still have to find time to dig into it's datasheets (I'm about to release a new AVR based product to the market...), but for shure 1% for the internal oscilator is really welcome for us. Anyway, our systems always use 32KHz crystal for RTC, thus we systematically calibrate the internal oscilator for serial comms.

But that doesn't mean that this feature is not welcomed.

Guillem.
"Common sense is the least common of the senses" Anonymous.

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

kevin123 wrote:
Quote:
Too bad it's a Renesas part and I have very little interest in learning yet another new family of parts.

I like the Renesas series of micros. I haven't used the R8C series, but some of the M16C series seems like it would be comparable to the Xmega. Most of my recent projects have either used Atmel AVR or Renesas M16C or in some cases a combination of both.

One thing that is for sure is that the AVR Freaks forums are much better than the Renesas Rulz forums.


Do you have any experience with the open source C compiler for Renesas parts? I've looked at it a couple times in the past - and every time it looks like it's not really ready for mainstream... As in, it looks like you still have to compile it yourself (http://people.redhat.com/dj/m32c/) and it still doesn't even support all the part's opcodes (http://people.redhat.com/dj/m32c...)

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

curtvmsince no dip packages (yet? ever? never?), I doubt you will see the 'dip'(2 meanings) freaks user using these things, except on pre-made boards that will most likely include a crystal.[/quote wrote:

Well I don't know about your application but we use about a million AVRs a year and if we can save the $0.10 that an external crystal costs then we just saved $100,000. Sure it's not THAT much, but it's fairly welcome. (and I don't know about other's IQC rates but we maybe find something like 0.1% failure rate on some of the crystals we use - if that causes the whole unit to fail it costs $10's if not $100's in support costs on each failed unit)

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

nleahcim wrote:

Do you have any experience with the open source C compiler for Renesas parts? I've looked at it a couple times in the past - and every time it looks like it's not really ready for mainstream... As in, it looks like you still have to compile it yourself (http://people.redhat.com/dj/m32c/) and it still doesn't even support all the part's opcodes (http://people.redhat.com/dj/m32c...)

You should take this to the Off Topic Forum.... Or another site altogether since this is AVR Freaks.

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

Cliff wrote:

Quote:
Well I don't know about your application but we use about a million AVRs a year and if we can save the $0.10 that an external crystal costs then we just saved $100,000. Sure it's not THAT much, but it's fairly welcome. (and I don't know about other's IQC rates but we maybe find something like 0.1% failure rate on some of the crystals we use - if that causes the whole unit to fail it costs $10's if not $100's in support costs on each failed unit)
The savings will be even more than that: assembly-cost in production will be less as well. Less parts to place, less costs.

Nard :)

A GIF is worth a thousend words   She is called Rosa, lives at Mint17.3 https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

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

Quote:
Anyway, our systems always use 32KHz crystal for RTC, thus we systematically calibrate the internal oscilator for serial comms.

And with the Xmega without software!

Two built-in Digital Frequency Locked Loops (DFLLs) can be used to improve the accuracy of
the 2 MHz and 32 MHz internal oscillators. The DFLL compares the oscillator frequency with a
more accurate reference clock to do automatic run-time calibration of the oscillator. The choices
for the reference clock sources are:
• 32 kHz Calibrated Internal Oscillator.
• 32 kHz Crystal Oscillator connected to the TOSC pin

Look ma, no hands!

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

Let me just say for the record- I'm in favor of accurate internal oscillators.

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

I my company, we had been using many Cypress PSoC without Xtal, and we never had problems with serial comms. 1% straigh from factory, no calibration. No costs.

We quote about 0.03€ to mount any small SMD parts, thus an Xtal that costs us 0.1€, in fact it's about 0.13€ or a little more.

I should definitively find time to read the datasheets. How accurate is internal 32KHz oscillator? I hope is better than the one used at AT91SAM7 families.

Guillem.
"Common sense is the least common of the senses" Anonymous.

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

Guillem Planisi wrote:
I should definitively find time to read the datasheets. How accurate is internal 32KHz oscillator?.
From AVR1003 I referenced above:
Quote:
The 32.768 kHz internal RC oscillator (RC32K) is factory-calibrated to 32 kHz with an accuracy of 1% at 3V and 25°C. The calibration value is stored in the calibration row and is automatically loaded into the oscillator’s calibration register (RC32KCAL) on reset. This value is read and write accessible for the user

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

OK, I haven't had much caffeine yet this morning, but:

24 hrs/day, 60 min/hr, gives 1440 minutes/day.
1% of 1440 = 14.4, or about 14 minutes per day.

I guess one could individually measure and tweak their systems, but if it really is an RTC, then to me a crystal still makes sense.

JC

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

1% certainly is not good enough for accurate timekeeping... I don't think anyone was suggesting that. It should, however, be good enough for serial communications.

Quote:

Two built-in Digital Frequency Locked Loops (DFLLs) can be used to improve the accuracy of the 2 MHz (1%) and 32 MHz (1%) internal oscillators. The DFLL compares the oscillator frequency with a more accurate reference clock to do automatic run-time calibration of the oscillator.

The choices for the reference clock sources are:
• 32 kHz Calibrated Internal Oscillator. (1%)
• 32 kHz Crystal Oscillator connected to the TOSC pin

I am curious, however, how one could "improve" the accuracy of a 1% accurate clock by using another 1% accurate clock? (all 3 oscillators 32K, 2M, and 32M are factory calibrated within 1% @ 25C / 3V) So I'm thinking that the external 32K crystal is really the only viable "accurate" time source to calibrate against.

[edit] added the accuracies, ane emphasis in the quote

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

Last Edited: Thu. Feb 28, 2008 - 05:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Depending on the drift numbers over time, temperature, & Vcc levels of one (or more) of the internal clocks, it may give very satisfactory results to do a one-time cal on the bench against a known signal. For USART comms the xxxCAL steps on classic AVRs are fine enough for this. I/We will have to dig a bit to see if the steps in the CAL register for the 32k are fine enough to give "good" results for timekeeping. My rule of thumb with an uncalibrated DS1305/6 is a minute a month is good enough, and nearly all built boards come within that. Lessee-- 40k minutes/month, so 1 minute is about 25ppm, which is about the spec on many crystals anyway. Without hard numbers, the "average" on a batch is less than half a minute, so maybe 10-20ppm. That's good enough for all my apps for logging and timestamping.

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

curtvm wrote:
since no dip packages (yet? ever? never?)

We don't need your stinkin' dip packages...lol

Join the dark side luke... (in a very breathy, puffer medication sort of way). :D The STK600 will help with that won't it?

Last Edited: Fri. Feb 29, 2008 - 06:29 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Please correct me if im wrong:

With the DMA in xmega the cpu will not be
blocked when writing on EEPROM like in the atmega.

Pages