XMEGA Family is Losing in the Popularity Polls

Go To Last Post
128 posts / 0 new

Pages

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

awneil wrote:

jgmdesign wrote:
..kinda like a platypus.

or an AVR32 ... ?

 

cheeky

Good point

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?  - Lee "theusch"

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

Gotta say I love the Xmegas, and I'm 90% hobbyist.

 

I looked at a couple of the new XTinies for a project and decided to just use an XmegaE5.

 

JC

 

 

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

When I started to use the Xmega and I wanted to understand the inside of it I used ASM, up close and personal, the timers were a big pain, not to mention the ADC.

 

Atmel support tried to "help" with ASF like code that buried everything even deeper, well sort of worked but I didn't know why.

 

So I have around 2,000 boards in the field now and, you guessed it, coded in ASM, about 8K of code. A lot of the stuff I had already for the AVR and it remained untouched ie it was "portable" devil

 

Apart form the way the peripherals are accessed and set up it's like using and AVR compared to say using an ARM.

 

+++++ Xmegas a lot more popular than ARM here.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Last Edited: Thu. Feb 22, 2018 - 09:21 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

they don't do DIP, but the TQFP packages are easy enough to hand solder. Is that what you mean by unfriendly?

Soldering is a big part of it, but also "breadboard/protoboard comapibility."  With DIP parts, you could believe that you could build a project without needing a PCB (breadboard, stripboard, perfboard, etc), or with a homemade little-effort PCB.  With TFQPs those options are essentially gone.  (Of course, the price of having high quality PCBs made has gone way down as well.)

 

 

5V is no longer for 8bit devices only, there are Kinetis E devices now and SAM C20/C21.

The Cypress PSoC ARMs are also 5V capable.

 

 

[XMega has] Intelligently laid-out registers, giving the ability to define peripherals as structs whose addresses could be passed as pointers to functions, and header files that provided meaningful names to bitfields (e.g. "ADC_CH_GAIN_16X_gc, DMA_CH_TRIGSRC_USARTC0_RXC_gc").

That's more of a style issue with the way the Atmel-provided .h files were created.  You could create similar definitions for most of the normal AVR peripherals.  It's sort-of a "C vs ASM" leaning, and I think I've seen mostly-ASM AVR programmers confused by the structure-based scheme ("when do you use "." and when do you use "->"?" and similar.)  It's especially "amusing" since the structure-like definitions can lead to smaller code (occasionally.)

 

 

I will ALWAYS be a hobbyist as long as I am experimenting with new things that I do not get paid for.

Indeed!  I've decided that "Professionals" are frequently indistinguishable from "Hobbyists" when it comes to that initial "evaluation" of new architectures and chips.  The number of occasions where a "pro" is given the time to PICK a new chip, based on all new research, are few; usually it's "we're using this chip that the Senior Engineer picked" or "this chip is supposed to be compatible with our existing code, but it's faster, so we should use it unless you see any major problems" or even "their engineers say it will be really great!"  (Oh, that lovely PA Semi MIPS chip we were going to use! :-()   A vendor can get more penetration by offering "play" systems at "play" prices that engineers (and hobbyists) can use without needing to be "sponsored."  (IMHO)

 

I like to wonder how things would have turned out if the "Arduino Mega" had used an XMega chip instead of the meag2560.   It would have been faster, with the more advanced peripherals, as well as having more memory and more pins.  Alas, I think the XMega was announced "too late" for this to happen, and it SHIPPED "much too late."  (sigh.)

 

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

Okay, I tried Atmel Start again. Tried to set up a basic USB vendor specific device and got this message:

 

 

So it hasn't even reached parity with the old ASF yet.

 

And the ASF is not great either. For example, you can't have DFU runtime with any other type of USB. And the whole stack is bloated as hell so forget fitting it into a 4k bootloader.

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

larryvc wrote:
Oh, BTW Start is a "nice framework"
Can you create a project to just toggle one GPIO line - how many lines of C, how many opcodes? If you now dig out the datasheet and write a "bare metal" version in C then how many lines of C is that and how many opcodes?

 

A lot of these libraries suffer from trying to be all things to all people. If they concentrated on "normal use cases" and what 95% of the users actually want/do they could probably be much more like the code us engineers might right. I can't help thinking of Peter Fleury libraries and what makes them so popular - they target exactly what it is the majority want to do.

 

I know this if a bit of an extreme example but take a USART. Who in their right mind ever used the "S" bit? Yet the vendor library probably caters for it and possibly complicates the bit we all use in the process.

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

clawson wrote:

larryvc wrote:
Oh, BTW Start is a "nice framework"
Can you create a project to just toggle one GPIO line - how many lines of C, how many opcodes? If you now dig out the datasheet and write a "bare metal" version in C then how many lines of C is that and how many opcodes?

 

A lot of these libraries suffer from trying to be all things to all people. If they concentrated on "normal use cases" and what 95% of the users actually want/do they could probably be much more like the code us engineers might right. I can't help thinking of Peter Fleury libraries and what makes them so popular - they target exactly what it is the majority want to do.

 

I know this if a bit of an extreme example but take a USART. Who in their right mind ever used the "S" bit? Yet the vendor library probably caters for it and possibly complicates the bit we all use in the process.

 

I agree completely. One of my recent example is a STM32 nucleo board that I want to use as a programming dongle for another architecture. I started with a simple led toggle at the default clock option. Then, the first important thing was to rise the clock to its max, 80MHz. This was exactly 10 lines of C code (without comments) at the register level (CMSIS). Switching clock sources, setting PLL, enable PLL, set the flash wait states, that stuff. Their library file only for the clock stuff is thousend of lines, lots of functions, with names that take half the line by themselves only.

Still, there are people that only complain about the lack of documentation for such a library. They don't realize that this won't happen, ever.

 

What a vendor should do, is to provide good examples, for the usual use cases. At the register level and properly commented in the same style as the user manual.

Having this, programmers can understand how and what to do to get their job done. With no bloat and no fat. And encouraged to read the datasheet and the user manual.

 

I can ask you (in general) the question: would you use a microcontroller with no user manual, no register level, only libraries documented by doxygen?

 

 

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

clawson wrote:

larryvc wrote:
Oh, BTW Start is a "nice framework"
Can you create a project to just toggle one GPIO line...

To be fair, this is taken out of context.  Did you read the whole post, especially the lean and mean part, did you follow the link.  We discussed Start before Cliff ;-)

 

