Hi there, I like the look and feel of the IDE over the basic Arduino IDE offering!
I have installed the above version (first install of UECIDE on any of my development machines) with a pre-installed Java 8.
Does UECIDE run with Java 8? I ask this as I cannot compile my sKetches (target is Arduino Nano) and the Console tab shows the following (and nothing in the Output tab: Compiling... • Preprocessing... java.lang.NullPointerException at org.uecide.Sketch.prepare(Sketch.java:1273) at org.uecide.Sketch.build(Sketch.java:1638) at org.uecide.Editor$DefaultRunHandler.run(Editor.java:195) at java.lang.Thread.run(Unknown Source)
I would prefer not to have two versions of Java on my machines if possible.
Thanks in advance, Graham
Hi again, I have continued to work the problem i reported in this thread.
Having closed and re-opened the IDE, compiling now does compile my source complete with my private libraries.
It sounds like maybe the core or compiler hadn't been selected when you chose the board, but reopening caused the selection to run again which fixed it.
Java 8 is actually the recommended version to run UECIDE with and the version (OpenJDK 8) I compile it with.
Hi Matt, Installed on my new development machine and ensured that the board was selected. This kicked the compiler off OK, but on this new machine it fails to compile the library (which does compile in the Arduino IDE). Frustrating - I'll switch back to the Arduino IDE for now.
What error do you get when compiling the library?
Hi Matt, Actually neither machine will compile my library (actually it is picking it up from my source folder rather than the Arduino common library folder in Documents) but either way it should be compile-able as it is with the Arduino IDE.
The Console tab: Compiling... • Preprocessing... • Compiling sketch... • Compiling core... ? arduino • Compiling libraries... ? TWire [C:\Projects\Arduino\UPItests\libraries\TWire]
The Output tab: main(org.uecide.Context@396f50, root) main(org.uecide.Context@396f50, root) C:\Users\mossgr\AppData\Local\UECIDE\compilers\avr-gcc/bin/avr-g++ -c C:\Users\mossgr\AppData\Local\Temp\build-240f2dcc-04b5-4335-a851-9d90a0e253fa\UPItests.cpp -o C:\Users\mossgr\AppData\Local\Temp\build-240f2dcc-04b5-4335-a851-9d90a0e253fa\UPItests.cpp.o -mmcu=atmega328p -g -std=gnu++11 -fno-threadsafe-statics -fno-exceptions -ffunction-sections -fdata-sections -DF_CPU=16000000L -DARDUINO=106 -DARDUINO_NANO -DARDUINO_ARCH_AVR -IC:\Users\mossgr\AppData\Local\UECIDE\cores\arduino\arduino -IC:\Projects\Arduino\UPItests\libraries\TWire -IC:\Projects\Arduino\UPItests\libraries\TWire -IC:\Users\mossgr\AppData\Local\UECIDE\boards\Arduino\arduino-nano328 -IC:\Users\mossgr\AppData\Local\Temp\build-240f2dcc-04b5-4335-a851-9d90a0e253fa -IC:\Projects\Arduino\UPItests -Os -w
There appears to be no output from the compiler.
I am wondering if this is because it's finding the library in the sketch. I made some changes to library detection recently to fall back on an older system if preprocessing isn't configured in the compiler, and I don't thing the AVR GCC has preprocessing configured (never got round to adding it, and uploading compilers takes forever, so it's been on the back burner - hence the fallback). I am wondering if that fallback is breaking on sketch-located libraries.
Try (temporarily) removing the library from the sketch and refreshing the internals (in the debug menu, or restarting the IDE) to see if that then compiles the non-sketch located version of the library properly.
Hi Matt, I have copied the source only over to a new folder so the library folder was not copied, therefore the library would be found down the MyDocuments\Arduino\libraries path.
Now I am back to the original problem of NullPointerException as per the first post. I have tried closing and re-opening the sketch, restarting the IDE and resetting things through the debug menu. None of these have got me past the snag message.
I have opened the debug console and notice that getCore is alternating between arduino and chipKit, as this snippet shows: Board.java 88 (getCore): Board's core is [arduino] Board.java 90 (getCore): Found base core Arduino 1.8.2 Board.java 88 (getCore): Board's core is [arduino] Board.java 90 (getCore): Found base core Arduino 1.8.2 Board.java 88 (getCore): Board's core is [chipkit] Board.java 90 (getCore): Found base core chipKIT Editor.java 2343 (heading): Compiling... Editor.java 2357 (bullet): Preprocessing... Editor.java 2423 (error): java.lang.NullPointerException at org.uecide.Sketch.prepare(Sketch.java:1273) at org.uecide.Sketch.build(Sketch.java:1638) at org.uecide.Editor$DefaultRunHandler.run(Editor.java:195) at java.lang.Thread.run(Unknown Source)
The Hardware ->Cores shows that it is 'Arduino 1.8.2', but the above seems to indicate it is confused. Hopefully this is useful information for you.
Well, line 1273 in the source (unless this file has changed since the version you are running) is:
if(!Preferences.getBoolean("compiler.disableline")) out.append("#line 1 \"" + mainFile.getAbsolutePath().replaceAll("\\\\", "\\\\\\\\") + "\"\n");
So either out is null, which it can't be since it is defined just the line before, or there is no mainFile to your sketch, which is impossible, or the mainFile has no path, which is also impossible.
Are you using 0.8.9-pre16 at the moment?
Hi Matt, I am still using 0.8.9-pre16 at the moment.
The plot thickens. The problem can be caused by changing the .ino file name so it does not match the sketch folder, then change the name back and the problem goes away. I would conclude it is related to the mainFile name. What is more difficult to explain is why it occurs when the folder and file are correctly named - which is the situation where I first experienced the problem.
Are there any other tests I can do for you?
A sketch is not just an INO file - it is an INO file in a folder where the folder is named the same as the INO file. If you have managed to get a sketch that doesn't have an INO file in it named the same as the folder then all hell will break loose.
If you can replicate the error with the files properly named then I can investigate further.
Hi Matt, I suggest that we drop this for now and see if others report it.
I have some pressure on me to get a ATMega I2C project converted to run on the PIC32 core, and that needs to be my focus.
All the best - I am sure we will communicate again. Graham