@eely22 - What CPU are you using and what approach did you take to porting the firmware to that? (Also how complete is the port?)
I am in the process of reworking the core firmware so that the top-levels of code are more hardware neutral, pushing hardware-dependent code down into a platform layer. If you’d like to share your experiences of building sparkLE, I’d be happy to listen.
Hi @eely22,
That’s a great question! Provisioning access to the Spark Cloud is paid for when you buy a core, but it’s slightly different when you’re building hardware in bulk. I think that would be a question for our business development team at hello@spark.io. I don’t have the details on that quite yet, I just make the bits go. 
Thanks,
David
@Dave Thanks, I will try and ping the business development team to get details.
@mdma I am implementing this directly on the Nordic nrf51822 and using their BLE Stack. My approach to porting the firmware wasn’t to directly make it work, but rather to take the pieces I needed and figure out the proper flow based on BLE events. I started by getting the handshake procedure working, and then moved on to getting the basic Spark functionality implemented (publish, subscribe, variable, function). This is all working right now, I am able to use a SparkLE as any other Core with respect to these pieces (though there were a few tricks along the way, as you can see above). I have even been debugging and testing Spark code examples on it.
My next step is to get the bootloader and wiring portions complete. There is a lot of work surrounding the ability to store and program the chip remotely, as well as getting all the CLI portions supported. So there is still lots to do, and I wanted to get a board completed first for this portion so I could test on something that would resemble a final product (have the extra flash on board, the handshake MCU, etc).
I would definitely be interested in learning more about the FW changes you are making, and would be happy to help out where I can as I continue to work on SparkLE. Let me know if you have any questions.
If it fits with your timeline, you may want to hang fire with the higher-level wiring changes. At present the firmware is a mix of hardware dependent and hardware-neutral code - we are reorganizing to put all the hardware-dependent stuff in a separate layer so porting becomes much simpler.
This would also keep your codebase aligned with the main repo so you can easily pull in updates from new releases etc…
Sounds great! Do you have a timeline of when these changes would be completed?
With the portions I have already done, the HW dependence wasn’t that high. I had to basically rip out the WiFi buffers and replace them with my custom GATT profile, which wasn’t too bad because of the callback structure from spark-utilities to spark-protocol. I made almost all the changes just in spark-utilities.
Moving forward, there will certainly be a lot of HW dependency, so I would welcome the changes. We are evaluating this for another product I am working on that we are targeting for a Kickstarter launch this fall, so timelines may be important. Thanks!
@eely22 I’m so excited that you’re working on this! The documentation for product creators will be released sometime in October. As you are aware there are lots of pieces both technical and on the business side that we need to consider. We want to make sure we get this right!
I’ve made a note about your device ID question. I’ll be sure to document a clear scheme for device IDs that will work long term.
Regarding the work @mdma, @BDub, and @satishgn are doing to separate hardware independent code from hardware dependent code, this is all happening in the open—open source FTW! You can see from the Spark firmware network graph that the feature/hal branch is way ahead of master—that’s where the work is taking place. It should settle down a bit and be reasonably usable outside Spark by the end of Sprint 20 on October 1st.
Cheers!
Thanks @zachary.
As for the documentation, I certainly look forward to it, but would also like to offer that we have somewhat of a conversation about it as you develop it. On one hand, I am not sure how many other product creators you have, but I can perhaps provide some insight into what would be needed and desired. I have thought an awful lot about this over the last month.
On the other hand, I am working on using SparkLE in one of my own projects that we hope to put onto Kickstarter in October. It would be hard for us to meet that deadline if we are relatively in the dark about this until next month.
I am welcome and open to talk, so please feel free to contact me if you would like to go this route.
@eely22 Duly noted. I’ll loop you in.
Very interested in this project. Hope it will be successful. Cant wait to order
Wanted to post an update/cry for help 
The main issue with using the nrf51822 (as I have already documented) is lack of RAM. There is only 8K, and this just isn’t enough to do RSA encrypt/decrypt on the key sizes Spark Cloud uses with the TropicSSL library. To solve this, there are a few hardware ways I can think of:
There are various pros and cons to all of these, but if I was forced to choose I would go with number 2 since it has the lowest implications on cost, size and battery life while maintaining simplicity, ease-of-use and security. I still don’t like it though…
So, I broke out my textbooks from college and really tried to dig into the TropicSSL library and see if it is possible to do RSA cryptography with less RAM (spoiler alert: public key cryptography and efficient ways of doing it is not my area of expertise, I have read more about this in the last few days than I have in the past 8 years).
My short answer is, it appears very difficult, but may be possible. There are many papers on how to fit RSA into tiny MCU’s (here and here for example), but I haven’t been able to get much working so far.
I ran some tests on the current FW during the handshake and I see about 5076 bytes of RAM being allocated on the public server key encrypt and up to 6824 bytes on the private key decrypt. That is a lot. So I was trying to find ways to change how the math works so it is optimized for RAM and not speed (not gonna care too much if it takes a few seconds). I think I would have to realistically get this under 2K for it to be feasible in SparkLE, and I know that is asking a lot (and may not be possible).
Anyway, anyone know a library or better way? Any volunteers to help try? 
Any savings we could find here would help this project, but would also help Spark Core since it uses the same method. More RAM for everyone!
I am going to back-burner this for a bit and move on with SparkLE with the handshake MCU so I can continue moving it forward. Any solution can just drop in in the future, so if anyone wants to help in pursuing this, let me know.
Alternatively, is there any intention or desire from the Spark team to move to ECC encryption? Again, I am no expert on this, but it seems to be more conducive to resource constrained devices.
Having been around this block a few times, the difference between #1 and #2 on your list is basicly your sanity and the ability to actually make something work in an interesting timeline. Adding a '103 as #1 is not really a “big” processor. They are pretty cheap, and can be got in small packages. They code is known to work, you don’t have any bootloader issues etc etc etc.
Most of the hardware that is under consideration for Core-II has on-chip hardware crypto engines, so it is unlikely that the main thrust of the project will adjust to accommodate a different crypto method targeting lightweight hardware.
My recommendation remains to just use a '103 to establish functionality and get it done, then iterate if required/possible/desired.
And regarding your ECC question, that would be great, but when we were designing the communication protocol last year, there were no open source and patent free ECC libraries available. Switching now would be difficult, and as Andy points out is unnecessary given the hardware available now and in the future.
Hey all,
Just wondered if you had seen this, https://www.kickstarter.com/projects/1842650056/sam-the-ultimate-internet-connected-electronics-ki?ref=category
Its a bit like McModule in that it is BLE but they also offer custom hardware (sensors and outputs) and a visual coding platform. I get the impression that this range of products is not aimed at the maker or manufacturer community like spark but it is aimed at anyone. Of course some compromises have to be made.
Looks interesting though.
Wanted to post a quick update. Mainly I am just excited I finally got this working after running into a few stupid user issues, including reversing the ST-Link SWD interface after I read the datasheet backwards, not realizing my BLE breakout board was using the pin numbers of the chip and not the module, and forgetting to turn off HW flow control.
This is the first standalone prototype, with everything needed to run the Spark protocol over BLE on-board. That is an STM32F072 MCU which takes the data from the BLE module and handles the handshake encrypt/decrypt. Everything else is run on the nrf51822 chip, which I am currently using a Laird BL600. Power is running from the AAA battery pack.
Next step is to add the external flash and add a power circuit so I can shut off the STM32 at all times, except when I am doing the actual handshake. Those parts should be straight forward, then it is time to draw up the schematics, lay out some boards, and make some standalone SparkLE’s so I can work on the FW and integrate into my other project.
So, after all the hard work getting SparkLE working with a “handshake MCU”, there has been an interesting development. I found out a few weeks ago (and Nordic Semiconductor just announced this week) that there will be a new version of the nrf51 chipset with 32K RAM. That means no more need for a second MCU on-board!
Ultimately, this is great as the design is a lot simpler, the board will be cheaper, and it is less components to place. I have the new DK from Nordic and am working with my module suppliers on delivery dates, as the new version won’t go to production until Q1 sometime. So, this is a good thing, but just may delay how fast I wanted to produce a board like this.
In the meantime, we will be launching a product on Kickstarter next week that will use SparkLE and the Spark Cloud, so you can check that out if you’re interested: http://goglove.io/
Hey,
I just wanted to express my support for SparkLE. I habe several ideas which require cheap network hardware without lots of bandwidth so SparkLe would be incredibly useful for me! So keep up you’re amazing work!
your product is awesome.
is the video on your goglove site what you are using for the kickstarter? i bet the guys at spark can introduce you to their video guy, and you can make it awesome!
Thanks. And no worries, we have already shot a much better video and will be uploading it to the site when we launch on Kickstarter. Check back next week when we go live!
I am also working on some projects that are utilising Spark Cores and BLE, therefore, a Spark LE preferably with WiFi would be extremely welcomed. Also, I t would be great if the BLE function calls available be as high level as possible and that it supports both Central and Peripheral mode.
For SparkLE, I am envisioning three parts (at least initially).
Beyond that, you could of course program any part to do whatever you want as it would all be open source. I plan to expose as many underlying API’s as possible, the biggest problem I have today with BLE development boards is they are too restricted.
Would this cover most of your needs from s high level?