AVR BUTTERFLY Q&A FAQ

PROGRAMMING VIA THE UART:

I want to use a Butterfly developpment kit for a school project. After surfing the web for sevral hours, I still haven't found the best way to download code to it. I found sevral places that suggest using the ISP headers and others that suggest using the UART with the included bootloader.

Could someone explain to me what would be the best way to proceed? And also, what software should I use to download my program?

P.S. I really don't care if I need to erase the demo program that comes with the butterfly

P.S.S. I need to use a "free" cable to hook up the butterfly to my computer. I really can't afford anything else.

QUOTE

You can use the bootloader or the AVR ISP cable. If you are going to use the ISP (In System Programming) header you can make a cable that connects to your parallel port for $1 probably. The ISP headers are the direct interface to the memory of the AtMega169.

To use the the bootloader you need a serial cable (DB9 connector on one end). See the description in the user manual at http://www.atmel.com/dyn/resources/prod ... oc4271.pdf in section 3.7. The bootloader is pretty easy to use, as it is a program that runs on the Mega169 in a special section of memory, that loads the data into the application section.

Using a bootloader you cannot change the bootloader section or fuses, which is good and bad. And you may already have a serial cable around which will work. Check the user manual section 2.4.1 where it talks about using the bootloader.

BUTTERFLY CLOCK SPEED:

I want to use the UART on my butterfly. It seems that I need the exact clock speed of my CPU to do that. Unfortunately, I have not been able to find it after searching on the web... Could somebody help me on this please??

QUOTE

The Butterfly uses the internal oscillator as the processor clock, else has an external crystal 32.768khz for the RTC,

On power up OSCCAL is adjusted to 1mhz using the external clock crystal ,
you may want to have a look at "OSCCAL_calibration()" function in the file "main.c". At 1 mhz only baudrate 2400, 4800 and 9600 are possible with and error of .2%, any other baud rate have a large error.

with some manipulation (OSCCAL and prescaler) you may be able to get close to 1.8432mhz, this will give you any baud rate from 2400 to 230.4k.

USING BUTTERFLY UART:

I am trying to use the butterfly UART to send charachters to a PC. I have made a simple 3 wires cables as explained by the doc. As I understand it, I should not need any additionnal hardware, such as a MAX232.

I have tried numerous librairies that claim to support UART on virtually all AVR chips. However, I have yet to find one that works. That seems to be because the registers for the UART on the mega169 wich the butterfly uses are named differently from the other AVRs(ex: UDR is UDR0).

QUOTE

If you use the calibration routine used in the Butterfly you can communicate from 2400, 4800 and 9600 bps only, the internal clock is adjusted to 1mhz;
you need to modify the clock calibration routine for 1.8432 mhz for a better baud rate range ( 2400 to 230.4k).
withouth calibration the internal oscillator it's not reliable enough for standard serial communication.

Actually, the internal oscillator is adjusted to 8MHz. Then the prescaler is used to set the internal clock to 1MHz. For serial comms, the prescaler is changed temporarily so that the internal clock is set to 2MHz, which allows the 19200 baud rate to be used.

SIZE OF BUTTERFLY DATAFLASH:

I've had a quick look at the datasheet for the 4Mbit AT45DB041B that ships on the Butterfly and noted -

"2048 Pages (264 Bytes/Page)"

Ok, are we saying that this guy has 132 bits per byte? (2048 * 2 (132 bit bytes))

Come someone please clarify this for me - thanks.

QUOTE

The memory is organized such that you get 8 additional bytes for every 256 bytes, this is common for NAND type flash devices.

so think of it this way

8bits/byte * 256 bytes/page * 2048 pages = 4,194,304 bits = 4Mbit

as a bonus you also get

8bits/byte * 8 bytes/page * 2048 pages = 32,768 bits = 32Kbit

so the dataflash is really a 4Mbit+32Kbit device

The addional 8 bytes arae typically used for wearlevel management and error correction codes for flash filesystems.

SOURCE FOR BUTTERFLY JOYSTICKS:

Does anyone know where I can get a little joystick like the one in the Butterfly?

QUOTE

recently ordered a couple of different 4way + enter digital joypad's from both RS & farnell.

For farnell try :
415-6225 - TPA511G 4 Way + Select
415-6249 - BTNTPA02-02(Clear) Button - TPA Hat
(Both on page 433 of Book2 (2004 NZ catalogue))

For RS try :
336-7413 - SKQUCA - Multi-Fn Tactile (4 Way + Enter)
(page 1083 in NZ 2003 RS Catalogue)

QUOTE

You can get it from RS-Components (www.rs-components.com).
I tried the cst device and it worked well.

It's also available at www.elfa.se. Part Nr. 35-665-44

BUTTERFLY VOLTAGE:

