I wanted to show you my small side project: a Atom editor package, which allows quick flashing using bundled dfu-util. Just open an Arduino project, compile it using Spark CLI spark compile ., press F6 in Atom and have your code uploaded using DFU:
That's sweet! Looks similar to Sublime Text... which leads me to the question, why Atom vs. Sublime Text? Is it just that it's free and open?
I've been trying to think of a better way to get the Core into DFU mode automatically... there is one suggestion that uses the Cloud which is quite novel, but not practical in the sense that you have to add special code to your Core with every application
Atom was chosen because it started as a āSpark Studioā idea I wanted to create a standalone IDE for core and I needed an editor which license would alow that. But weāll see how it goes.
With DFU I was looking into the same topic, but it would create additional problems. I can add this code before compiling, but then thereās no guarantee that core is connected to cloud or which core is the one we want to flash. Only way I see is tinkering with DFU protocol on both core and desktop to be able to force DFU mode via dfu-util. But even with manual DFU it still beats cloud flash when it comes to speed (at least in EU)
This is AWESOME!!! I canāt wait to try it myself.
Have you thought about adding the option for flashing through the Cloud, in addition to flash over USB? You could use the Spark CLI:
I could imagine this working in two ways. First, you could call the CLI directly with exec; second, you could integrate the Node.js code from the CLI directly into the IDE. That would quickly give you the full power of the CLI, which would give you the OTA flash, and also the account management stuff (to login to your spark account so you donāt have to manually enter your access token)
@zach definitely! I want to integrate whole CLI along with OTA flash and all the other goodies it provides Iāve looked into it and it should be pretty straightforward (just needs a few UI views).
@kennethlimcp I see that all tools (gcc-arm-embedded, make, dfu-util) actually already have binaries for Windows. Only the part with Zadig and replacing driver with libusbK (thanks for the tutorial BTW!) can be tricky from command line/script. Iāll have to get hold of some Windows machine and try it out.
@BDub I did not now about this It looks like I wasted a lot of my time on bundling binaries and generating makefiles for nothing. Iāll play around with it and probably use it as a default way of compiling in future versions.
@kennethlimcp Are you using this Windows build? We can Skype (my handle is suda_skype) and try to resolve any issues.
About update, core utils like gcc, make or dfu-util donāt have to be updated. Only core-firmware and libraries need to be up to date. There can be a schedule to update plugin once a week with new firmware. Although if cloud compile would be used, thereās no need for that.
another thing to take note is that the Spark-CLI compile function via the allows the file to be a .cpp and the folder name does not to be the same as the .cpp file
Something for the backlog maybe?
Thanks man! Iāll loving this new tool on top of the existing Spark-CLI which brought me tons of joy
This plugin contains all required tools required to compile core-firmware with replacing application.cpp using your code. Then it launches dfu-util to flash the core
So if youāre on OS X, itās all you need to build and flash your code locally (without the cloud).
this is awesome! now, assuming that i add this function all my applications (wish this could be built in by default!)....would i just make a rest call to "doDFU" before using the Atom plugin to compile / flash? it would be really great if we could modify the plugin to all "doDFU".
I wanted to create a standalone IDE for core and I needed an editor which license would alow that. But weāll see how it goes.
Iāve looked into it and it should be pretty straightforward (just needs a few UI views).
allows the file to be a