BOUNTY: Docker image for Particle Cloud #32
Comments
|
Im pretty sure I can do this so I'm going to have a go. I'm aiming to finish by the end of Wednesday but I'll post an update with how it goes :-) |
|
I'll give it a shot too. Hopefully I will be able to do it over the weekend |
|
Hi guys, Still hoping to get it done in the next couple of days :-) |
|
Nice! Let me know if I can help. I wasn't able to get free time to do much -- Paul On Mon, 15 Feb 2016, 01:36 Usman Iqbal notifications@github.com wrote:
|
|
@paulscott56 , thanks very much for the offer! I'm definitely keen for some help with testing once complete; I haven't used PlatformIO before so it'd be good to confirm it's building something useful! @digistump , I have a question about the spec. I've installed PlatformIO with ESP8266 support; within that it gives me a number of boards to choose from. Should I be using one of them (which one?) or do I need to create a custom board for the Oak? (I couldn't find anything directly applicable in the latest release code). |
|
@usmanatron - the Oak files should be copied in where the ESP8266 files reside, and I think that should allow PlatformIO to support it and show the Oak as a board, its a completely separate core, the reason for installing the ESP files first is to get the support files like the compilers - it may take some tweaking for paths to match and such |
|
@digistump , thanks for the clarification - that makes sense. I'm at the point where I have a container with everything installed, so I can just attach to the container and hack away until the paths agree :-). I should have loads of time this weekend to get it done, fingers crossed! |
|
Hi guys, Good news: I think I've got it working! Though not using PlatformIO... I can see that the structure of OakCore closely matches that of the esp8266/Arduino repo, so I've used build instructions for that and ended up using make. I'm at the point where I can actually build a binary! (though I haven't tested it actually works on flashing). My next job is to write this all up into the Dockerfile and commit. After that I'll get my Oak setup and start testing. I hope using this alternative approach isn't a problem :-) Usman |
|
@usmanatron - that sounds like a much superior approach! thanks for working at this! |
|
@digistump - sorry this has taken so long (work takes up all my time on the weekdays...) I've managed to put everything together and I have a working prototype! The latest version is available here: https://github.com/usmanatron/buildpack-oak/tree/OakCore-32. When you start the container (see below), it builds the firmware and dumps it into /output with the logs. At this point, I'd be grateful if you could test the image and the firmware it spits out; I still haven't setup my oak and, more importantly, you'll have a lot more experience using it than me! One important limitation though - the input ino file needs to be named sketch.ino. I'm planning to fix this along with moving the intermediary files from /output to /cache (Ill possibly do these after this issue is done as they're arguably less of a problem) Finally, these are the Docker commands I ran to get it working. They'll need updating but otherwise it should "Just Work" (famous last words?!) If you have any questions \ it doesn't work please let me know! |
|
Good evening @digistump, This has given me a firmware file which Im now attempting to flash via the Arduino IDE (which I need to install etc.). I'll get back to you regarding how this goes. In the meantime, I'm happy enough with the status of everything to put up a pull request: digistump/buildpack-oak#1 Note that you need to update the Dockerfile for each successive release (the Url and the folder name). Maybe we can fix this when the dust has settled :-) If you have any questions with how anything has been implemented, please let me know! |
|
@usmanatron - This is awesome! I apologize for the delay in getting back to you on this. This setup looks great and I'll test and have Particle test ASAP. Please send me an email at support@digistump.com to claim the bounty (and let me know which form you want it in). As soon as I test I'll get back to you about any changes, but the requirement to update the dockerfile for new releases is fine as they must be manually pushed to Particle anyway. |
|
Usman - as mentioned in my email, Particle had some feedback about this - Basically the key thing is - they aren't using the buildpacks for their build farm right now, not sure how I came to understand they are, but basically they haven't implemented docker within their build farm yet to run images like this. This of course led me to make sure I understand how the build farm works right now vs how it is documented to work and here is what I found: Their build servers can be 32 or 64 bit Ubuntu - they do the following: Run the pre-processor So what the Oak needs to have is - A repo with a Makefile that uses the same environment vars as theirs (except where it relates to toolchain, which could be hardcoded) and takes input and outputs to the same places as theirs. I think mostly this means unpackaging your work here and repackaging it into these parts - and probably tweaking the makefile a bit. Is this something you'd be interested in doing/helping with? I apologize I so profoundly misunderstood what they needed for their build farm, not sure where the wires got crossed other than their github certainly suggesting the docker way was the current way. Thanks again for your work on this, if you'd like to continue to help with this I'd be happy to offer you more free stuff, and if not no problem I'm sure I can personally shape it into what it needs to be or offer it up as another bounty. Thanks, |
|
Hi @digistump, Thanks for the feedback and explanation. That's unfortunate, but at least it sounds like everything we've done so far has been directly useful :-) I'm more than happy to get involved again and re-package the components to fit the new setup. In order to do this efficiently though, it would be good to get more information on their setup (e.g. what exactly their toolchain looks like, what env. variables they use etc.). Ideally, Id like to get a VM image of one of their build servers so I can see where things are \ how it's currently setup and get it right the first time! Do you think that's possible? (Feel free to pass my details along to Particle if that helps) Thanks |
|
Usman, I've asked Particle for as much of info as they can give us, or an image, I'll let you know when I hear back - thanks for being willing to get involved again! Thanks, |
|
@digistump |
|
No real update or ETA - we are entirely waiting on Particle at this point On Wed, Apr 6, 2016 at 1:25 PM, sacbhale notifications@github.com wrote:
|
|
Hi @digistump Cheers |
|
Particle has said they will have clear instructions to set it all up by May Thanks for still being willing to work on this! On Sat, Apr 30, 2016 at 6:12 AM, Usman Iqbal notifications@github.com
|
|
Hi @digistump Thanks |
|
Yes that is correct - Particle has decided to move forward with the Docker Thanks! On Fri, Jun 10, 2016 at 4:53 AM, Usman Iqbal notifications@github.com
|
|
Has this been implemented? |
|
bump |
|
@usmanatron @digistump Apparently Particle recently fixed a problem at their end with the Particle IDE stuff and are ready to work with you guys on getting Oaks working for online IDE flashing. Currently it appears that Particle IDE is actually offering to flash Oak devices online with firmware v1.0.5 (which sounded promising), but those who have tested it report that it bricks the Oak causing it to need a serial restore. Reading back through this thread I see that there was previously a requirement on the docker build system developed by @usmanatron that required the input sketch to be named sketch.ino and wondered if that was still a requirement and could be the cause of the problems? Equally it could be something much more complex at fault. It sounds like things are getting really close though, and I'm getting very excited by the Oaks getting Particle Build IDE. Hoping you guys can liaise with Particle and make some dreams come true. |
|
Hi @emardee , With any luck I'll have a chance to try this over the weekend. I'll try to keep this thread updated with progress. |
|
@usmanatron Thanks for the update. Glad to hear you guys are on the case... hopefully not much further to go! @emardee Looks like we were both thinking the same thing... I just hopped on to post a comment also! :D |
|
@usmanatron Glad to hear the news.... if you need anyone to rest it, I'm sure @pfeerick could be useful... as I understand it, he's bricked and serial-restored his Oak devices so many times, he can do it in his sleep! So he might be a fearless tester to have on your side.... (me less so unfortunately, but I can make encouraging noises from the sideline!) Hope you find some time soon. Thanks for all the hard work. |
|
lol... so much so that I decided to try this was as good a reason as any to learn how to use docker, so built and ran the docker config from https://github.com/digistump/buildpack-oak. I set it up for 1.0.5, but it seems to be making firmware files about 25k bigger than the equivalent arduino install is on windows, so I'll have to compare it with the linux install to see if that is a anomaly or not. I bricked the test subject again though... so I suppose that's something? |
|
Don't forget to ask if you need any help... or encouragement... or both! |
|
Ok, So if I flash my Oak from the Particle Build interface. It works great now. Does that mean that it uses the Docker image? If so, it works great, except: it doesn't seem to include a -Ilib/ in the compile options, because if I try to include libraries, it says: So it seems like the library is put in lib/, but that the compiler doesn't search lib/ for headers. |
|
Yeah, I'm pretty sure that is the case... it took a while but particle finally rolled it out. There is a possibility that this broke because they changed a load of stuff recent in relation to library include and management... but there has always been an issue with library includes on this docker image... some libraries worked just fine... but not others. I get that same output if I add the HttpClient library to a simple sketch like the led blinky view the Particle Build library manager (and basically the same message if I just add the include line without 'installing' the library). Interestingly enough, I get an completely different error if I add it on the Arduino IDE and compile for the Oak - |
Skills Required: Intermediate Docker/Linux Skills, some familiarity with PlatformIO a plus
Difficulty: Easy to Moderate
Challenges/Thoughts:
The Particle Web IDE uses compilers in the cloud to build sketches. The compilers run from Docker images for each platform that take an input folder (sketch and libraries) and output a .bin file for the cloud to upload to the device. They also output a log file.
The Particle devices (Photon and Core) use this environment with a custom preprocessor and make files to compile. The Oak uses an Arduino compatible core setup and so it can instead use PlatformIO to do the compiling from the command line and handle preprocessing.
Fork https://github.com/spark/buildpack-hal (or whichever image seems correct for this) and modify so that it:
Bounty
$100 cash or $200 credit or 20 Oaks
If you are sure you can do this, and able to do this quickly - please feel free to respond to this issue and say that you are working on it and when you will complete it, so that others don't waste their time on it. If you are just entertaining the idea/unsure if you can do it, please don't "claim" it until you are sure.
Cash or credit is your choice. Cash to be paid via Paypal. Credit has no expiration but can only be applied to a single order and does not cover shipping (because that is how our shopping cart works, not because we want to be limiting). Oaks reward includes shipping.
You may credit yourself in the files as well, leaving in tact existing licenses and credits.
Legal Stuff: We will choose a winner at our sole discretion. The winner will be the first pull request that submits fully working code meeting the above requirements and following good coding practices, based on the timestamp of the pull request. Bounty will be awarded (or in the case of Oaks, sent) within 48 hours of confirming winner. Cash awards will be made in USD. This is not an offer for hire. All work submitted becomes the property of Digistump LLC to be used at our discretion in compliance with any associated licenses. Void where prohibited by law.
The text was updated successfully, but these errors were encountered: