Programming an Orangutan

I have an Orangutan that I am having trouble programming.
I am using WinAVR and the AVRII USB adapter.
I have a simple program which just updates the Display.
I have run all the updates to the software for the WinAVR and the USB adapter, and installed the updates.

When I compile the program and click the “Run” button, it attempts to connect through the adapter to the Orangutan. I get a dialog box indicating to select the type of connect, where I have selected the ATMega168 processor.

When I click the Finish button, I get a popup box indicating there is an error connecting to the port.

I have tried it with the Orangutan powered and not, and either way I get the same error. The two LEDs on the USB adapter are green before it attempts to upload the program.

I am not sure if there are any documents I should have read regarding this. If anyone can provide some instructions or helpful hints, I would appreciate it.

Thanks

Joe

The system apparently does not detect your avrisp mkii programmer.

You need to tell us more about how you are trying to program the Orangutan. If you are using only WinAVR, then, depending on your “makefile” the actual device programming will probably be done by a program called “avrdude”. In this case, you need to tell avrdude (in the makefile) which type of programming adapter, i.e. avrispmkii or avrisp2, is to be used, and the port through which it should connect.

I have not been able to get this to work on a WinXP computer, as the avrisp2 doesn’t seem to appear to windoze to be a normal USB device. Instead, it appears on my computer as a completely novel device called “jungo”. If anyone knows how to make this connection, please let me know. Little can be found on the web.

If you download AVRStudio4, it will find WinAVR and, if you tell it to do so when starting a new project, it will use the WinAVR gcc compiler. It will also recognize the avrisp mkii programmer automatically.

Under AVRStudio, you can compile your program using the “Build>build and run” menu entry, and then program the Orangutan under the “Tools>program AVR>autoconnect” menu entry. This will bring up the programmer window–tell it to “program flash”, using current simulator flash memory. Note: I set the ISP programmer clock up to 1 MHz.

Jim

When getting started, I recommend a very simple program like “blink the red led”, see below. In this example, you should make sure that the compiler uses -O0 (no optimization), or it may eliminate the empty for loops. Set -O0 under “Project>configuration options”.

//Orangutan:
//blink the red led with about 1 second period - 8 mHz clock (no optimization)

#include <avr/io.h>
#define looptime 110000

int main(void)
{
	long int i;
	DDRD |= _BV(1);  //set PORTD.1 = output

	while(1) {
	PORTD &= ~(_BV(1));  	//led off
	for(i=1;i<looptime;i++);  //waste time
	PORTD |= _BV(1);		//led on
	for(i=1;i<looptime;i++);  //waste more time
	}
	return 0;
}

Hello.

Unless you have a good reason for doing otherwise, I recommend using AVRStudio. That way, you can at least avoid issues of the software not being compatible with your programmer (assuming it is also from Atmel), and you get a nice graphical interface for the programmer (be careful with the fuses!). You’ll probably appreciate the simulation features later on, too.

Also, you will definitely need to have power on the target device to program it.

- Jan

When using AVRStudio 4, there are some settings you’ll need to check before you can build a program and load code on your AVR:

First, the simulator wants to know what kind of a device you’re simulating. When you create a new project in AVRStudio and you get the list of available devices, this is what you’re actually setting.

In addition, you need to tell WinAVR what device you’re compiling for. This is done in the Project -> Configuration Options dialog. (This is also where you set your compiler optimization flags… more on that in a sec.)

In addition, you need to tell the AVR ISP Mk II what kind of a device it’s supposed to be writing to. This is done in the dialog box for the AVR ISP. It’s important, or the AVR ISP won’t be able to detect the target correctly and may report it as not existing at all.

In addition, there are two other values that need to be set in that dialog box. I don’t have my AVR ISP with me, so I can’t pull it up to look at where those settings live, but here’s the upshot: The programming speed needs to be set to some reasonable number. I’ve got mine set to 1MHz. Straight out of the box, I think my installation of AVR Studio was trying to program at something like 1kHz, which resulted in errors every single time. Also, it needs to know the voltage of the device. The AVR ISP Mk II can auto-detect the device voltage, but I forget how you tell it to do this. When I switched from doing an Orangutan to doing an AVR Butterfly, then back to the Orangutan, this setting tripped me up both times.

On compiler optimization settings: When it comes to compilation, you can optimize for speed or you can optimize for small binaries. Can’t optimize for both. In that Project -> Configuration Options dialog box, there’s a slot called “Optimization”. Far as I know all projects start out with a default of -O0. This makes for efficent and very large code. For smaller code try -O2, -O3, or -Os. When you compile, it’ll tell you the resulting size of the binary. Tweak away.

