megaAVR 0-series

Go To Last Post
285 posts / 0 new

Pages

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

Getting Started With Your AVR-IoT WG Development Board - YouTube

by Microchip Technology

Oct 10, 2018

https://www.youtube.com/watch?v=WK4ljyKDMIQ (6m26s)

via https://plus.google.com/+MicrochipTech/posts/7pLed2HKFf5

 

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

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

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

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

http://packs.download.atmel.com/#collapse-Atmel-ATmega-DFP-pdsc

1.2.272 (2018-09-14)

Corrected CLKCTRL signals, ALT out signals and interrupt edge triggering values for CCL and added SEQCTRL1 for ATmega4809, ATmega4808, ATmega3209 and ATmega3208.

Corrected RW status on MCLKSTATUS register.

...

Added ATmega1609, ATmega1608, ATmega809 and ATmega808.

...

 

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

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

gchapman wrote:

...

Added ATmega1609, ATmega1608, ATmega809 and ATmega808.

...

 

 

Interesting. So that's (likely) the megaAVR 0-series family complete. You can't go bigger than 48k because of the way the memory is mapped, it probably doesn't make sense to go smaller than 8k, it also probably doesn't make sense to go more than 48 pins, and you'd never fit all the functionality is less than 28 pins.

 

The tinyAVR 1-series is looking to be complete, unless there are plans for 48k devices, as is the tinyAVR 0-series.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

It seems I also need to add the ATmega1609, ATmega1608, ATmega809 and ATmega808 to the avrdude.conf file in my programmer.

 

BTW, tiny3204, tiny3206 and tiny3207 are also missing in my avrdude.conf, but they don't seem to be planed even as future products.

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

Brian Fairchild wrote:
So that's (likely) the megaAVR 0-series family complete.
USB megaAVR are popular.

Prediction - megaAVR 1-series

Updated USB device controller, unified memory, ...

 

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

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

Currently future product :

ATmega1609

ATmega1608

ATmega809

ATmega808

 

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

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

the overview say :

 The series uses the latest Core Independent Peripherals with low power features.

is that new version or just a bug fixed one ? 

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

IIRC, CIP is from the PIC side of the house.

 

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

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

CIP is from the PIC side of the house.