I have checked all the parts on the Butterfly board and they all can run at 5 Volts. I don't know about the LCD tho.

Has anyone run this board at 5 volts without any problems?

QUOTE

Yes! I've use 5 volts, from my programmator via programming connector.

QUOTE

It works with 5 volts

BUTTERFLY PORT E CONTROL & JTAG:

Hello I'm programming the butterfly to controll a battery charger circuit, but the problem is i need 8 bits out.. I can controll port E 4-6 but i'm 5 pins short.. I was thinking of using some pins on port F (something like pin 1 and 4-6) but they don't seem to respond to my programming... Do i have to unmount something from the butterfly to make them work; any suggestions?

QUOTE

Yuo have JTAG enabled, that's why PORTF doesn't respond to OUT commands. Look at "Memory programming" in datasheet, you'll find fuses setings there. Diasble JTAG via SPI programmer and everything will be OK

In Atmega169 datasheet. Look also chapter 2.4.3 in Butterfly datasheet. The only reason for PORTF not to respond is that JTAG is enabled. JTAG occupies pins 4-7 of PORTF. You have to clear JTAGEN and OCDEN fuses, this can be done thru ISP programmer. How to connect it, see Ch.3.2 Butterfly datasheet.

BUTTERFLY & JTAG ICE:

I have connected AVR butterfly to jtag ant to my pc (my OS win XP). I power up target device(butterfly) with battery which is included , then i power up JTAG ICE and launch AVR studio 4 . After this i go
Tools->STK500/AVRISP/JTAGICE, then there appears STK500 window. In the bottom there is written "Detecting ... Failed" so i can do nothing with my butterfly...

So what i am doing wrong ??? What i need to do to get start to program my BTF, how can i erase this device ? I'v read all JTAGICE user guides, avrstudio guides and checked all troubleshootings , but it didn't help...

QUOTE

Could be the XP/NT problem of not being alowed to communicate directly with th e ports. You will need a seperate prog inther to enable that to happen.

This has been covered several times on this forum with referances to software for overcoming this problem. If that is the problem

QUOTE

I run my STK500 on XP Pro without troubles. Haven't tried the JTAG ICE on it. But as with most RS-232 connections, the problem is most likely a reversed pin problem. One way to make sure you've got the right connection is to measure the voltage on pins 2 and 3 of your RS-232 connectors. One of them will have a voltage on it and one will not. Make sure that the connector you're plugging into has voltage on the OTHER pin. That is, if the PC is driving pin 2, make sure pin 2 on the device you're connecting it to does not have any voltage on it, and make sure pin 3 DOES. On a DB-9 connector, I believe ground is pin 5. On a DB-25, it is pin 7. Nine times out of ten, this is the problem. If you find that your connectors don't match, add a "NULL MODEM" adapter (available at Radio Shack) to one end of the cable. Baud rate is another thing to check, although I think the program should be setting that up for you. Inability to detect the device is almost certainly a connection or baud rate problem. Could also be a power problem. Make sure you have power applied.

Posts: 3

BUTTERFLY CLOCK SPEED & OVERCLOCKING:

I'm using the Butterfly for the first steps into the world of AVRs. I've studied the demo app and the manual for the atmega169(V) and now there's the following question: Atmel uses a 2 MHz "boost" clock to achieve a good 19200 baud rate an usart, but the 169V is only specified to wirk with 1 MHz. Does this mean it is overclocked or does it really work @ 2 MHz?

QUOTE

According to the data sheet, the 169 can employ "double-speed" clocking to the USART. This could be what Atmel is refering to, and not the MCU clk speed.

QUOTE

No answer to the initial question but an attempt to clear things up a little bit: The Butterfly is clocked by the internal RC (8Mhz) which is devided by 8 by default to a 1MHz clock-freqency. This interal RC is calibrated during startup (OSCAL) with the on-board 32kHz clock-crystal which is used for the RTC in the first place in the preinstalled application. Main reason for this calibration may be getting the UART-Timing more precise. To get 19200 baud with a low error the divider is first changed to 4 (CLKPR) which results in a system-clock of 2MHz. Baud rate is set to 9600 and the UART is set to double speed which results to 19200 baud at 0,2% error. See also the source-code of the Butterfly-bootloader. Overclocked or not, it is a good idea to keep the default at 8/8 Mhz to save battery-power and "boost" only if needed.

BUTTERFLY RS2323 LEVEL CONVERTER:

The ATmega169 on the AVR Butterfly can talk to the serial port on a pc with no external RS232 converter. Can all the Atmega ics do this

QUOTE

None of the AVR's can do RS232 directly. If you look on page 4 of the butterfly schematic you'll see the level translators that were used.

BUTTERFLY NUMBER OF I/O PINS & LCD:

If the Mega169 that comes with the Butterfly has a whopping 53 I/O pins, then why are the only ones available to the user through a header connection tied up with the on-board stuff like the LCD?

