1
\$\begingroup\$

I'm designing an IoT Device with many sensors which are going to be integrated using serial interfaces like UART, SPI, I2C and so on. For communication capabilities, I plan to use Wi-Fi (IEEE 802.11). Does it make sense to use something like Atmel’s Wi-Fi SoC and SAM D21 ARM Cortex-M0+ MCU or use Atmel's Cortex M4 and then integrate a WiFi module using SPI or UART (not a SoC solution).

  • If I go with M0 option, I have the advantage of Wifi and MCU on single chip.
  • With M4, I will have to integrate them together using some serial interface. But the advantage is a faster processor.

Since I have many peripherals on board, does it makes sense to use a Cortex M4 CPU which is much faster and capable?

Edit: I'm sure this is opinion based. But I'm looking for some valid design inputs which help me make this choice. For example,

  • I plan to integrate a SD storage, real time clock, a number of sensors - temperature, energy etc. The number of peripherals might be 10 - 12. All integrated through UART, SPI and I2C. I also plan to have communication - Wifi, RF, GSM, Ethernet etc.

  • I don't need any hardcore mathematical capability. FPU unit would be nice but not compulsory.

What I'm looking for are answers to questions like --

  1. Does having many peripherals mean I need a bigger and a faster processor? I know this can be handled by ATMega. I was using an 8 bit ATMega for something similar. It worked. But I'm moving to a bigger platform with more peripherals.
  2. Will going for bigger processor like M4 and M7 help me handle time sensitive operations like RF, WiFi and sensor communication?
  3. How does one choose based on valid design principles? Is there a set of rules?
  4. Does faster processor speed, RAM and Flash mean easier to work with when I'm switching between different peripherals?

Also: I'm an electrical engineer with amateur/decent embedded programming skills. Not the greatest but decent.

\$\endgroup\$

closed as primarily opinion-based by Turbo J, Asmyldof, PeterJ, Daniel Grillo, m.Alin Jan 26 '16 at 14:52

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    \$\begingroup\$ The main problems with this question, in my opinion are: 1. It's almost entirely opinion based, also because (but not limited to): 2. You specify nothing about required mathematical capabilities. What you do talk about can be handled by an ATMega, if not Tiny. 3. You specify nothing about your own design skills, vis-a-vis building the design around whatever option \$\endgroup\$ – Asmyldof Jan 26 '16 at 12:51
3
\$\begingroup\$

To summarily answer your central points;

In handling communication with peripheral devices selecting the right processor with the correct support for the hardware busses you are using is the most important. There are many ways to do many kinds of communication, but most SPI enabled items that you should concern yourself with as a somewhat experienced amateur will be in the 10 to 20MHz of SPI range at most.

That means that your SPI peripheral will clock out a byte for every 20-ish core clock cycles on a 48MHz CPU at the moments of highest activity. In a well designed interrupted environment that is more than enough if you're not doing huge amounts of masking, shifting, adding and dividing on each individual byte, for every single byte.

Moreover, going to 80MHz will not help you significantly there if you start chocking.

So you are much better off finding a processor with good support for Peripheral Management such as a DMA/uDMA system that's usable for large transfers and a nice hardware FIFO, if at all possible, that will hold at least 4 bytes of data (2 16bit words, or 1 32bit qword, or just 4 bytes), so you can bulk-build int32 values.

What will help you most with Real-Time considerations is understanding how interrupts work and how to efficiently use them without blocking up huge chunks of processor time. After-all, while the serial peripheral is clocking out or in data at a few MHz your core needs to not do anything about that, as long as you chose the right controller with the right kind of hardware support.

