Arduino vs Raspberry Pi: What's the best hardware for IoT prototyping?

05.11.2021
guide-image

Choosing the right hardware is one of the key questions for building any IoT solution. This decision directly impacts important factors like the functionality, security and scalability of your IoT project. For prototyping and piloting purposes, Raspberry Pi models and Arduino boards are the most common choices, but which one is the best for your solution? You’re about to find out.

What is an Arduino and a Raspberry Pi?

Arduino Raspberry Pi
An Arduino board is a micro controller able to read inputs and execute simple tasks like activating a motor, sending an SMS, reading temperature, etc. programmed though an open-source software. A Raspberry Pi is basically a small scale computer, which runs on a full OS (Linux based), capable of reading inputs and running programs.

For the purpose of comparison, we will look at the Raspberry Pi model 3 and the Arduino Uno, one of the most popular Arduino boards. While a newer version, the Raspberry Pi model 4 exists, the model 3 still shares the same or very similar features that are important in IoT while being more affordable and less power consuming compared to the Model 4. In addition, the model 3 benefits from a significantly larger amount of documentation and support.

Computing Power

The most important question you will need to answer is - What task(s) does your hardware need to do?  

Arduino 

The Arduino Uno typically uses an ATmega328 chip operating at 16MHz with 2KB RAM, 1KB of EEPROM and 32KB flash memory. It can perform simple, single tasks one at a time. For example, streaming input data via cellular as its received by the Arduino would not be possible.

Raspberry Pi 

The Raspberry Pi, as explained earlier, comes with a full-fledged OS, a 1.2GHz 64-bit quad-core ARM Coretx-A53 processor and 512MB RAM, a 32GB SD card and ports for USB and HDMI. It's more powerful than the Arduino Uno and capable of running multiple programs and execute many tasks simultaneously.  

I/O and interfaces

RaspberryPi 3BArduino Uno

Arduino  

The Arduino UNO comes with 14 digital input/output pins, 6 of which can be used as PWM outputs, and 6 analog input pins. PWM, short for pulse width modulation, can be used to create analog signals by digital means, which can be used to create audio signals or providing variable speed control for motors. A USB type B port is used to connect the Arduino to a laptop/computer, where you can use the Arduino IDE software to program it. It does not support a visual output interface through which data could be displayed.

Raspberry Pi 

The Raspberry Pi 3 has 40 pins on board, two of which are 5V power pins directly connected to the power input and another two 3.3V. The 5V power input pins can be used for power supply in low power applications. The 3.3V pins may power other components like blinking LEDs indicating activity, but they cannot be used to power the Raspberry Pi. Apart from the 8 ground pins, there are 28 GPIO (general purpose input/output) pins, meaning they can all act as either input or output pins. Furthermore, the Raspberry Pi 3 has a built-in Ethernet port, two USB 3.0 and two USB 2.0 ports as well as an HDMI output. 

Power consumption 

Power supply is one of the critical aspects of  IoT. If your devices are deployed at locations with no power supply or only send data every now and then, batteries might be the right option.  

Arduino 

The Arduino Uno can be powered with a 9V battery, making it ideal for low-power applications. It also does not need a proper bootup process as it runs the moment it is connected to a power source.  

Raspberry Pi  

The Raspberry Pi model 3 in contrast, requires a proper boot-up and shut-down protocol, much like your computer. Its power consumption is also significantly higher (~700mW) compared to the Arduino Uno (~150mW), making it unfavorable for a battery powered IoT solution. 

External hardware compatibility 

Both the Arduino Uno and Raspberry Pi 3 can be equipped with shields to add functionality, like cellular connectivity. While the Raspberry Pi 3 already has connectivity (Wi-Fi, Bluetooth) and different interfaces in the base model, the Arduino Uno requires more shields, which can be connected to the I/O pins. Depending on the use-case, many shields may be required, which can impact the price of the development boards.

RaspberryPi_Closeup

Developer support 

When working with new hardware and software, rich documentation and support is crucial for efficient development and speed of deployment. Both the Raspberry Pi and the Arduino Uno were originally designed for educational purposes, meaning that both come with a full documentation on hardware and software.

Arduino

Arduino group  offers an active forum covering projects, development, software, and community questions. Their documentation includes quick-start guides, datasheets, pin schematics and suggested open-source libraries.

Raspberry Pi

The Raspberry Pi foundation provides courses for beginners, tutorials on the configuration and applications for Raspberry Pis. Abundant user guides to all accessories / shields and an active support forum are also available.   Apart from the in-house support , several independent creators offer video tutorials on YouTube or documentation on other forums.
 EMnify Imagery-18

Cost

Hardware costs are an important factor when building an IoT solution. Even for prototyping and piloting purposes with 10-100 devices, development boards and necessary add-on shields can become expensive.

The basic Arduino Uno board costs around 20-25$, whereas the Raspberry Pi 3, being one of the newer models, costs around 35-40$. While the Arduino might seem like the preferred choice, one must keep in mind that it requires add-on shields for any extra functionality, like connectivity. Also, as discussed above, the Raspberry Pi comes with more processing power and capabilities compared to the Arduino, making it ideal for more complex IoT solutions.

Summary 

Features Arduino Uno Raspberry Pi 3
Computing Power ATmega328 chip 16MHz, 2KB RAM, 1KB EEPROM, 32KB flash memory Raspbian OS (Linux based), 1.2GHz 64-bit-quad-core ARM Coretx-A53, 512MB RAM, 32GB SD card.
I / O Interfaces 14 digital I/O pins, 6 analog input pins, USB type B 40 pins total (28 GPIO, 2x 5V power input, 2x 3.3V power output, 8 ground pins), 2x USB 3.0, 2x USB 2.0, HDMI
Power Consumption Low power consumption. Standard AC plug 7-12V. Alternatively 9V battery is sufficient High power consumption. Standard AC wall plug, only low power applications can be powered through the 5.5V power pins.
External hardware compatibility Requires shields for any type of connectivity (Wi-Fi, Bluetooth, cellular) Wi-Fi and Bluetooth are integrated. Cellular connectivity requires add-on shield
Developer Support Rich documentation and active forum. Video tutorials of independent creators are also available Rich documentation and active forum. Video tutorials of independent creators are also available
Cost 20-25$ 35-40

Arduino_RPi_Cost

Use-cases 

As we have seen, both the Raspberry Pi 3 and the Arduino Uno have their strengths and weaknesses. In the end, the right choice is highly dependent on your device requirements / limitations. Prototyping and deploying small, battery-run weather sensors to remote locations where they occasionally measure humidity, temperature could be an ideal use-case for an Arduino Uno. More complex tasks can be handled by a Raspberry Pi, like acting as an aggregator of many individual sensor data and as a gateway to your backend application. 

More ways to optimize your IoT solution 

The right hardware choice, whether its Arduino or Raspberry Pi, provides incredible value to your business by reducing developer hours, time-to-market and troubleshooting incidents. Choosing the right hardware, however, is just the first step to future-proof your IoT application.

 

All cellular IoT solutions require a reliable and secure connectivity partner that understands individual needs – providing tailored data plans,  and a powerful platform that is built to scale easily with automated connectivity management via API and no-code integrations. 

Want to start prototyping your devices with the best cellular connectivity for global IoT?  

Order your free trial kit today and start testing our platform with 3 free SIM cards and a balance of 10€.
Image of Constantin Ernst

Constantin Ernst

Product Manager at EMnify.

Related Posts

Image for post Create an IoT Gateway with EMnify, Raspberry Pi and Sixfab

Create an IoT Gateway with EMnify, Raspberry Pi and Sixfab

25.03.2021 –

While there are several ways to connect your IoT devices, cellular connectivity is by far the favorite choice for mobile applications. Although when you are in the prototyping phase of your IoT application, mobile connectivity can get a little tricky with choosing the modem, the connectivity provider, the configuration required, etc.
Image for post How to fit a Raspberry Pi with mobile connectivity

How to fit a Raspberry Pi with mobile connectivity

11.10.2015 –

The Raspberry Pi is a great platform to prototype and realize projects for IoT. Network connectivity can easily be established via its build-in Ethernet interface or an optional Wifi dongle.
Image for post LwM2M vs MQTT: Which one is the best for IoT Solutions?

LwM2M vs MQTT: Which one is the best for IoT Solutions?

13.12.2021 –