On the whole, I do agree with your comments.

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

Last Edited: Fri. Feb 23, 2018 - 06:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Back in the day...

 

The GW-Basic (PC),  and Basic Stamp, (micro), both had instruction books.

Each instruction had a description of what it did, and a short example.

Easy.

 

JC  

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

I still use the XMega, and in fact am using it in 3 current projects right now.

 

One project is going into a prop hub extender on a single engine aircraft (for actual flight), and the other is inside a user console of a custom made CNC machine.

The third project is a fun one, overclocking the XMega-384 to 68MHz to give a 6502 processor a new VGA output.

 

I think the XMega is the best damn 8-bit uC ever made.

You can overclock all of them up to 64MHz safely, and often reach 72MHz.

At 68Hz, I am getting 34MHz IO bandwidth, which blows all PICs (32bit included), and most ARMs totally away.

The only thing on my bench that beats XMega IO speed is an FPGA.

 

I hope the XMega stays around for a while!

 

Brad

 

I Like to Build Stuff : http://www.AtomicZombie.com

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

I like the XMEGA on paper, but I am starting to wonder a little based on some past threads on the thing, and the miserable experience I am having by trusting a certain utility I elected to use to configure the device.

 

Jim

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?  - Lee "theusch"

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

Sounds like your problem is more with the utility than with the chip itself ...

 

Seems that Start is giving you more of a Stop; it's a futility - not a utility ... ?

 

frown

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AtomicZombie wrote:

I think the XMega is the best damn 8-bit uC ever made.

You can overclock all of them up to 64MHz safely, and often reach 72MHz.

At 68Hz, I am getting 34MHz IO bandwidth, which blows all PICs (32bit included), and most ARMs totally away.

The only thing on my bench that beats XMega IO speed is an FPGA.

 

The other great thing about the XMEGA architecture is how clean it makes your code. Peripherals are neatly self-contained and duplicated, and seem to be designed in such a way that you can write self-contained modules which don't conflict with each other.

 

On 8 bit PICs you have stupid things like shared interrupt vectors. The 16 bit range is a bit better in that respect, but the peripherals are still a bit of a mess in terms of what registers they use and your ability to write clean code for them.

 

A really interesting example of how Microchip just doesn't "get it" is their PIC24 USB stack. Maybe it's better now, but I have to maintain a product that uses it via polling in the main loop. Because of this the USB interface is extremely unreliable. Timing is all over the place because critical bits of it don't run in interrupts. And when you look at Microchip's example code it's clear they have no idea about careful separation and isolation of interrupt and normal code.

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

jgmdesign wrote:

I like the XMEGA on paper, but I am starting to wonder a little based on some past threads on the thing, and the miserable experience I am having by trusting a certain utility I elected to use to configure the device.

 

Jim

 

I have three projects with xmega, quite complex projects. When I started with xmega, the first thing was to carefully read the user manual. At least what I was interested in, GPIO, clocks, UARTS, ADC. At that time I even don't think START existed. I had no problem at all to get it working.

 

