@BDub This is a known bug with make-3.81 in cygwin when generating dependencies. Its been around for at least 6 years and there seems to be no interest in it getting fixed upstream.
If you build in the mingw shell (for example, using git-bash) or build in linux then you wont encounter problems.
@bdub - that is ugly. I have a fresh win8 virtual machine online, I will be trying the dev tools out over the next day or so. If I can help you with this, I will!
Which version of make is getting called? Are you sure that gnu make is first on your path, that looks like make from visual studio, which is not going to be compatible with a gnu makefile.
I’m just quibbling with your “latest firmware” statement. Yes, you will get the latest released firmware which I believe is the “compile-server2” branch (see below). Since much of this thread is talking about compiling your own fw (possibly from other branches), I figured I’d mention that.
github has a nice interactive “graph” which shows you where the different branches are (see here) Here’s a screenshot showing the compile-server2 which was “released” in late December.
@dorth is correct - a new build will be uploaded to the web IDE by the end of the week. In general we’ll be trying to push new firmware to the cloud every two weeks.
When I get something right on my main PC, I can’t reproduce the success with my laptop.
In this case, actually the original guide (in the first post) is the actually the simplest method and works well. There was just few points to pay attention to:
Use Git Bash instead of Windows Command prompt. It installs with Git and runs from context menu (right mouse click).
Make sure everything is in Windows PATH variable so they can be found and run anyywhere
Do not install Git or Make to Program Files. Space in certain places breaks things in unix-style enviroment.
That last part took me whole saturday to figure out.
I redownloaded clean Spark sources from GitHub and it seems to build well without modifications to makefiles. First build with i3-laptop is slowish, but after that I only have to rebuild the application.cpp related changes, which is suprisingly fast compared to time it takes the online IDE to send me new firmware.
Cool, glad you got it building again! The original makefile was OS independent, but the much faster makefile has a few more requirements, as a Windows user myself, I’m looking forward to trying this out.
The build time on the build server is also about under a second, so if you’re watching your core, by the time your core flashes magenta once, the cloud has already transferred your code, built it, and has started sending chunks to your core. Most of the time is spent making sure all the packets get there safely, and making sure you have firmware to fall back on if the transfer fails.
Edit: Which is to say, we’ve been brainstorming on ways to make the OTA updates faster, and I think we have some good solutions in the pipeline to speed that up significantly.
It just occurred to me that the speed of the reflashing must be related to the speed at which the CC3000 and STM32 are working together to read bytes over TCP. And if the firmware is about 70KB or so, then the transfer speed is a lot slower than I think it could be… sounds like 1 - 2KB per second (my flashing process takes about 45 seconds), and should be way faster, at least 30KB/s or more.
A big component of the OTA delay has to do with the small receive buffer size (256 bytes, so more ram is left available), and the positive confirmation message after every package is received. This means on a medium latency network, say ~100ms ping, you have to wait an extra ((70000/256)*100)/1000 ~= 27 seconds. The trade off here is this is very robust in a high-error environment, but slow in a clean environment. My plan was to try to carefully send more than one chunk at a time in a way as to not overwhelm the core. I think this is possible, but it requires some careful coding, and it needs to be backwards compatible as well.