Its just with they'd have used a simpler LCD with maybe a 4-bit interface instead of hogging up over 20 lines.

I'm thinking about using this as the basis of my weather balloon flight computer and it would be nice to have two full I/O ports.

It is a nice little kit, though.

QUOTE

Yep, there sure is a need for someone to take chips like the 169 and 128, those high preformers that are not DIP format, design a board, have just that chip put one in, with places to connect an LCD like the ButterFly has and other 4 pin LCD plus bring out all the other ports to headers., place for a xtal and a RS232 I/O chip. Keep it really inexpensive by having only the micro itself on the PCB. The end user can add what they need.

QUOTE

The whole point with the m169 is that it features a LCD CONTROLLER and hence each LCD segment must be multiplexed using several IOs for line and coloumn select. If you wan't to acess the LCD with a 4 bit interface the LCD itself must contain an LCD controller and the entire point of having an LCD controller inside the m169 falls apart That's why so many IO pins are used to drive the display.

BUTTERFLY AS FAN CONTROLLER:

My objective is to create a fan controller that will do the following things:

1. Use data from multiple temperature sensors (4 minimum, more is better) to control several fans (4 minimum; again, more is better) so that the fans are operating at the minimum possible speeds (and noise levels) needed to keep the system operating at or below maximum temperatures. If possible fan RPM monitoring is desireable.

1A. Additional sensors of other sorts, and the ability to respond to them would be highly desireable, but not essential (examples might include leak detection and flow detection in a watercooling system, etc.)

2. Once configured, operate independently of the PC systems main motherboard, operating systems, etc. (with the exception that data reporting is OK, but a failure by the OS to deal with reported data must not cause the controller to fail)

3. User configureable as to what sensors (or combination of sensors) control what fans, what temperatures turn fans on / off, ramp rates, data reporting, etc. Configuration MUST be available in Linux, may be desirable in other O/S's.

4. Function in as fail safe a manner as possible. Excess temperatures should trigger alarms, and must cause system shutdown (graceful desired, but power shutoff is OK) controller failure should cause all fans to go to full speed,

5. Extremely Desirable, but not absolutely mandatory, would be the ability to display temperatures, fan speeds, and other such information on a secondary LCD display. The ability to display other data generated by the main system would be nice but is far less important. The display should be either remote mountable (ideal) or fit in the space of a 5.25" PC drive bay cover. Ideal display size would be on the order of 2 lines X 40 char, but smaller would be OK.

6. The entire controller should be reasonable in size, I would want it to be no larger than a typical 5.25" PC device (such as a CD ROM drive)

The other big issue to me is that the software development I would want to do under Linux. I refuse to allow a Windows machine on my network, and rank using Micro$haft products in the same general class as skunk wrestling, cesspool diving, and the like.

In terms of my personal skills, I'm good with tools, and have a pretty good level of construction ability. My hardware design skills are mixed, but I think reasonable. I have little or no software programming skills - I used to be good with DOS batch files, and I've done a little bit of Bash scripting, but not much beyond that.

QUOTE

It sounds like a do-able project (actually I have thought about making something similar).

I wouldn't bother with the Butterfly - you will not be using enough of its features to make it worthwhile. Instead use an AtMega16 controller - that will be pretty much all you need!! It has 8 ADC inputs, lots of digital outputs, and other fun stuff.

For software tools you will pretty much have to use avr-gcc, which is quite good! There is a windows distribution of it (WinAVR), but in your case just compile them for linux. See the avr-libc documention - it talks about installing in Linux I think (google for avr-libc, hit HTML documention, then goto "Others" or "FAQ" section or something like that).

To make this easier to start out get an STK500 - it takes care of all the hardware requirements. Then you can later move over to a custom circuit board.

For control of the thing just use a normal serial port, a lot of motherboards have an extra COM port connector internally (10-pin header) you could plug into. Otherwise use an FTDI Chip to make a simple USB --> Serial converter. This way it will be useful under any OS.

You will need some MOSFET devices or something like that for the actual fan power control. Check out http://www.maxim-ic.com/appnotes.cfm/appnote_number/707 for some info on the fans and controlling them.

I appreciate that the Butterfly may be overkill for my needs in some ways, but unless I'm missing something, the STK500 approach is relatively expensive, while the Butterfly is only $20. Given that I'm more likely than not only going to be making one or two of these things, it seems the Butterfly is less of a budget buster.

Interesting that you point me at a Maxim appnote, as I've studied a small amount about the Maxim "DOW" or "Dallas One Wire" family of sensors. These have a certain amount of appeal in that they allow up to 32 sensors on a single string.

QUOTE

The butterfly would work if you end up using digital sensors. The reason I didn't recommend it was that the only way to get some analog inputs is to disable the JTAG interface, even then it only gives you four inputs.

