Porting from Arduino to Particle.io (Simplified-Hopefully)


#1

I can simplify and teach anything I understand, but I am having a really hard time understanding porting from Arduino to Particle.io. Could someone please clear up a few things:


A: Some Arduino include files are pre-installed on the particle IDE, so we just have to delete the include calls from the Arduino code.

Wire.h (I2C serial communication)

Servo.h

stdio.h

SPI.h (SPI serial communication)

are their any more include files we can add to this list that are pre-installed into the particle IDE?
.

.

.

.


B: A few include files are pre-supported by the Particle.io IDE but you still have to call them.

#include "math.h"

replace #include "Arduino.h" and #include "application.h" with #include "Particle.h"

Does anyone know the complete list of includes that you can just call from the IDE?
.

.

.

.


C: Some Arduino include files have supporting include files that just have to be fully written and included in your app, the following list occure more often than others

#include “fonts.h”
#include “Adafruit_mfGFX.h”
#include “SparkIntervalTimer.h”
#include “Keypad.h”
#include “JsonObjectBase.h”
#include “elapsedMills.h”
#include “Adafruit_Sensor.h”
#include “RGBmatrixPanel.h”

Can anyone think of other include files that are often called from inside Arduino style include files?

.

.

.

.


By the way if you have never seen @peekay123 github site it is a wonder to behold https://github.com/pkourany?tab=repositories

P.S. We can talk about the libraries on another post.


Newbie needs to convert Arduino>Photon libraries for IMU sensor (MinIMU-9 v3)
Teaching High School Robotics with the Spark Photon
Atlas Scientific Ardiuno to Particle code issues
Connecting Adafruit 2.8" TFT Touch Shield to a Photon
VL53L0X Time-of-Flight Ranging Sensor
#2

For A:
I’m not fully aware of all the headers commonly used on Arduinos, but any starting with avr/ should be removed too.
Also looking at application.h lists these

#include "spark_wiring.h"
#include "spark_wiring_cloud.h"
#include "spark_wiring_interrupts.h"
#include "spark_wiring_string.h"
#include "spark_wiring_power.h"
#include "spark_wiring_fuel.h"  
#include "spark_wiring_print.h"
#include "spark_wiring_usartserial.h"
#include "spark_wiring_can.h"
#include "spark_wiring_usbserial.h"
#include "spark_wiring_usbmouse.h"
#include "spark_wiring_usbkeyboard.h"
#include "spark_wiring_spi.h"
#include "spark_wiring_i2c.h"
#include "spark_wiring_servo.h"
#include "spark_wiring_wifi.h"
#include "spark_wiring_network.h"
#include "spark_wiring_client.h"
#include "spark_wiring_startup.h"
#include "spark_wiring_timer.h"
#include "spark_wiring_tcpclient.h"
#include "spark_wiring_tcpserver.h"
#include "spark_wiring_udp.h"
#include "spark_wiring_time.h"
#include "spark_wiring_tone.h"
#include "spark_wiring_eeprom.h"
#include "spark_wiring_version.h"
#include "spark_wiring_watchdog.h"
#include "spark_wiring_thread.h"
#include "fast_pin.h"
#include "string_convert.h"
#include "debug_output_handler.h"

// this was being implicitly pulled in by some of the other headers
// adding here for backwards compatibility.
#include "system_task.h"
#include "system_user.h"

#include "stdio.h"

So any header relating to these (no matter how they are called in Arduino land) will be superfluous (or fail to build as not-found)

B: Any of the headers that come with the STM32/ARM Cortex M3 platform.

C: is too open that I could answer that :wink:


#3

I am getting there. Thanks for the list of includes @ScruffR. You have also helped with my understanding of situation B.

B: Any of the headers that come with the STM32/ARM Cortex M3 platform.

Since these work, any Arduino code with these include statements will also work, so this is one list I don’t have to worry about.

Quick question:

what’s with the following Arduino format does it work on particle?

#include <math.h>

#4

Which should we use in our code. They seem to be the same thing

#include "application.h"

#include "Particle.h"

I think the answer is #include “Particle.h” but I am not sure why.


#5

Originally application.h was the only one that existed but following the scheme set by “Arduino.h” and to avoid confusion as application.h could be anything, “Particle.h” was introduced and should be used for future projects.

Imagine this code

#if defined(ARDUINO)
#include "Arduino.h"
#elif defined(SPARK)   // don't ask ;-)
#include "Particle.h"  // makes more sense 
#endif 

BTW: The only active line in Particle.h is

#include "application.h"

What do you mean by that?

Is it the #include <.....> notation?
If so, it’s not Arduino but standard C as the #include "....." is.
https://gcc.gnu.org/onlinedocs/gcc-2.95.3/cpp_1.html#SEC6


#6

@rocksetta, let’s not forget that the trickiest part of porting is hardware differences (GPIO, timers, etc). The second one is data representation differences. For example INT on Arduino is 2 bytes whereas it is 4 bytes on STM32. So anything depending on data element sizes will fail. In this example Arduino INT is int16_t on STM32. :smile:


#7

Good point about the data type errors, but I am not nearly close to those situations yet. I am still trying to figure out how to do simple things.


#8

Is it the #include <…> notation?
If so, it’s not Arduino but standard C as the #include “…” is.
https://gcc.gnu.org/onlinedocs/gcc-2.95.3/cpp_1.html#SEC62

from your link it looks like the #include <…> format is for systems calls. I assume on the particle devices we are not making any system include calls, so all our includes will be in the #include “…” format.