Your experience can confirm one of my feeling: the START like things (ST CubeMX, Microchip I don't know the name, etc.) probably put customers off. Atmel START is really bad in fact it seems. CubeMX and the Silabs equivalent are a lot better. CubeMX generates quite correct code, but based on their libraries. That really leaves you in the dark after the initialization code. At least the Silabs 8051 code generator generates code based on direct register access... It is the most honest code generator probably. It generates some writes to some registers and only that. Not claiming it's anything else. When you look at the generated code, you think: yes, what a simple code. I would have done that myself easily if I would have read the user manual.

 

 

 

 

 

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

I think the code libraries are mostly there to convince managers to use those parts. They believe all the stuff about being able to quickly get projects working, think they can get some budget contractor cowboy in to knock something up in three months because the manufacturer already did most of the work.

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

rammon wrote:
At least the Silabs 8051 code generator generates code based on direct register access...
But that is exactly what Start does!  More evidence that those that complain the most about Start understand the least about Start!

int8_t SPI_0_init()
{

	// SPIC.CTRLB = SPI_BUFMODE_OFF_gc /* SPI Unbuffered Mode */
	//		 | 0 << SPI_SSD_bp; /* Slave Select Disable: disabled */

	SPIC.INTCTRL = 1 << SPI_RXCIE_bp   /* Receive Complete Interrupt Enable (In Buffer Modes Only).: enabled */
	               | 0 << SPI_TXCIE_bp /* Transmit Complete Interrupt Enable (In Buffer Modes Only).: disabled */
	               | 0 << SPI_DREIE_bp /* Data Register Empty Interrupt Enable (In Buffer Modes Only).: disabled */
	               | 0 << SPI_SSIE_bp  /* Slave Select Trigger Interrupt Enable (In Buffer Modes Only).: disabled */
	               | SPI_INTLVL_LO_gc; /* Low Level */

	SPIC.CTRL = 0 << SPI_CLK2X_bp        /* Enable Double Speed: disabled */
	            | 1 << SPI_ENABLE_bp     /* Enable Module: enabled */
	            | 0 << SPI_DORD_bp       /* Data Order Setting: disabled */
	            | 1 << SPI_MASTER_bp     /* Select Master/Slave Operation: 1 */
	            | SPI_MODE_0_gc          /* SPI Mode 0, base clock at "0", sampling on leading edge (rising) & set-up on
	                                        trailling edge (falling). */
	            | SPI_PRESCALER_DIV4_gc; /* If CLK2X=1 CLKper/2, else (CLK2X=0) CLKper/4. */

	return 0;
}

 

I am not defending Start outright though, it has many interface bugs, and as noticed chooses pins poorly.  But let's get down to it, any programmer worth a grain of salt should be able to look at the generated code and spot what is off right away.  The most important lesson here is that you must read the datasheet, Start is not a substitute for it.

 

On the upside, they have been cleaning out more of the unnecessary cruft and reported flaws are being addressed.  Get used to Start as being a work in progress, it isn't going away any time soon.  If you don't like it, write your own bare metal code.

 

rammon, I do agree with your comments about the XMEGA being easy and well designed.

 

Brad, always nice to see you check in.  If you say the XMEGAs are awesome, then they must be!

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

Last Edited: Sat. Feb 24, 2018 - 10:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AtomicZombie wrote:

At 68Hz, I am getting 34MHz IO bandwidth, which blows all PICs (32bit included), and most ARMs totally away.

The only thing on my bench that beats XMega IO speed is an FPGA.

 

Here is a 40MHz signal out from a pin of an PIC32MX running at 80MHZ (not overclocked).

 

    And by the way, do you overclock your XMega for the propeller project ?

 

    I too thing that the XMega is the best 8 bitter on the market right now, but it cannot stand a 32 bit processor in general.

When I started to mess with microcontrollers, I weighted PIC vs Megas. I chose Atmel just because it was faster and I was able to build my own programmer based on the PonyProg software. At that time I could not afford an Atmel programmer. And since then I think I made the right decision. Later I kinda switched to XMega, and what I mean by saying that is that I would not go back to Mega again since XMega is here, unless it is about a very small project. Recently I started working with PIC32 and I amazed about it. Again, now I have the feeling that I would not go back to 8bit unless it is about a quick prototype or something very small project where a tiny would fit the bill.

    I do think that Microchip made a very good decision to go with MIPS instead ARM.

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

Sorry for the OT, but I notice you have a Kingst logic analyser. Are they ok? Would you recommend their products?

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

angelu wrote:

AtomicZombie wrote:

At 68Hz, I am getting 34MHz IO bandwidth, which blows all PICs (32bit included), and most ARMs totally away.

The only thing on my bench that beats XMega IO speed is an FPGA.

 

Here is a 40MHz signal out from a pin of an PIC32MX running at 80MHZ (not overclocked).

 

    And by the way, do you overclock your XMega for the propeller project ?

 

    I too thing that the XMega is the best 8 bitter on the market right now, but it cannot stand a 32 bit processor in general.

When I started to mess with microcontrollers, I weighted PIC vs Megas. I chose Atmel just because it was faster and I was able to build my own programmer based on the PonyProg software. At that time I could not afford an Atmel programmer. And since then I think I made the right decision. Later I kinda switched to XMega, and what I mean by saying that is that I would not go back to Mega again since XMega is here, unless it is about a very small project. Recently I started working with PIC32 and I amazed about it. Again, now I have the feeling that I would not go back to 8bit unless it is about a quick prototype or something very small project where a tiny would fit the bill.

    I do think that Microchip made a very good decision to go with MIPS instead ARM.

 

Hi,

How can you do 40MHz at 40% duty cycle from 80MHz clock? Just curious.

I'm with you about not going back to 8bit from 32. But I have designs that are 5V only. A 32bitter at 3V3 would complicate the design unnecesarly. Also, some of my boards are so simple that I almost feel sorry for a 32bit to put it there (as someone here said previously :)

 

I'm glad to hear that the PIC32 is great. I never used any, and probably I will continue to do that... Only that they came lately with a very very interesting chip, with a graphical coprocessor inside and 32MB DRAM! This really would fit on one of my designs, replacing an Cortex-M4 (LPC4088) and an external 32MB SDRAM.... For a new project of the same kind,it would be very tough to decide frown

 

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

larryvc wrote:

rammon wrote:

At least the Silabs 8051 code generator generates code based on direct register access...

 

But that is exactly what Start does!  More evidence that those that complain the most about Start understand the least about Start!

- for me it is a pleasant surprise it does register level access.

- I didn't use START, I concluded it is buggy from the posts here on avrfreaks. But I do use CubeMX and silabs studio, and I put the START in the same category. I won't say I don't (or can't) understand START.

 

