(yup, reviving an old, dead thread - hope it is OK…)
This thread (and the other’s referenced by it) leave me feeling like there is an us-or-them mindset in play when there really shouldn’t be… As good as I’m finding the Photon to be, I’m still happy with my Teensy’s, Uno’s and ProMini’s - and I need a way to use them all in a cooperative ecosystem. (yeah, I’m OK with dropping those PIC 16F’s off a cliff somewhere, but the others still give good value…)
In the light of “ARDUINO” being more than just AVR (zero, due, edison, yadda…) what does the define really mean? In the same sense, what is SPARK supposed to mean?
To me, ARDUINO is indicative of the environment - if it isn’t defined, I’m probably using a traditional gcc/avr environment with main(); with it, I’m the world of setup() and loop()…
With that in mind, it seems “wrong” that “ARDUINO” and “SPARK” are either-or alternatives - I would have expected to find ARDUINO to be defined by all Arduino-compatible environments, including the build.particle.io one. In addition, I’d also expect to find SPARK (now PARTICLE, I’m sure ) defined by build.particle.io when building code for my Photon, as well as in the Arduino IDE with a Spark/Particle core in use, but not when using the Arduino IDE for a Uno or Due or Edison board…
Part of living in a world where ARDUINO is defined is an expectation of how that world works - including Arduino.h, the stupid pseudo-language pre-parsing for libraries, setup() and loop(), etc. In as much as you present a compatible experience, I shouldn’t need/care about ifdef SPARK at this level.
Of course, once I get beyond the trivial, I need to be able to determine specifics about what core and what arch and …, where feature-enabling predefines for PHOTON and PARTICLE_IOT_WEB and the like become important.
my generic I2C helper library for managing IO expanders should be completely agnostic of everything, as long as I2C/TWI is supported by a core. My library code should be able to presume that if ifdef ARDUINO and include Wiring.h succeed, it will work.
- this is a clue that there is a problem - that simple things that should work, don’t.
When I added support in my lib for the onboard pins on the processor itself, I found myself needing to know what core and what board instance ('328 -vs- Leonardo -vs- R1-vs- R3 shield…) were being used; as I added support for my new Photon, I started looking for an ifdef PHOTON “hardware core ID” trigger.
I’d like to see
- the web based particle.build.io define ARDUINO
- Renaming application.h to Arduino.h
- putting a bunch of stuff into it thats missing, like bitRead…
- Define PARTICLE_CORE , PARTICLE_PHOTON or PARTICLE_ELECTRON in addition as appropriate.
- In the stand alone world, I’d like to see a Particle supported downloadable core that would work in the Arduino IDE - that environment would obviously have ARDUINO defined in addition to one of the PARTICLE_ defines…
This is hard, but not unique to SPARK/Particle - the whole 'duino community is grappling with this as well as they try to span all the way from AVR’s to ARMs and Atoms…