Poll
Question:
Would you buy a 32bit Moteino?
Option 1: Yes: I have a very specific requirement of ARM+RF
votes: 9
Option 2: Yes: sounds cool - but I have no idea why it would be better than existing 8bit AVRs
votes: 3
Option 3: No: 8bit AVRs work just fine for my needs
votes: 6
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...
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
(https://cdn.sparkfun.com//assets/parts/1/1/0/9/2/13664-01.jpg)
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
8) 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...
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.
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.
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.
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?
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.
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
Are any of the ARM chips more energy efficient than the atmega328p? i.e. would you get better battery life?
QuoteAre 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.
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:
Quote
/***************************************
* 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.
When I last looked into this (around 6+ month ago), I found that this was a helpful chart:
(https://www.silabs.com/SiteCollectionImages/Misc/32-bit-mcu/energy-modes.png)
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.]
Quote from: WhiteHare on March 03, 2016, 11:54:23 AM
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
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.
If you were to look at supporting the MSP430 I would also take a serious look at the MSP432 for all of the reasons outlined in http://e2e.ti.com/support/microcontrollers/msp430/f/166/t/411030. The biggest downside is the relative newness of the MSP432 family, less than a year since it was announced.
Given how some of us love their RTC here's Ambiq's ARM mcu: http://ambiqmicro.com/system/files/Apollo_MCU_Data_SheetDS0010V0p45.pdf. 196nA sleep with RTC and ram retention and 34uA per MHz, cortex m4f. I don't think there's anything lower power available.
Really cool mcu but tough package options.
Quote from: joelucid on March 04, 2016, 01:20:30 AM
Given how some of us love their RTC here's Ambiq's ARM mcu: http://ambiqmicro.com/system/files/Apollo_MCU_Data_SheetDS0010V0p45.pdf. 196nA sleep with RTC and ram retention and 34uA per MHz, cortex m4f. I don't think there's anything lower power available.
Really cool mcu but tough package options.
Nice find! According to the benchmark results, it tests out as significantly better than all the others: http://www.eembc.org/ulpbench/
and twice as good as the Atmel one that I had referenced above.
Some of my applications do need some more ram and a processor with more interrupts and other goodies such as an RTC. As a test we took an Adafruit M0 Feather and connected it to an RFM69:
RFM69 ---> Feather M0
MISO MOSI
MOSI MISO
SCK SCK
NSS A2
DIO0 (INT) 10
The only changes on the RFM69 library are in RFM69.h on lines 49 and 50:
#define RF69_IRQ_PIN 10
#define RF69_IRQ_NUM 10
This should work with any SAMD21 arduino such as the Sparkfun SAMD21 breakouts, all the Adafruit M0 Feathers and the Arduino M0s. So far it seems to be working just fine. Props to @wifixcort who figured this out.
If we are missing something please let us know!
@bborncr Thanks for your post. For 32 bit, you might also be interested in some of the new "ultra low power" STM32 eval boards, which are $10.99 on Digikey and $10.33 on Mouser: http://www.digikey.com/product-search/en/programmers-development-systems/evaluation-boards-embedded-mcu-dsp/2621773?k=stm32l0&pv47=27856&pv47=27857&FV=fff40028&mnonly=0&newproducts=1&ColumnSort=0&page=1&quantity=0&ptm=0&fid=0&pageSize=500
Never to say never, but at this point I doubt there will be an ARM based Moteino.
Steve Chamberlin from Big Mess'o'Wires wrote an excellent summary (http://www.bigmessowires.com/2016/04/11/too-many-arms/) of why ARM is hard to get started with, and his points are exactly why I did not mess around with ARM so far, so if you want my standpoint read his article, he is spot on on everything. In addition - a main personal reason (and I believe of most Moteino users) is that for the stuff I do I don't need ARM - 8 bit AVR is easy, people get it (well in general), it's super widely known and supported and documented, it does just fine and is low power enough as proven in many excellent research topics in this forum. If you need DSP use an ARM or FPGA.
Yup, I agree with you. Nonetheless, I was over at Mouser earlier today shopping for a few odds and ends when I unexpectedly stumbled across a new component that's was foreshadowed by the discussion earlier earlier in this thread: it's a fairly small package (just 14x14mm in size) that contains both an 915Mhz FSK radio (with bitrates up to 500kbps) and one of the recently discussed "ultra low power" 32Mhz ARM processors that sports 16KB RAM and 128KB Flash: http://www.mouser.com/pdfdocs/DM00133214-2.pdf
Quoteit's a fairly small package (just 14x14mm in size)
That's 14x14mm including the chip antenna! Wow.
Quote from: joelucid on April 19, 2016, 12:17:26 AM
Quoteit's a fairly small package (just 14x14mm in size)
That's 14x14mm including the chip antenna! Wow.
Is the ARM Cortex programmable ? It's seems it's only the core of the module that need to communicate with another host cpu no ?