32Bit Moteino

[lafleur]

As you consider upgrades to your Moteino's, please consider adding a family using the same processor family as used on the Arduino Zero board...
Atmel's SAMD21 MCU, with a 32-bit ARM Cortex M0+ core. Some of the low end part are cheaper that the 8bit 328.

This would allow instant development tools, large support community, and your form factors...

would be a happy alpha tester....

Thanks...

[Felix]

Thanks for the suggestion Tom,

This is a very considerable dev effort and cost, it's like starting development from scratch. What would be a use case where 32bit SAM is a much better choice than the 8bit AVR?

What about adding a shield for a board that already exists: https://www.sparkfun.com/products/13664

[lafleur]

Yes, I have a radio + I/O board that I have built for this device... But it would be a nice upgrade if it was available in a commercial device with RFM69 and LoRa radios...

1) I do a lot of signal processing in some of my nodes, so fast 32 bit math is needed
2) Lot more memory, ram
3) almost the same foot print as the AVR328, so it should be easy to port to your format
4) full support as a Arduino Zero, very little development if any on your part to support it
5) built in USB for programming
6) lots of I/O port configuration... Serial, Interrupts, RTC, ect
7) reference design from Arduino Zero and Sparkfun
smaller foot print than a stack unit..
9) its time to move up to low cost 32 bit devices and escape the limitation of the 8 bit world.
10) cost the same as the 8bit processor, more bang for the $

just my two bits...

[Felix]

Let me comment on each point:

1) I do a lot of signal processing in some of my nodes, so fast 32 bit math is needed
2) Lot more memory, ram
Felix: interesting. I sure can see how DSP and lots of FLASH and especially RAM are needed so these go hand in hand.

3) almost the same foot print as the AVR328, so it should be easy to port to your format
Felix: Agree

4) full support as a Arduino Zero, very little development if any on your part to support it
Felix: Somewhat agree. These things tend to be very open ended. I need a bootloader that is compatible with DualOptiboot, that can be a time burner.

5) built in USB for programming
Felix: Cool but .. it does not come for free that's for sure.

6) lots of I/O port configuration... Serial, Interrupts, RTC, ect
Felix: This can be a 2 edged sword. More configuration and option means more support when people are clueless as to how to use the device. Who will put in the time for that support?
What i'd really like to see in such a device is a hardware 128/256bit AES engine. That would be a great complement to any DSP and especially RF applications.

7) reference design from Arduino Zero and Sparkfun
Felix: Nice to have but still the heavy load is on me, it's really not like [copy paste submit pcb done].

8 ) smaller foot print than a stack unit..
Felix: OK

9) its time to move up to low cost 32 bit devices and escape the limitation of the 8 bit world.
Felix: Maybe. 32bit is not always a net upgrade from 8bit. It really depends on the requirements. Why are there 8bits in most simple computers in our houses?
Low Cost 32bit is a rather overstatement. This particular chip is still about 2x more expensive in quantity than the atmega328p so no win here (although we're comparing apples to oranges), but strictly price speaking.

10) cost the same as the 8bit processor, more bang for the $
Felix: Disagree, see response to #8

Still lots of other points to touch on in order to have a full perspective of what it involves to make a board like this and add radio, make it compatible with the other devices in the family, make it easy to use, keep the design clean to minimize support, etc etc...
From an economical point of view for LPL as a small business, the imperative question is if such a device is really wanted by a large majority of users. I am talking hundreds to thousands. Then numbers start to favor making it. If only say 100-200 people want it, then the hundreds of hours invested into putting a product like this into the end user hands, will translate to less than minimum wage which is not fun

I am adding a poll to this thread as a curiosity.

[jra]

To be perfectly honest the 32 Bit Teensy Boards https://www.pjrc.com/teensy/index.html already provide the following:

