CodeLite IDE

I have been using codelite for AVR development for two year now, and mostly it's been working okay. But since moving to a new Win7 machine having some issues.

One:
I'm using the latest release of WinAvr which is based on cygwin. Unless I rename WinAVR's version of sh.exe to something like sh_nope.exe I get errors like...

/usr/bin/sh: /c/WinAVR-20100110/bin/avr-gcc: Invalid argument

Which I take is some incompatibility between the older sh.exe in WinAvr and the shell expected by codelite. (Note WinAVR is about two years old at this point). What is odd is I have a work space with a couple of different projects and some of them suffer this an some don't. Very odd.

Two:
I tried using the latest version of codelite on my home machine (also win7) and I get similar errors when trying to compile a simple program. This is actually the most annoying, you expect a vanilla install to just work.

Three:
For WinAVR I have to create a custom compiler option. Which is okay. But when I upgrade to the new version of codelite, the configuration file gets overwritten. And all the projects get converted to use VC++. I have to recreate the custome compiler for WinAVR and then update the settings on my projects. Makes me a bit unhappy. It would be nice if it didn't do that, or if there was a way to copy an existing compiler and 'tweak it' since WinAVR is essentially just gcc with the same options etc.

Four:
Sometimes when swapping projects between machines, the compiler setting gets switch back tot he default (VC++). Not the end of the world, but another annoying thing.

Otherwise I've been happy with codelite. It would be nice to see it get used for embedded stuff more. (I think no one is happy with Eclipse, and in AVR land people very unhappy with Atmels switch to Visual Studio)

Gibbon1 wrote:One:
I'm using the latest release of WinAvr which is based on cygwin. Unless I rename WinAVR's version of sh.exe to something like sh_nope.exe I get errors like...

/usr/bin/sh: /c/WinAVR-20100110/bin/avr-gcc: Invalid argument

have you tried setting the SHELL environment variable to SHELL=CMD.EXE ?

Gibbon1 wrote:Which I take is some incompatibility between the older sh.exe in WinAvr and the shell expected by codelite.

codelite does not use any shell, it is supposed to work with pure cmd.exe

Gibbon1 wrote:Sometimes when swapping projects between machines, the compiler setting gets switch back tot he default (VC++). Not the end of the world, but another annoying thing.

Are your .project files under source control? make sure that when you do 'svn up' or the equivalent of your source control tool, Reload the workspace

Gibbon1 wrote:I have to recreate the custome compiler for WinAVR and then update the settings on my projects. Makes me a bit unhappy. It would be nice if it didn't do that

I am in the process of changing the compilers configuration - one of the reasons I am changing that is because of this exact problem: old configuration are overwritten whenever I change something.

For your particular problem about codelite 5.0: I did a major change where I moved the 'make' command from a global setting to become part of the toolchain defined by each compiler
Maybe a good idea is to set a SHELL as part of the toolchain as well.

Eran

Setting the

Path environment variable under Build Settings --> Compilers --> Tools to

$(PATH); SHELL=CMD.EXE

made the problem with the cygwin shell issue with WinAVR-20100110 go away. (Rename it from sh_nope.exe to sh.exe and the compile error goes away)

PS: A suggestion for Build Settings would be a tool path option in addition to being able to copy an existing compiler setting. Then you could add a new compiler by copying the existing gnu gcc compiler and change the path to point to a different compiler. (I do embedded cross compiling all the time, so it's nice to be able to invoke the exact compiler I want)

@Gibbon1

Do u use CodeLite only to compile your project or also to debug your code through the GDB Debugger over JTAG?

I was thinking to try to create a project for ARM Cortex-M3 development, usually no problem to compile but could be critical using the GDB Debugger with JTAG

I've been mostly doing AVR development. Writing code in codelite and debugging with AVR Studio.

I have used codelite for ARM development and was able to download and run code, but wasn't able to get it to break. Might have been the cheap Olimex Jtag dohicky I was using. I was using a dev kit from http://www.bertos.org/ they have an open source kernel + plus a lot of drivers and provide support with codelite for a small fist full of Euro's. I needed something fast, so I punted and debugged via printf.

PS: If you can get ARM development working with GDB and Eclipse, you aught be able to get it working with codelite.

Yes, after many years with IAR, I am actually using Eclipse + GDB + OpenOCD with various JTAG interfaces. It works but Eclipse CDT is cpu demanding, sometimes it hangs for few seconds and this is quite annoying. Plus the setting options are too many, so I was looking for a simpler, no java, IDE. Will do some experiments in the incoming weeks. Thank you.

After using programmers note pad, I tried Eclipse and had similar issues you report. Unhappy with it being a dog, especially when running under linux on a virtual machine. Slogged along for six months and then the new version of Eclipse came with a broken CDT tool, and I bailed on it.

The two options that I found were codelite and code:blocks. My impression is both would be a good platform for embedded development. In particular it would be nice to get a bundled version of codelite with avr-gcc that just works, since Atmel has switch to Microsoft Visual Studio as their platform (no one is happy with that)