SparkCore Programming with Arduino IDE

simoher and Scruffr, for a while now the web IDE no longer pre-processes .cpp files. If you have an .ino file (the one containing setup() and loop()), it will however apply the pre-processing.

Good code writing does not rely on pre-processing and most (if not all) good Arduino libraries define their class and function prototypes in the .h (header) files. I have yet to port a library that required me to define function prototypes.

The reason I say “good” is that everything is explicit in the code, which follows best-practice. The Arduino approach is designed for beginners who may not understand this when they start. It may be a little more frustrating for you at first but this is what makes this community so great - support! All you need to do is ask :smile:

1 Like

Sorry, I forgott to mention the distinction between *.ino and *.cpp :blush:

I got into the habit of using sketch when I mean an *.ino

I created the following tickets on the GitHub repository:

  • CLI — Remove application.h Opened by rei-vilo on May 10 #201
  • CLI — Adopt folder structure compatible with Wiring / Arduino’s standard
    Opened by rei-vilo on May 10 #200
  • CLI — Create boards.txt file and board tag Opened by rei-vilo on May 10 #199
  • CLI — Create framework variable Opened by rei-vilo on May 10 #198
  • CLI — Avoid circular #include references Opened by rei-vilo on May 10 #197
  • CLI — Group headers and code source files in same folder Opened by rei-vilo on
    May 10 #196
  • CLI — Create framework entry Opened by rei-vilo on May 10 #195
  • CLI — Add #include “application.cpp” in main.cpp Opened by rei-vilo on May 10 #194
  • CLI — Remove main.h Opened by rei-vilo on May 10 #193
2 Likes

Any news?

The tickets #194~#202 I created are still open…

Please correct the title of the thread and remove [SOLVED] as the issue is still pending and the tickets open!

Thanks :smile:

OK, so I took SOLVED off of the title.

Personally I think the burden is on you to explain why forcing the Spark build environment to conform to the Arduino build environment is the right thing to do. It is not obvious to me that that is the preferred way to go here.

I have used the Arduino environment and I don’t find it to be ideal (particularly the serial monitor), so while I agree with some of the cleanups your issues raise, I don’t see myself ever using the Arduino IDE with my Spark.

Maybe @zach or @jgoggins could comment here on where this might be going.

2 Likes

Thank you for your answer.

I’ve sent @zach and @zachary an elaborate list for improving the command-line build and upload process.

Among other items, today’s framework uses circular #include, there’re header files for main and sketch, the framework has no entry, …

I created entries at the repository and hope the tickets are going to be addressed!

Cuneiform writing wasn’t the most efficient system ever developed, but it remained the standard for over 2,000 years of recorded history. Why? Because it was the first writing system developed for practical use.

Here and now, universities and schools, startups and established businesses across the world are using Arduinos, writing code and building devices to communicate using their standard IDE.

Amateurs and professionals alike are now used to double-clicking a single icon and coding within 30 seconds of loading up a simple barebones IDE. Want to demo your code? One button clicked and no worries about OTA failing. Spark 2 comes out? Select it from a drop-down menu. People don’t actually want to care about library management and all the other stuff the ‘experts’ think they should care about.

I feel we ignore the dominance and standardisation brought by Arduino at our own peril…

Extend and improve yes, but replace and ignore? No. It just won’t work.

1 Like

This is what I don’t understand about the github repository - nobody from the dev team ever seems to comment on issues.

Look at an active development like bitcoin and there are comments flying on every single issue and pull raised, improving the whole process. But here it’s like you want feedback but hit a wall of silence, so it makes you less likely to want to contribute in the future.

If the Spark team wants the development input of the greater open source community, they need to start commenting (positively OR negatively) on issues and pulls raised by members of the public.

Hey @NanoAkron,

I understand what you are driving at and I mentioned it during our session last Thursday.

However, it doesn’t help if you repeatedly mention this in various threads. Please respect the Code of Conduct for the discourse for that matter?

I’m not trying to be mean here but let’s be more objective about this and how we provide feedback. :wink:

@teke, something you might need to keep these issues on your radar for the pointers i feedback last week.

Hi @kennethlimcp, I’ve only mentioned this communication issue once here on the discussion site and once on github.

I won’t mention it again.

Thanks for your understanding @NanoAkron, i’m always watching the discourse and sending my feedback to spark HQ but with that said, I have no control on what gets through and what gets worked on.

But rest assure that I will feedback on community-related issues to the team on behalf of the awesome owners of the core :wink:

@NanoAkron, as @kennethlimcp mentioned, the need to address outstanding issues has been and remains on the Elite’s radar and we keep mentioning it at each hangout we do with the Spark Team. After all, we are the authors of a lot of those issues! Spark is presently on a hiring spree and one position’s rols will be the timely review and management of github issues. My thoughts are the sooner the better! :stuck_out_tongue:

In the meantime, thanks for your patience and every couple of weeks poke one of us with a PM just to remind us :smirk:

Hi @peekay123, I don’t want you to see my comments as ‘digs’, it’s just that I like to read how things are being addressed on github and watching conversations as they’re happening gives a more visible sense that things are progressing.

@NanoAkron, I hear you and completely understand. We all want the same thing :smile:

@NanoAkron like @kennethlimcp and @peekay123 said, the lack of activity on issues comes simply from our team being spread too thin. We're trying to double the size of our team, but hiring is incredibly time consuming, and we are of course trying to push the product forward at the same time. We will try to do a better job, but we should be much more capable of being as responsive as we would like once we have a larger team.

6 Likes

Have a look at the RedBear Duo board!

It relies on Particle for the IoT infrastructure with the same WebIDE. More importantly, Red Bear offers compilation with Arduino.

When does Particle plan to release the same feature for the Core and Photon?

Like other devices they have code plug-ins for the Arduino IDE. In fact they have STM32 code. It just doesn’t support the F2 currently. They should be able to do something similar with their libraries.