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.
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.
#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."
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.)
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.
#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."
#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."
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!
#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."
#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."
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”
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.
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.
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.
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?
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).
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.
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.
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.
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...
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.
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...
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.
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)
via https://plus.google.com/+MicrochipTech/posts/7pLed2HKFf5
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
Topmega4809 Curiosity Nano is a new arrival at Mouser :
https://www.mouser.com/ProductDetail/Microchip-Technology/DM320115?qs=byeeYqUIh0ORWC1t9ckMow%3d%3d
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
Top"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopInteresting. 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."
- Log in or register to post comments
TopIt 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.
- Log in or register to post comments
TopPrediction - megaAVR 1-series
Updated USB device controller, unified memory, ...
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopCurrently future product :
ATmega1609
ATmega1608
ATmega809
ATmega808
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
Topthe overview say :
is that new version or just a bug fixed one ?
- Log in or register to post comments
TopIIRC, CIP is from the PIC side of the house.
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopIf 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.)
- Log in or register to post comments
TopIt'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.
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopThe code for the new ATmega4809-based Arduino board has been checked in:
https://github.com/arduino/ArduinoCore-megaavr
- Log in or register to post comments
TopHow they run it at 16MHz ? I thought it will run at 20MHz. Is the schematic available ?
PIC32 based Ethernet Shield Arduino Uno hardware compatible
PIC32 based Ethernet Shield with Network Switch Arduino Uno hardware compatible
- Log in or register to post comments
TopCouldn'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
- Log in or register to post comments
Top#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."
- Log in or register to post comments
TopATmega4809 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
- Log in or register to post comments
Topin stock
lead time is 15 weeks
ABX00021 Arduino (Uno WiFi Rev2) | Mouser
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
Top"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopThat'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."
- Log in or register to post comments
TopAnd 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...)
- Log in or register to post comments
TopDid 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.
- Log in or register to post comments
TopNo, 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!
- Log in or register to post comments
TopYou'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
- Log in or register to post comments
Top- Log in or register to post comments
TopYes
mega324PB isn't in PDIP.
ATmega324PA - 8-bit AVR Microcontrollers - Microcontrollers and Processors
https://www.microchip.com/mymicrochip/Reports.aspx?type=subject&filter=PDIP
ATmega324PB - 8-bit PIC Microcontrollers - Microcontrollers and Processors
Edit :
No
PDIP picture removed at ATMEGA4809 - 8-bit AVR Microcontrollers - Microcontrollers and Processors
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopArduino 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."
- Log in or register to post comments
TopWhat is a Core Independent Peripheral? - Developer Help
via https://plus.google.com/+MicrochipTech/posts/bfEQ3Nro6mS
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
Top#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."
- Log in or register to post comments
TopSo 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”
- Log in or register to post comments
TopAren't you just talking about PROGMEM (C++) or __flash (C) ?
- Log in or register to post comments
Top- Log in or register to post comments
Top- Log in or register to post comments
Top- Log in or register to post comments
Topor
or
So the compiler provides the address to use because it knows the address of text[] or the PSTR()
- Log in or register to post comments
Top- Log in or register to post comments
TopBut 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?
That does mean using Strcpy() in place of either strcpy() or strcpy_P().
- Log in or register to post comments
TopHi 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).
- Log in or register to post comments
Top- Log in or register to post comments
TopI 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.
- Log in or register to post comments
Top- Log in or register to post comments
TopYes, 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.
- Log in or register to post comments
TopBut 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.
- Log in or register to post comments
TopOops. I know that I should not type directly from my a*se.
I should have looked at my PC first!
David.
- Log in or register to post comments
TopI 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:
will work fine. (I guess I should try it, eh?) But I'd like something "cleaner."
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.
- Log in or register to post comments
TopIt 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...
- Log in or register to post comments
TopNowadays 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.
- Log in or register to post comments
Top- Log in or register to post comments
TopIAR 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
- Log in or register to post comments
Top"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopTexas 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
- Log in or register to post comments
TopPages