User Tools

Site Tools


microcontrollers:avr_ides_for_linux

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
microcontrollers:avr_ides_for_linux [2012/01/26 22:56] mithatmicrocontrollers:avr_ides_for_linux [2012/09/17 22:16] (current) – [AVR IDEs for Linux] mithat
Line 3: Line 3:
 :!: //While I have spent good chunks of time experimenting with the tools listed below, I have yet to develop anything like a non-trivial AVR---or any other microcontroller---project on any of them. So take it all with salt.// :!: //While I have spent good chunks of time experimenting with the tools listed below, I have yet to develop anything like a non-trivial AVR---or any other microcontroller---project on any of them. So take it all with salt.//
  
-Some quick notes on some options I've investigated. No matter what, it seems that learning the toolchain's individual tools and the commands they offer is inescapable.+Here are some quick notes on some options I've investigated in alphabetical orderThe more I investigate the available IDEsthe more it seems that learning the toolchain's individual tools and the commands they present is inescapable.
  
 Executive summary (at this moment): If you are willing to run Java and deal with some intense resource demands, [[#eclipse|Eclipse CDT]] with the [[#AVR Eclipse plugin]] is quite good.((See the updates in [[#Eclipse]] below regarding debugging issues.)) [[#Geany]] plus some extra foo works for a very slim but usable setup. For something between these two extremes, [[#CodeBlocks]] is a good choice.((See the update note in [[#CodeBlocks]] below for a spook though!!!))  Executive summary (at this moment): If you are willing to run Java and deal with some intense resource demands, [[#eclipse|Eclipse CDT]] with the [[#AVR Eclipse plugin]] is quite good.((See the updates in [[#Eclipse]] below regarding debugging issues.)) [[#Geany]] plus some extra foo works for a very slim but usable setup. For something between these two extremes, [[#CodeBlocks]] is a good choice.((See the update note in [[#CodeBlocks]] below for a spook though!!!)) 
Line 9: Line 9:
 ===== CodeBlocks ===== ===== CodeBlocks =====
  
-//:!: **Update (2011-01-16)**: CodeBlocks' build system for AVR development seems to be broken in Debian Wheezy. I managed to find a fix and wrote it up on [[http://lovingthepenguin.blogspot.com/2012/01/fixing-codeblocks-avr-build-problems-on.html|one of my blogs]]. It's really not too horrible as you only have to do it once.//+//:!: **Update (2011-01-16)**: CodeBlocks' build system for AVR development seems to be broken in Debian Wheezy. I managed to find a fix and wrote it up on [[http://lovingthepenguin.blogspot.com/2012/01/fixing-codeblocks-avr-build-problems-on.html|one of my blogs]]. It's really not too horrible as you only have to do it once per profile.//
  
 //:!: **Update (2011-01-21)**: Integrated debugging remains elusive. Another reason to use Makefiles w/CB (similar to the one used in my Geany stuff).// //:!: **Update (2011-01-21)**: Integrated debugging remains elusive. Another reason to use Makefiles w/CB (similar to the one used in my Geany stuff).//
Line 17: Line 17:
 Code completion is pretty good; completions popup automatically or with Ctrl-Space; calltips are available w/ Ctrl-Shift-Space. When you set up an AVR project, make sure to add ''/usr/lib/avr/include'' to //Project > Properties... > C++ parser options//. This will let the autocomplete engine pick up on all the AVR stuff? Code completion is pretty good; completions popup automatically or with Ctrl-Space; calltips are available w/ Ctrl-Shift-Space. When you set up an AVR project, make sure to add ''/usr/lib/avr/include'' to //Project > Properties... > C++ parser options//. This will let the autocomplete engine pick up on all the AVR stuff?
  
-==== Using the built-in AVR template ====+==== Using the built-in AVR project template ====
  
 Some cautions: Some cautions:
-  * The standard CB AVR project doesn't appear to integrate support for chip programming (e.g., ''avrdude''). You'll need to set this up as an external tool and/or use a Makefile or similar external script/build tool.+  * The standard CB AVR project doesn't appear to integrate support for **chip programming** (e.g., ''avrdude''). You'll need to set this up as an external tool and/or use a Makefile or similar external script/build tool.
   * How to change the **MCU** and **clock frequency** used isn't that intuitive.   * How to change the **MCU** and **clock frequency** used isn't that intuitive.
     * **MCU**: //Project > Build options... > Compiler settings > Compiler flags// (scroll down to the middle) **and** //Project > Build options... > Linker settings > Other linker options://     * **MCU**: //Project > Build options... > Compiler settings > Compiler flags// (scroll down to the middle) **and** //Project > Build options... > Linker settings > Other linker options://
     * **Clock frequency**: //Project > Build options... > Compiler settings > #defines//     * **Clock frequency**: //Project > Build options... > Compiler settings > #defines//
  
-There doesn't appear to be a convenient way to ask CB for the MCU type and clock speed. This means that any external scripts developed to fill in the holes (debugging and programming) will require redundant entry of information---leading to a host of possible problems. So despite the platform-independence and apparent ease of using the CB build system, maybe going with a Makefile based setup is in the long run a better option.+Any external scripts developed to fill in the holes above (debugging and programming) will require redundant entry of information---because there doesn't appear to be a convenient way to ask CB for the MCU type and clock speed. This could lead to a host of possible problems in use. So despite the platform-independence and apparent ease of using the CB build system, maybe going with a Makefile based setup is in the long run a better option.
  
 ==== Setting up a CB AVR project that uses a Makefile ==== ==== Setting up a CB AVR project that uses a Makefile ====
Line 128: Line 128:
 Geany is awesomely lightweight, and its project support seems reasonably well-suited to Makefile-based projects. Geany is awesomely lightweight, and its project support seems reasonably well-suited to Makefile-based projects.
  
-Geany's biggest problem is that code completion is based only what is open and some basic language-specific stuff. It's other problem is that it really is basically an editor plus stuff tacked on to give it some mojo. I've put together a [[https://bitbucket.org/mithat/avr-geany-support/overview|small bundle]] (still quite beta however) that leverages that mojo and turns Geany into a reasonably credible, Makefile-enabled "almost IDE" for AVR development. Debugging with ''simulavr'' (using the hideous but effective [[https://www.gnu.org/software/ddd/|DDD]] for the debugger interface) is pretty easy to make go and seems to work as expected in this setup.+Geany's biggest problem is that code completion is based only what is open in the editor and some basic language-specific stuff. It's other problem is that it really is basically an editor plus stuff tacked on to give it some mojo---so by itself it won't solve your build and MCU programming woes without some help. I've put together a [[https://bitbucket.org/mithat/avr-geany-support/overview|small bundle]] (still quite beta however) that leverages Geany'mojo and turns it into a reasonably credible, Makefile-enabled "almost IDE" for AVR development. Debugging with ''simulavr'' (using the hideous but effective [[https://www.gnu.org/software/ddd/|DDD]] for the debugger interface) is pretty easy to make go and seems to work as expected in this setup.
  
-Even with the bundle above, Geany still doesn't parse files referenced in the file you're editing for autocomplete symbols---meaning that local header files will need to be open if you want things defined in those to be autocompleted. The only workaround to this that I can think of is to have all the headers that are part of your project open during the session. Geany also won'give any refactoring goodness---but the search/replace support is quite good.+Even with the bundle above, Geany won't parse files referenced in the file you're editing for autocomplete symbols---meaning that local header files will need to be open if you want things defined in those to be autocompleted. The simplest workaround to this that I can think of is to have all the headers that are part of your project open during the session. Geany doesn'have any refactoring goodness---but the search/replace support is quite good.
 ===== Netbeans C/C++ ===== ===== Netbeans C/C++ =====
  
-//:!: **Update (2011-01-20)**: As was the case with Eclipse, I can't get debugging with ''simumavr'' to work with Netbeans. I get the same "debugger doesn't repsond to 'run'" message, and I can't find a way to turn the autorun off. However, unlike Eclipse, Netbeans has a very convenient way of opening up a shell right in the IDE, from which ''make gdbinit'', ''make simulavr'', and ''make [[https://www.gnu.org/software/ddd/|ddd]]'' (which you have thoughtfully put in your makefile, right?) can easily be invoked. So, a plus for Netbeans.//+//:!: **Update (2011-01-20)**: As was the case with Eclipse, I can't get debugging with ''simumavr'' to work with Netbeans. I get the same "debugger doesn't repsond to 'run'" message, and I can't find a way to turn the autorun off. However, unlike Eclipse, Netbeans has a very convenient way of opening up a shell right in the IDE, from which ''make gdbinit'', ''make simulavr'', and ''make ddd'' (which you have thoughtfully put in your makefile, right?) can easily be invoked. So, a plus for Netbeans.//
  
 It's something of a tossup between Netbeans w/C++ and Eclipse CDT. Both have about the same intense hunger for resources, both have really excellent code completion, both can be configured for Makefile-based builds, both can be directed to additional includes on a per-project basis so autocompletion and tooltips work as expected, both support some C/C++ refactoring. It's something of a tossup between Netbeans w/C++ and Eclipse CDT. Both have about the same intense hunger for resources, both have really excellent code completion, both can be configured for Makefile-based builds, both can be directed to additional includes on a per-project basis so autocompletion and tooltips work as expected, both support some C/C++ refactoring.
Line 141: Line 141:
 ===== No IDE ===== ===== No IDE =====
  
-Use a text editor, a terminal emulator, and a Makefile. Clean. Minimal. Hardcore. This is actually so frightfully close to the [[#Geany]] setup above that you may as well reference that. +Use a text editor, a terminal emulator, and a Makefile. Clean. Minimal. Hardcore. This so frightfully close to the [[#Geany]] setup above that you may as well reference that. 
  
 ===== Qt Creator ===== ===== Qt Creator =====
microcontrollers/avr_ides_for_linux.1327618600.txt.gz · Last modified: 2012/01/26 22:56 by mithat

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki