Understanding the build process and IDE internals

I'd like to extend the IDE so it can support development for other AVRs, such as the ATTiny series, using direct programming. To this end, I've been working through the source code trying to understand what things need to be modified to make this work. However, I've run into some snags:

  1. Some of the code seems a bit hardwired in ways that tend to lock it into the ATMega series of processors. For example, this code from AvrdudeUploader.java.
    commandDownloader.add("-pm" + 
      Preferences.get("boards." + Preferences.get("board") + ".build.mcu").substring(6));

would need to be modified to so it can set a "-pt45" switch instead of a "-pm168" switch.

  1. Honestly, I'm still confused by where all the various pieces come from and how they get put together to create the final build.

So, I just thought I'd ask if anyone else has experience in trying to work out all these details and can offer any shortcuts, or advice?

Wayne

There are some details here: Redirecting. Patches are welcome to make the build process more flexible.

Just my opinion, but I think it is asking too much of the arduno environment. How do you do a bootloader on an attiny? AttachInterrupt? The analog/pwm pins will all be off too.

If you are Dependant on arduino ide then I think it is ok to be dependant on atmega. If the few extra dollars for an atmega are going to add up then time to learn avrdude/avrstudio or or?

Maybe you have to start with a atttimy schematic and compare it to an arduino to see if it looks anything like an arduino anymore.

Just my opinion, but I think it is asking too much of the arduno environment.

I see your point, and I would definitely agree that it's too much to support every AVR.

However, it would be nice to have one of the small ones supported, for low intensity projects that don't rate a full Arduino.

How do you do a bootloader on an attiny?

Don't bother - as of 0012, the IDE can burn directly with a programmer.

Other issues like the interrupt functionality could be addressed with compiler directives that would make the program fail to compile.

Some folks are making good progress on integrating a larger ATmega (the 644), and hopefully one day it will be advanced enough for the Arduino team to consider official integration with the project. It's entirely reasonable for an ATtiny to get there eventually. Like any open source project, it's a matter of someone wanting it badly enough. :slight_smile:

-j

Well, the 644 can do everything the 168 can do, as can the 328. And they all could do what the mega 8 could do, so there isn't any loss of functionality with the newer chips in the current evolutionary path. But explaining to people why pulsein stopped working or complicating the instructions and playground with a lot of statements about "if you have an attiny..." will be a source of issues as well.

I think it is a lot of work for everyone for a backwards step in functionality. And requiring a programmer will eat in to the cost savings of the attiny, so why are we considering this? Getting a reliable programmer working is not a trivial task in my experience, unless you want to assume linux on top of everything.

I should ask why attiny support? What does one hope to gain by adding it to the ide? atmega8s are pretty dang cheap and process circles around any of the tiny series.

I guess the main issue is that it is a fair bit of work to

  1. get programmers working
  2. pepper the existing examples and playground with explanations about why certain functions/pins won't work if you have an attiny something.
  3. not actually save any money once you factor in the time and expense of getting an external program working

I spent half a day getting my tinyusb working on my pc, never got the parallel one working, though it worked sometimes on the laptop. Loading the ftdi driver and plugging in the cable is orders of magnitude easier, and we still have to help folks out with that sometimes.

But I can see a case for improving the isp programming experience in arduino, 2k of flash can be a steep price to pay. But I can't see crippling the core arduino built ins conditionally to save a couple bucks on hardwares in what is largely considered a "beginners" environment.

So, I respectfully disagree, but I don't agree that it is entirely reasonable. There is nothing you cannot do with an atmega that you can do with an attiny, and the price difference isn't significant, but the support costs are.

I should ask why attiny support?

  • cheaper
  • smaller (DIP-8 vs. DIP-28)
  • simpler (no crystal, etc)
  • etc...

A better question may be "Why not?"

For some projects, the mega8 is already overkill; the 328 and 644 even more so. For some projects all you need is 3 or 4 I/Os. Sometimes 4k is enough program space. Sometimes it's nice to build a circuit around an 8 pin device instead of a 28 pin device (or 40 pin 644). The Arduino IDE grants easy access to a growing library of code and examples; it would be nice to tap that resource for smaller projects.