larryvc wrote:

I am not defending Start outright though, it has many interface bugs, and as noticed chooses pins poorly.  But let's get down to it, any programmer worth a grain of salt should be able to look at the generated code and spot what is off right away.  The most important lesson here is that you must read the datasheet, Start is not a substitute for it.

 

On the upside, they have been cleaning out more of the unnecessary cruft and reported flaws are being addressed.  Get used to Start as being a work in progress, it isn't going away any time soon.  If you don't like it, write your own bare metal code.

Microchip should understand that such a tool sould be as rock solid as possible. They should make it like that asap. Because otherwise it can be a show stopper instead of a good helper. See Jim experience.

 

I will use such a tool myself for the following functionality:

- pin functions assignment. When you have chips with lot of pins and/or lot of alternate functions per pin, a nice graphical screen with the chip and the possibility to play with all the functions of the pins, and to see that graphically, is a pleasure. And very helpfull. A user manual cannot provide that.

- clock tree assignment (I now this from cubemx, but any complex chip with lot of clocks should have that). Complex chips tend to have complex clock tree. Seeing it on a single page and being able to play with it, change the clocks here and see all the implications here and there, it's very convenient.

 

But once you played with these graphicall interfaces and fixed the things in stone, the initialization code is simpler to write at the register level, now based on the user manual (you may understand the user manual even better after playing a while with the graphical interfaces!).

 

Speaking about code generation: I found it a bit frustrating because, after you have it generated for the initializations, you are left alone. I feel a bit dissapointed because I cannot generate more of my application functionality from the GUI (even I knew from the start that this is the case). And the net result is that you still have to read the user manual and to write your code, yourself.

 

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

Regarding the 40Mhz frequency from the PIC32. The Logic Analyser samples @ 200M/s i.e.5ns.
A 40MHz square wave has 25ns period i.e. half-period of 12.5ns. You will always see 15ns + 10ns unless you sample with an exact fraction of 12.5ns
Does a PIC32 really handle GPIO in one cycle? Or was this a timer output?
The XMEGA does do CBI, SBI in one cycle. And it works reliably when overclocked.
All AVRs can do IN, OUT in one cycle.
.
I think it is an excellent strategy for Manufacturers to provide some form of Code generator. Just to get someone started with their evaluation boards. It is wise to make the same demos work on every board. I do find it fairly convoluted.
.
I became quite familiar with the old Atmel app notes. Simple to follow but not always easy to port to different Atmel devices.
.
Any form of demo software must work 100%. If it does not, the Manufacturer's reputation suffers.
.
David.

Last Edited: Sun. Feb 25, 2018 - 08:09 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is the PIC output just a PWM channel? Or a long series of GPIO toggle op-codes?

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

