You can submit patches through pull requests on any of our public repositories:
If youāre not familiar with Github pull requests:
You can submit patches through pull requests on any of our public repositories:
If youāre not familiar with Github pull requests:
Are you using the fork and pull or the shared repository and topic branches model?
btw, the links under āDownload and Install dependenciesā no longer work, e.g. link 4 Zatig goes to - http://discourse/#4-zatig
Iāve got the toolchain all setup, and can run make
no problem from the build directory, but now it would be nice if I could get dfu-util working.
Easier said than done on Windows 7 32-bit! Itās practically non-supported⦠Iām working my way through installing all of the tools again to build the sources for dfu-util
http://wiki.openmoko.org/wiki/Dfu-util-windows
If anyone has a better way, please let me know! Thanks.
Hey @BDub,
It looks like they have pre-compiled binaries for Windows on the site: http://dfu-util.gnumonks.org/releases/dfu-util-0.7-binaries.7z ā open it up with 7-zip, and the win32-mingw32 version worked for me (at least on win7-64 bit)
Thanks!
David
Awexome! Thanks Dave I put the binaries in my PATH and they work. Just had to install the Zatig WinUSB driver for the CORE DFU device that pops up with you put the
Core into DFU mode (Flashing Yellow). Built the master branch and Iāve got Tinker loaded as expected.
Earlier I had replaced the SPARK CORE WITH WIFI device that is present when the Core has booted, with the Zatig WinUSB driver. So Iām guessing I should put the other driver back that creates the USB to Serial Bridge.
One problem I am now having is when I try to rebuild the project again by typing make
in the core-firmware\build directory, I get this error:
obj/src/application.o.d:1: *** multiple target patterns. Stop.
Also can anyone comment on about how long it takes to compile the sources this way? I will time mine again when I get it working, but it seems to take quite a while longer than the web IDE.
The first compile takes a while because itās clean (from scratch) compile. After that, only files that have changed are compiled.
I didnāt have to remove the Zadig driver and still got usb comms from the core.
So at this point, what is the most supported / easiest environment for this? I can run Linux in a virtual PC if needed as it looks like Windows is just not really a supported env here.
Sill - I winder how long it will be, or if the road map even includes, parity support in the āofficialā Arduino IDE?
I ask because frankly my dev box is to important to my day to day to destabilize byhacking in random bits and chunks from different locations, unofficial links and so on. So I am putting it into a VC anyway - so is Linux a more directly supported ENV?
Ken
Thatās kind of what I was thinking too based on the bounty to rework the makefile. Problem is I havenāt been able to compile a second time yet. I wonder if installing the MinGW environment has done something? I did that to try to compile dfu-util sources⦠well Iāll try to uninstall and see what changes.
I decided to google the error first, and found the GNU make manual says:
āmissing target pattern. Stop.ā
āmultiple target patterns. Stop.ā
ātarget pattern contains no `%'. Stop.ā
āmixed implicit and static pattern rules. Stop.ā
These are generated for malformed static pattern rules. The first means there's no pattern in the target section of the rule; the second means there are multiple patterns in the target section; the third means the target doesn't contain a pattern character (%); and the fourth means that all three parts of the static pattern rule contain pattern characters (%)āonly the first two parts should. If you see these errors and you aren't trying to create a static pattern rule, check the value of any variables in your target and prerequisite lists to be sure they do not contain colons. See Syntax of Static Pattern Rules.
Hereās the files that itās complaining about⦠these times are all from when I created the first build successfully.
And the first part of the application.o.d file:
I doubt this is MinGW related⦠so I think Iāll leave it installed.
EDIT: Ok, If I delete all 3 of the obj
directories, it will build again⦠but Iām guessing that shouldnāt be necessary?
Allllrighty then⦠.I think this might be the issue but still donāt know enough to solve it.
I read that Make interprets the colon as defining a target pattern, and since this is technically all one line it thinks there are multiple target patterns.
Two sources claim the c:\
windows path should be generated in a more relative path manner so Make doesnāt chokeā¦
http://stackoverflow.com/questions/14514086/make-multiple-target-patterns-stop
http://cygwin.com/ml/cygwin/2009-04/msg00006.html
But I have no idea how to do thatā¦
EDIT: for now I just made two batch filesā¦
M.BAT
@ECHO OFF
ECHO BUILDING PROJECT!!!
rmdir /S /Q obj
rmdir /S /Q ..\..\core-common-lib\build\obj
rmdir /S /Q ..\..\core-communication-lib\build\obj
make
and
P.BAT
@ECHO OFF
ECHO PROGRAMMING!!!
dfu-util -d 1d50:607f -a 0 -s 0x08005000:leave -D core-firmware.bin
@BDub - Iāll fire up a linux VM and get it running, then a windows one and work in this some - Makefiles and so on are within my sphere (as opposed to this hardware stuff ) so I can actually be useful there!
Thanks @Soulhuntre! Iāve been searching and reading, trying to figure this outā¦
I renamed the paths in the application.o.d file like this manually:
And now the error is in the next dependency file. Hereās a before and afterā¦
So if possible to make the GCC toolpath relative somehow I think that could be the best solution, or if ā/cygdrive/c/ā is valid for everyone (probably not) do some kind of renaming thing on the dependency file. I dunno, Iām not an expert here ā¦
Windows (MinGW) is supported - Iāve been compiling on windows. There are some āgotchasā in the makefile that mean it doesnāt work fluidly out the box, but I hope to submit patches to fix these issues.
@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.
I tried git-bash and it starts to compile but it fails after a bit about not being able to find a file.
Linux is cool and all, but not that practical for me.
I guess Iāll just work with my batch files and deal with longer build times.
@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!
Ken
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.
Anyone able to make it work on Windows platform?
I tried setting up and it always give āmake: *** [check_external_deps] Error 2ā when recompiled.