Particle Workbench New user question

I am new to software and just getting started on Particle using Relay Shield. I used the Web IDE successfully, now moving to the Particle Workbench on the desktop (need the serial debug). When I create a new project, copy the code from the example code, it’s giving a compile error.

build.mk:65: *** “No sources found in c:/Sunder/projects/Particle IO/junk2/Trial/”. Stop.
make[2]: *** […/…/…/build/recurse.mk:12: user] Error 2
make[1]: *** […/build/recurse.mk:12: modules/photon/user-part] Error 2
make: *** [C:\Users\sunder.particle\toolchains\buildscripts\1.5.0\Makefile:42: compile-user] Error 2
The terminal process terminated with exit code: 2

Can someone help with this? or point me to a step-by-step tutorial to compile, run and debug with the serial port on the Desktop workbench. Any help appreciated

Have you created the project via the dedicated command?
image

If so, your sources should go inside the src folder.

How are you compiling?
image
or
image
or any other way?

1 Like

in addition to what @ScruffR suggests, we have docs over here:

https://docs.particle.io/workbench/

including a quick start:

https://docs.particle.io/quickstart/workbench/

and more in-depth tutorial:

https://docs.particle.io/tutorials/developer-tools/workbench/

these and other resources are available within Workbench via the Particle: Get Help command - from VSCode’s main menu, click “View > Command Palette” and then start typing “Particle” - or from the “Welcome” screen that is shown when you click the Particle logo in the main Activity Bar on the left.

hope that helps!

2 Likes

If I use the buttons at the top right of the screen

image (or use Particle Compile Application (local)) it DOES NOT work, gives the same compile error. (I did install the local compiler)

but when I used Particle: Cloud Compile and Particle Cloud Flash, I was able to upload to the photon. For now I am unblocked, thank you both.

those buttons and a number of other things are configurable - see:

Workbench-related settings can be found under the “Particle” section :+1:

the error you are seeing is most likely due to what @ScruffR pointed out

your sources should go inside the src folder

2 Likes

I’m getting the same error compiling locally so I landed on this conversation.
My sources are in the /src folder. However, I have a library that uses sub folders so I have /src/util/ folder too. Must src be flat with no sub folders? (And I have a readme.md and changelog.md in the base folder)

I have not yet tested moving the files out of the sub folder, not knowing if I’ll end up with new problems or not.

So for anyone else coming across this thread…not all of these things may be a problem, but follow along and it may solve your problem too.

When trying to create a new project it wouldn’t due to a space in the folder name. So it may not build if your current project is in a folder like /users/me/Visual Code/projects/Test1/

So I moved my folder to c:\test1\ but it wouldn’t build. Interestingly, a .cpp file appeared that was never before in my project folders.

Then I moved supporting library files from my src/utils/ sub folder into the main src folder, and updated dependencies. Still would not build.

Deleted the now empty src/utils/ sub folder.

Finally it build! Yay. And took maybe 15 minutes. I’m not sure the local compile will get much use taking that long and not sure if that is normal or if there is a way to speed it up.

Was it a .cpp file with the same name as your .ino?
If so, that's to be expected. It is the output of the Partice pre-processor converting the .ino (which the compiler wouldn't touch) into something the compiler likes to work with.

I can confirm that Workbench has no issues with subfolders under ./src as long there are no conflicting files in it, but (real *) libraries should rather go into a subfolder./lib/<libName>

Can you provide some tree diagram of a non-working project for us to test?


*) real libraries adhering to the library standard structure with a library.properties file and all.

1 Like

Thanks @ScruffR for taking a look. This morning I tried to retrace the steps.

Yes, the .cpp file is the same name as the .ino. Part of the point is that the .cpp file does not build when your project is in a folder with a space (in my case meaning a folder higher up in the tree, e.g. “/users/me/Visual Code/projects”). So if there is no .cpp file that is the first hint of the problem.

This morning it did compile with the src/utils/ sub folder, when I exercised a lot more patience and paying attention. When the project folder (with the space removed) is opened it takes a really long time for it to go through its process (keeping an eye on the terminal until it is finally done).

Then compiling locally, the terminal is stuck at “/makefile” for almost 9 minutes before finally there is some action and part 1 is produced. It takes nearly 20 minutes before finally part 3 with the user firmware is completed.

I think my prior perception of failure is either I interrupted the process or assumed it to be completed when it was still stuck on “/makefile”.

My libraries are actually in the /src folder. I’ve not created a libraries.properties file so I guess they are not *real.

PS: Running local compile a 2nd time (no code changes), it only takes 45 seconds to get to part 1, 1:30 to part 2 and finishes part 3 after 2:10.

If the inaction in terminal is something you want to change, you can re-enable the verbose output of the compiler via File - Preferences - Settings

Yup, that's expected. A full build with all modules for the first time takes ages on Windows, but as long the sources are unaltered (and you don't switch platform) previously compiled modules can be reused.

3 Likes

@bloukingfisher

the .cpp file does not build when your project is in a folder with a space

this is a limitation of the underlying build system (make) - see here:

You can also add support to different directories by customize the file tree. The default configuration to avoid mistakes if you don’t have much experience with build environments is to only look at root/lib and root/src. In fact, the default make file has a weak definition to the make file in use, allowing you to point to a new one:

USER_MAKEFILE ?= build.mk

and if you want to follow different standard to organize your code, like root_folder/app/src; root_folder/app/include; root_folder/lib1/src; root_folder/lib1/include you can customize your make file with the following entries:

INCLUDE_DIRS += $(SOURCE_PATH)/include
APPSOURCES+= $(SOURCE_PATH)/src/file1.cpp

Edit @m_m, sorry I wrongly quoted your comment.

1 Like

That's helpful thanks, at minimum as a visual reminder that the process is still running.

Good info to have @Gildons. If anything, I think I should first migrate to the default configuration before getting that fancy.