AVR Freaks

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 ? 

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.)

 

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

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

 

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...)

 

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!

 

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

  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.

  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.

 

 

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.