Sam G Cortex M4 256KB flash or 512KB flash.
If you don't know my whole story, keep your mouth shut.
If you know my whole story, you're an accomplice. Keep your mouth shut.
IIRC those are the first picoPower SAMs.
SAM G53 -
Dual digital microphone interface.
Connect it to one of a number of small low power hardware codecs.
I'm guessing enough compute power to run the IP-ready Opus software codec.
Coin cell powered small personal dictation tool.
"Dare to be naïve." - Buckminster Fuller
For a comparison I tried an xmega384c3 as that's the closest Xmega get in flash size. The ARM (one-off) is $8.44, the Xmega is $9.77. One gives you 512K flash and a whopping 96K SRAM at 48MHz and 32 bit with hardware FPU. The other is 384K flash and 32K RAM at 32MHz and just 8 bit, no FPU.
Not difficult to see why Cortex are the more attractive ;-)
just a quick look at the links from digikey, but is it correct that the xxx51xxx have a max voltage of 2.0
but the xxx53xxx have a max of 3.6 ?!
Or is it just a normal Atmel datasheet error?
Nope that 1.62..2V range for Vcc on the x51's seems to be everywhere - not just the datasheet so unless the error was made in one place and has just "snowballed" it would appear to be the case.
All other M4's from Atmel have that 3.6V upper limit to it seems very unusual in that sense.
BTW just noticed:
The SAM G family comes in two series, the SAM G51 and SAM G53. These devices are fully compatible,
For a comparison I tried an
No RSTDISBL, no fun!
I am trying to figure out the SAM3G51's 100uA/MHz and have no idea how to get that value.
Every defined clock system in the characteristics draws more than that by itself. So I suppose that figure was tested with some kind of "external clock" that draws no power.
I also cannot see how (from datasheet tables) 100uA/MHz can be obtained. It is interesting, though, that at 48MHz the active power is about 2x of 12MHz. So there is a "base" value to be active, and then an increment above that?
12MHz running from SRAM is 1.75mA. 24MHz running from SRAM is 2.69mA. So to go from 12Mhz to 13MHz takes less than 100uA more. qed :twisted:
You can put lipstick on a pig, but it is still a pig.
I've never met a pig I didn't like, as long as you have some salt and pepper.
It is interesting, though, that at 48MHz the active power is about 2x of 12MHz.
and then an increment above that?
As for executing code from SRAM - if flash is disabled then that can save some mA - that is the same on all uCs, I doubt manufacturers can compete here. Additionally SRAM typically has no wait states (but that is not a rule) so the overall SRAM:flash performance is not 1:1.
LOL--a quick pass at the datasheet and indeed Atmel marketing needs a medal for that one.
103 ÂµA/MHz running Fibonacci on SRAM
Table 20-3 gives valid paths for master to slave access. The paths shown as â€œ-â€ are forbidden or not wired, e.g. access from the processor I/D bus to internal SRAM..
executing code out of RAM is as you may know, often done during debugging. I never use that, just re-flash and run and use flash breakpoints, etc. These test/dev boards don't ship as products.
executing code out of RAM is as you may know, often done during debugging.
Atmel's "100uA/MHz" advertisement was not given in the context of debugging but in the context of the product of lowest active mode power consumption on the market (even beefiest STM32L reach only 195uA/MHz, from flash).
My point is that to A/MHz efficiently execute from SRAM on ARMv7-M (irrespective of what your aim is) you have to tie I-bus to SRAM, otherwise whole "100uA/MHz" is, paraphrasing OP: "mighty stupid".
I am not an ARMv7-M expert, just a user, but executing from S-bus is really slow. I tried that on STM32 and LPC, it is doable but transfer of instructions was always much slower than through I-bus.
Perhaps there is some magic trick that allows SAM G reach 100uA/MHz? Any test code available?
Flashing 10's of KB is so fast, and boards are so cheap, that I don't mess with run-in-RAM debugging. But the main advantage of RAM debugging is the ability of setting many breakpoints without having to rewrite flash from within the debugger (J-Link flash breakpoints, et al). I used the heck out of J-Link.
Flashing 10's of KB is so fast, and boards are so cheap, that I don't mess with run-in-RAM debugging.
Similarly OT: I do use SplitCode regularly but I neither care about how fast it runs nor how much current my DEBUG build reaches really.
Back on topic:
Related discussion about how ARMv7-M execution from SRAM works and why s-bus execution for A/MHz performance is a silly idea.
If you are running code from SRAM via the system bus, it lose performance because:
© 2020 Microchip Technology Inc.