How to set up development tools on Windows?

I’ve gone through the installs, added environment variables to set up the build environment.

Ideally I’d like to code and compile in Visual Studio Code. Preferably upload automatically to the Daisy Seed.

Using git command line I cloned the daisyexamples to my harddrive.

Double clicked rebuild_all.sh to rebuild the cloned github daisy examples directory. I just get these errors:-

./rebuild_examples.sh: line 11: make: command not found
done
rebuilding DaisySP/examples/faustnoise/
./rebuild_examples.sh: line 10: make: command not found
./rebuild_examples.sh: line 11: make: command not found
done
rebuilding DaisySP/examples/jitter/
./rebuild_examples.sh: line 10: make: command not found
./rebuild_examples.sh: line 11: make: command not found
done
rebuilding DaisySP/examples/line/
./rebuild_examples.sh: line 10: make: co

(etc)

I’ve no idea how to fix that it can’t find Make. Do I even need make to build with VSCode?

Should the environment variable on windows be a user or system variable? (I’ve done both) Where should it point? On my system “make.exe” is here: “C:\Program Files (x86)\GnuWin32\bin” (which is what I set the environment variables to). Still not working. I called the variable “Make” should it be something else?

Thanks in advance.

Hey @redmotion, I think this might be the problem. You need to add the path to the variable called Path which will have multiple entries.

Select Path in the environment variables, hit edit, add the path. I have the same entry as you, “C:\Program Files (x86)\GnuWin32\bin” - among other paths for other programs, displayed on multiple lines.

Let me know if that works for you!

1 Like

Many thanks that seemed to do the trick.

Moving onto uploading: I also managed to upload to my Daisy on the Blink program compiled. It appears to work correctly on the Daisy but there was this at the end of the compile messages:

File downloaded successfully
Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
Error during download get_status
make: *** [program-dfu] Error 74

Is this something I need to worry about?

I’ve added the Platform IO plugin to VSCode. I’m assuming that I need to Create a new Project. And typing Daisy selects “Electrosmith Daisy” for the Board. For a Daisy seed, do I select Arduino, CMSIS or STM32Cube?

Many thanks again.

I get this particular dfu error as well but the flashed program works.

Here’s why I reckon this happens: If you use STM Cube Programmer to upload the program via DFU, there’s a flag you can set whether the program automatically launches upon completed flash. If you set that, the DFU resets and is disconnected, resulting in an error message in STM Cube Programmer also (the program is unable to see the DFU now because it was rebooted and launched the program you flashed). The behaviour of the commandline DFU upload seems similar.

Read this thread about community efforts to get things working with PlatformIO.

My best results so far have been to write and edit code in VSC, then compile with make and upload with make program-dfu. This way you’ll have nice editing with context highlighting and side by side windows etc. but the last step is command line which is very quick and easy enough.

Or maybe you’ll read the thread and just find the missing piece in the compile-from-VSC puzzle! If you do so, please share! :smiley:

2 Likes

Thanks MSM. Seems like the VSCode route is still trying to find it’s feet!

I’d normally vere towards VSC because of the autocomplete, syntax highlighting and built in compiling. (I’m using it with Unity3d usually). But if it’s not working fully… can I ask about Arduino?

Is this for using the Daisy Library with an Arduino or building and uploading to Daisy via the Arduino IDE? I’ve used the Arduino IDE before - maybe I can use it while the VSCode implimentation is worked out.

1 Like

The thread explored both options, and for Arduino a compile from both the Arduino IDE (“normal” install) and VSC with PlatformIO compiles and uploads from the IDE (Daisy on Arduino Platform, with the DaisyDuino libs dropped into the project). The VSC / PlatformIO solution has autocomplete, syntax highlighting and built-in-compiling.

I opted for C++ because there seem to be more examples at this point (and the examples are really cool!) and I wanted to switch over anyways. So just editing the CPP file in VSC still has syntax highlighting, but no autocomplete. Compiling is with make but it’s as much work as copypasting a folder path you already have open and executing the same two commands over and over.

If you’re already familiar with C++ I wouldn’t recommend Arduino. The dev tools are still a lot less nice (although they are cooking up a new IDE).

1 Like

Thanks again MSM. I’m taking your advice and I’m going to stick with C++. I’ve been coding in C# for years with Unity3d and its not a huge leap over to its older brother.

The thread you linked to is quite technical but by scanning through some of the posts I’m now making progress:-

  1. Created a new Daisy project with PlaformIO.
  2. Copied libDaisy and DaisySP folders downloaded from Github to the lib folder of the project.
  3. Typed or copied some of the examples to check autocomplete is working for the two libraries. Examples show no errors.

Next stop: compiling.

Continuing to root around the thread! :slight_smile:

I added the line: “upload_protocol = dfu” to platformio.ini

I made a copy of the blink.cpp file in the src directory of the project

I created a makefile in the same directory targeting blink.cpp and locating the exact root directories of the libraries:-

Project Name

TARGET = blink

Sources

CPP_SOURCES = blink.cpp

Library Locations

