The Spark Core Firmware


#7

You can submit patches through pull requests on any of our public repositories:

If you’re not familiar with Github pull requests:

https://help.github.com/articles/using-pull-requests


#8

Are you using the fork and pull or the shared repository and topic branches model?


#9

btw, the links under “Download and Install dependencies” no longer work, e.g. link 4 Zatig goes to - http://discourse/#4-zatig


#10

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.


#11

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


#12

Awexome! Thanks Dave :slight_smile: 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 :spark: 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.


Bug bounty: Kill the 'Cyan flash of death'
#13

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.


#14

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


#15

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.


#16

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? :wink:


#17

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…

@zachary @mattande any ideas?

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

#18

@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 :slight_smile: ) so I can actually be useful there!


#19

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 …


#20

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.


#21

@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.


#22

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.


#23

@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


#24

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.


#25


#26

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.