atmega8s are pretty dang cheap and process circles around any of the tiny series.

The Tinys are cheaper, and are as fast or faster than the original mega8.

Nobody is talking about crippling the arduino core to support the Tiny, just discussing the possibility of adding support for it.

-j

Why not? Why not use avrstudio for non arduino hardware? The single step simulator/debugger is awesome. You can look at almost every transistor on the chip at any point during execution with the tools. I think people have to get out from under arduinos wing sooner or later if they are going to get that serious about embedded development.

Why reduce arduinos functionality?

use case 1:
guy goes to playground with atmega8, wants to do pwm, reads about the 6 pwm pins, doesn't know what attiny means or if it applies to him, scratches head and curses arduino for overcomplicating things.

use case 2:
guy reads all about this LCD library, spends a couple days figuring out that it is impossible to use with his attiny. Curses arduino for overcomplicating things.

  • cheaper
    not when you factor in external programmer costs and headaches. And the cost of making the changes plus documentation changes plus library changes and producing the hardware and getting everyone to agree on a standard pinout AND agreeing on which chips to support. You are probably looking at 1500 man hours of work over the next year (frustrated users time included) if we try to do too many things with arduino ide will cause.

It is not cheaper, you have to be in "production" for it to be cheaper. It is a lot of work, I put some value on peoples time. You are looking at $75,000 worth of effort just for the next year.

  • smaller (DIP-8 vs. DIP-28)
    other really good IDEs support it already. The lack of pins is a liability in the arduino ide. You don't have to reinvent any schematics.

  • simpler (no crystal, etc)
    atmega8 can run w/out crystal also, but I expect you knew that.

  • etc...
    etc... :wink:

Lets look at cost a little more closely:

from mouser:
ATTiny45
1@$2.13 100@1.24

ATTiny2313
1@$2.26 100@1.31

atmega8
1@$3.36 100@$2.13

So in quantity, they are less than a dollar apart, the major difference is that the atmega8 is %100 arduino love, the tinys are a hypothesis with a fair bit of work behind them for far less pins and functionality than the atmega.

The tiny's do allow a bootloader, but they are so short on ram/flash that many libraries wont fit. So there might not be as much reuse opportunity as you think either.

so to do a lot of work to save 80 cents on the chip and give up a bunch of io and libraries and easy for beginners bootloader path? Sorry, but I can't see why anyone would want to. You would have to be planning on selling 90,000 boards at atmega8 prices to make up the time investment.

I think cost is moot. As is arduino library reuse to a large degree.

I think the only thing left is the form factor, and the smd atmega devices provide an option there.

But again, I would definitely like to see better support for isp. Getting started with uploading with an isp is no where near as easy as with the bootloader.

I think there needs a standard recommended isp uploader, that can be built with either a ftdi chip (serjtag?) or another arduino and a pde file and get all the kinks worked out of it on all platforms. And make it a menu item.

Also worth noting that using gcc for a ram challenged device like some attiny has been dubbed "abuse" :slight_smile:
http://www.lightner.net/avr/ATtiny/projects/README.txt

So in quantity, they are less than a dollar apart

Or, looking at in another way, the mega8 costs over 50% more than the tiny45. :slight_smile: Seriously, cost is not a huge part of the issue.

The 8 pin form factor (or even 20 pin tiny2313) is non trivial, especially if you are hand building a one-off project that you want to make a) small and b) quickly. I challenge you to hand solder a 32 pin TQFP in the same time as an 8 pin DIP or SOIC. I think physical size is the real advantage to the ATtinys.

As far as AVRstudio goes, I'll start using it when they port it to OS X (or linux or Solaris).

