In case you haven’t noticed, Internet of Things is the phrase on everyone’s lips right now; why make a device, when you can make an IoT device? And the good folks at Particle.io have made it easier than ever to create your own IoT device in a maker friendly environment.
If you’re not familiar with the Particle platform, take a look at some of our other Particle tutorials, but today we’re going to be looking at moving from Arduino to Particle.
When Particle built their cloud platform, they realised the power that Arduino has to enable anyone to get into programming, and write their own code fairly easily. Arduino does this by using a coding abstraction called Wiring. There is a messy history between Wiring and Arduino, however we won’t be looking at that today. However the basis of Wiring is that it simplifies much of the code used in everyday programming such as serial communication, delays, input/output manipulation, and much more. With this ease of use in mind, Particle have used the Wiring abstraction in their IDE which makes it incredible easy to get started, especially if you have experience with Arduino.
There are a few things to consider though. With an Arduino, you are flashing your code to the microcontroller itself, and all that is going to run is the code that you put on it. However with Particle, because they are cloud connected devices, one processing thread is running your code, and the other is running the various overhead processes that are required to keep your board connected to the internet and handle wireless communication. This factor introduces a few constraints when writing apps for your Particle boards.
As far as cloud connectivity goes, there are three modes you can use for wireless communication; AUTOMATIC, SEMI-AUTOMATIC, and MANUAL. Each of these modes gives a different level of control to the user over when and how the device communicates with the cloud server. To learn more about SEMI-AUTOMATIC and MANUAL mode, we’ll leave you to do some reading in the Particle docs on these modes, however let’s take a look at the AUTOMATIC mode as this is the ‘default’ mode that all devices run as unless specified otherwise. In the background of your code, hidden away from our eyes are a few different functions, most importantly is Particle.process(). This function allows your device to connect to the Particle cloud, and processes the data. If it doesn’t run, strange things can happen, bad things.
So when does this run you ask? Well as powerful and all as the ARM Cortex processor running the show is, it’s still only a single core CPU which means it can’t be doing two tasks at the same time. Therefore, while in AUTOMATIC mode, Particle.process() is run at the end of your main loop(). Issues arise if you don’t allow the loop to finish often enough. This is essentially what is happening underneath your code:
We’ll use the Particle Photon as an example because it’s a little simpler. Let’s say that you write the following program:
void setup() {
pinMode(D7, OUTPUT);
}
void loop() {
ledBlink();
}
void ledBlink() {
while(1) {
digitalWrite(D7, HIGH);
delay(100);
digitalWrite(D7, LOW);
delay(100);
}
}
This will run perfectly fine on an Arduino board, however you will run into issues running this on a Particle board because we’ve moved away from the main loop entirely and our board is stuck in a separate infinite loop. A far better, more standard alternative is to write our code so that everything happens inside the main loop:
void setup() {
pinMode(D7, OUTPUT);
}
void loop() {
digitalWrite(D7, HIGH);
delay(100);
digitalWrite(D7, LOW);
delay(100);
}
You can of course use the information in the previously linked Particle docs to gain more control over the way that these functions run in your code using the other modes, however this functionality it something to keep in mind, especially if you’re moving from Arduino to Particle.
That being said, the cloud backend that is built into the Particle boards doesn’t bloat or slow down the processor. It’s still clocked at over 7x the speed of an Arduino Uno, the ARM Cortex processors simply have the advantage with their 32bit power. They are both real time processors which means that they are stepping through each line of clock without any underlying software layers to take care of. This is where these type of platforms differ to say a Raspberry Pi, which has a number of different software layers going on before you can manipulate the GPIO pins. Another cause for issues connecting to the Particle cloud is in line delays. The delay() function is great when used well, but imagine if you were to put a delay(60000) in your code. This effectively renders your processor useless for a whole minute, during which time your board can't maintain communication with the cloud. Consider using incremental/parallel delays, and avoid anything that is going to bog down your processor.
Hopefully this has given you more of an idea of the core differences between Arduino and Particle, and a few things to watch out for. So what are you waiting for? Get making!