The butterfly does have one on-board temperature sensor though, could be case temp or something. See http://www.atmel.com/dyn/resources/prod_do...nts/doc4249.pdf for quick guide to Butterfly, and http://www.atmel.com/dyn/resources/prod_do...nts/doc2514.pdf for the AtMega169 datasheet.

QUOTE

I don't think that you would find one wire support on anything other than Dallas' range of microcontrollers.

But if you want to avoid all this, why not use some thermistors and the Mega's ADC inputs? Use the thermistors as part of a resistor paralell/ serial network and they should demonstrate a reasonably linear characteristic. If you only need it to be accurate to within a couple of degrees this should be quite acceptable.

I have not looked at the PC component market for a while. But I seem to remember these type of fan controllers being fairly costly, considering what they actually do. Seems like you have yourself an interesting project here! Perhaps with some commercial potential too!

BUTTERFLY BODLEVEL & CLOCKSOURCE:

I nuked my Butterfly... Accidentally I set BODLEVEL to the binary value 011 which is dokumented as a reserved value in the datasheet.
The device is no longer discovered via SPI serial programming.

In addition I also changed the clocksource from 0011 (RC 2MHz) to 0100 (RC 8MHz), but this shouldn't make the device disappear on the SPI.

The original fuses where EXT=0x7 HI=0x98 LO=0xE2
I accidentally wrote it to EXT=0x3 HI=0x98 LO=0xE4

Now it's dead. Can it be revived using the SPI?

I only have an old Kanda parallel port dongle from a STK200. I handwired a 5V -> 3.3V adaptor and it worked flawlessly until I touched the fuses...

Btw, I measured that the 32kHz watch crystall still oscillates.

QUOTE

Try to find a STK500-owner near you and try prarallel-programming. It's described in the Butterfly user-guide. With par.-prog. you should be able to reset the fuses to delivery-state.

BUTTERFLY PORT PINS FOR PORT B & E:

I want to use Pins from Ports B and E als voltagesource, but when I connect something (for example a multimeter) or set Pins on Port B I get problems with the program (functions change or it doesn`t react anymore). Stabil is the use of PORTE (4, 5, 6) PORTB (0, 4, 5). I need two more Pins.

QUOTE

Maybe the ISP-Pins (MISO/MOSI). Keep the the dataflash in mind which is connected to the SPI-interface (control the DF chip-select pin). You may also disable the JTAG interface (JTAGEN fuse or JTD-bit in MCUCR) and then use the 4-JTAG-pins as "general I/O".

BUTTERFLY PORTF & JTAG:

Somewhere I read that one could get access to PORTF bits 7-4 if one disabled JTAG using the MCUCR.JTD bit. I have tried this, and have debugged extensively enough that I am quite sure it does not work. The datasheet refers only to the fuse in this context and it seems that's exactly what it means.

QUOTE

I tried this and at first it didn't work. Closer examination of the data sheet showed that the same data has to be presented within 4 machine cycles to be effective. I guess it's some sort of safety feature. I ended up making sure by doing it four times in a row, and it works fine.
In avr-gcc,
MCUCR |= (1<<JTD); //settting jtag disable to use pf4-7 as i/o
MCUCR |= (1<<JTD);
MCUCR |= (1<<JTD);
MCUCR |= (1<<JTD);

See page 236 of the complete ATMega169 data sheet.

Incidentally, the .lss file from the compiler shows that the machine code that is compiled is
4f0: 85 b7 in r24, 0x35
4f2: 80 68 ori r24, 0x80
4f4: 85 bf out 0x35, r24

and that is repeated 4 times. I'm posting it in case you aren't using a C compiler.

It's page 237 in the version of the datasheet I have.

Now I have 4 more signals to play with, having already changed over to port B!

If any Atmel people read this, please consider adding mention of this little gotcha in the several other places that discuss JTD, such as on pages 36 and 229 (also note typo "MCUCSR" rather than "MCUCR").

QUOTE

The "four cycles" method is used to manipulate a number of subsystems--watchdog timer, SPM, vector select, etc. Search the datasheet for "four cycles".

QUOTE

To ensure the "within four cycles" criterion, do the sequence when global interrupts are disabled. This could be during your system startup or bracket the sequence with CLI/SEI as with other operations that need to be monolithic.

It seems to me that the paragraph on the JTD bit of MCUCR is fairly straightforward, and is quickly found with a datasheet search for "JTD".

Using cli/sei and just doing it twice seems like a good idea. I think I'll do that.

The problem with the datasheet search for JTD is that you get several references to writing one or zero to the JTD bit, with no mention of the special requirements. The secret is only revealed on page 236. They could improve the datasheet with a parenthetical: (see page 236 for special requirements for writing JTD).