If you say so.  I always thought that Microchip's "Core Independent Peripherals" and Atmel's "Event System" and/or "Sleepwalking peripherals" were approximately the same thing.  (though I haven't looked at either one in enough detail to see if there are any important differences.)

 

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

It's my assumption.

In '11, became aware of the Charge Time Measurement Unit (CTMU) in some PIC18F where the CTMU is sensing touch buttons while the CPU sleeps.

Atmel QTouch is implemented by library software (CPU) that was improved by some PB megaAVR with the Peripheral Touch Controller (PTC)

AVR32 UC3L has an autonomous touch button hardware interface (Capacitive Touch or CT) to wake the CPU.

 

Waking up a capacitive touch-sensing device with an MCU peripheral

Nithin Kumar Mada and Harsha Jagadish, Microchip Technology - July 27, 2011

 

When a capacitive touch screen goes into sleep or standby mode to save energy, how can you design the system to wake up quickly without degrading its performance or burning a lot of power. Here are two options: a traditional method and a new MCU-based method. 

https://www.embedded.com/print/4218309

Microchip Technology

Overview of Charge Time Measurement Unit (CTMU)

https://www.microchip.com/stellent/groups/SiteComm_sg/documents/DeviceDoc/en542792.pdf

...

 

(page 32)

Other Applications of CTMU

[capacitance sensing, TDR, precise time, temperature sensing, humidity sensing, DAC]

 

...

 

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

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

The code for the new ATmega4809-based Arduino board has been checked in:

https://github.com/arduino/ArduinoCore-megaavr

 

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

    How they run it at 16MHz ? I thought it will run at 20MHz. Is the schematic available ?

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

Couldn't quickly locate the schematic of Arduino Uno WiFi rev2.

Its competitor is AVR-IOT WG Development Board

AVR-IOT WG's mega4808 is on page 3 at B3 :

http://ww1.microchip.com/downloads/en/DeviceDoc/AVR-IoT_WG_Schematics.pdf

To megaAVR 0-series UARTs were added autobaud (BREAK, SYNC, data) and FBRG.

AVR-IOT WG's nEDBG SAMD21 (page 2, C5) has access to USB SOF for creation of an accurate internal clock.

 

Edit: page 2

 

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

Last Edited: Wed. Oct 31, 2018 - 07:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

angelu wrote:

    How they run it at 16MHz ? I thought it will run at 20MHz. Is the schematic available ?

 

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

ATmega4809 Curiosity Nano

has separate LDO for mega4809 and nEDBG SAMD21 such that mega4809 VCC can be nearly USB VBUS.

http://ww1.microchip.com/downloads/en/DeviceDoc/ATmega4809_Curiosity_Nano_Schematics.pdf

 

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

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

in stock

lead time is 15 weeks

ABX00021 Arduino (Uno WiFi Rev2) | Mouser

 

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

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

angelu wrote:
Is the schematic available ?
ARDUINO UNO WiFi REV2, documentation tab

 

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

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

gchapman wrote:

angelu wrote:
Is the schematic available ?
ARDUINO UNO WiFi REV2, documentation tab

 

That's a lot of level shifters.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

And man, that power supply just keeps getting more and more complicated.  Six transistors, now!  (oh wait - the opamp is gone...)

Am I missing something?   Were there spectacular problems with the old design?  Is there something wholy awful about a couple of diodes?

(and you'd think that someone would have put this whole "USB or external power to 5 and 3V @500mA total" on a single chip/module by now...)

 

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

Did someone test the Arduino Uno WiFi Rev 2 ?

 

It is very strange to see "coming soon" at the Arduino store, as if it had not arrived !

But it is available at Mouser ...

Bernard.

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

Did someone test the Arduino Uno WiFi Rev 2 ?

No, but I've been playing with the code using an Xplained Pro board.

That's the lovely thing about Open Source - you can analyze it, criticize it, submit bugs, even write fixes, all without actually contributing to the vendor's revenue stream!

 

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

You're onto something really handy (breadboards, typical protoboards)

top left at ATMEGA4809 - 8-bit AVR Microcontrollers - Microcontrollers and Processors

 

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

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

gchapman wrote:

You're onto something really handy (breadboards, typical protoboards)

top left at ATMEGA4809 - 8-bit AVR Microcontrollers - Microcontrollers and Processors

 

Do you think they'll come with a DIP40 version of the 4809?

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

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

Last Edited: Sat. Jan 26, 2019 - 05:26 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Arduino Uno WiFi (the one with the mega4809 on it) is now in stock at Farnell...

 

 

https://uk.farnell.com/arduino/a...

 

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

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

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

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

So is there compiler support for putting tables of constants in .text, and then reading it via ldd/etc in the shared address space?
First looks says the shared space doesn’t help much - foo[x] gets pretty much exactly the Same code up until the actual spm instruction vs “ld r,Z”, for maybe a 10% improvement in cycle count. But there should be many more options for fetching the data - X and Y in addition to Z, plus ldd,plus the extra addressing modes...

I assume I could manually put data in .text via the section attribute, but I was hoping for something prettier, and “official”

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

Aren't you just talking about PROGMEM (C++) or __flash (C) ?

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

westfw wrote:
So is there compiler support for putting tables of constants in .text, and then reading it via ldd/etc in the shared address space? First looks says the shared space doesn’t help much - foo[x] gets pretty much exactly the Same code up until the actual spm instruction vs “ld r,Z”, for maybe a 10% improvement in cycle count. But there should be many more options for fetching the data - X and Y in addition to Z, plus ldd,plus the extra addressing modes... I assume I could manually put data in .text via the section attribute, but I was hoping for something prettier, and “official”
The real improvement would be to get rid of those strcpy/strcpy_P functions and having a single set. I'm looking for this high level support. I don't care if the strcpy_P will be 10% faster because of the low level support of addressing modes, as long as I will still be forced to use strcpy_P functions.

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

rammon wrote:
The real improvement would be to get rid of those strcpy/strcpy_P functions and having a single set. I'm looking for this high level support. I don't care if the strcpy_P will be 10% faster because of the low level support of addressing modes, as long as I will still be forced to use strcpy_P functions.
But do that would really require __flash and C++ to be combined. Then you could have overloaded versions of strcpy() etc that are simply based on whether the parameters have "const _flash" modifiers. I suppose this might be possible with "const" alone but then you are effectively saying the RAM one has the potential to modify its parameters.

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

clawson wrote:

rammon wrote:
The real improvement would be to get rid of those strcpy/strcpy_P functions and having a single set. I'm looking for this high level support. I don't care if the strcpy_P will be 10% faster because of the low level support of addressing modes, as long as I will still be forced to use strcpy_P functions.
But do that would really require __flash and C++ to be combined. Then you could have overloaded versions of strcpy() etc that are simply based on whether the parameters have "const _flash" modifiers. I suppose this might be possible with "const" alone but then you are effectively saying the RAM one has the potential to modify its parameters.

strcpy will work even in the current implementation as long as the __flash parameter will be correctly given (as the aliased address in the data space). The problem is who will give that address to the strcpy? Not me anyhow.

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

rammon wrote:
The problem is who will give that address to the strcpy? Not me anyhow.
No idea what you mean. You generally use it as:

// C
const __flash char text[] = "hello"
char buff[20];

strcpy_P(buff, &text);

or

// C / C++
strcpy_P(buff, PSTR("hello"));

or

// C++
const PROGMEM char text[] = "hello"
char buff[20];

strcpy_P(buff, &text);

So the compiler provides the address to use because it knows the address of text[] or the PSTR()

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

clawson wrote:

rammon wrote:
The problem is who will give that address to the strcpy? Not me anyhow.
No idea what you mean. You generally use it as:

// C
const __flash char text[] = "hello"
char buff[20];

strcpy_P(buff, &text);

or

// C / C++
strcpy_P(buff, PSTR("hello"));

or

// C++
const PROGMEM char text[] = "hello"
char buff[20];

strcpy_P(buff, &text);

So the compiler provides the address to use because it knows the address of text[] or the PSTR()

The whole point is to use strcpy(), not strcpy_P().

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

But the whole reason why C has to have two (differently named) implementations of strcpy() is that one has to use LD and the other LPM. I suppose another alternative might have been a non-standard strcpy() with an extra parameter to identify which address space the address points to. I cannot see any mechanism (in C) that would allow for just one function - I suppose you could use a _memx pointer so that the address and the memory space flag are combined into a single parameter? But this would then be a very non-standard strcpy().

 

C++ function overloading provides a way to have two functions with the same name that do the same thing in subtly different ways but it needs to see some difference in the type of at least one of the parameters.

 

If using C have you considered a "wrapper" using __memx?

char textRAM[] = "hello";
const __flash char textFlash[] = "world";

char * Strcpy(char * dest, __memx char * src) {
    if (__builtin_avr_flash_segment(src) == -1) {
        strcpy(dest, (const char *)src);
    }
    else {
        strcpy_P(dest, (const __flash char *)src);
    }
    return dest;
}

int main(void) {
    char buff[20];

    Strcpy(buff, textRAM);
    Strcpy(buff, textFlash);
}

That does mean using Strcpy() in place of either strcpy() or strcpy_P().

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

Hi clawson,

Here the talk is about the new chips that have the flash (well, a part of it) mapped to the data space. 

And I said that (for me) the best value of it is if we can use this feature to get rid of the dual function thing of the standard c library (at least). To finally have a unified memory architecture (like arm, stm8) and not having to deal with different versions of the same function anymore.

If gcc can support this or not is beyond my understanding (or how hard it is).

 

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

rammon wrote:
If gcc can support this or not is beyond my understanding (or how hard it is)
GCC is OSS - if someone has an improvement to add to it everyone is free to contribute.

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

I am confused.   The AVR has an 8-bit data bus and 16-bit address bus with 16-bit-wide instructions.

 

You could map SRAM, Flash to a linear memory space but you are still stuck with 16-bit addressing.   Fine for say 40kB Flash and 24kB SFR/SRAM.

But a mega128 has got 64k instruction words and 64kB RAM addressing.

 

mega2560 or Xmega384 has got more Flash but needs a page register.

 

Yes,   I agree that an ARM has a much cleaner architecture.   Let's face it,  the AVR was pretty revolutionary when it came out.   I doubt if they even considered more than 64k words of Flash.

 

Even now,  C compilers and libraries don't handle data above 64kB very well.    Program memory works with trampolines.   Most data memory is assumed to live below 64kB.    You have to tell the linker to do things otherwise.

 

David.

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

david.prentice wrote:
You could map SRAM, Flash to a linear memory space but you are still stuck with 16-bit addressing.   Fine for say 40kB Flash and 24kB SFR/SRAM.
That's exactly why these new devices have memory regions with the size restrictions they have - so everything can still be mapped into a single, linear, 64KB space.

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

Yes, and you shoot yourself in the foot if you produce a 40kB chip in 2017 and can never add a new family member above 56kB.
.
8-bit microcontrollers have lived with Harvard architectures for over 30 years.
Even the ARM has different address spaces. They just get mapped to a linear space.
.
The C++ compiler can distinguish for overloaded methods.
The C compiler can use __memx
.
Yes, it is irritating at times. Just live with it.
.
David.

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

  Fine for say 40kB Flash and 24kB SFR/SRAM

But that is what a 4809 has:

48k Flash

6k RAM

and the rest is IO etc.

 

But they could not find room for the 32 registers :(

 

About using memory mapped flash, then I checked when the chips first was supported and there the compiler didn't know about the memory mapped flash.

But you can just make pointers to the flash (remember that flash addr and "RAM" addr of the same are different) , and the compiler was using both X and Z as pointers.

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

Oops.   I know that I should not type directly from my a*se.

 

I should have looked at my PC first!

 

David.

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

  that would really require __flash and C++ to be combined.

I thought __flash (and C++'s "objection" to it) specifically handled separate memory sections; ie it allows the compiler to generate LPM instructions when needed.

In the case of the zero-series MEGAs, this isn't needed - the flash and data address space are all unified.  Von Neuman architecture compilers (including gcc) generally just put all "const" data (inc literal strings) into ROM/Flash, or have an option to do so.  Perhaps whatever hack avr-gcc uses to put const data in RAM can simply be turned off?

 

Edit:  Oh wait - perhaps not.   Addresses in .text are zero-based, but when accessed as data, they appear at a different offset...

I'm pretty sure that something like:

  

const uint8_t PROGMEM foo[] = {1, 2, 3, 4};
 :
static inline uint8_t pgm_read_byte(uint8* p) {
    return *(p+MAPPED_PROGMEM_START);
}
// or
printf("%s", (char *)(foo)+MAPPED_PROGMEM_START);

will work fine.  (I guess I should try it, eh?)  But I'd like something "cleaner."

 

 

you shoot yourself in the foot if you produce a 40kB chip in 2017 and can never add a new family member above 56kB.

yes and no.  The AVRs that implement more than 64k (and most other 8 or 16bit CPUs that fundamentally work with 16bit addresses) get a bit kludgey with the various bank switching schemes and such.  It's one of my main criteria for selecting a 32bit CPU: "do I run into bank switching complexities."  Positioning the mega-0 chips to only compete with the small-memory segment might be a good thing.

 

 

Last Edited: Fri. Nov 23, 2018 - 01:10 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It seems you need to use __attribute__((section(".rodata"))) on constant data to convince the compiler to use the flat memory model. But I need to do more experimenting...

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

westfw wrote:

you shoot yourself in the foot if you produce a 40kB chip in 2017 and can never add a new family member above 56kB.

yes and no.  The AVRs that implement more than 64k (and most other 8 or 16bit CPUs that fundamentally work with 16bit addresses) get a bit kludgey with the various bank switching schemes and such.  It's one of my main criteria for selecting a 32bit CPU: "do I run into bank switching complexities."  Positioning the mega-0 chips to only compete with the small-memory segment might be a good thing.

 

 

AVR architecture was revolutionary because allowed 128K program space naturally, with no banks, no special instructions to go beyond 64K. The flash is byte readable only in the first half, but this is still a full 64K (with LPM). Atmel exagerated a bit going beyond the 128K/64K limit (with those RAMPZ, ELPM, etc.) but in those days the 32bit computing was not that ubiquitous.

 

Nowadays an 8bit chip should stay in 64K address space. For example, an unified 64K with 56K flash, 6K ram, 1K eeprom and 1K io space looks very nice to me. Should you go beyond 64K? Use one of the myriad 32bit chips.

 

STM8 architecture is very nice in this respect. They've put the flash start address at 0x8000 (some have a bootloader at 0x6000) too high IMO, but otherwise it's a very clean chip if you stay into 32K flash. 

 

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

El Tangas wrote:
It seems you need to use __attribute__((section(".rodata")))
See prior posts from Georg-Johann about this very thing.

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

david.prentice wrote:
Even now,  C compilers and libraries don't handle data above 64kB very well.    Program memory works with trampolines.   Most data memory is assumed to live below 64kB.    You have to tell the linker to do things otherwise.
... for AVR GCC.

IAR EWAVR has 24b pointers for program and/or data spaces (several memory models)

XMEGA DMA has 24b addressing though with max 64KB transactions.

AVR GCC has 24b types so could create functions to match existing 16b pointer functions though might be easier to use ASF3 Huge Memory (32b parameters)

 

IAR Embedded Workbench, AVR

http://gcc.gnu.org/wiki/avr-gcc#Types

http://asf.atmel.com/docs/latest/xmegaau/html/group__hugemem__group.html

 

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

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

IAR Information Center for Atmel AVR - Release notes

Release notes

for IAR Embedded Workbench for Atmel AVR version 7.10.3

...

 

 

Service Pack 7.10.3

...

  • Support has been added for the following devices:
    ATA5787, ATA5835, ATmega3208, ATmega3209, ATmega4808, and ATmega4809.

...

 

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

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

rammon wrote:
... and 1K io space looks very nice to me.
More than 1KB as CIP could be a source of IO for a possible megaAVR 1-series.

rammon wrote:
Should you go beyond 64K? Use one of the myriad 32bit chips.
Unless limited by temperature and/or leakage and/or GCR requirements.

Texas Instruments MSP430TM has a 20b flat memory space option in FSF MSP430 GCC.

One of AVR's advantages versus MSP430 is some AVR have an EBI; likewise with some PIC24 and dsPIC.

 


CIP - Core Independent Peripheral

What is a Core Independent Peripheral? - Developer Help

GCR - Galactic Cosmic Rays

https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/MSP430-Options.html#MSP430-Options (-mlarge)

 

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

Pages