• 72 MHz MK20DX256 ARM Cortex-M4 (256K Flash, 64K RAM)
• Already supported by Arduino IDE
• RFM69W supported (via http://www.airspayce.com/mikem/arduino/RadioHead/), maybe LoRa as well
• $20 for the Teensy 3.2 ($17 for the Osh Park version)
• Small footprint (but not the same as Moteino)

There are also the various Maple Mini clones floating around (http://www.stm32duino.com/viewtopic.php?t=94 or do a Google search for  "red/blue pill stm32"), STM32F103RCBT6 ARM Cortex-M3, 128K Flash, 20K RAM, small form factor, ~$4 on ebay, you get what you pay for.

What you don't yet get and what I suspect would be the hardest to implement are:

• OTA programming via the radio
• Maintaining a small form factor while finding a place to solder the radio AND bring out all of the pins to access all of the available I/O
  
• Running on batteries for an extended period of time

Although interesting from a technical standpoint, I'm not sure there is a favorable business case to justify this.

[john4444]

Lafleur,
JRA posted before I did but, I agree with each of his points except for #3.
The Teensy's Arduino IDE support is very helpful but I want to use Felix's instead of Radiohead's library.
I find the 328's small amount of memory limiting.

[Felix]

In terms of memory there is the MoteinoMEGA to address that.
I have to concur that the 48mhz of Zero's SAMD21 Cortex M0 is a bit of a let down.
An additional thought - DSP feels like a special task that should be done on a separate board, as far away from RF as possible. Cross check anyone?

[jra]

Going from a 2K RAM ATMega328 to a 16K ATMega1284 is arguably a more significant jump than going from a 16K ATMega1284 to a 64K ARM.  I'm trying to think of a real world problem (other than DSP and related number crunching) for an MCU that would benefit from more than 16K of memory, maybe running a display with custom fonts?  Then again, my first exposure to embedded systems involved an Intel SDK-85 with a 3MHz 8085 and 256 Bytes of RAM that was programmed by keying in hand-assembled code so I am probably showing some bias (or age).  Given the EMI thread https://lowpowerlab.com/forum/index.php/topic,1538.0.html I think keeping the radio isolated from the DSP is an excellent idea.  If you're doing enough crunching that battery power is not practical, it's tough to justify a $20 MCU board when $25 will get you a multi-core Raspberry/Orange Pi with loads of debugged libraries/applications already available.

[joelucid]

I have to say I agree that having a ARM based 32-bit Moteino would be a good thing. Of course most applications work on an AVR processor as well. Maybe the most important argument hasn't even been brought up yet: guiding customers into a future-proof platform.

The Moteino is a great gateway drug into the embedded world and once you start with it, like Felix, you'll find that the next project is just so much easier to do with an AVR processor again. Meanwhile you build up knowledge and infrastructure that make it less and less likely that you'll ever switch.

But let's face it: AVR isn't exactly the platform of the future. Today I'd be much happier if Moteino had pulled me into the ARM direction and I'd have all the options and power of that platform at my disposal. And had learned the deep details of that platform instead of AVR.

However even if there were an ARM Moteino available now I don't know if I'd switch. I think it takes a killer application that's just much, much easier to do with ARM, or that can only be done with ARM to cause the switch once you're fully invested.

Joe

[WhiteHare]

Are any of the ARM chips more energy efficient than the atmega328p?  i.e. would you get better battery life?

[joelucid]

Are any of the ARM chips more energy efficient than the atmega328p?

There are many that come with a decent wakeup source < 1uA. On the other side the 100nA powerDown with memory retention is still very good compared to ARM.

[jra]

There is a Snooze library available for the Teensy 3.x and LC (Freescale MK20X256 Cortex-M4 and MKL26Z64VFT4 Cortex-M0+, respectively) https://github.com/duff2013/Snooze.  According to the notes in the https://github.com/duff2013/Snooze/blob/master/examples/deepsleep/pushbutton_pullup_deepSleep/pushbutton_pullup_deepSleep.ino example:

/***************************************
* deepSleep with pushbutton w/ pullup.
* Expect IDD of  around 230uA for deepSleep
* and 15uA for hibernate (Teensy 3.x) and
* IDD of around 150uA for deepSleep and 4uA
* (Teensy LC).
****************************************/

BTW the MKL26Z64VFT4  used by the Teensy-LC is a lower cost product with 62K of Flash and 8K of memory which is about half what you would get in an ATMega1284. Other flavors of ARM may have more favorable low power characteristics.  There are a bazillion versions of ARM processors available so I agree with joelucid that the biggest advantage is that this family is going to be around for a long long time.  The flip side is there are a bazillion versions available that are all different enough to make generic support difficult.  Read some of the comments on the http://www.stm32duino.com/ board about supporting the F1 vs. F3 vs. F4 lines and these are all from the same STM32 family from the same vendor.  The hardest part about switching to ARM might just be deciding which vendor/family(s) to support and then hoping that particular choice sticks around for awhile.

[WhiteHare]

When I last looked into this (around 6+ month ago), I found that this was a helpful chart:



The 20na shut-off mode seems like a viable option when you consider that the wake-up time from that mode is just 160uSec, which is less than the atmega328p's wake-up time from powerdown.

Unrelated to that, I was also impressed that the Atmel SAM L21 Cotex M0+ consumes 35uA/Mhz while in Active mode.  Why?  Well, it's deepest sleep mode is 200na, and it consumes less while active than the above EFM32 does while sleeping!  Here's a  datasheet for it:   http://www.atmel.com/images/atmel-42385-sam-l21_datasheet.pdf

What about cost?  Looks as though the L21 costs about $4.49 in quantity 1 on Digikey, where it is already in-stock and available for purchase:  http://www.digikey.com/product-detail/en/atmel/ATSAML21E15B-AUT/ATSAML21E15B-AUTCT-ND/5702296  If it means anything, that's actually a lot cheaper than the quantity 1  Digikey price ($7.56)  for the atmega1284.  The Moteino Mega is a very nice board, though, so I only mention it so as to have a point of reference.  Likewise, the quantity 1 digikey price on the atmega328p is $2.50.  Perhaps those three datapoints  give some indication as to the relative mcu costs in higher volume.

Anyhow, it's hard to have a meaningful comparison without putting numbers on things, so hopefully the above helps in that regard.

[Edit: Just an idea, but if Felix were to make an mBed Moteino, he could possibly reach a large audience, because mBed appears to be picking up with a plastform agnostic common development toolchain while the Arduino Italians have been slow to develop new stuff:  https://developer.mbed.org/platforms/   That would also address the concern voiced by some here of being stranded on the Arduino island while the rest of the world moves on.  There are already a number of mBed Lora boards turning up there, but not yet any mBed RFM69's.]

[TomWS]

The 20na shut-off mode seems like a viable option when you consider that the wake-up time from that mode is just 160uSec, which is less than the atmega328p's wake-up time from powerdown.

The EM4 power state is pretty pointless unless you have a case where you need to setup GPIOs and have them frozen in some state prior to the next reset.  All RAM is lost in this state so a simple resume is impossible.

Tom

[Felix]

What about MSP430 guys? There are literally endless variants available, even MCUs with wireless capabilities (SOC), all made by TI so that's a plus. They have a very low power reputation.