Eclipse IDE on Windows

@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:

/core-common-lib/SPARK_Firmware_Driver/inc
/core-common-lib/CMSIS/Device/ST/STM32F10x/Include

I suspect we need to add yet more, as there are many inc/include directories in the 3 projects.

UPDATE2 - now the errors are back - not sure whats going on!

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 :frowning:

@ScruffR I have my Eclipse setup decently, but not completely right: I still have some errors if I dig into the dependency projects.

So far my setup has been documented on my blog http://rlogiacco.wordpress.com/2014/01/25/the-sparkcore-makers-meet-the-cloud/

Where do you get stuck? What is not working for you?

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 :spark:, 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.

I finally got my Eclipse setup clean - yea! :smiley:

If anybody likes to know:

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 :wink: )

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

@ScruffR,

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 :smile:

Then its time to take a knife to Tinker App :wink:

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?

Thanks

Hi @IOTrav, since your problem description is quite brief, some questions:

  • What toolchain/Eclipse versions are you on?
  • Have you got a toolset to ā€œsubstituteā€ Windows rm and mkdir versions (e.g. like the Git tools)?
  • Have you set out PATH to allow make to find the toolchain and toolsets?
  • Have you seen the warning not to use ā€œC:\Program Files (x86)ā€ for the toolchain/toolset?
  • Can you run a manual make by going into \spark-firmware\build and run make from the command line?
  • Can you provide a more verbose copy of the make output messages?

Hi @ScruffR

Thank you very much for taking the time to reply.

-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.