Why this is important: -O0 optimization tries to make things fast by expanding the code and having fewer branches. Makes for big code. It’s very easy to write a program that’s bigger than the memory on the Orangutan. Change the optimization flags and you can go from 110% memory usage down to 25%. The reason I mention it is if you’re trying to load your first program and things don’t work (which is what it sounds like is happening), this is just one more thing to be aware of and not get frustrated with.

Above all, don’t get discouraged! And if you get stuck, ask. Chances are it’s something someone else has run into as well.

Best of luck!

Tom

OK, heres what I have going for me so far:
I am using AVRStudio 4. I didn’t realize WinAVR and AVRStudio aren’t the same thing…

I have an AVR MKII USB Adapter. I upgraded the firmware on it today.

In My “Project”=>“Configuration Options” I have the following:
Active Configuration = Default
Output File = TurtleTurtle.elf
Output Directory = default
Device = AtMega168
Frequency is 1000 kHz (I changed this from 1 kHz)
Optimization = -O3
Create Hex File is checked.

I compiled my program.

I clicked on the AVR button (“AVR” is on an icon of a microchip) Which opens the AVRMkII Dialog box

Device = atmega168
Programming Mode = ISP Mode
Erase Device is checked
Verify Device is checked
I selected the input hex file for the Flash to be my default\TurtleTurtle.hex (which has a long path before it)

I changed the settings in the board tab:
ISP Freq = 1MHz. It was 1 KHz as a default. However the setting does not stay, so I obvoiusly don’t know what to do for that.

I clicked the “Program” button on the Flash section and it did the following output:

Reading FLASH input file… OK
Setting mode and device parameters… OK!
Entering programming mode… OK!
Erasing device… OK!
Programming FLASH … OK!
Reading FLASH … FAILED!
Leaving programming mode… FAILED!

Then I get a popup box that indicates:

"A problem occurred when executing the command. See the command output for more info.

Tip: check the ISP programming frequency on the Board tab… should be less than 1/4 the clock frequency…"

I am not sure how to check these settings nor how to modify them correctly.

It appears my program DID upload. Every time I hit the reset button the display changes, and occasionally it prints the word “Turtle” from my program. Most of the time it just prints garbage. Also the red LED lights up (which is part of the program, though i am not sure if the program is doing it or its just lighting up because of garbage…)

Any more help would be appreciated.

For reference, here is my program:

#include <avr/io.h>
#include <util/delay.h>
#include <avr/sfr_defs.h>

#define F_CPU 20000000

#define LCD_COMMAND_CLEAR   0x01
#define LCD_COMMAND_LINE1   0x02
#define LCD_COMMAND_LINE2   0xC0

#define   LCDDelay   _delay_loop_2

#define Delay _delay_loop_1

// Prototypes

void Speaker (int cycles);
void   LCDSendNibble( unsigned char data );
void   LCDData( unsigned char data );
void   LCDString( const unsigned char *str );
void   LCDCommand( unsigned char data );
void   LCDHexNibble( unsigned char data );
void   LCDHex( unsigned char data );
void   LCDInit( void );
void LEDLight(int light_state);

int main()
{
    LCDInit();
	LCDCommand(LCD_COMMAND_LINE1);         //Goto start of Line 1 on LCD
	LCDString( "Turtle" );
	LCDCommand(LCD_COMMAND_LINE2);         //Goto start of Line 2 on LCD
	LCDString( "  Turtle" );
	Speaker(6);                             // Let the world know I am awake.
	LEDLight(1);							// turn the led ON
    return(0);
}





void Speaker( int cycles )
{
   DDRB |= 1<<PB0;               //make PB0 an output

   long i;
   int cycles_left = cycles;

   while (cycles_left > 0) {
      PORTB |= 1<<PB0;         // buzzer pin high
      for(i=0;i<2000;i++);
      PORTB &= !(1<<PB0);      // buzzer pin low
      for(i=0;i<2000;i++);
      cycles_left--;
   }
   return;
}


/*
** LCD
*/


void   LCDSendNibble( unsigned char data )
{
   data &= 0x0F;
   data <<= 3;
   PORTB &= ~0x38;
   PORTB |= (data & 0x38);
   data <<= 1;
   PORTD &= ~0x80;
   PORTD |= (data & 0x80);
   PORTD |= _BV(4);      //   LCD_STROBE = 1;
   Delay( 200 );
   PORTD &= ~_BV(4);   //   LCD_STROBE = 0;
   Delay( 200 );
}

