Thoughts on my first XMEGA project

Go To Last Post
62 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've gotten a lovely sine wave tonight out of my XMEGA A sample on its PA2 pin using its integrated DAC. What fun it is to have an AVR output analog signals. I'm using an assembly language output loop of 9 cycles running at 32MHz using a 24-bit phase accumulator and 8-bit output. Next step will be to use 12-bit output.

Initial impressions:

  • The 2 MHz internal oscillator is well-calibrated. Using the PLL to boost to 32 MHz is just plain fun. A sine wave that should be 1000.086 Hz measures 1000.09 Hz on my Fluke ScopeMeter.
  • Goodbye "magic" frequency crystals for UART output. With the 4095 possible values of BSEL (the replacement for UBRR) and using BSCALE to bit shift BSEL from -7 to +7 bits, it's possible to get very close baud rates, even with formerly impossble situations like 115.2Kbps with a CLK of 1MHz and 300 baud with a CLK of 32MHz. I'm extending AVRCalc ( http://www.avrcalc.com/ ) to handle selecting the best BSEL and BSCALE for a given clock frequency and desired baud rate.
  • Mouting on a STK600 and using a JTAGICEMkII for programming/debugging works as well as one would expect. Performing this on a MacBook Pro using VMWare Fusion and WinXP works better than I would have expected. I'm looking forward to when AVR ONE supports XMEGA debugging using PDI.

I wonder if I just posted the first XMEGA usage report?

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

Oh...I am Green with envy...it sound like fun. I should get my rear in gear and get some samples too. Congratulations. :D

-Jim
http://www.noniandjim.com
Analog and Digital Electronics
Music Synthesizers

Last Edited: Sat. Jun 21, 2008 - 08:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks, Jim. From your signature, I imagine that you'll enjoy the DAC capabilities as well. Completing a sample request form on Atmel's web site takes only a few minutes.

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

Really looking forward to this beastie. It will save a bunch of peripherals (DACs, etc) in my biggest project.

Yum!

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

Agreed, Jim. Even in small projects, I doubt I'll use as many crystals since the new RC oscillators are more accurate and the USART baud rate selection is much more robust.. I'm waiting real specifications for the RC oscillator to show up in the preliminary data sheets. I did read in one App note about a 0.5% accuracy for the RC oscillator at room temperatures.

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

Quote:
Goodbye "magic" frequency crystals for UART output

When the "men in black" first gave me the Xmega presentation my first thought was "thank God for this - imagine the reduction in posts to 'Freaks this is going to have!"

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

clawson wrote:
When the "men in black" first gave me the Xmega presentation my first thought was "thank God for this - imagine the reduction in posts to 'Freaks this is going to have!"
There are certain categories of posts for which a decrement in posts would be nice! Along those lines, I hope that Atmel adds tables of pre-computed BSEL/BSCALE/U2X values for clock frequencies/UART speeds to their XMEGA A datasheet similar to what they now do for UBRR/U2X tables.

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

I implemented 12-bit DDS. The length of the output loop is 16 cycles (1). At 32 MHz, that has a output frequency of 2 M samples/sec which is double the maximum conversion rate of 1 M samples/sec. I'm thinking the next step for the project will be to convert the code to be an audio-frequency generator with a output sample rate of 44 kHz using the XMEGA event system tied to a timer. At 44 KHz, there's 727 CPU cycles per output. That's enough time to process UART input/output and create new waves on the fly using double buffering. Using the event system and interrupt priority will also help so that the event-driven DAC output occurs automatically without timing jitter (event system) and the interrupt to put a new sample in the DAC DATA register will occur at a higher priority than the UART input/output interrupts (if the two interrupts are triggered at the same time).

For those curious, here's the code for 8-bit and 16-bit output at 9 and 16 cycles per loop:

;;; Below loop makes assumptions:
;;; 1) The X register points to CHxDATAH and the DAC CHxDATA is left-aligned 
;;; 2) The Z register (pointing to the wave table) is aligned on
;;;    256-byte boundary and is 256 bytes long so that rolling over is trivial
        lpm	r0,Z	        	        ; 3 (load byte from wave table)
        st     X,r0		                ; 1 (output to DAC CH0DATACH
        add	PHASE_ACCUM0,PHASE_INCR0	; 1 (add 24-bit phase increment)
        adc	PHASE_ACCUM1,PHASE_INCR1	; 1
        adc	PHASE_ACCUM2,PHASE_INCR2	; 1
        rjmp	DdsLoop8	        	; 2 => 9 cycles (repeat)
;;; Below loop makes assumptions:
;;; 1) The low byte of DACA_CH0DATA will NOT be equal to 0xFF
;;;    (or else just resetting the low byte of X will not be be sufficient)
;;; 2) The X register points to CHxDATAL and the DAC is right-aligned 
;;; 3) The Z register (pointing to the wave table) is aligned on
;;;     256-byte boundary and is 512 bytes long
DdsLoop16:
        lpm	r0,Z+	        	        ; 3 (low byte of wave, incr Z)
        ldi     r26,low(DACA_CH0DATA)           ; 1 (Reset X pointer to DATAL)
        st	X+,r0		                ; 1 (store in DAC DATAL)
        lpm     r0,Z                            ; 3 (load second byte)
        st      X,r0                            ; 1 (store in DAC DATAH)
        ;; r30 has advanced by 1 (to get high byte of table entry)
        ;; This is compensated by having PHASE_INCR2 (r30) be
        ;; SET TO ONE LESS THAN ITS REAL VALUE (which is precomputed above)
        add	PHASE_ACCUM0,PHASE_INCR0	; 1
        adc	PHASE_ACCUM1,PHASE_INCR1	; 1
        adc	PHASE_ACCUM2,PHASE_INCR2	; 1
        adc     r31,ZERO_REG                    ; 1
        andi    r31,0x01                        ; 1 (roll-over at 512 bytes)
        rjmp	DdsLoop16	        	; 2 => 16 cycles
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kevin,

