@rlogiacco - I followed the updated instructions on your blog, using a clean install of eclipse and new git clones and agree they are the best so far. I still get the errors about gcc and g++, do you also see these?
I am seeing many errors including the ones you mention above when I open spark_wiring.cpp.
UPDATE - I got rid of the errors in spark_wiring.cpp by adding two further includes:
Thanks @rlogiacco,
YES I had to set the arm-none-eabi/include which got rid of any errors reported when fiddling in application.cpp once I rebuilt the index.
Edit: Found more āerrorsā when working on other src files, too. Had to add more includes, as well.
On the other hand Iām using GitHub, so I canāt find a git\bin directory, since GitHub only seems to be a collection of .Net DLLs in the GAC.
So I could either install Git ver 1.8.5 in addition or there is another way which does not require any extra installations. ???
I'm not aware of any other way to do it: either you modify the makefiles or you add the git binaries to your path. I opted for the latter as I consider that neater.
@chrisb2 I canāt see the pictures, they are reported as broken imagesā¦ With regards to your update I hope @satishgn will be able to provide the proper list considering he seems to be using Eclipse as his dev environment
About your last update a little bit more info would be of help: have you done anything to bring back the errors? I had the same impression while doing my tests and I found adding the paths to different builders (C vs C++) can introduce/remove errors, not sure which was the combination though as I was too tiredā¦
Iām going to perform other tests during the upcoming weekend: it would be nice if we manage to share our experiences in a faster wayā¦ any thoughts on this?
Mmm - my images above are working for me, or did you mean the ones on my blog?
I have tried a little more trying to get those default includes to work, but no luck, I am sure they are at the bottom of the remaining issues. It seems to me that Eclipse has not properly configure the GNU ARM Tool chain.
I think the errors disappear while the indexer is running after a change to the includes.
I am pretty busy this weekend, so will not get much time. I am in New Zealand (GMT+13), maybe get in touch via Skype?
I am wondering if another approach may be more productive, such as GNU ARM Eclipse
Iām in Italy (GMT +1) so thatās quite a difference! I can definitely PM you my Skype nickname, but I wouldnāt count on that because I believe we are going to have hard time in being both available at the same time.
Images are working fine now, probably my work proxy had an issue. I would agree with you regarding the Eclipse and GNU ARM toolchain thing, I already gave a try to teh GNU ARM Eclipse with no joy, but I will try again nevertheless and I suggest you do as well.
@rlogiacco, @chrisb2 & @satishgn,
as I was more occupied with my version of the Android Tinker App (using Eclipse as dev env) I have not really done a lot more fiddling with Eclipse ARM toolchain settings to get Core FW to build propperly, but now Iād like to focus a bit more on this again, so has anyone got a stable running setup to do local building in Eclipse under Windows?
If so - how?
I tried to follow all the steps from above again - including fresh Eclipse install, but no luck
Hi @rlogiacco,
thanks for your offer to help out!
I seem to be able to clean build the core-firmware with only warnings and no errors in the āProblemsā view.
But when I got into any (or almost any) .cpp in core-common-lib or some in core-communication-lib I get loads of bugs and undeclared messages in the source view and when doing āIndex -> Search for uresolved includesā I do get loads of messages telling me that Iām missing things like āerrno.hā, āstdio.hā, āwindows.hā, āvector.hā or such.
So Iām not that sure, that the build actually did work without errors.
But even if the build should have worked, Iām not to happy looking at code and working on it, when I canāt be certain whether the reported bug actually is one or is only a false positive of the IDE.
Hi @ScruffR - what kinds of false positives are you still seeing in the web IDE? Weāve made lots of improvements and have, at this point, created something very stable and usable, at least to my knowledge. If there are bugs youāre still seeing, please share so that we can correct them.
Hi @zach, sorry to give you a fright, but when I was talking about a bug, I didnāt think of some actual problem with the Core FW or your Web IDE/cloud SW, but rather a - by Eclipses IDE - falsely as bug marked code line in the firmware sources - hence āfalse positiveā (while looking for bugs in the code).
Iām absolutely happy with what you have achieved with the Web IDE - for smallish projects. But Iād still like to do some more extensive building locally with Eclipse (also used for my Android programming) - but I just canāt get my setup cleaned up to only show my own mistakes - it rather keeps complaining about errors that are no errors after all.
Yes, I have your exact same situation @ScruffR. My experience is that everything compiles just fine and it is indeed flashable on the , but there are tons of warnings on the inside and I have your exact same feeling on applying changes. The good side of the thing is that you donāt really need to touch any of the code generating false positives 99.9% of the time as that is low level code providing WiFi, cloud and serial, but I understand perfectly the sense of instability it gives you.
I havenāt found a way to have it fixed, not yet. I did ask @satishgn if he can provide some help on this as he has been indicated as having a proper working Eclipse setupā¦
Thanks @rlogiacco,
that does give me some relieve that I can dare to flash my output file.
On the other hand I had a look at the video in this thread about NetBeans and at about timeline 20:30 I stumbled over @seulater 's include paths and tried them in Eclipse, which seemd to get rid of a fair amount of problems.
It didnāt solve all of them, but at least some - I think.
I have exported my paths here:
<?xml version="1.0" encoding="UTF-8"?>
<cdtprojectproperties>
<section name="org.eclipse.cdt.internal.ui.wizards.settingswizards.IncludePaths">
<language name="holder for library settings">
</language>
<language name="Assembly">
</language>
<language name="GNU C++">
<includepath>C:\ProgramFiles\GNU Tools ARM Embedded\4.8 2013q4\arm-none-eabi\include\c++\4.8.3</includepath>
<includepath>C:\ProgramFiles\GNU Tools ARM Embedded\4.8 2013q4\arm-none-eabi\include\c++\4.8.3\arm-none-eabi</includepath>
<includepath>C:\ProgramFiles\GNU Tools ARM Embedded\4.8 2013q4\arm-none-eabi\include\c++\4.8.3\backward</includepath>
<includepath>C:\ProgramFiles\GNU Tools ARM Embedded\4.8 2013q4\lib\gcc\arm-none-eabi\4.8.3\include</includepath>
<includepath>C:\ProgramFiles\GNU Tools ARM Embedded\4.8 2013q4\lib\gcc\arm-none-eabi\4.8.3\include-fixed</includepath>
<includepath>C:\ProgramFiles\GNU Tools ARM Embedded\4.8 2013q4\arm-none-eabi\include</includepath>
</language>
<language name="GNU C">
<includepath>C:\ProgramFiles\GNU Tools ARM Embedded\4.8 2013q4\lib\gcc\arm-none-eabi\4.8.3\include</includepath>
<includepath>C:\ProgramFiles\GNU Tools ARM Embedded\4.8 2013q4\lib\gcc\arm-none-eabi\4.8.3\include-fixed</includepath>
<includepath>C:\ProgramFiles\GNU Tools ARM Embedded\4.8 2013q4\arm-none-eabi\include</includepath>
</language>
</section>
<section name="org.eclipse.cdt.internal.ui.wizards.settingswizards.Macros">
<language name="holder for library settings">
</language>
<language name="Assembly">
</language>
<language name="GNU C++">
</language>
<language name="GNU C">
</language>
</section>
</cdtprojectproperties>
Maybe you can have a look if this is any good to you too.
oops! @rlogiacco sorry I missed your earlier message. Regarding eclipse setup, I havenāt got it working since the build scripts got updated. doing command line āmakeā build ever-since.
First I did all the above, but dropped all the include paths - they will not be required.
Then I installed the GNU ARM Eclipse Plug-ins
AFTER that I imported the three core projects selecting Cross ARM GCC as ToolChain with org.eclipse.linux.org.cdt.autotools.core.toolchain.builder
Under Project Properties / Builders I moved Scanner Configuration Builder to the top (before CDT Builder)
Under Project Properties / C/C++ Build extend the Build path to e.g. ${workspace_loc:/core-firmware}/build
Under Project Properties / C/C++ Build / Settings I set the Global path as C:\ProgramFiles\GNU Tools ARM Embedded\4.8 2014q1\bin
(make sure the Prefix and C/C++ compiler enties are correct)
Add Project Properties / C/C++ General / Export Settings for the respective Workspace base paths in core-common-lib and core-communication-lib (if Export Settings is not available go to Window / Preferences / C/C++ / Property Pages Settings and tick the respective box)
Add a reference to these exports via core-firmware Project Properties / C/C++ General / Paths and Symbols / References
After that I did run a Clean and Build All and everything worked as expected (same warnings as CLI build) and almost no false positives (errors where no errors are) in any of the sourc files, but all the required ToolChain header files referenced under the Includes branch of the respective project trees.
Edit:
Some errors still seem to exist, some of which are easily solved
* missing include for bignum.h in core-communication-lib/src/handshake.h (otherwise handshake.cpp has bug marks)
* many wrong bug marks in core-firmware since core-common-lib and core-communication-lib are not yet used as Includes (still trying to solve this without manually setting the paths )
There are still some unresolvable includes
* ARMCM4.h (in core-common-lib/CMSIS/Include/arm-math.h)
* windows.h (in core-communication-lib/tests/ā¦/Win32/TimeHelpers.cpp
This is great news as you know mine bombed last week. I am out of town this week but, will try your process on my windows computer and let you know if its flying high
Hey everyone. I feel like I am really close to having Eclipse setup. I am able to flash to the module but Make appears to be failing. I get make: arm-none-eabi-gcc: No such file or directory as an error on my build. Says build finished and I flash but since the new make didnt happen i just keep flashing the same firmware back into the controller. Any ideas?
-What toolchain/Eclipse versions are you on?
I am using Eclipse Kepler.
Using Cross GCC toolchain as suggested.
-Have you got a toolset to āsubstituteā Windows rm and mkdir versions (e.g. like the Git tools)?
I am actually running on mac but can make rm and mkdir calls from terminal no problem.
-Have you set out PATH to allow make to find the toolchain and toolsets?
Honestly not sure on this one. Make does work through terminal but not sure how to tie it to a particular tool chain in eclipse
-Have you seen the warning not to use āC:\Program Files (x86)ā for the toolchain/toolset?
Being as I am on a mac no. Also have not seen a similar error to this. Would this come up in the console log in eclipse when performing build?
-Can you run a manual make by going into \spark-firmware\build and run make from the command line?
Yes, I have performed a make in the terminal successfully.
-Can you provide a more verbose copy of the make output messages?
Do you want the output from the terminal when performing make there? Or in Eclipse? Here is my output in Eclipse when performing build:
17:03:18 **** Incremental Build of configuration Default for project core-firmware ****
make all
Building core-common-lib
make[1]: Nothing to be done for `all'.
Building core-communication-lib
make[1]: Nothing to be done for `all'.
Building file: ../src/application.cpp
Invoking: ARM GCC CPP Compiler
mkdir -p obj/src/
make: arm-none-eabi-gcc: No such file or directory
arm-none-eabi-gcc -g3 -gdwarf-2 -Os -mcpu=cortex-m3 -mthumb -I../inc -I../libraries/Serial2 -I../../core-common-lib/CMSIS/Include -I../../core-common-lib/CMSIS/Device/ST/STM32F10x/Include -I../../core-common-lib/STM32F10x_StdPeriph_Driver/inc -I../../core-common-lib/STM32_USB-FS-Device_Driver/inc -I../../core-common-lib/CC3000_Host_Driver -I../../core-common-lib/SPARK_Firmware_Driver/inc -I../../core-common-lib/SPARK_Services/inc -I../../core-communication-lib/lib/tropicssl/include -I../../core-communication-lib/src -I. -ffunction-sections -Wall -fmessage-length=0 -Werror=deprecated-declarations -MD -MP -MF obj/src/application.o.d -DUSE_STDPERIPH_DRIVER -DSTM32F10X_MD -DDFU_BUILD_ENABLE -DSPARK=1 -DRELEASE_BUILD -fno-rtti -fno-exceptions -c -o obj/src/application.o ../src/application.cpp
make: *** [obj/src/application.o] Error 1
17:03:18 Build Finished (took 166ms)
That seems odd.
Since you can make from terminal, could you have a look what make reports there after Invoking: ARM GCC CPP Compiler
Maybe this will give a clou what file/directory canāt be located.
Or you could look in the makefile what the next steps would be and why it fails.