Create virtual Spark Device

Yes, I’m a developer, specializing in embedded/real-time systems, and I should have some time available until my Digispark Oaks arrive.

I’ve only just started browsing the Particle repository.

The Initial target should be for RasPi2 Raspbian (closest to the generic Debian ARMhf tree, and that’s what I have at hand). But to minimize platform nuances (and to maximize testing bandwidth), the real target should be Posix (IEEE 1003.1).

My initial guess is we’ll need to do something like the following to get the most bang for our development effort:

  1. Create a new “POSIX” HARDWARE tree (GNU is mostly a superset of Posix, and Windows folks can use Cygwin for now). (Or perhaps a “HAL” tree with a POSIX port?)

  2. Refactor CORE-* as needed to meet the above.

At some point, I’d like to include other IoT embedded OS targets, such as FreeRTOS and Contiki (both are already Posix-compliant, but with differing coverage of optional parts of the spec). Whatever refactoring is done should keep those platforms in mind.

That ought to keep us busy until the Thread tsunami hits and changes everything.

For cross-platform support, I used Boost, since that supports on sockets on Windows and other OSs. It thunks down to posix when running on a posix compliant platform.

For expedience, initially the HAL will be single threaded, but it’s no problem to expand to multi-threaded execution on FreeRTOS.

I haven’t used Boost networking: The last time I checked it was a memory hog. Is that still the case? If so, it’s probably best to go with straight Posix networking (which isn’t bad) so we can continue to make use of smaller SoCs (there’s room for FreeRTOS on the ESP8266).

I’ve been considering something like this, but was considering the CoAP side of things. I have devices like the NetDuino and ESP8266 that I would love to Particulify with the public cloud. It’s a daunting dream at the moment. I also know that there is zero incentive to do this for Particle, especially on the public cloud. It costs money to run this public infrastructure and somebody has to pay for it. A bunch of 3rd party devices that don’t support Particle financially doesn’t make much sense.

Maybe @mdma can do it in his free time and gets bored! (Just kidding, Matt!)

For targeting other platforms I believe we will need a separate implementation of our hardware abstraction layer, e.g. to target the ESP8266. That layer may well build on a common posix layer if that's possible, but there are always platform-specific details that need addressing.

We're using FreeRTOS in the photon, wrapped up by the WICED library. From what I've seen there, posix support isn't there - although WICED does use an older version of FreeRTOS (7.2.8 iirc) so this may have changed in more recent versions. (I believe I saw a project that provides pthreads on FreeRTOS although it hadn't been maintained in some time.)

Using Boost was specifically for the cross-platform compile (Linux/Windows, possibly Rpi) on devices with comparitivlely plenty of memory. If targeting posix makes these redundant, then we can do that, although I'm unsure about Windows support.

@wgbartley makes an important point! Perhaps only purchased hardware or licensed users/devices should get to use the Particle Cloud, and DIY stuff should be restricted to Local Cloud. That should provide benefits to both groups.

That’s exactly how it is now. Each device has to be registered with the cloud before it can be claimed and accessed. All particle devices are pre-registered in the cloud so they work out the box. Cloud support can be purchased for third-party devices.

1 Like