It took about 5 minutes for me to configure arduino 0012 to program a mega168 with my avrispmkii from within the IDE (nice feature, BTW). I expect this functionality will be in the default configuration in the next release (not sure why it isn't there now).

If there is a standard minimum recommended programmer, it should be the AVRispmkII. US$35 is not an unreasonable price. I could probably be convinced that LadyAda's programmer is an appropriate "arduino standard programmer" because of the cheaper price tag. The parallel is out of the question as far as I'm concerned, as the few computers that have a parallel port still may not be compatible with that design.

IMO the only down side is development cost.

-j

Hmm, hoping for answers I, instead, get questions back. So, where to start...

I should have specified that I have already reviewed the "Build Process" page, but thanks for the suggestion, in any case. I also should have noted that I'm using the Arduino IDE on a Mac (G5, not an Intel, so I can't run ACR Studio using Boot Camp, or Parallels), which partially answer some of the "why" questions. I realize that it hardly makes sense to use a bootloader on these smaller devices, which is why I stated in my original post that intended to use "direct" programming (I use the AVR ISP MKII.) Perhaps I should have been more specific so as not to confuse those that didn't pick on this.

Also, I rather admire the way the Arduino IDE has simplified the process of writing embedded code. Before discovering Ardunio, I'd worked quite a bit with C on the PIC chips and frequently used the smaller pin versions in projects where space is at a premium. So, I wanted to investigate how hard it might be to support the smaller ATTiny chips, as the documentation suggested that the IDE was designed with the intention of supporting other chips. Honestly, it rather surprises me that some of you seem to feel that a few bucks, or a few pins hardly matter, so why not just use an ATMega. I guess the only answer I can give is that it matters to me, otherwise why would I spend the time to pursue this? Ultimately, I'd like to find a way to contribute somethings back to the Arduino project and I figured this might be a way to do this, as well as to start learning about how all the internals work.

Wayne

I'm all for it. I like the idea of taking the arduino "experience" and making it available for attiny. If you only need a couple of pins, why use a mega? It does seem like a waste.

The Arduino environment (just the edit/download/monitor stuff, not even including the libraries) seems elegantly simple enough that I was also thinking along the lines of modifying it to allow arbitrary programs to be executed for the compile and download phases (along with a bit of formality about where to put things, how to set them up, and how to return errors.)
Among other advantages, this would allow the use of commercial compiler suites for all sorts of non-AVR cpus... (I guess that theoretically, it would reduce the effort required for new CPUs to a configuration file and some libraries to "fully" support the arduino toolset.)

On the other hands, this might be a rather large can of worms better left unopened...

FYI, if you just want a replacement for avrstudio for non-windows, there are other options:

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=41478

more avr IDEs
http://www.scriptforge.org/2008/05/avr-8bit-ides-and-freertos/

I'm a big fan of eclipse, runs anywhere, and you get a real nice java development environment out of the deal with it, but no c++ debugging/simulating.

vmlab looks like windows target, but they have a special wine page:
http://www.amctools.com/wine.htm

I'm a big fan of EMACS, and I could probably re-write the arduino environment as a set of EMACS extension functions, but that wouldn't make the resulting tool a good choice for beginners... :slight_smile: I don't think Eclipse is for beginners, either!

Well, it may well be that there is a market for an arduinito. I just wouldn't try and integrate it with the arduino offerings.

Yay emacs! I've been using emacs (and my custom bindings and perosnal collection of elisp functions) for 20-something years now.

That more or less summarizes the whole thing for me: I can use C and emacs and write makefiles, but the Arduino suite (IDE, library, hardware) makes the whole microcontroller thing so nice and neat that I don't want to mess with doing it the other way.

-j

I would also be interested in something as simple as the Arduino environment for some attiny chips. For me, the goal is also size (and inability to solder surface mount packages).

I want to make a keyfob wireless transmitter. The ATMEGA168 may fit (I should have the case in a few days). The ATTINY45 would be far better.

I understand the limitations (fewer data pins, needing an AVR programmer) but it would still be nice to be able to do all the work within the Arduino environment, without having to worry about all the other code overhead. Just setup() and loop()...

We are using an attiny84 in our project. This chip has a much smaller footprint than the atmega168. Compared to other attiny chips it has many I/O pins and 'a lot' of sram, flash and eeprom.

It took some work but now the attiny84 can be used with our modified Arduino IDE. Almost all sketches and libraries that run on the Arduino will also run on our LumiNet.

If you are interested in our Arduino port to the attiny84 you might want to check out this thread as well:
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1236434254