david.prentice wrote:
Regarding the 40Mhz frequency from the PIC32. The Logic Analyser samples @ 200M/s i.e.5ns. A 40MHz square wave has 25ns period i.e. half-period of 12.5ns. You will always see 15ns + 10ns unless you sample with an exact fraction of 12.5ns

That clears the mistery.

david.prentice wrote:
Does a PIC32 really handle GPIO in one cycle? Or was this a timer output? The XMEGA does do CBI, SBI in one cycle. And it works reliably when overclocked. All AVRs can do IN, OUT in one cycle.

Even if it does, you can generate this output only inlining the instructions one after the other, for ... how many?

A better, and real life example would be how fast you can bitbang a simple SPI, read, write or even read/write.  Here, even if you inline eight spi bit cycles, you still need to serialize/deserialize the data. Another problem with these "monsters" is that they have pipelines, some of them quite deep pipelines. And running from flash you face the wait states problems...

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

With any micro you need to make best use of the hardware peripherals. e.g. USART_MSPI, DMA if possible.
I was just pointing out that the Xmega does this extremely well. Some instructions are faster e.g. SBI. All GPIO can work efficiently with VPORTs.
Yes, a small amount of inlining can make a dramatic difference to an "inner loop". Especially when the active body has few cycles relative to the loop control.
.
I can control TFT displays better with Xmega GPIO than Cortex-M0. However computation is more powerful with a 32-bit ARM.
.
It is unfortunate that the Xmega never appeared as an Arduino. It could have gained hobbyist support. And within an instant, cheap clone boards.
.
David.

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

david.prentice wrote:
Does a PIC32 really handle GPIO in one cycle? Or was this a timer output?

 

According to the datasheet,the ports have set, clear and toggle registers called CLR(clear), SET (set) and INV (invert), that's how a 1 cycle toggle is achieved.

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

next page in PIC32MZ EF :

12.1.3 I/O PORT WRITE/READ TIMING

One instruction cycle is required between a port direction change or port write operation and a read operation of the same port. Typically this instruction would be an NOP.

"Dare to be naïve." - Buckminster Fuller

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

Well, but you don't need to do a read, right? Just writes.

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

That's just the input synchroniser, same as AVR.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

mojo-chan wrote:

Is the PIC output just a PWM channel? Or a long series of GPIO toggle op-codes?

 

A long series of GPIO toggle op-codes. I think AtomicZombie implies the same thing when getting 34MHz output signal from an Xmega at 68MHz.

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

I like the event and DMA systems on the XMEGA.

 

One trick I often do is to use a timer to detect the end of a transmission. An event resets the timer whenever the RX pin changes, and the timer is set to do a compare match after say 1.5 characters of no change.

 

I was reading a serial bus (Dreamcast game console) where it used two wires that alternate between data and clock. First A is clock and B is data, then after one clock the swap so A is data and B is clock. Bit rate is 2MHz so at 32MHz you only have 16 cycles per bit, but it's actually a lot worse than that because the duty cycle isn't 50%. In fact it varies from device to device.

 

But on XMEGA it's easy. Use an event triggered on a falling edge to trigger a DMA read of the port. Have two of these set up, one for line A and one for line B. Use the timer trick to detect end of transmission, rather than trying to decode and calculated the expected number of words in realtime. Then you just sit there until the timer interrupt triggers and decode the captures port readings at your leisure.

 

It's this kind of thing that makes XMEGA awesome. Other MCUs have events, they have DMA, they have timers obviously... But the flexibility and ease of use you get from XMEGA is rare.

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

awneil wrote:

Sounds like your problem is more with the utility than with the chip itself ...

 

Seems that Start is giving you more of a Stop; it's a futility - not a utility ... ?

 

frown

Absolutely.  Larryvc is defending it, and he is right in many respects, but in this age of manufacturers pushing their code generation tools as being superior to others I took START for a spin as I am a noob of sorts to the XMEGA...and the START experience is a STOPPER. Just my opinion.

 

larryvc wrote:
But let's get down to it, any programmer worth a grain of salt should be able to look at the generated code and spot what is off right away.  The most important lesson here is that you must read the datasheet, Start is not a substitute for it.

No argument from me on this.  My reasoning for using START was because of how complex the clock scheme is from what I had been reading in the XMEGA forum so my intent was to see what the utility does and dissect it.  Then I remembered my Codevision License does XMEGAS and took it for a spin.  As I posted in my other thread it kicked a&& on my initial test, but failed with the same issue when I add SPI to the project.  Working on that now to see what happened, and will report accordingly.

 

