ATAVRXPLAIN is finally here

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

On Atmels home page under product releases for Nov 02 there is an announcement for the Expain board.
It has a recomended price of $29. Avnet Electronics has stock for just a little more than the recommended price.

Enjoy

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

I'm still waiting form mine to be delivered.. :(

edit they must have heard me. Xplain board just landed. Joy of joys...

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Ordered this afternoon. $32 at Avnet.... 32 avail.

Imagecraft compiler user

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

If anyone is crazy enough here is an ASM project of the STK500 leds program adapted for the Xplain board. The bits definition file is not fully complete yet but ready enough for this test.

Attachment(s): 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Have to wait until someone local starts to stock them too. farnell maybe? Arrow or ELFA even :)

What do you guys think? is this worth the money? I'm going to make a project using it in the beginning of next year so I probably need something simple as this as a start, or not?

-Rain-

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

Quote:

is this worth the money?

You're kidding? It's unbelievable value for money at $29. Clearly a "loss leader". Don't forget that it's not just an Xmega, these even an AT90USB1287 on there. Not to mention buckets full of memory.

When other folks were talking about making Xmega eval boards they were talking about a virtually bare board for somewhere around the $50 mark!

Cliff

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

Here is a C led flasher program too. It has 3 ways of accessing the port bits. If you want to use the older way with Pxx then grab the Xmega_IO_bits_definition.h from the ASM project above otherwise it is not needed.

/*Led flashing program, uses PE0 as led output XMega128A1*/

#include 
#include 
//#include "Xmega_IO_bits_definition.h"	//Not needed if using _bm or _bp bits notation


int	main (void)
{
	PORTE_OUT=0xff;		//All leds off, negative logic
	PORTE_DIR=0xff;		//Initialise port

	for (;;)
	{

//Led on, negative logic

//		PORTE_OUT &= ~ (1<<PE0);		//Alternate usage with Xmega_IO_bits_definition
//		PORTE_OUT &= ~ PIN0_bm;			//Alternate usage
		PORTE_OUT &= ~ (1<<PIN0_bp);	//Alternate usage
		_delay_ms(500);

//Led off
//		PORTE_OUT |= (1<<PE0);			//Alternate usage with Xmega_IO_bits_definition
		PORTE_OUT |= PIN0_bm;			//Alternate usage
//		PORTE_OUT |= (1<<PIN0_bp);		//Alternate usage
		_delay_ms(500);
	}

}

Remember to set the clock at 2MHz which seems to be standard default for the Xplain board.

hmm I guess this can now be moved to the AVR on topic forum..or the Xmega forum.

[I agree - it is on topic for AVR so moving from Off Topic]

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 have the rev 1 xplain for 6 months now and has proved invaluable in develpoment for the XMega chip. The XMega is certainly a step forward for me personally with the io options, competative pricing and library/example support makes it a superb choice. I've had a hand full of 128A1's that I've been playing with and developed boards for that i've previously used the mega1281 and it's given me a whole lot more.

I'd well reccomend the small cost of buying this board.

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

Quote:

and library/example support

What an irony - there was a long thread the other day berating the fact that Atmel don't provide "library code" like other manufacturers do. :lol:

BTW for those of us just starting out, do you have any pointers for making an easier AVR to XAVR transition? What are the "gotchas"?

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

Much reading to do. The peripherals are more complex and require more setup. Many things to ponder. Much more power, however the simplicity is now lost.
The application notes have many working examples for peripherals. I have tested with CV2 (CodeVision) and all seem to work as I needed. I did not test all the various modes. CV2 has "set up structures", for the control registers. This really helps!

The examples run at 2MHz internal clock. With the addition of PLL, and 2X clock on some periperals, the clock setting are also complex. I suggest starting at 2MHz (default), the USART worked fine with it at standard baud rates. Then speed things up.

It all starts with a mental vision.

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

It did take a little getting used to accessing registers through the structure type way but it now seems more logical to me to use portin = PORTD.IN rather than portin = PIND for instance. Also with the duplicates of hardware on the differing ports its nice to use the structure method of accesing to differentiate between them easier.

The only gripe was the uart setup I spent way too much time trying to figure out how to configure the baud rate but I've since found an excel spreadsheet that does all the hard work for you.

Anyway it's all what people feel comfortable with and sometimes changing to a different processor can cast doubts when pulling hair debugging a seemingly easy problem… I did come across an issue with the TWI register addresses not being correct in the datasheet once!

My view is definitely worth the change.

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

Quote:

but I've since found an excel spreadsheet that does all the hard work for you.

A link to that would be great ;-)

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

No probs... it is actually in the XMega serial port example that's on the atmel website. It is not refered to anywhere in the documentation but it's in there!

I'm happy to email it to anyone who wants it directly.

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

Sorry i missed the post earlier for hints and tricks for migration. Actually I have ported lost of code from the mega1281 to the xmega128A1 with ease. There have been no issues and direct replacement of the harware access registers are all that's really needed. For the setup registers that are usually accessed once in an init routine there is a little work to do but no more than what you'd have to do with the old processors when figuring out and atmel have done a fab job of providing examples for both iar and gcc compilers.
The only gotcha i came accross and atmel have confirmed it, some of the TWI registers are not correct in the iodef file or the data sheet and I needed to tweek the file! I haven't since seen a correction for this in an errata so it may still be there. i have posted previously on this.
If there are any issues I’m willing to help out, I can say I’ve used most if not all of the functions of the 128A1 over the last 6 months and i doubt any seasoned AVR user will really have any problems.

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

Have you used timers - other posts here have suggested they may be quite different?

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

Yes, I have used timers but no more than ctc and input capture modes I have also used the pwm to generate ouput for a BLDC motor with the commutation handled in ASM. They are a bit different in setup but essentially the same but with more functionality. There is DMA support and event triggers but if converting code then these won't be an issue as they didn't exist and therefore don't really need to know about them, we covered them at the seminar and reading the datasheet tells all. I mainly skip to the register description!

One thing that does stick out is you are responsible for the port pin direction control for most of the IO where as previously simply enabling the IO block took control.

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

Quote:

One thing that does stick out is you are responsible for the port pin direction control for most of the IO where as previously simply enabling the IO block took control.

Yup I saw this the other day when someone was talking about UART. In the old days TXEN/RXEN was enough to take control of the pins and set the direction.

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

My BABY steps contribution.

The simple, "turn on port bit to turn on pullup resistor" in input mode no longer works.

Each pin has a dedicated port to set up pullup, pull down, invert etc. There seems to be some common port where one can set this up for the whole port but I could not make any sense.

Also each pin has a dedicated register, if one wants to use it, to set a bit, clear a bit, toggle a bit as well as do something with the whole port like any other AVR.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

clawson wrote:
What are the "gotchas"?
One thing to keep in mind is that on the xmega the RAMPZ register is in effect with all usage of the Z register. For example, on the mega devices ld R23,Z doesn't involve RAMPZ but it does on an xmega.

Moreover, the xmega has RAMPD, RAMPX and RAMPY registers that serve the address extension function for direct RAM accesses and indirect access through X and Y. I believe that if you plan to use any of RAMPD, RAMPX, RAMPY or RAMPZ you should turn off interrupts for the period of time that they are non-zero. If you don't you'll have to re-code any of your ISRs that use direct or indirect addressing to save/set/restore the corresponding RAMP register.

As a side note, the ISR code generated by avr-gcc assumes that the RAMP registers are zero.

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

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

Another gotcha is the ADC offset. There is a small negative voltage offset in the ADC which also shaves some resolution off of the top end. It also makes taking accurate ADC measurements a pain in the butt. xmega16 and xmega32 also have errata where the differential gain ADC cannot go above 2.4V for some weird unexplained reason. Otherwise it's been a really neat chip to work with.

I like cats, too. Let's exchange recipes.

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

clawson wrote:
What are the "gotchas"?
Another one is that reti works slightly differently, preventing it from being used as a generic "return and enable interrupts" instruction. On the xmega, reti enables interrupts only if one or more of the bits 0-2 in the PMIC_STATUS register are set.

For most applications, this will not be an issue but for some special purpose code (e.g. context switch code) it can be problematic.

Another thing I've seen is that with the JTAG MkII connected, the time between reset being released and the processor beginning execution is quite variable and can be about two orders of magnitude longer than when the JTAG MkII is not connected. For example, with the "startup time" fuse set for 4mS and no JTAG, the time from reset going high until the first instruction being executed is repeatably close to 4mS. With JTAG MkII connected I've seen the startup time as low as 210mS and as high as 580mS. Again, for most applications this is immaterial but for some special situations it may cause a problem.

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

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

Also, the ATxmega128A devices have a 3-byte PC. This makes sense when you realize that the device has 128K+8K of Flash memory. In contrast, the mega devices with 128K of Flash (mega128, mega1281, mega1280, mega1284P, etc.) have a 2-byte PC.

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net