Another day another bug

Hi all

Finally got my Spark Core out of its funk (it was claiming to be connected to the cloud but wasn’t) by doing a hard reset and then claiming it with the CLI. Claiming it with the mobile app didn’t work either. Took about an hour and a half because installing node didn’t go smoothly on my Mac, but I’m there now.

So I’m using the desktop particle dev app because the web build was giving me errors.

Now particle dev isn’t allowing me to compile and upload because

wire.h: no such file or directory
arduinoproject.ino:2:18

For some unknown reason particle dev seems to be rooting around in an old arduino project which is stored in a completely seperate folder on my hard disk?

Or am I reading this wrong? Arduinoproject.ino is not related in any way, file name or content, to the project I’m trying to compile and upload.

Sorry … frustrated. :slight_smile:

Could you take a Screenshot of the interface, preferably with the directory open to where your files are, and if possible the error?

Thanks @moors7. I seem to have sorted it by isolating my file in a folder all of its own and directing the dev software there. So it is a weird bug/weird behaviour but I can work around it.

But now I have encountered a new problem: something that compiles/uploads fine on web does not do so from desktop dev:

Uncaught TypeError: Cannot read property '0' of undefined

I guess it’s back to the web for me?

Have you tried opening only the folder you’re trying to use, as stated in the linker github issue?
Dev certainly has some odd quirks, but it’s still very useful once you’ve got used to it :o Hopefully, the situation will improve in the nearby future when the electron is finally out and some more resources can be devoted to fixing existing things like this.

Thanks @Moors7, yes, as I said, that’s what sorted the issue for me, but then as I said, another unrelated bug cropped up which meant I have to go back to using the web anyway.

And now yet another problem: the spark core is disconnecting from WiFi every 30seconds or so. I know it’s not router or wifi strength related.

Thanks for your help and interest.

The problem here is not actually a bug but a somewhat counter intuitive but perfectly sane (room for argument here :wink:) behaviour.
Atom (on which Dev is based on) is foremost a file editor and has no knowledge about your project structure.
So you can open any file and work on it, but once you press build the last file you worked on does not matter whatsoever (it could just be your shopping list). The only thing relevant for building is the project folder you selected - maybe even in a previous session.
Opening a file (e.g. shoppinglist) from a different folder (e.g. lists) does not automatically promote this folder to be the project folder.

Another useful way to build is CLI

particle compile core . firmware.bin

This will upload the source files of the current directory (".") to the cloud where it will be built for the core and the resulting binary will be downloaded as firmware.bin and can be flashed via USB or OTA via CLI again.

The good thing about this is the possibility to employ your own source control (e.g. local github repo) and you will get a full error log too.


This might be due to blocking code.

1 Like

That’s normal in the IDEs I’ve used.
Edit anything.
Only files added to the project collection matter in the build.
Good IDEs have you “add” .c and .h files to the project. Rather than just looking at what files are in a folder.

Yes, but you have to be aware of the fact and do the adding to project conciously.

I don’t know if you’d see Visual Studio, Eclipse, NetBeans, … as “good” IDE, but they don’t force you to (or have you) add every file you open to your project, or do yours?

For instance, you can open any file with VS withouth creating a solution, or if you have a solution selected you can “side load” an additional file, but you have to use a solution as project container.
But who says that a FS folder has to be an invalid/inadequate project container?