rammon wrote:
Microchip should understand that such a tool sould be as rock solid as possible. They should make it like that asap. Because otherwise it can be a show stopper instead of a good helper. See Jim experience.   I will use such a tool myself for the following functionality: - pin functions assignment. When you have chips with lot of pins and/or lot of alternate functions per pin, a nice graphical screen with the chip and the possibility to play with all the functions of the pins, and to see that graphically, is a pleasure. And very helpfull. A user manual cannot provide that. - clock tree assignment (I now this from cubemx, but any complex chip with lot of clocks should have that). Complex chips tend to have complex clock tree. Seeing it on a single page and being able to play with it, change the clocks here and see all the implications here and there, it's very convenient.   But once you played with these graphicall interfaces and fixed the things in stone, the initialization code is simpler to write at the register level, now based on the user manual (you may understand the user manual even better after playing a while with the graphical interfaces!).

Cannot agree more with this.

 

I stand by my opinion that I like the XMEGA...on paper.  I will probably like it even more once I get past the speedbumps I am hitting.  But my mood is telling me to send START back to the shop for a rebuild, and concentrate on using Codevision for things...Stay tuned for the outcome.  AS I also mentioned somewhere popularity is based on the user experience in this day and age.  My experience with START has not been pleasant.  I wonder what would happen if I try the configuration through ASF within Studio and see what happens.  As many know I am not a fan of ASF either, but I have used it here and there.

 

Grumpy times....Grumpy times...frown

 

Jim

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?  - Lee "theusch"

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

jgmdesign wrote:
Grumpy times....Grumpy times...frown

 

Jim

Time for tea Jim? cheeky

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

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

@mojo-chan wrote:

It's this kind of thing that makes XMEGA awesome. Other MCUs have events, they have DMA, they have timers obviously... But the flexibility and ease of use you get from XMEGA is rare.

+1.  The XMEGA Event System is rather awesome, allowing peripherals to be interconnected in hardware, and to require CPU intervention only when a new measurement/result/state/etc. has been achieved.

 

The XMEGA peripherals have both a newer/smarter design and an intelligent register layout that is unseen (at least by my aging eyes...) in other 8-bit MCUs. 

Greg Muth

Portland, OR, US

Xplained/Pro/Mini Boards mostly

 

Make Xmega Great Again!

 

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

larryvc wrote:

jgmdesign wrote:
Grumpy times....Grumpy times...frown

 

Jim

Time for tea Jim? cheeky

Inside joke of sorts....but yes, exactly.

 

Jim

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?  - Lee "theusch"

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

Greg_Muth wrote:
+1.  The XMEGA Event System is rather awesome, allowing peripherals to be interconnected in hardware, and to require CPU intervention only when a new measurement/result/state/etc. has been achieved.

 

The XMEGA peripherals have both a newer/smarter design and an intelligent register layout that is unseen (at least by my aging eyes...) in other 8-bit MCUs. 

+1 and +1 for the aging eyes, seems to be going around.  The new ATtinys (XTINY) have the same Event System and Peripheral structure as the XMEGAs.  I've been amazed at what I have been able to accomplish with the XTINYs.  Should have given the XMEGAs more of a look a long time ago.

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

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

The XMEGA Event System is rather awesome

 I wouldn't mind seeing some example projects that do neat things with the Event System.  It sounds neat, but all I can think of doing with it offhand is setting up the A2D to take samples at regular intervals without a timer ISR.  It's marketing seems aimed at power-saving (handling events while the CPU sleeps), which is not usually sometime I'm concerned with...

 

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

@larryvc wrote:

+1 and +1 for the aging eyes, seems to be going around

wink  +2.0 here!

 

 

EDIT:

I've been amazed at what I have been able to accomplish with the XTINYs.

I have a couple TINY817 Xplained Minis that I played around with a few months ago.  The "XTiny" moniker is appropriate.

Greg Muth

Portland, OR, US

Xplained/Pro/Mini Boards mostly

 

Make Xmega Great Again!

 

Last Edited: Sun. Feb 25, 2018 - 09:51 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@westfw wrote:

 I wouldn't mind seeing some example projects that do neat things with the Event System.

I must admit the neatest thing I've done is measure the echo pulse width of an HC-SR04, which is probably too simple to be termed "neat."  After configuration, the Timer's CCA interrupt fires when a new measurement is ready.

 

 

Greg Muth

Portland, OR, US

Xplained/Pro/Mini Boards mostly

 

Make Xmega Great Again!

 

Last Edited: Sun. Feb 25, 2018 - 09:48 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

westfw wrote:

Indeed!  I've decided that "Professionals" are frequently indistinguishable from "Hobbyists" when it comes to that initial "evaluation" of new architectures and chips.

 

This.  As a freelancer, my clients don't really care what chip I use, as long as it does what they want it to do.  If some outfit comes out with a new wunderprocessor but charges 10,000 Omani Dinar for the programmer and IDE, I'm not even going to experiment with it.

 

Because I won't experiment with it, it's not going in any of my new gizmo designs.  And the manufacturer won't sell any to me or to my clients who mass-produce the gizmos.

 

