AVR Freaks

I'm not on the right computer to check this, but didn't / doesn't the Xmega A have a zero crossing detection built into its ADC?

That is one of the stated reasons for the 0V offset at the low end of the ADC, so one can see the signal go through the zero.

JC

What do the first number refer to in Part numbers: AVR28DA128 AVR32DA128 AVR48DA128 AVR64DA128   ?

Package pin count ?

The 128 seems 128k Flash ? - but it's a little unusual to have the package pin count up-front in a part number ?

This is the new naming-scheme going forward: AVR<pin-count><family-letters><flash-size>

Trying to find the reason behind marketing decisions is rarely worth the effort...

Agreed, but the above links seem to suggest Microchip had second thoughts and it now is 

AVR<flash-size><family-letters>​​​​​​​<pin-count>

Maybe someone smarter pointed out to marketing, that AVR32 was already taken, and no one is expecting AVR32 to be a 32 pin 8 bit AVR  ?

Of course, they still need to now avoid 32k Flash parts ;)

​​​​​​​

It's possible to create Atmel Start projects for these chips, browsing the options gives a good idea of their capabilities.

Hey, this guy has authored some pretty interesting appnotes. I sense Microchip's analog expertise in him, so it seems the AVR-DA are already a product of Atmel+Microchip know-how. I'm looking forward to these and more products.

Yay... PTC events, when the PTC operation itself remains a secret. Really, I don't get this policy... What's the big deal about revealing how it operates? Is it alien tech?

It certainly looks like the chip family I would have loved to have had 5 years ago...

Now, it's competing with those 120MHz CM4 chips...

Just installed the new packs. So this is "xmega4", hum? Yeah, the architecture is different, of course 128Kb can't fit in the 64Kb linear address space. They use some kind of memory paging, or else it's back to progmem...

Time to do some experiments while waiting for the actual chips.

edit: and yes, as I feared constant strings are being processed like on classic AVRs, by being copied to SRAM first. So PROGMEM is back...

Well, the xmega3 have this

  .rodata  ADDR(.text) + SIZEOF (.text) + __RODATA_PM_OFFSET__    :
  {
    *(.rodata)
     *(.rodata*)
    *(.gnu.linkonce.r*)
  } AT> text

I'm guessing the AT> text means that .rodata is in the text memory region, whose size is known to the linker, so it should complain.

I really don't know what I'm doing, but maybe something like this for the xmega4?

  .rodata  0x8000 : AT __TEXT_REGION_LENGTH__ - 0x8000
  {
    *(.rodata)
     *(.rodata*)
    *(.gnu.linkonce.r*)
  } AT> text

As you know, on classic AVR we have 2 choices for using constant data:

• let the compiler do it's thing, and we will be wasting SRAM, because all constant data is copied there
• Use the facilities of pgmspace.h; this way you save SRAM, but now you need to use PROGMEM and cumbersome pgm_whatever to access the data

The flat address space of the AVR-0/1 had solved that problem, we could use standard C for constant data and not waste RAM. But now with the DA series the problem is back, so I'm just complaining a bit, I like to complain from time to time 

edit: and also complaining because they decided to recycle xmega4 scripts for the DA instead of going to the trouble of writing new ones that could make use of the linear mapped flash area.

Mine have arrived too, they come in narrow 28 pin DIP packages like the mega328p. Background is my IKEA silicon mat that I use for soldering, it was on sale 

(interestingly, the MPLABX programmer doesn't seem to complain if I have the wrong chip connected.)

Microchip has published some information about the new DB series!

AVR128DB64

AVR128DB48

AVR128DB32

AVR128DB28

Sigh.  It would be nice if the NVM Controller wasn't COMPLETELY DIFFERENT from the mega0/xtiny series :-(

Heh.  I got a couple of the Curiosity boards.

I observe that the slightly-staggered pin-header arrangement (AFAIK, invented by SparkFun to help hold the headers in place during soldering - I don't think they're tight enough to make soldering unnecessary) is really annoying when used with that long a strip of pins...  My poor fingers!

I hear you. My fingers suffered too, but I managed to get the two full strips in.

While playing with the analog comparator, I found the first error in the (admittedly preliminary) datasheet. It says that the voltage reference for AC is using the DAC reference. This is not so. The AC has its own independent reference.

Hello to everyone!

Unfortunately I have no AVR DA chips yet, so I cannot make the following test by myself. I need more PWM channels, so I’d like to use timer type A (TCA type) in split mode. Hoverer, I have some bad experience with this mode on XMEGA32E5, and in many other XMEGAs split mode doesn’t work as expected.

So, can you please confirm that in split mode timer really can generate 6  8-bit PWMs? XMEGA32E5 in this mode can generate 8-bit PWM but the number of available channels is not doubled as stated in datasheet.

TIA

Thank you very much! I really appreciate your help.

While trying to get the USART and CCL to do automatic collision detection and backoff on a half-duplex line, I came across something that isn't documented in the datasheet. In the USART CTRLA register description, there is one bit allocated for RS485/XDIR pin signalling:

But when looking in the device headerfile (at least ioavr128da48.h), it looks like there are two bits related to RS485:

/* RS485 Mode internal transmitter select */
typedef enum USART_RS485_enum
{
    USART_RS485_OFF_gc = (0x00<<0),  /* RS485 Mode disabled */
    USART_RS485_EXT_gc = (0x01<<0),  /* RS485 Mode External drive */
    USART_RS485_INT_gc = (0x02<<0),  /* RS485 Mode Internal drive */
} USART_RS485_t;

Is this a hidden feature, or just an error in the headerfile?

I tried "AUTO TUNE" of the clock controller.

I used AVR128DA28.

The crystal frequency is off by about 46ppm, but I don't have a more better caps.

In low power mode, oscillation margin 3 (147k in series) could not be achieved, so it is normal mode.

OSCHF 1MHz output.

It worked fine, but the adjustment steps seems to be around 0.4%, the same as manual. Don't expect too much.

Wow, gotta love it.

Adding back the HF Xtal is, at least for my projects, a great improvement.

I've used the Xmega32E5 for some little projects, but having a wide selection  of Vrefs, and having 3 internal Op-amps for Analog Front End Signal Conditioning is a great feature.

The two level priority interrupt is a step down from the 3 Level interrupt controller in the Xmegas, but is a big step up from a single level controller in the classic AVR Mega and Tiny micros.

Although the core runs at 24 MHz, several T/C's can be clocked at 48 MHz, in spec.

A couple of the micros have 6 USARTs... (Maybe the DC version will have a USB module).

Plus the Event System, ADC,DAC, CCL (with 6 tables), the ZCD, and the usual modules.

Now, if I could just find a few more hours in the day to tinker I'd be all set!

JC