Flash the Core via WiFi (Without the Cloud)

Firmware
1

Hey everyone,
I was wondering if it is hard to alter the firmware of the core to flash new firmware via WiFi. Without using the SPARK-cloud and without a connection via USB. (instead of “PC -> Cloud -> Core” or “PC -> USB -> Core” i would like to have “PC -> WiFi -> Core”)

I wanted to ask! Perhaps has any of you achieved this already? I used the search function of this forum but I haven’t found anything.

I am lazy and would like to avoid to invent the wheel a second time. But if such a solution is not available, I am willing to spend time on this. But I am happy for any usefull comment from your site…

As a “thank you” I promise to share my results with the community…

Cheers!

3 Likes
2

@TheUser,

you will need a local cloud if you want to do the firmware flashing via Wifi.

We are targeting release in Summer 2014 :smile:

1 Like
3

i'm not convinced we should need a whole local cloud to do that. surely if we have a local build (or download the hex from the IDE) there should just be a way to flash that over wifi on the lan?

spark wifi flash would be nice - a half-way between spark cloud flash (ota) and spark flash (usb).

4

Basically,

the Local cloud is essentially a compiler but self-managed + OTA flash capabilities.

You don't have to mess with the GCC etc.... You work directly with the Spark-CLI or some other frontend IDE and use the same tool to flash via Wifi.

Since @TheUser asked about Wifi i did not mentioned about the availability of DFU-util USB flashing of firmware.

You can do the local build but what is your mechanism to perform the OTA flash without the local cloud?

I simply mentioned local cloud because it's basically:

  1. Compile feature
  2. OTA download capability

Instead of suggesting something which doesn't exist as a standalone now, i would rather just mention the solution as local cloud

Thanks!

1 Like
5

I think there only two ways this could work:

  • Not use encryption for the local core connection
  • Have a private cloud with the RSA public key for your cloud on the core, as Kenneth suggests
1 Like
6

well local cloud doesn't exist yet either :wink:

i was just suggesting that maybe wifi flashing without the cloud would be something nice for the future, but as @bko pointed out, this could be difficult with key handling, although i doubt impossible as i doubt the spark inc. private key will come with the local cloud, so there must be a way to have multiple keys recognised by the sparkcore.

7

The local cloud is essentially what the :spark: cloud is running on already. Just short of cleaning up the code and packaging it properly to be easily consumed by everyone who is excited about it :smile:

8

I did not expect that this topic is so interesting. Anyway. Yes, I want a local OTA functionality!
What I do now, I compile it locally and push the binary via USB and DFU-util to the core. But the OTA feature is used by the cloud so why can’t we have a small standalone program like “SparkCoreWifiPush -I -t ” In the end, the ota feature is just a Socket based firmware upload and some replacement magic…

EDIT: But i do not want to install a whole cloud environment (what ever cloud stands for, in this case…)…

2 Likes
9

To us, OTA feature sounds so simple and works out of the box.

On the backend to get this running and reliably send data over Internet isn’t that easy especially with security in mind.

I’m sure we would have done that if it was simple enough. Tools like Spark-cli has to first be created before we can even move on to the local cloud just to make it really simple to setup and use locally.

OTA feature is simple to use, but not simple to setup and commission the backend. IMO :slight_smile:

10

maybe when we get the local cloud delivered we can figure out how to bypass it.

seems a bit much to need the local cloud, spark-cli etc. when we already have a local toolchain. i agree with @TheUser that it would be nice to just have a command in the makefile to send a firmware hex over wifi like we do with dfu-util.

11

I know that it is not that easy… my command line example was an example :smiley: It could also take a privKey as an input to compute a signature or to encrypt the communication channel.

Actually, the communication is that easy. I guess the replacement magic is much more complex… but this doesn’t need to be touched.

I would like to have something like dfu-wifi-util :slight_smile: It needs to work “offline”

Can you give us some more information about the “local cloud”? Does it require a working internet connection to, i do not know, singe anything?

1 Like
12

Nope. Local cloud basically runs on a machine in your Wifi environment. Internet connection is not a pre-requisite for sure!

Many enterprise are waiting for the release to implement it behind their own firewall :wink:

1 Like
13

It’s me again :slight_smile:

I took half an hour for a quick review… And first of all I must admit you have created an interesting (nice) piece of software. A little more documentation would be helpful for better understanding of the firmware… :smiley:
Anyway, I think a good documentation about the SPARK Protocol including some sequence diagrams would be enough for the most of the people to create their own solutions for OTA.

This might be wrong but right now the process is something like “connect -> handshake -> (post) u-message (UPDATE_BEGIN) -> some chunks ((post) c) including the new binary -> update done … I guess

Well, I haven’t understood the handshake process fully. For now… Like I sad ‘quick review’. I guess(hope) that some kind of signature validation is used to ensure that the cloud is not hosted by some attacker…
But now I am pretty sure that it is just a diligent but routine piece of work to realise a command line tool for OTA…

Really, if you could offer something like a function to deploy custom keys and a local standalone OTA service which can be built-in in to any backend of any project… this would be brilliant!

Unfortunately i do not have the time right now to dig deeper…

Cheers!

14

I realize this it is probably too early to answer this, but do you think local cloud would be lightweight enough to run on a Raspberry Pi? I’m building a weather station, and plan on using the RPi as the base station, and having the local cloud running on the base station would really be a slick setup.

1 Like
15

i'd actually like to know that too, most of my other electronics stuff runs on my pi and i'd rather not run it on my external server. at the moment i'm just using python "proxy" scripts to tweet etc; so they're very minimal load.

16

That’s 1st in my list :slight_smile:

Basically, node.js run okayyy on Rpi which is the basic requirement for the local cloud.

But in the long term, I’m looking at the Beaglebone :smiley:

Good to know people have plans that I do.

1 Like
17

yeah might be something to finally get my BeagleBoneBlack doing, not convinced it’ll make much difference to the pi.

i’d think most of the cloud load would be compiling, but if you just use it for its communications it should be ok surely? hell the requirements for getting this sparkcore online are getting heavyyyyyyyyy

18

I guess I’m not sure what you mean, my plan is to make sure people can easily flash over wifi locally with the local cloud running on a pi / beaglebone.

2 Likes
19

yes that's what the last few comments were about. the original thread question was can OTA be done without the (local) cloud just over wifi on the lan.

20

Ahh, thanks!

We’ve been playing with an app for the Core called voodoospark - https://github.com/voodootikigod/voodoospark during JSConf, which lets you remote control your Core mostly over your local network without going to the cloud and back. I’m sure someone could hack in OTA updates if they really wanted :slight_smile:

Thanks,
David

2 Likes