The same thing applies to those who pass out 'free trials' (Hi, Xilinx) and then ask for thousands of dollars a year to maintain a license so you can maintain a one-off product.  No.

 

If you want to sell chips, make it as easy as possible for people to use them.  Pay no attention to the beancounters who say, "Hey, we wrote all this software, we should monetize this!"  NO.  Tell those beancounters they're penny-wise and pound-foolish, because the more they charge to develop with those chips the fewer chips you are going to sell.

 

And isn't your business selling chips?

 

Thank you,

 

S.

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

I should have been more specific when I seemed to bash the PIC32!

What I was doing was a tight, cycle counted loop in assembly to read from internal SRAM, and then send a full byte to a port.

The XMega can do this in 3 cycles...

 

ld r1,X+ ;2
out VPORT,r1 ;1

I spent a few weeks learning MIPs for the PIC32-MZ series, and finally realized that the XMega stomps all over it when it comes to getting data from internal SRAM out to a port in a fast and predictable manner.

 

Clocked at 68MHz, I can achieve a 256 color fully bit-mapped VGA resolution of 580x480 purely by bit banging alone.

I do a lot of this kind of thing for fun, just to see what processors are made of. XMega is the clear winner by far.

 

To the other question... no, my propeller torque sensor and data logger project is clocked at the "legal" 32 MHz.

Someone is going to be in the air with this thing (not me!), so everything is being done to ensure safety.

The other production board I used an XMega on is also clocked using the internal 32MHz clock.

I chose XMega for both projects as it was cheaper than an FPGA for similar performance.

 

Also, just for fun, I have had an XMega256 overclocked to 64MHz, and over-volted to 5v running for almost 4 years non stop.

This project has been displaying NTSC video, using the entire 256K program memory and all of SRAM since 2013.

I plugged it in and let it sit in a corner of my lab so I could do a "rebuttal" to all those claiming that overclocking could harm a uC.

The over-volting from 3.3v to 5v was just icing on the cake!

I intend to post my results in another year or so.

Again, just for the hell of it.

 

I hope one day an even faster XMega with more SRAM comes out.

Rated for 80MHz, with 512K of SRAM.

Give me that, and I will stop using FPGAs altogether.

Ditch the old PIC8 family and make me a new XMega!

 

Brad

 

angelu wrote:

mojo-chan wrote:

Is the PIC output just a PWM channel? Or a long series of GPIO toggle op-codes?

A long series of GPIO toggle op-codes. I think AtomicZombie implies the same thing when getting 34MHz output signal from an Xmega at 68MHz.

I Like to Build Stuff : http://www.AtomicZombie.com