LIBDAISY_DIR ?= F:/___Daisy_Code/TestProject02/lib/libdaisy
DAISYSP_DIR ?= F:/___Daisy_Code/TestProject02/lib/DaisySP

Core location, and generic Makefile.

SYSTEM_FILES_DIR = $(LIBDAISY_DIR)/core
include $(SYSTEM_FILES_DIR)/Makefile

Then I used the VSC terminal to locate the folder and ran the make command. It created a build directory and filled it with files relating to the build but then failed when trying to build blink.elf (I think).

arm-none-eabi-g++ build/system_stm32h7xx.o build/blink.o build/startup_stm32h750xx.o -mcpu=cortex-m7 -mthumb -mfpu=fpv5-d16 -mfloat-abi=hard --specs=nano.specs --specs=nosys.specs -TF:/___Daisy_Code/TestProject02/lib/libdaisy/core/STM32H750IB_flash.lds -LF:/___Daisy_Code/TestProject02/lib/libdaisy/build -L F:/___Daisy_Code/TestProject02/lib/DaisySP/build -ldaisy -lc -lm -lnosys -ldaisysp -Wl,-Map=build/blink.map,–cref -Wl,–gc-sections -o build/blink.elf
c:/program files (x86)/gnu arm embedded toolchain/9 2020-q2-update/bin/…/lib/gcc/arm-none-eabi/9.3.1/…/…/…/…/arm-none-eabi/bin/ld.exe: cannot find -ldaisy
c:/program files (x86)/gnu arm embedded toolchain/9 2020-q2-update/bin/…/lib/gcc/arm-none-eabi/9.3.1/…/…/…/…/arm-none-eabi/bin/ld.exe: cannot find -ldaisys

Seems to be something wrong with the gnu arm embedded toolchain?

It’s possible that I should have built the libraries DaisySP and libDaisy before trying to run make on the blink example.

After running build all in the Daisy Examples project folder, I then copied the /build/ folders into my project’s lib DaisySP and libDaisy folders. Then ran make again from the command line and it appears to have built the blink example successfully.

Will try to upload to my D_Seed tomorrow. (need to sleep now…)

Ah yes that’s in the getting started guide! I hope you got things running now! Also if you change something in libdaisy you have to run ./rebuild_libs.sh again, and if you add e.g. device drivers you have to add them to the make file.

With the USB cable connected, you can set the Seed in DFU mode with holding the boot button, then clicking the reset button and the letting go of the boot button. Then you can upload the code you compiled with make program-dfu

I think the intended file structure is to have the DaisyExamples folder, and a copy of libdaisy and DaisySP folders in it.

3 Likes

Agreed. I basically got ahead of myself and tried to make my own development project folder without building the Daisy Examples folder first: which would have shown me the missing piece of the puzzle.

Thanks again for your help, MSM.

1 Like

Hey guys this is my first post in here.

This is really useful @MakingSoundMachines

I have similar issues and errors once trying to set up in Windows and did similar mistakes as @redmotion by not building Daisy Examples first I just downloaded it so was useful to find this thread.

I have now rebuilt it from git and I am trying to compile and upload pd patches but get this error while compiling both the example and the test pd patch.

$ make program-dfu
dfu-util -a 0 -s 0x08000000:leave -D build/FilterBank.bin -d 0483:df11
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util / Tickets

No such file or directory: Could not open file build/FilterBank.bin for reading
make: *** [program-dfu] Error 74

Would you have an idea how to go about this? I added absolute paths to the environment path. Installed toolchain but it looks like it cant make bin file. I cant find any bin files myself too.
I am trying to compile both with MSYS2 and MINGW64 on Git Bash and get the same messages with both of them. I’ve changed the driver to WinUSB before building Daisy Examples. Do I have to add it to makefile somewhere?

Really appreciate any tips. Cheers!

Just saw this now, but better late than never.

It looks like you didn’t create the .bin file by running make in the directory first.

The workflow should look similar to this :

  1. Install toolchain (make, arm-none-eabi, dfu-util, etc. – looks like you’ve already done this)
  2. Clone DaisyExamples and initialize submodules
  3. build libDaisy, and DaisySP (by navigating into each of those folders and running make)
  4. building an example (by navigating to the example’s directory and running make)
  5. programming the example onto your daisy (by running make program-dfu from the example’s directory).

Steps 0-1 only need to happen the first time after cloning, step 2 can be repeated whenever you want to update the libraries. Step 3 needs to happen anytime the example itself is changed.

As a sanity check you can always check if you have a build/ directory in the directory of the example you’re trying to run. That directory should contain a .bin file. For example, in the above output you would be looking for a file called, FilterBank.bin

Hope this helps!

2 Likes

Thanks for this workflow, it helped get from never using Git or Make to compiling and uploading my first program to the Pod.

Just as feedback, it would help other novices if this added to the toolchain documentation. I’d be happy to do this and provide a draft if you are interested.

Scratch that comment…I started from scratch and the toolchain documentation already covers everything. I must have missed a step the first time, but the documentation is fine as is.

1 Like