1
\$\begingroup\$

Although I am an experienced software engineer, I am still quite a novice in electrical engineering. So please bare with me in explaining my requirements:

I have a small garden in my backyard and I would like to add a soil moisture sensor in the ground, connecting it with an RFM95W as a LoRaWAN node.

The sensor will likely take a measurement every 6 to 9 hours, and go to sleep to save battery life.

Whichever board I use will connect to another RFM95W that's a LoraWAN gateway hooked up to an Rpi inside my home, so that I can forward the data to a local LoRa Server (MQTT).

Eventually I hope to get to a point where the board will open a water source when the soil is dry (over PWM motor control -- which I have done with the Pi over bare metal before).

Secondly I hope to run some very basic deep learning on the data, directly on the MCU as discussed in this blog post

Therefore, choosing an ARM MCU seems like a good fit. There's the Cortex-M0 and its successor the M0+.

The problem I have in making the decision between them is based on the following:

1) The M0+ is marketed as a very power efficient MCU and therefore can work well with a battery for a long time

2) The M0 however seems to be very reasonably priced in its development boards, such as the SMT32F vs. the SAMD

Therefore I am wondering if the low power consumption is the case for the difference in price and if I can still get the same performance; i.e. long battery life, from the M0?

\$\endgroup\$
19
  • 1
    \$\begingroup\$ @Maple an ATtiny will not be up to the task of running a practically suitable radio stack for this transceiver, nor will that now ancient core necessarily win on power. LoRa is a radio modulation, it is not a controller, so you cannot connect a sensor directly to it. The Semtech LoRa chip in the mentioned Hope RF RFM95 is an SPI peripheral and needs quite a lot of support code from a host MCU for the typical protocols and frequency hopping schemes utilized with that modulation type. \$\endgroup\$ Commented Jun 16, 2018 at 1:34
  • 3
    \$\begingroup\$ @SamHammamy this type of question is off topic here. The reality is you'll probably change course a few times before you have something deployed with useful battery life after you consider things like the regulator and receive windows (if you want downstream control, which is much more power expensive than upstream reporting). Start with a higher memory resources ARM board for which you can find a good LoRa (or better, LoRaWAN or TTN) example, and once you've learned from that you can port to something that based on that experience feels like a better fit. \$\endgroup\$ Commented Jun 16, 2018 at 1:40
  • 1
    \$\begingroup\$ Personally, I'd get either the NUCLEO-L073RZ and prototype on a high memory variant until I made up my mind what I needed in deployment, or the CMWX1ZZABZ-078 which is the same 192KB M0+ combined with the SX1276 off the RFM95, in a compact module. \$\endgroup\$ Commented Jun 16, 2018 at 5:36
  • 1
    \$\begingroup\$ You have several tasks, first take ANY board, an rpi or whatever and figure out how to configure and use the RFM95W, most of that knowledge can be ported to your final platform. Next do the low power work, most of the MCU vendors have low power products, buy one/some and figure out how to make them run at low power. Also you have to do your power design, understand how much each component uses when sleeping and when not, is this solar, battery, etc. And do that design. it is great to have an overall goal but you have a long road to get there. \$\endgroup\$
    – old_timer
    Commented Jun 16, 2018 at 16:16
  • 1
    \$\begingroup\$ Expect failure and redesign. if you stick with it you can on each new design extend the battery life or increase the range of your transmission, use a smaller battery, smaller enclosure, etc... \$\endgroup\$
    – old_timer
    Commented Jun 16, 2018 at 16:17

1 Answer 1

2
\$\begingroup\$

It's not really possible to answer this question accurately, because neither you nor the article you link to provide any sort of useful definition of 'deep learning'. Depending on who you talk to, this can encompass simple filtering and correlation work, all the way up to what DeepMind are doing. The term is ambigiuous to the point of being meaningless.

At a more practical level, there are very few differences between the M0 and M0+. While the M0+ has the potential to be more power efficient, the reality is that it depends much more heavily on the actual vendor implementation. On a very low power system peripherals and clock circuits can easy negate any power savings in the core itself. Most vendors have specific ranges of chips that are optimised for power saving, and you should just make your decision based on the characteristics of these chips - ignoring whether the internal implementation is an M0/M0+ or even any other Cortex M core.

One thing to note is that the M0/M0+ architecture is quite badly IO constrained, as it typically takes 2-3 instruction cycles to load/store a register from memory or IO. There is also no load/store pipelining as in the higher end Cortex chips. The result is that if you are doing a lot of bit bashing then an 8-bit processor can usually run rings around an M0/M0+. For example, flipping an IO port bit on the PIC12 can be done in 1 instruction cycle. On a Cortex M0/M0+ it would take between 5 and 7.

At the other end of the performance spectrum, this slowness of register transfers can also have a profound impact on the chip's ability to process large data sets (e.g. if you are implementing a filter or correlator). Going to something more powerful like an M3/M4 might actually gain you power efficiency under heavy math loads but you'd need to know a lot more about what analysis you plan to do before you could determine that.

\$\endgroup\$
2
  • \$\begingroup\$ Not at all true! DeepLearning has a clear definition: injecting one or more layers of a neural network into any machine learning task. Taking in the output of an SVM for example, or used as output to a reinforcement learning algorithm. \$\endgroup\$ Commented Jun 16, 2018 at 16:30
  • 1
    \$\begingroup\$ I am accepting your answer because it really gives an excellent reasoning for why the question is too vague. I have a lot to get to before I can decide how the learning will work. \$\endgroup\$ Commented Jun 16, 2018 at 16:34

Not the answer you're looking for? Browse other questions tagged or ask your own question.