While building IoT solutions, keeping the footprint small is of utmost importance. This requirement influences all design aspects of IoT solutions, including communication. Transferring data from your IoT devices to your application servers efficiently is important, but at the same time, you also need to have a lightweight way of doing so. In this post, I will compare MQTT and LwM2M communication protocols for IoT solutions. What are Communication Protocols? Simply put, communication protocols are rules that define how two connected systems communicate with each other. These protocols cover everything from authentication, signalling, security, data transfer, flow control to error detection and handling. The Internet of Things drives innovation in these protocols to make them more efficient and secure among other things. What is MQTT? MQTT stands for MQ Telemetry Transport where the MQ part comes from an IBM product called the MQ Series. MQTT is a protocol that was specifically built for M2M and IoT message transfer by Andy Stanford-Clark (IBM) and Arlen Nipper (Arcom). The protocol helps transfer messages using the publish and subscribe model which enables it to send messages to one or multiple subscribers. What is LwM2M? LwM2M stands for Light Weight M2M. It is a protocol designed by OMA SpecWork’s for device management but is also suitable for data transfer with the objective of attaining reduced power and data consumption. It is built on top of CoAP (Constrained Application Protocol) which increases its bandwidth efficiency. LwM2M has a transport agnostic design which by default uses UDP, but also supports TCP and SMS. Architecture MQTT As mentioned, MQTT has a publisher and subscriber model. There is no direct connection between the sender of the message and the receiver. There are 2 basic components in this architecture. Client Broker Clients can publish messages on topics to the broker. The broker then dispatches these messages to any clients that subscribe to that topic. Thus the broker decouples the publisher and the subscriber. MQTT brokers do not normally store messages, but do offer buffering of messages in some cases. MQTT uses TCP/IP to connect to the broker. The broker authenticates and authorizes the clients and maintains the session data of all active clients. The broker is responsible for receiving all messages, filtering the messages, determining who is subscribed to each message, and sending the message to these subscribed clients. LwM2M In an attempt to standardize device management and telemetry, LwM2M supports device management functions, in addition to data reporting (as MQTT does). Bootstrapping Device Configuration Firmware Update Fault Management Configuration & Control Reporting For all the above functions there are procedures defined, e.g. how the device registers at the server, or how the server initiates a client diagnosis. The common structure under all the above functions is a client - server model. The client initiates the connection with the server. The server then uses REST APIs to perform either of the above functions. Implementation MQTT An MQTT client can be any device that runs the MQTT library and connects to the MQTT broker and can have a very small footprint depending on the library used. An MQTT client usually sends data to the server, such as telemetry data. It contains scripts to publish messages to a topic. There are several MQTT client libraries available depending on your preferred programming language. An MQTT broker is the heart of this protocol and can handle millions of MQTT clients depending on the implementation. An MQTT broker needs to be highly scalable, integrated into your backend systems, and failure-resistant. The broker needs to receive, filter and forward all messages to the clients that subscribe to them. As mentioned earlier, it needs to maintain the data-sessions of all the clients connected to it. There are several implementations of the MQTT broker available as open-source or paid. LwM2M Depending on the function that you are using it for, there can be several implementations of the LwM2M client and server. The LwM2M client initiates a connection with the server. LwM2M uses a simple resource model with the core set of objects and resources defined in the specification. As an example, the device here is an object, with id 3 and the device has resources like firmware version, serial number, etc. which have a fix resource id. So to get information about a particular resource of the object device, the server can send a call like READ 3/3/0. The LwM2M client implementation contains code to initiate the connection with the server with credentials, sending the necessary data requested by the server, callback functions for LwM2M resource executions and send error events. It can also contain other functions depending on the use-case. The LwM2M server on the other hand needs to authenticate LwM2M clients, send correct requests using the REST API and process the requested information. There are several open-source as well as paid implementations available for the LwM2M client as well as server. LwM2M also has a Developer Toolkit which can be used to implement your own versions. Security MQTT MQTT supports various authentications and data security mechanisms. These mechanisms are configured on the broker and the client needs to comply with these mechanisms. MQTT uses TCP/IP and you can also leverage Transport Layer Security (TLS) to use secure the connection. LwM2M LwM2M also supports authentication and data transport security mechanisms. LwM2M uses CoAP which usually uses UDP as the transport protocol. When using UDP, LwM2M supports DTLS. CoAP also supports TCP and TLS accordingly. Use Cases MQTT MQTT is used for sending payload for low-power and constrained applications, thus making it a favorite choice for many IoT applications. MQTT brokers are a big component of Cloud based IoT solutions. Logistics - for connectivity and real-time monitoring of vehicles Manufacturing - For monitoring of manufacturing plants Smart Home - For energy monitoring, home security, home patient monitoring Oil and Gas - The use-case it was first built for, to monitor the oil pipelines Consumer products - Like smart appliances Urban Mobility - For city transportation systems, car sharing etc. LwM2M While LwM2M also supports sending telemetry data, it was built to standardize device management and provisioning, thus making it ideal for the 6 functions that it defines in its implementation. Bootstrapping - Enables headless device management, thus enabling shipping the devices without configuring them in the factory. Device Configuration - Enables device life cycle functionalities like enable, disable and update. Firmware Update - Enables FOTA/ SOTA for devices. Fault Management - Enables monitoring of statuses like battery level, memory, sw/hw version etc. Configuration & Control - Enables setting of APN and other functionalities for cellular connectivity, as well as activating, rebooting and disabling the device. Reporting - Enables error reporting from the devices Conclusion While deciding the right protocol for sending essential data from your connected devices to your application, the question is not whether you use MQTT or LwM2M. From the above description, you can see that both protocols were designed for different and specific purposes. So if your application needs a higher payload of data to be sent, you might choose MQTT and will have to implement functionalities like device provisioning, OTA on top of it. On the other hand, if the application needs to monitor critical statuses on the device, as well as needs the convenience of lightweight device management, you might want to choose LwM2M. Platforms like AWS IoT, Azure IoT Hub have an inbuilt version of the MQTT broker which you can use to send payload through your device. You then only have to configure the MQTT client on the device. The device management in AWS IoT and Azure IoT hub is then done through device shadow and device twins respectively. If you are hosting and managing your own cloud applications, you can use LwM2M for device management and build your own MQTT broker for messaging. There can also be use-cases where you might need to use a combination of both. In any case, it is important to understand that MQTT and LwM2M protocols are not replacements of one another but built for distinct use-cases. Stay glued to this space to see a comparison between MQTT and CoAP next. And if you wish to know more about protocols and IoT check out our Comprehensive Guide to IoT Protocols. Until then, Stay Connected!