Last Edited: Mon. Feb 26, 2018 - 12:05 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:
I wouldn't mind seeing some example projects that do neat things with the Event System.
Though not a project (it's a post)

AVR Freaks​

E5's XCL doing 2Mbps(!!!) FSK, appnote to follow

https://www.avrfreaks.net/forum/e5s-xcl-doing-2mbps-fsk-appnote-follow

...

- receive pin drives an event which is configured to RESET the XCL's timer BTC0
...

- XCL is configured in DFF mode, where the receive pin's event selects via MUX whether the D flip-flop is looped back or latched to the OC0 value.

...

westfw wrote:
... without a timer ISR.

AVR42772: Data Logger Demo Application on XMEGA A1U Xplained Pro

APPLICATION NOTE

http://ww1.microchip.com/downloads/en/appnotes/atmel-42772-data-logger-demo-application-on-xmega-a1u-xplained-pro_avr42772_applicationnote.pdf

(page 5)

2.2. Event System

...

In this application the event system removes 64 relatively short RTC interrupt routine calls per program cycle, and give us approximately 1% lower power consumption by using the event system.

...

via http://start.atmel.com/#examples/CustomBoard-ATxmega128A1U-AU

 

"Dare to be naïve." - Buckminster Fuller

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

AtomicZombie wrote:
I hope one day an even faster XMega with more SRAM comes out.
Conversely, a 16-bit data path with variable-width (up to 16b) single-cycle I/O ports.

Anyone for AVR16?

 

"Dare to be naïve." - Buckminster Fuller

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

westfw wrote:

 I wouldn't mind seeing some example projects that do neat things with the Event System.  It sounds neat, but all I can think of doing with it offhand is setting up the A2D to take samples at regular intervals without a timer ISR.  It's marketing seems aimed at power-saving (handling events while the CPU sleeps), which is not usually sometime I'm concerned with...

 

Another trick I did using the event/timer system I outlined was to handle the NMEA output from a GPS module. Used DMA to capture characters into a buffer with no interrupt overhead, and the event/timer to detect the end of the sentence block.

 

I also used an event triggered by the 1 PPS pulse to restart a timer for super accurate timing.

 

Oh, I did an RTC calibration routine using the XMEGA timers with a 10MHz TCXO reference clock and the event system triggered by the RTC overflow causing a timer capture. If the capture is under 10M you know that the RTC is running fast, if it's over you know that the RTC is running slow, and you can calculate exactly how much you need to compensate by.

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

Rammon is spot on.

 

Libraries often do too much and have unwanted side effects. The classic example is the ASF code for the XMEGA, which disables all the peripheral clocks as part of the clock management init code. You include it because you want to set a 32MHz core clock, but then find that it disabled all your peripherals for some unknown reason. Why isn't that part of the power management module? Because it has the word "clock" in it? And what part of "init" implies "disable everything"?

 

The AVRxxxx app notes and example code are much better. You can use them as libraries or as references. They are short enough and transparent enough to understand, unlike the ASF that has 50 layers of abstraction or code generators that produce thousands of lines of mostly unused crap with little organization for you to sift through.

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

gchapman wrote:

Conversely, a 16-bit data path with variable-width (up to 16b) single-cycle I/O ports.

Anyone for AVR16?

 

 

The Chinese AVR cloners at Logic Green Technologies devised a clever trick; certain memory areas trigger 16 bit access. So, for example, if you store r16 to these addresses, actually r16 and r17 are written to consecutive byte addresses. That is, "st Z, r16" causes a 16 bit write. They used this only to a very limited extent, though.

Of course gcc has no notion of this feature so it can only be used from assembly. Still, it's an idea...

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

So, for example, if you store r16 to these addresses, actually r16 and r17 are written to consecutive byte addresses.

I expect that will only have value to the likes of Brad if both bytes are written in the same clock cycle i.e. a true 16-bit write, not two consecutive 8-bit writes.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

XMEGA AVR at Microchip :

  • XMEGA A1U in BGA - additional assembly site
  • XMEGA E - Microchip Technology Thailand (MTAI) as an additional assembly site

Again though now it's QFP-100 for XMEGA AVR and megaAVR (iow AVR with a segment LCD controller (many segments) or an EBI)

Microchip Technology Inc

Microchip Technology

Product Change Notification - GBNG-05QUVX037 - 09 Aug 2018 - CCB 3496 Initial Notice: Qualification of MMT as an additional assembly site for selected Atmel products of the 35.4K, 35.5K and 35.9K wafer technologies available in 100L TQFP (14x14x1.0mm) package.

http://www.microchip.com/mymicrochip/NotificationDetails.aspx?pcn=GBNG-05QUVX037

...

 

Affected CPNs:

https://www.microchip.com/mymicrochip/Data/GBNG-05QUVX037/GBNG-05QUVX037_Affected_CPN_08092018.pdf?TimeStamp=8/9/2018%203:35:12%20PM

 

...

 

Estimated Qualification Completion Date:
November 2018

 

...

via http://www.microchip.com/mymicrochip/Reports.aspx?type=cpn&filter=xmega

 

"Dare to be naïve." - Buckminster Fuller

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

I'm a great fan of the ATXMEGA range and wait for the day when USB OTG is provided.

Sad to say, but  if Microchip loose interest in the ATXMEGA range, then when the IP period has run out, I hope the Chinese do start selling compatible chips.

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

jalbinson wrote:
... and wait for the day when USB OTG is provided.
USB OTG isn't a part of XMEGA AVR for a reason.

jalbinson wrote:
... if Microchip loose interest in the ATXMEGA range, ...
That will not occur as long as XMEGA is a commodity.

That's apparent for several XMEGA due to increased assembly production capability.

Will the ones at Microchip seek to better compete against MSP430TM and its ecosystem by a follow-on to XMEGA and PIC24?

(the best of both plus a twist or two)

jalbinson wrote:
... then when the IP period has run out, I hope the Chinese do start selling compatible chips.
currently that's by Logic Green for a relative few AVR.

https://www.avrfreaks.net/forum/forbiden-tech-china-has-arrived

https://olimex.wordpress.com/2013/12/12/3-arduino-possible-holly-molly-chinese-avr-clones-are-coming-meet-lgt8f88a-mavr-core-processor/

 

"Dare to be naïve." - Buckminster Fuller

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

jalbinson wrote:

I'm a great fan of the ATXMEGA range and wait for the day when USB OTG is provided.

Sad to say, but  if Microchip loose interest in the ATXMEGA range, then when the IP period has run out, I hope the Chinese do start selling compatible chips.

 

Why would the Chinese want to sell XMEGA clones ?

The new low-end MCU of focus in China, is now the 8051 - no licenses, no tariff risk, and good eco-system.... 

 

If you want USB-hosting, the company that makes the CH340, now has a series of USB-MCUs

http://www.wch.cn/products/categ...

https://lcsc.com/search?q=CH55

 

 

Pages