Consider adding Particle Platform

[rpurser47]

Enhancement Request: Consider listing the particle hardware as a platform. It's effectively a web enabled variant of Arduino, and popular, at least in the US.

[loopj]

:+1:

[loopj]

Would be happy to donate particle photon / particle core boards if that would help with development.

[mgcrea]

:+1:

This might be useful:

• https://github.com/spark/particle-cli/blob/master/lib/deviceSpecs/specifications.js#L44

[dbrgn]

This would be great. The default CLI tool compiles the code in the cloud. I'd prefer to keep that local, but without manually setting up the toolchain.

[ivankravets]

@suda could you help us with development platform for Particle? See

• Docs http://docs.platformio.org/en/stable/platforms/creating_platform.html
• Dozen examples https://github.com/platformio?utf8=✓&query=platform-

Thanks!

[boneskull]

For anyone curious about Digistump Oak support, I've done a little work here:

platform-oak

If anyone has any suggestions, I'm all ears--haven't attempted to create a platform before.

---

There's quite a bit of overlap between Oak's framework and the Arduino ESP8266 framework; the former is basically a fork of the latter. I don't know if it actually needs to be a fork. Maybe the Arduino ESP8266 project would accept the Oak board definitions--but we'd still want to use the Particle tooling on top of it.

Speaking of which, the Particle tooling is written for Node.js. If PlatformIO was going to support it, Node.js would likely be a prerequisite. Is that feasible? If not, it should be possible use a Python-based wrapper around their API.

Curious if there is any other similar platform with this style of OTA uploads I would want to look at?

[boneskull]

The Oak uploader is a Node.js script which is "compiled" using nexe. It flashes the board via Particle's API.

The Particle CLI uses native modules (serialport, for one), so nexe won't work.

[ivankravets]

@boneskull great work! Thanks!

Maybe the Arduino ESP8266 project would accept the Oak board definitions--but we'd still want to use the Particle tooling on top of it.

We have own fork where you can put own Oak core and variant. See

• https://github.com/platformio/framework-arduinoespressif8266

If PlatformIO was going to support it, Node.js would likely be a prerequisite. Is that feasible?

We can show "warning" message to user that need to install node.js. I think that is not a problem.

Finally, how about to have 1 development platform and continue implementation using https://github.com/platformio/platform-espressif8266 ?

You can keep active development in own development platform. However, I recommend later to merge it to main repo. WDYT?

[boneskull]

@ivankravets Sure, thanks for the suggestion. WFM

[boneskull]

@ivankravets I was able to compile a project and flash an Oak (using Particle OTA) using PlatformIO with my forks of framework-arduinoespressif8266 and platform-espressif8266. I co-opted the upload_port setting in platformio.ini to be the "name" of the board:

[env:oak]
platform = espressif8266
board = oak
framework = arduino
upload_port = barth

... where barth the name of an Oak.

Unfortunately, I was not able to upgrade the core--the firmware failed to reboot and connect, so I did something wrong there. I had hoped to upgrade the oak core to the current esp8266 core, then manually merge the changes Digistump had made. I probably missed something, but unsure what. I'm not awesome with C/C++, especially the toolchains. And most of the languages. :smile:

