New "Sam" arm chips are mighty attractive

Go To Last Post
12 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

http://www.digikey.com/product-h...

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. 

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

IIRC those are the first picoPower SAMs.
SAM G53 -
Dual digital microphone interface.
Dual I2S.
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

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

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

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

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?

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

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:

Quote:
The SAM G family comes in two series, the SAM G51 and SAM G53. These devices are fully compatible,

Not sure how they could claim that if they have differing upper Vcc limits?

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

Quote:
For a comparison I tried an

STM32L that is not CM4 but CM3 only (32-512kB of flash), operates 1.65V to 3.6V.
That is quite hard to compare both uCs as SAM3G51 has 64/128 bit flash and STM32L has 32/64 bit flash.
STM32L is A/MHz efficient at 4.2MHz RC from flash when it draws 900uA (214uA/MHz).
I am trying to figure out the SAM3G51's 100uA/MHz and have no idea how to get that value. When executing at similar performance (same wait states, flash width, F_CPU and voltage) then both draw about same current. Where did they take that 100uA/MHz from??

No RSTDISBL, no fun!

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

Quote:

I am trying to figure out the SAM3G51's 100uA/MHz and have no idea how to get that value.

LOL--a quick pass at the datasheet and indeed Atmel marketing needs a medal for that one.

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.

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

Quote:
It is interesting, though, that at 48MHz the active power is about 2x of 12MHz.

Mind that the 12MHz consumption is given with flash running at 12MHz (0 wait states) and 48MHz consumption is also given with flash ticking at 12MHz (3 wait states) so it is only the core (+ buses) that is ticking at 48MHz while the flash stays unchanged.
Quote:
and then an increment above that?

Razzle-dazzle them.

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.

Quote:
LOL--a quick pass at the datasheet and indeed Atmel marketing needs a medal for that one.

Digging deeper, in datasheet they wrote:
103 µA/MHz running Fibonacci on SRAM

So this performance can be achieved when running from SRAM at 4.97mA at 48MHz..

EDIT:

Quote:
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..

To me that looks like SAM3G does not have SRAM wired to I-bus?! Or I read it wrong? Executing code this way and moving instructions through S-bus is dog-slow (at least 3-4 times slower than through I-bus) so I do not get it what is the point running it at 48MHz, advertising 103uA/MHz if only a quarter of the ticks gives any effect and the rest of the ticks is directly transferred to heat...
Can anyone test some code (nop loop) execution from SRAM on SAM3G?
My STM32L has SRAM connected to all three buses so it can execute from SRAM with the same performance as from flash with 0 wait states..

No RSTDISBL, no fun!

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

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.

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

Quote:
executing code out of RAM is as you may know, often done during debugging.

Actually it is done whenever the method offers an advantage over alternatives (over flash in this case) so this is a matter of:
    convenience of debugging, speed of programming,
    execution speed,
    power consumption,
    self-modification of the code,
    need for dynamic linking,
    available memory size
    etc.
Use it whenever it suits your needs, not necessarily for 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?
gksyj

No RSTDISBL, no fun!

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

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.

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

stevech wrote:
Flashing 10's of KB is so fast, and boards are so cheap, that I don't mess with run-in-RAM debugging.

Everyone has some personal preferences.

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

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.

Joseph Yiu wrote:
If you are running code from SRAM via the system bus, it lose performance because:

g3ij5

No RSTDISBL, no fun!