void   LCDData( unsigned char data )
{
   PORTD |= _BV(2);      // LCD_RS = 1;
   LCDSendNibble( data >> 4 );
   LCDSendNibble( data );
}

void   LCDString( const unsigned char *str )
{
    while (*str != 0)  {
      LCDData( *str++ );
    }
}

void   LCDCommand( unsigned char data )
{
   PORTD &= ~_BV(2);      // LCD_RS = 0;
   LCDSendNibble( data >> 4 );
   LCDSendNibble( data );
   LCDDelay( 100 );
}

void   LCDHexNibble( unsigned char data )
{
   data &= 0x0F;
   if ( data > 9 ) {
      data += ('A' - '9' - 1);
   }
   LCDData( data + '0' );
}

void   LCDHex( unsigned char data )
{
   LCDHexNibble( data >> 4 );
   LCDHexNibble( data );
}

void   LCDInit( void )
{
   DDRB |= _BV( 3 ) | _BV( 4 ) | _BV( 5 );
   DDRD |= _BV( 7 ) | _BV( 4 ) | _BV( 3 ) | _BV( 2 );
   PORTD &= ~_BV(4);   //   LCD_STROBE = 0;
   PORTD &= ~_BV(3);   //   r/w = 0
   LCDDelay( 200 );
   LCDCommand( 0x32 );
   LCDCommand( 0x20 );
   LCDCommand( 0x1C );
   LCDCommand( LCD_COMMAND_CLEAR );
   LCDCommand( 0x28 );
   LCDCommand( 0x06 );
   LCDCommand( 0x0C );
}


/******************
 **  LED Light
 ******************/  

void LEDLight(int light_state)
{
    if(light_state == 1)
	{
	    PORTD |= 1<<PD1;         // LED on
	}
	else
	{
	    PORTD &= !(1<<PD1);      // LED off
	}
}

Tom,

If you check the documentation on gcc optimizations flags, I believe that you will find that -O0 means “no optimization”, with the specific intent being that each C statement is compiled (and executed by the MPU) as a separate unit. This is particularly advantageous for debugging.

The other options -O1,2,3,s add various tricks that generally work make your program faster or smaller. They also make debugging difficult because results are not always calculated in accord with the intended program flow–and entire statements can be eliminated if the compiler can figure out a way to do so. This can be frustrating for a beginner, if he/she is learning to use an interactive debugger!

Finally, although gcc seems to be a mature product, I’ve been burned by other compilers, and wasted much time trying to fix bugs that were actually introduced by the optimization.

It is entertaining to compile the “blink” program that I posted above with the various options, and compare the results.

Here is the GNU gcc reference:
gcc.gnu.org/onlinedocs/gcc/Optim … ze-Options

Best regards, Jim

Joe:

After just a brief glance at your example, three problems stand out. There may be others, but this is a place to start.

First, if you are using the new Orangutan (with the ATmega168) then the CPU clock frequency is 8MHz by default. So, you need to enter the correct value into AVRStudio, under Project>Configuration Options.

Perhaps this is why you could not change the programmer ISP clock (not the same thing as the CPU clock) to 1 MHz – it has to be less than 1/4 of the CPU clock frequency. As Tom pointed out above, the default ISP frequency seems to be about 1kHz, which leads to problems. You should be able to set it to 1 MHz, after setting the processor frequency to 8 MHz.

Second, you have the statement
#define F_CPU 20000000 in your code, which should be changed to 8000000UL to reflect the 8 MHz clock.

Third, your LCD routines won’t work with an 8 MHz CPU clock, because the delays are too short. Tom has posted a better set on his site for 8 MHz CPUs (see elsewhere in this forum).

I still recommend trying to get the “blink” program running before you tackle a larger project! An LED blinking at the correct rate is genuine and satisfying milestone (the micro equivalent of “Hello World”).

Jim

DOH! Thanks for the correction, Jim. Right you are on the gcc optimization flags.

And I’d like to second and third Jim’s comments on blinking the LED. Don’t be satisified with your results until it does exactly what you think it should do! Case in point, a while back I was laboring under the misconception that the Orangutan and Baby-Orangutan both ran at 20MHz. I’m wrong, of course, but justified the difference in blinky behavior between the two as some sort of mistake on my part. Nope, they really were running at different rates. Had I stuck to it, I could’ve avoided a lot of wasted time.

Blinky’s good!

Tom