Or are they interchangeable?


#9

System includes e.g. refers to everything that comes as the STM32/ARM Cortex framework and standard C libs like stdio.h, math.h, …
So, yes, we do!

But yes, if you use the double quotes it will work just fine, as the system headers paths will be scanned too - after the local project path.
That’s explaned quite clearly in the linked article.


#10

I am getting there. Thank you for spending the time answering my questions.

Any idea why some library files do not have the “Use This Example” button. I have found the following:

ADAFRUIT_DHT

MQTT

SPARK-DALLAS-TEMPERATURE

SPARKINTERVALTIMER835

SPARKTIME 0.0.6

LIQUIDCRYSTAL

I thought they must have something wrong with the github site, but that does not seem to be the case. Any suggestions?


#11

Here is what I am finding out:

When you find a library, and the default alphabetically first file in the library is a header .h or .cpp connected to the header file, then the “USE THIS EXAMPLE” button is not visible.

If there is a “USE THIS EXAMPLE” button and you immediately click it, then the IDE picks the first alphabetical file in the library, which may or may not be a working example. So probably a good idea to view the file you are interested in before clicking the “USE THIS EXAMPLE” button.

Also many example sketches use .cpp extensions instead of .ino extensions which confuses the issue a little bit.

Probably too complex for the IDE but it would be a nice feature if a little success checkmark was near the .ino file showing a successful compile like what they have on the Docker Hub site.

https://hub.docker.com/r/jupyter/notebook/builds/


#12

You already found out, but I just repeat what I’d already sent you in the PM :wink:

Not all libraries do come with sample sketches, although they should (the existance of an examples folder is required for contributions)
But even if there are samples you won’t always see the button.
This depends on which file you’ve selected in the list of lib files.
If it’s a file that directly belongs to the lib itself, you won’t see that button. If it’s one of the files that were stored in the examples folder of the GitHub repo for the lib, then the button appears.

I personally would prefere it if people would name their sample sketches .ino and only the lib files .h/.cpp - this would make it easier to find samples, especially in huge libraries with many files.


#13

This may be a really silly question, but when I use the servo variable in my apps I do not have to include the particle.h file. Does that mean the particle.h file is always included in any of our apps?

So these two statements can be deleted from any .ino or include file ported from arduino?

#include "particle.h"
#include "application.h"

So these two files are really just for backwards compatibility if you wanted to port the code so it can work on both arduino and particle products using the following code.

#if defined(ARDUINO)
#include "Arduino.h"
#elif defined(SPARK)   
#include "Particle.h"  
#endif

but if we don’t care about switching back and forth we can just delete any calls to

#include "arduino.h"
#include "particle.h"
#include "application.h"

or is that only correct for our main .ino file and include files still need to have links to

#include "particle.h"

#14

Another quick questions. Is there a maximum number of characters for an include file name. I am getting an error with

arduino-includes-to-photon-template.h

#15

If your project main file is an .INO file and you have not used #pragma SPARK_NO_PREPROCESSOR then the preprocessor will add that include for you.
Or if you include a header that in turn does include application.h or Particle.h that’ll do too.

There is an implicit limit which depends on the maximum length of the full path for that file which depends on your OS and the location of your file.
AFAIK e.g. Windows chokes on paths longer than 255 characters.

But what exactly is the error message you get?
And how does the #include statement look like?


#16

I have noticed several library .ino have this same problem where the .ino can not find the header file. See image from the library entry called webserver, second .ino called WEB_AJAXRGB_MOBILE.INO. Does not compile since it can’t find the header.


#17

This is also by design.
The sample relys on its own library and some other libraries but does not contain these (to prevent redundancy and keep up with updates).
So in order to build the sample you have to import that required library too.

Another possible cause for this might be the wiring preprocessor getting tripped.
You can try adding an empty first line or removing the leading comment block.
If this also doesn’t help, #pragma SPARK_NO_PREPROCESSOR might help.


#18

The 2nd suggestions worked great for the Webserver library WEB_AJAXRGB_MOBILE.ino

I added a blank line at the very top and now it compiles. That did not fix my include. I will check it and publish it so that you can have a look.


#19

That is one strange library system. Has any one randomly gone through it and loaded libraries. When using “Use this Example” sometimes they compile, sometimes they don’t (the error; can’t find the include file), very strange. Load the same file up again and it works. (Even the Official libraries do this. Adding a blank first line sometimes helps.)

Anyway I managed to get my first include working, but once again a very strange compile system was needed. Don’t really want to publish it since it sounds like I then can’t delete it and this is just a test repo.

The repository is at

I guess anyone can try to contribute it then import it and “Use this Example”. When I try it. It does not compile.

a01-beginner.cpp:6:23: fatal error: myar/myar.h: No such file or directory
 #line 2 

So in the file a01-beginner.ino using the IDE I change the line

#include "myar/myar.h"

to

#include "myar.h"

and try again and I get the error

a01-beginner.cpp:6:18: fatal error: myar.h: No such file or directory
#line 2

So I change it back to the original

#include "myar/myar.h"

and it compiles just fine!!!

I flash it to the photon and it works great. Blinks every second (2000 ms for a complete on off cycle). I assume I have screwed something up, but not really sure what.


#20

Could it be that you have been rather quick with your first build attempt after you uploaded the lib?

Maybe the build farm was not yet completely “aware” of the new files.

Try to remove and reimport the lib (or another), let one or a few minutes go by and then try then.