A problem is the current Oak Core is incompatible with the stuff in tools/sdk/ (framework-arduinoespressif8266's master branch), so I can't just toss the Oak Core into the framework and use it. I'm not sure what to do here, @ivankravets--any suggestions? I don't even know at what changeset Digistump forked the esp8266 core, because they re-imported the sources instead of clicking the "fork" button.

It seems like it should be possible to upgrade, though. Would welcome any help from anyone interested in the project.

[boneskull]

(Currently, the Oak toolchain in my fork only works on Mac)

[ivankravets]

@boneskull do you have other Particle's boards? Or only Oak?

[boneskull]

Only Oaks

[ivankravets]

Why did you close it?

[rpurser47]

Sorry -- my mistake.

[ohhorob]

I have two Particle Core I would like to use with platformio

[ivankravets]

We have this task in our TODO. Would be thankful if some help us with this integration or provide PR.

[ohhorob]

Is there an example PR where another (similar?) board was added to platformio?

[ivankravets]

We need separate dev/platform. Please take a look at https://github.com/platformio/platform-ststm32

So, need to make a research how do they build a code, how to upload a final firmware to end device.

Also, see https://github.com/particle-iot/firmware You can try to build a firmware using Make. After that, we can repeat the same using our build system based on SCons.

[Niko-La]

is particle io photon supported on platformio now? thanks

[LongLiveCHIEF]

I'm going to start working on a PR to support Particle. Hopefully have a beta ready by the end of this weekend. I'll update this issue when I have some code to show for it.

[ivankravets]

@LongLiveCHIEF If you will need any help, please contact us here.

[LongLiveCHIEF]

I think I have a pretty good idea of where to start. I spent some time setting up my recording studio and was going to live broadcast, but having a few issues with my second camera and the rtmp server I have that I was going to use to show video of the physical board testing.

I did however, start the project at github.com/HackerHappyHour/platform-particle.

I'm using the platform-espressif8266 project as a good guide, along with the docs for custom platforms and boards.

I've done some tinkering recently under the hood of pio core, with the xtensa toolchain, so I could use newer versions of their compiler, and that taught me most of what I think I'll need to get this in place.

The particle framework has a cli, so that'll basically work the same way as the xtensa toolchain does for the espressif8266 platform if all goes well.

I have a boron and a photon, so my PR will have support for those boards, and that should give the community a base to extend support for the other boards in that product family.

[LongLiveCHIEF]

livestream link: https://youtu.be/1wC6HgvWCTM

I'll be working on this most of today.

[LongLiveCHIEF]

So I wrapped up part 1 of my stream. Over the last 3 hours, I found out that particle platform at it's core is extremely similar to esp8266. It used a node tool instead of a python tool for uploads, but it's compiler toolchain is just a different variant of gcc-avr, and it supports Arduino framework.

The big picture is coming together, and here's what it looks like right now:

1. I should be able to add a platformio.ini file with some custom parameters for includes and such, and a simple build script, and that will be a good POC. That should be ready ~1 hour from now.
2. I think i have the library and package dependencies mapped out for the platform and the boards
3. I'll start working on an actual platform definition after step 1 is complete, and I think I should have a beta ready ~5-6 hours from now.

Since platformio-core and particle-core use basically the same folder structure and terminology for their "platforms", the work is mostly just going to be setting path mappings for the particle libraries and packages in the platform script, and then mapping the platformio core commands to the particle cli tools commands.

If anyone who is experienced with python (I'm not trained with python but can probably get by) wants to help me with the mapping stuff, please reach out to me here, and I'll send you an invite to our hackerhappyhour discord so we can voice/screen-share while I work on this stuff this evening.

particle also has a set of udev rules. @ivankravets what repo contains the current udev rules that get referenced from the docs, so I can add the 2 particle rules in there when the first RC is ready for this platform?

[LongLiveCHIEF]

what repo contains the current udev rules

n/m, found it in this project under scripts. :smiley:

[LongLiveCHIEF]

@ivankravets any suggestions on the best way to generate package registry manifests?

I think my next step is setting up the particle-cli as a platformio toolchain, and getting that downloaded and installed.

I've noticed other frameworks and toolchains are resorting to tarring up binaries and then commiting them to github. Is there a way to publish these to your platformio bintray?

I can get everything running locally by embedding everything into package_dir and core_dir of my platformio installation. Maybe I'll see about the new github registry feature?

[LongLiveCHIEF]

ok, for now, I think I'll have two repositories, the platform-particle, and a toolchain-particle. I'll use github releases, which allows me to upload tar's, and I'll create a manifest.json to correspond to that, and add it to the platform-particle platform.json[packageRepositories].

[ivankravets]

particle-cli as a platformio toolchain

It depends on NodeJS which is not installed on user machines. We don't depend on the operating system software. The integration should be native. platform-particle should be built on top of PlatformIO Build API. Only in this case, other features will work: debugging, unit testing, project inspection, etc.

So, platform-particle should be responsible to build the Particle's Arduino/Wiring framework without any javascript files. This is not a web.

[LongLiveCHIEF]

So, platform-particle should be responsible to build the Particle's Arduino/Wiring framework without any javascript files.

They've actually already done all of that. the cli is just a wrapper task/job runner for it all. Their toolchain is nearly identical to the esp8266 toolchains, including the compiler and framework support.

Only reason I mentioned this approach is that it's the quickest way to get a PoC beta for supporting particle however, is to compress the particle toolchain (including a node binary) into a tar.gz, and drop it in as a framework package in the platform particle. Obviously this isn't the long-term approach, but it gives me what I need in the platform code so i can build out the framework library.

I'm hoping I'll only have this band-aid approach in for about a week or two while I get the other parts of the enablement system wired up.