Differences

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

--- microcontrollers:linux_microcontroller_development_options [2012/01/15 16:00] – [Atmel AVR] mithat
+++ microcontrollers:linux_microcontroller_development_options [2013/08/23 20:33] (current) – mithat
@@ Line 1: / Line 1: @@
 ====== Linux microcontroller development options ======
-:!: // This page is under development and is deeply clouded by the author's lack of experience with any of the tools mentioned.//
+:!: // This page is under development.//
 When it comes to microcontroller development platforms, Windows gets almost all the love. There are tons of commercial, gratis, and FOSS tools for Windows to support microcontroller development as well as the peripherals often associated with embedded design (e.g., [[http://www.digi.com/xbee/|Xbee]] cards).
@@ Line 8: / Line 8: @@
 ===== 8051 =====
-The 8051-family of devices' main advantage seems to be that unlike the other devices discussed here, 8051-based chips are not single-sourced.
+The main advantage of the 8051-family of devices seems to be that unlike the other devices discussed here they are not single-sourced.
 A fairly comprehensive package for 8051-family devices is available in the [[http://mcu8051ide.sourceforge.net/|MCU 8051 IDE]]. It provides a simulator, source code editor, assembler, programmer and other tools. It uses [[microcontrollers:linux_microcontroller_development_options#SDCC|SDCC]] for C language support.
@@ Line 32: / Line 32: @@
 Arguably, the microcontrollers with the best Linux support are the Atmel AVR series.
-Atmel provides a [[http://www.atmel.com/dyn/products/tools_card.asp?tool_id=17311&category_id=163&family_id=607&subfamily_id=760|toolchain for Linux]] where, "Several of the tools are based on tools from GNU (www.gnu.org), and some are developed by Atmel." Source code for this appears to be available, but I have not yet looked at the licensing terms to see if it's actually FOSS.
+Atmel provides a [[http://www.atmel.com/tools/atmelavrtoolchainforlinux.aspx|toolchain for Linux]] where, "Most of these tools are based on efforts from GNU (www.gnu.org), and some are developed by Atmel." Source code for this appears to be available, but I have not yet looked at the licensing terms to see if it's actually FOSS.
 An alternative to the bundle provided by Atmel is a "classic" toolchain that is made up of:((see: [[http://probing.wikidot.com/atmega-linux-tutorial]], [[http://pramode.net/articles/lfy/atmega8/pramode.html]], [[https://ariandy1.wordpress.com/2010/03/21/avr-atmega-and-ubuntu-linux/]], http://blog.isuru.net/?p=47))
@@ Line 42: / Line 42: @@
   * [[http://avarice.sourceforge.net/|AVaRICE]]: interface GDB debugger with the Atmel's AVR JTAG ICE.
   * [[http://www.nongnu.org/simulavr/|simulavr]]: simulator
+:!: The exact differences between the toolchain provided by Atmel and the "classic" toolchain are astoundingly opaque. Very little information on the Atmel-provided set is available outside of the Atmel site, suggesting that it may not be used that much in the wild.
 An [[http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin|AVR Eclipse Plugin]] supporting the above is also available if you want an IDE experience. Best part: "With this Plugin you don't have to hassle with makefiles any more. The makefiles for building your application are automatically created."
-AVR on Linux's biggest issue seems to be simulation support. The [[http://www.nongnu.org/simulavr/|simulavr]] project seems to be in a state of limbo and/or transition at the moment. While there appears to be some activity in the project, there have been no new releases in years and AFAICT the most recently available sources (from 2005) are not the most recent release! Also, the available release(s) seem to support a fairly narrow range of microcontrollers.
+AVR on Linux's biggest issue may be simulation support. The [[http://www.nongnu.org/simulavr/|simulavr]] project seems to be in a state of limbo, transition and/or chaos at the moment. While there has been some recent activity in the project, there have been no new releases in years and AFAICT the most recently available sources (from 2005) may not actually be the most recent release! Also, the available release(s) seem to support a fairly narrow range of microcontrollers.
-:!: The exact differences between the toolchain provided by Atmel and the "classic" toolchain are astoundingly opaque. Very little information on the Atmel-provided set is available outside of the Atmel site, suggesting that it may not be used that much in the wild.
 ==== Debian packages ====
@@ Line 67: / Line 68: @@
 ==== Programmer hardware ====
-There are several commercial and DIY implementations of AVR programmers available. However, I see little reason not to use the official USB-based [[http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3808|AVRISP mkII programmer]]---at least as a starting point. It's inexpensive and is [[http://www.nongnu.org/avrdude/user-manual/avrdude_1.html|supported by avrdude]].
+There are several commercial and DIY implementations of AVR programmers available. However, I see little reason not to use the official USB-based [[http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3808|AVRISP mkII programmer]]---at least as a starting point. It's inexpensive and is [[http://www.nongnu.org/avrdude/user-manual/avrdude_1.html|supported by avrdude]]. Another AVR-sourced alternative to consider is the AVR Dragon---which appears to be both a programmer and an ICE interface for debugging.
 To maximize the FOSS spirit, you may prefer an open-hardware design. The [[http://dicks.home.xs4all.nl/avr/usbtiny/|USBtinyISP]] is one such alternative, and Lady Ada packages a [[http://www.ladyada.net/make/usbtinyisp/|promising kit]] based on this design with some modifications. My biggest concerns with using a third-party programmer are that it introduces a layer of uncertainty in the development process ("Does it not work because my code is foobared or because the programmer isn't working?") and compatibility for new target devices will be less likely than with the official AVRISP mkII programmer.