Congrats on the first XMega project post!

Sounds like a fun project. Now all you have to decide is what to do with all those spare pins you save on not needing an R-2R ladder!

JC

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

Nice, Kevin!

I guess I'm going to have to put my bid into Atmel for some sample Xmega controllers.

I just wonder if they'll let me have a few.

But it'll be strictly assembly (JS is clapping and cheering) programming, as I'm not going to pay $650.00 for ImageCraft for C support for the Xmega.

I can think of a few uses for the DAC on the Xmega...

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

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

Hi JC, yes, it does seem like a good way to explore the new capabilities. (I'm working on the timer and event systems at the moment). Yes, one will save a few pennies on the R-2R ladder and maybe on an output driver as well. I haven't measured the output impedance of the DAC yet and the datasheet has TBD for the electrical characteristics of the DAC.

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

I was thinking of all of the spare I/O Pins saved by not using an entire port for an R-2R ladder, but I'll always takes pennies saved as a good thing, too!

Look out Jesper, there is a new DDS in town! :)

JC

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

microcarl wrote:
I guess I'm going to have to put my bid into Atmel for some sample Xmega controllers. I just wonder if they'll let me have a few.
I think it'll be in Atmel's best interests to give you a few.
Quote:
But it'll be strictly assembly (JS is clapping and cheering) programming, as I'm not going to pay $650.00 for ImageCraft for C support for the Xmega.
As an ImageCraft owner, don't you have access to the latest ImageCraft version which has XMega A support?
Quote:
I can think of a few uses for the DAC on the Xmega...
I'm sure you can!

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

DocJC wrote:
I was thinking of all of the spare I/O Pins saved by not using an entire port for an R-2R ladder, but I'll always takes pennies saved as a good thing, too!
Yes, saving 7 pins on an AVR is often a big win. But, so far I'm only using 3 I/O pins on this TQFP-100 package!
; PA2     DAC0 (DACA)
; PC2     RXD (USARTC0)
; PC3     TXD (USARTC0)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kmr wrote:
microcarl wrote:
But it'll be strictly assembly (JS is clapping and cheering) programming, as I'm not going to pay $650.00 for ImageCraft for C support for the Xmega.

kmr wrote:
As an ImageCraft owner, don't you have access to the latest ImageCraft version which has XMega A support?

I upgraded to the latest version of the ImageCraft compiler just a week or two ago, when I upgraded to Eagle 5.0. I hadn't even considered that the Xmega would be supported in v7.xx. I figured that ImageCraft would have bumped the revision up to 8.xx, especially seeings how the cost has jumped $300.00 in the last 2 to 3 years. I could spring for another $350.00, but not $600.00 to $650.00 that it now cost for my level compiler.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

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

Carl, I haven't gone through a version upgrade with ImageCraft, I don't know much they cost but I'd hope they'd only be 25% or so of the cost of a new license. But, gladly you're okay for XMEGA with your current version of ImageCraft. Nonetheless, for this first project, I'm using assembly (because of it's time critical nature) and am enjoying it!

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

kmr wrote:
DocJC wrote:
I was thinking of all of the spare I/O Pins saved by not using an entire port for an R-2R ladder, but I'll always takes pennies saved as a good thing, too!
Yes, saving 7 pins on an AVR is often a big win. But, so far I'm only using 3 I/O pins on this TQFP-100 package!
; PA2     DAC0 (DACA)
; PC2     RXD (USARTC0)
; PC3     TXD (USARTC0)

Wow, didn't know the AVR XMEGA came with its own generator! Hehe, I'm really excited about the XMEGA, I'd kill for a sample right now :(

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

Salgat wrote:
I'm really excited about the XMEGA, I'd kill for a sample right now :(
You should be able to get samples by completing a sample request form on Atmel's web site. It may or may not speed up your processing if you include "I'd kill for a sample right now" in your sample request :shock:

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

Well, I just submitted a request for 3 each of the ATxmega128A1-AU (TQFP) and the ATxmega64A1-AU (TQFP) Xmega flavors.

I'm really hoping that Atmel will accommodate my request, with at least one or two of each.

Rather then purchase an STK600 adapter card for the Xmega, I'm thinking of making my own evaluation PCB. It'll be far cheaper and I can customize the thing exactly how I want it. Of course, if Team Atmel wanted to send me an STK600/Xmega adapter card for use with my STK600, along with the samples, that would be just perfect!!!

Go Team Atmel!!!

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

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

Congrats! Sounds great! Thanks for the great AVRCalc BTW.

There are pointy haired bald people.
Time flies when you have a bad prescaler selected.

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

microcarl wrote:
Well, I just submitted a request for 3 each of the ATxmega128A1-AU (TQFP) and the ATxmega64A1-AU (TQFP) Xmega flavors.
Great - I hope that you get them, soon! I placed a request for 4 XMEGA128A1 late March and received 2 of them last week.

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

daqq wrote:
Thanks for the great AVRCalc BTW.
I'd glad that you've found it useful, David!

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

I just submitted a request for samples as well...although, I am with Carl...I might just do my own eval board. I want to put a Spartan 3E500 on the board with it...as well as an ethernet interface.

-Jim
http://www.noniandjim.com
Analog and Digital Electronics
Music Synthesizers

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

patchell wrote:
I just submitted a request for samples as well...although, I am with Carl...I might just do my own eval board. I want to put a Spartan 3E500 on the board with it...as well as an ethernet interface.

Well Jim,

I'm not planning on developing anything specific, per SE'.

I have been after zoomcityzoom about upgrading his Mega644 controller, so it uses STK500 compatible headers that are properly spaced and have only those components which are absolutely required on-board. He has come close with the announcement of his new controller board, but it still has extras that I wouldn't ever use, but it is in stamp form.

So I have been toying with coming up with my own Stamp-like controller, and with the Xmega coming on-line, it might be a good time to move forward with the concept.

But I still like zoomcitizoom's Mega644 controller board on the bench. It is very reliable and does a great job - it's only real flaw is that you can't connect two 10-pin IDC cables into two adjacent headers.

One thing I would like to try making with the Xmega is a nice 12-bit 0 to 36 volt bench style programmable power supply, capable of delivering about 5 amperes.

An arbitrary waveform generator would also be great.

And then there is my thirst for encoder translation and full servo control for my table-top mill. I think it would be fun to try my hand at developing a brush-less three phase servo motor control for my mill.

To date, I've not been able to achieve more then about 120 Inches Per Minute (IPM) rapid traverse with my current Mega644 servo control design - using zoomcityzoom's controller board. Where not talking hobby style servo control here; Rather, were talking about an axis motion control with encoder feedback and driving a 1/8 horse Pittman brushed DC motor. The increased clocking speed of the Xmega would hopefully provide the 200 IPM rapid traverse goal.

So, I guess I do have a lot of plans for the Xmega, after all. Now it's just getting my hands on a few Xmega controllers, and getting off of my lazy A$$...

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

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

microcarl wrote:
To date, I've not been able to achieve more then about 120 Inches Per Minute (IPM) rapid traverse with my current Mega644 servo control design - using zoomcityzoom's controller board. Where not talking hobby style servo control here; Rather, were talking about an axis motion control with encoder feedback and driving a 1/8 horse Pittman brushed DC motor. The increased clocking speed of the Xmega would hopefully provide the 200 IPM rapid traverse goal.
If your traverse speed scales with the CPU clock increase, the gain from 20 to 32 MHz will get you to 200 IPM. Perhaps the better PWM controller on the XMEGA (with Advanced Waveform and Hi-Resolution extensions) will help as well.

An XMEGA stamp sounds really cool! The selectable slower slew rate on output pins will help hobbyists and prototypers with longer signal runs.

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

patchell wrote:
I just submitted a request for samples as well
Let us know when you get them -- it'll be interesting to see how quickly Atmel can fulfill requests at this time.

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

Quote:

So, I guess I do have a lot of plans for the Xmega, after all. Now it's just getting my hands on a few Xmega controllers, and getting off of my lazy A$$...

Yes...you do have plans...The brushless motor controller sound like fun. I have done voice coil motors a while back using DSP chips...but the new xMega should be able to do quite a bit all on its own. I bet it will work quite nicely. I guess you can do the commutating by looking at the back emf from each field with the A/D converters.

What I want is a generic board that I can do my development on...I generally do some sort of fancy hardware thing in an FPGA and control it with a micro controller...and generally with serial ports and or ethernet. I do my ethernet stuff right now on an Ethernut 2.1 board, but it runs from 5 volts and is a pain to interface up to an FPGA.

Best of luck Carl...I imagine we will see the results of your effort.

-Jim
http://www.noniandjim.com
Analog and Digital Electronics
Music Synthesizers

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

Carl posted that he's about to get his XMega sample. I've attached the DDS code I ported to XMega for anyone who wishes to get started with some working XMega code. Code includes setting the 2MHz RC oscillator and configuring 16x PLL mode as well as configuring with the new USART divisor settings.

Attachment(s): 

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

Kevin, ... what a neat first project using Xmega DAC-capabilities. I voted for that in an earlier Atmel survey. Who knows it contributed ...

Happy sinewaving :)

Nard

A GIF is worth a thousend words   She is called Sylvia (2018), lives at Mint18.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

Thanks, Nard. Yup, the DAC is cool!

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

kmr wrote:
The 2 MHz internal oscillator is well-calibrated. Using the PLL to boost to 32 MHz is just plain fun.

Am I right to say that you can clock the XMEGA A1 only with 16MHz externally? I expected to clock it also with 32MHz...

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

From section 7.6 of the "A" datasheet:

Quote:
Four different reference clock sources can be chosen as input to the PLL:
• 2 MHz internal oscillator
• 32 MHz internal oscillator divided by 4
• 0.4 - 16 MHz Crystal Oscillator
• External clock

So you'd use the 16MHz and a x2 in the PLL

On intriguing phrase in the datasheet:

Quote:
The output frequency from the PLL should not exceed 200 MHz.

(crikey!)

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

clawson wrote:
So you'd use the 16MHz and a x2 in the PLL
That'd likely work, but I haven't tested it. For this project, and the code that I posted, I used the 2MHz internal oscillator and 16x PLL. Excerpted:
;;; Initialize clock
        ldi     TMP_REG,0xD8    ; Protected IO Signature
        sts     CPU_CCP,TMP_REG
        ldi     TMP_REG,CLK_SCLKSEL_RC2M_gc       ; Set 2 MHz RC Oscillator
        sts     CLK_CTRL,TMP_REG
        lpm                     ; Wait for clock to be stable (4 cycles req)
        lpm
        
        ;; 2 MHz Internal RC Oscillator, 16x PLL
        ldi     TMP_REG,OSC_PLLFAC4_bm
        sts     OSC_PLLCTRL, TMP_REG

        ldi     TMP_REG,OSC_PLLEN_bm
        sts     OSC_CTRL, TMP_REG
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Am I right to say that you can clock the XMEGA A1 only with 16MHz externally? I expected to clock it also with 32MHz...

ce -- Are you planning to use an external clock? If so, why? As kmr implied, and my take after reading the docs, one of the advantages of the Xmega is the accurate internal clocks leading to a closer to single-chip app.

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:
As kmr implied, and my take after reading the docs, one of the advantages of the Xmega is the accurate internal clocks
I did more than imply. From the original post in this thread:
kmr wrote:
The 2 MHz internal oscillator is well-calibrated. Using the PLL to boost to 32 MHz is just plain fun. A sine wave that should be 1000.086 Hz measures 1000.09 Hz on my Fluke ScopeMeter.

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

Quote:

I did more than imply.

After I posted I went back trying to find specs on the accuracy of the internal oscillators and did not find any. Perhaps it was in another publication or announcement? Do you remember?

What sticks in my mind is my conclusion that for all but the most picky of timing work, the internal oscillators should be more than sufficient.

I suppose if one needed a particular frequency that could not be obtained via PLL multiplication -- say, multiples of the "colorburst" or other video frequencies? USB-friendly 12MHz & 24MHz are integer PLL multiples of the 2MHz so should be OK. The fractional baud rate system should eliminate "magic" frequencies for UART work.

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:
After I posted I went back trying to find specs on the accuracy of the internal oscillators and did not find any. Perhaps it was in another publication or announcement? Do you remember?
There were some specs I found last year looking in one of the XMEGA app notes. IIRC, an accuracy of 0.5% was mentioned, but no detailed temperature/error graphs were included. The data sheets (as you know) don't yet included RC accuracy specifications.
Quote:
The fractional baud rate system should eliminate "magic" frequencies for UART work.
I think it will definitely eliminate such UART crystal frequencies. Again, quoting from my first post in this thread
kmr wrote:
Goodbye "magic" frequency crystals for UART output. With the 4095 possible values of BSEL (the replacement for UBRR) and using BSCALE to bit shift BSEL from -7 to +7 bits, it's possible to get very close baud rates, even with formerly impossble situations like 115.2Kbps with a CLK of 1MHz and 300 baud with a CLK of 32MHz. I'm extending AVRCalc ( http://www.avrcalc.com/ ) to handle selecting the best BSEL and BSCALE for a given clock frequency and desired baud rate.

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

Wow, I found AVRcalc a useful program when I used it (few months before, though), so now it would be a 'must have' tool on my desktop, if finally I do something with my Xmega samples.

Great tool and nice job, Kevin.

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

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

Thanks Guillem, the next release of AVRCalc has been a bit delayed while I've been working on some issues related to it operating on Cocoa and Mac OS X.

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

kmr wrote:
Salgat wrote:
I'm really excited about the XMEGA, I'd kill for a sample right now :(
You should be able to get samples by completing a sample request form on Atmel's web site. It may or may not speed up your processing if you include "I'd kill for a sample right now" in your sample request :shock:
I did that and got an email back with a name and address and a message saying "We'll send your sample after we see it in the news".

/Jesper
http://www.yampp.com
The quick black AVR jumped over the lazy PIC.
What boots up, must come down.

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

Has anyone outside the USA received samples already?

Requested a few a week or two ago, but haven't received or heard anything. How long does it take normally?

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

Guillem mentioned that he received samples. I believe that he is in Spain.

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

jesper wrote:
I did that and got an email back with a name and address and a message saying "We'll send your sample after we see it in the news".
:lol: Wow, they really do have a sense of humor!

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

theusch wrote:

ce -- Are you planning to use an external clock? If so, why? As kmr implied, and my take after reading the docs, one of the advantages of the Xmega is the accurate internal clocks leading to a closer to single-chip app.

Lee, the first hardware design was done by a colleague. Actually we were surprised that the XMEGA can be clocked with 32MHz internally. But I wonder if the clock is accurate enough for stable UART baud rates. I need this stability over a wide temperature range.

/Christoph

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

About the samples, I received them about june or july, IIRC, but that was because we were pressing the local distributor for samples and other microcontrollers. So there were a lot of 'politics' ivolved in the overall operation.

As Kevin Rossenberg has stated quite correctly, I'm in Spain, and in that case it was Arrow the distributor that gave me the samples. But they were hardly pressed becasue they were about to loose all the microcontrollers that they sell to my now former employeer. That means a lot of money.

As I read at the datasheet few months ago, and later on confirmed by an Atmel representative, it seems that the internal clock would be quite accurate for USART baudrates and over a good temperature range.

I had done tests with ATmega1281 with internal oscilator, self calibrated with the internal async timer (with 32KHz xtal), over a wide temperature range, and it seems that it is quite accurate over a normal environment temperatures (I had tested it at -5ºC, all around 20-25ºC and 70ºC). So I hope Xmegas would be more or less the same or even better.

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

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

Do those samples have something printed on top that tells they're engineering samples?

I find having an engineering sample of a certain chip is always a bit special :)

I guess big company will receive samples easier and quickier then small businesses.

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

jayjay1974 wrote:
Do those samples have something printed on top that tells they're engineering samples?
I posted scans of my samples in another thread. Two things identified them as engineering samples, the letters 'ES' and well as 'G' meaning revision G whose errata was detailed in the datasheet.

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

Quote:

I guess big company will receive samples easier and quickier then small businesses.

That certainly will be true--when Cliff makes noises about a 1-million unit design-in, the vendors will take more notice than to our paltry volumes.

That said, though, a decent company will treat all customers in a "fair" manner. While my outfit is small, we get very good service and response from the supply chain for Atmel--distributor(s), representative, and Atmel district person.

For samples and getting a few scarce chips, the representative is the key for us, serving as the "middle man" in these transactions. For example, when I post a sample request on the Atmel site, it gets back to my local rep for processing, and he also actually receives the samples and passes them along.

As I understand it, the "quality" of these reps varies widely. All I can say is to get to know yours on a first-name basis. It will not hurt. ;)

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

While we usually get pre-pro and engineering samples of new silicon from vendors (just to get a design started), we're actually in the same position as everyone else when it comes to ramping for production. We need the final silicon just like everyone else (admittedly our name is probably closer to the top of the list when the presses finally start to roll of course)

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

kmr wrote:
I used the 2MHz internal oscillator and 16x PLL. Excerpted:
;;; Initialize clock
        ldi     TMP_REG,0xD8    ; Protected IO Signature
        sts     CPU_CCP,TMP_REG
        ldi     TMP_REG,CLK_SCLKSEL_RC2M_gc       ; Set 2 MHz RC Oscillator
        sts     CLK_CTRL,TMP_REG
        lpm                     ; Wait for clock to be stable (4 cycles req)
        lpm
        
        ;; 2 MHz Internal RC Oscillator, 16x PLL
        ldi     TMP_REG,OSC_PLLFAC4_bm
        sts     OSC_PLLCTRL, TMP_REG

        ldi     TMP_REG,OSC_PLLEN_bm
        sts     OSC_CTRL, TMP_REG

If I use this code, the CPU still runs with 2MHz. Even if the CLK_CTRL register access fails this should not be a problem, because I write a '0x00' which is the reset value. If I set OSC_CTRL to 0x10 (OSC_PLLEN_bm) the RC2MEN-bit is still set. This means I read back 0x11 although I wrote a 0x10 to OSC_CTRL. Could this be the problem? Can anyone give me a hint what I am doing wrong?

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

ce wrote:
If I use this code, the CPU still runs with 2MHz.
Whoops, I didn't paste all of the relevant code. Here's a longer excerpt that should get your XMEGA running at 32MHz
;;; Initialize clock

        ldi     TMP_REG,0xD8    ; Protected IO Signature
        sts     CPU_CCP,TMP_REG
        ldi     TMP_REG,CLK_SCLKSEL_RC2M_gc       ; Set 2 MHz RC Oscillator
        sts     CLK_CTRL,TMP_REG
        lpm                     ; Wait for clock to be stable (4 cycles req)
        lpm
        
        ;; 2 MHz Internal RC Oscillator, 16x PLL
        ldi     TMP_REG,OSC_PLLFAC4_bm
        sts     OSC_PLLCTRL, TMP_REG

        ldi     TMP_REG,OSC_PLLEN_bm
        sts     OSC_CTRL, TMP_REG
        
WaitPllReady:
        lds     TMP_REG,OSC_STATUS
        sbrs    TMP_REG,OSC_PLLRDY_bp
        rjmp    WaitPllReady

        ;; Use PLL as clock source
        ldi     TMP_REG,0xD8    ; Protected IO Signature
        sts     CPU_CCP,TMP_REG
        ldi     TMP_REG,CLK_SCLKSEL_PLL_gc     ; Set PLL Oscillator
        sts     CLK_CTRL,TMP_REG
        lpm                     ; Wait for clock to be stable
        lpm

Pages