The amount of internal RAM (or fast parallel external RAM, but seriously, you don't want to start thinking about that at this point in your 'career') you need will be dictated by how much data one thing will generate in the time another thing needs to handle the output of it. If you make sure your output pipe (probably WiFi?) is fast and your sensors generate an order of magnitude less data, you won't need that much RAM as long as you manage the flow well. If you create 5kB data packages of which the start depends on the end through your own silly design, you will need more RAM than when you make it so there is no dependency outside 512byte blocks (or less).

A faster core speed will not help you greatly if all you are doing is move a few bytes around every interrupt you get. If you need super high speed SPI (which the WiFi module likely won't support if it's at all affordable anyway) you need a processor with a high-speed peripheral clock and high-speed, low-capacitance I/O pin drivers, rather than one with a fast core.

To paraphrase anecdotally: I'm now using an M4 processor to make something that could have been done with a 20MHz Atmega, if it weren't for the fact that the bus interface some numbskull specified needs very high speed Bit-Banging and FPGAs are not an option in this design. So, I am inputting let's say 5Mbps of data and outputting that over standard peripherals like I2C and SPI and all gets decoded, mathified and what not, but 70% of the time my core does something it's bit-banging the 5Mbps input and quickly deciding on bit-to-bit decisions. Take that away and I could have chosen at least an 8 fold cheaper MPU. Because almost all else is interrupt and hardware in which the core does absolutely nothing.

\$\endgroup\$
  • \$\begingroup\$ Thanks. This helped. I was looking for info along the lines you explained. Serial interfaces with interrupt handling is going to be the chunk of the project. I have a bunch of slave SPI sensors ( 8 - 10), WiFi (UART) and RF(SPI). Also storage (SPI) and RTC (I2C). So i'm looking at about 15 peripherals - SPI, UART and SPI. Most of the time will be spent on handling interrupts, doping some minimal processing and then sending data through Wifi/RF. I'm looking at 50 - 100 bytes data packets. I plan to execute algorithms locally. FPU might be useful here. \$\endgroup\$ – am3 Jan 26 '16 at 18:05
  • \$\begingroup\$ I was looking at some design guidelines on selecting a controller. Some of the points raised were 1) Are there any high frequency control loops/sensors? 2) Examine how often each task has to run? This is interesting because if I have 10 - 15 peripherals, I'm looping through at-least 10 functions to check the status/perform something. Also how do I estimate 2? ARMs Cortex M7 was released for the IoT market. Does it make sense to consider that or is it an overkill? \$\endgroup\$ – am3 Jan 26 '16 at 18:09
  • \$\begingroup\$ @AGM To be honest, you still haven't given me anything that'd make me think you need any significant core speed or processing power at all. WiFi is easier with a 32bit core, but otherwise I'd have guessed there are XMega's with over-clocked peripheral busses that might even win from an M0+ at 48MHz on a throughput argument, specially on an UART. Also, why an UART WiFi? Do they even exist? Asynchronous where synchronous is readily available is flushing performance down the drain outright. \$\endgroup\$ – Asmyldof Jan 26 '16 at 18:24
  • \$\begingroup\$ This is the architecture I have so far 1 RF (SPI slave), 1 SD storage (SPI Slave), 1 RTC (I2C), 1 WiFi (UART/SPI), 12 Temp/Energy Sensors (SPI slave) A total of 15 peripherals. Each of these sensors gather data and transmit to RF or to the cloud through Wifi. The entire system is time sensitive where I have to process, send and recieve in < 2s. I have some basic processing such as protocol conversion from RF <--> Wifi Also, I plan to have an algorithm which gathers data from all these sensors and determines state of the system. I'll have about 15 peripherals with about 8-10 sensors. \$\endgroup\$ – am3 Jan 26 '16 at 19:17
  • \$\begingroup\$ This is rapidly turning into "this is my stuff, help me design it". Although I can unequivocally say that in bare-metal programming 2 seconds is ages, even for a 2MHz core (4 MILLION clocks in that!). So if that's your only constraint stop worrying and order a dev board at random. Or based on solution cost. If you want host-type WiFi stuff get one with a crypto block and you'll be doing nearly no maths at all with your core anyway. \$\endgroup\$ – Asmyldof Jan 27 '16 at 10:35
1
\$\begingroup\$

I think m4 would be better since the CPU clock is much faster, you can conserve power (which I think is a major factor in IOT) by going to sleep mode quickly. Plus integrating using serial interface is not an issue, the utility should be a problem in design consideration. Plus you are using M0+ not M0, M0+ was designed for low power applications in mind. However if you are looking for something fancy I would recommend you take a look at cortex M4f. but I have given you a general overview for someone willing to take the plunge as an interest.

But like @Asmyldof pointed out there are a lot of factors that can affect your design decisions. So it would be better if you finalize them before selecting your choice of MCU...

\$\endgroup\$
  • \$\begingroup\$ Thanks @fazkan. My bad.. you're right, its M0+. Can you point me to some resources which will help me understand the factors you're talking about which will affect my design decisions and choose MCU. I already have a list of peripherals that I want to integrate and the interface they support. For example -- WiFi (UART), Temp sensor (SPI), RF (SPI), SD (SPI), RTC (I2C) and so on. I have narrowed down the manufacturer and the particular component. All I have left is choosing the MCU. \$\endgroup\$ – am3 Jan 26 '16 at 13:52
  • \$\begingroup\$ yea there is a great article that I read a while back..wait lemme check....link, this is the basic article ...then you can find ton of information on ARMS website....atmel.com/images/mcu_vs_mpu_article.pdf, here is another that should give you an idea of MCU measurement and differences...Can you upvote the answer if it helped you thanks..... \$\endgroup\$ – fazkan Jan 26 '16 at 15:19

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