Newbie to AVRStudio

[vidam]

Hi,

I'm a newbie to AVR Studio. I am wondering how you can debug your code before downloading to the mcu. For example, I want to use printf statements to print to a console window in AVR STudio. I tried this and did not see where the output statement "hello world"  is printed.

Code: [Select]

int main(void)
{

configure_ports();
printf("hello world");


}


[SixRingz]

Debug your code before you download it to the mcu? I'm not sure I understand... Do you want to run the code and print some outputs? Then you need to 1. Get an emulator program for the PC (if AVRstudio doesn't have one) or 2. Download and run the code with the mcu and use serial or some other communication line to screen on PC.

[pomprocker]

AVR Studio would have to compile for windows or mac for it to run on your computer.

Try using MetroWorks CodeWarrior (Free IDE) and doing some compiling of C for your OS.

[Webbot]

AVR Studio does allow you to run your code in Debug Mode. However - since its running on your PC then its actually not of much use since the sensor inputs, and actuator outputs, aren't connected to your PC.
Its fine if you just want to test stuff that doesn't require I/O - which isn't much

[krich]

For me, this was the single most frustrating part of programming MCUs.  You can't see what's going on.  If you want to see what's going on, you need a JTAG interface ($$$), so you just do without.  Soon I realized that my #1 job was to get a reliable serial interface working.  This way, you can redirect stdout to the serial interface and use printf to send debug messages out to a terminal program on your PC.  It's still not a debugger, but it's better than staring at the board, wondering WTF it's doing and then thinking "well, at least its not smoking...like last time...".

Come to think of it, that's still the single most frustrating part of programming MCUs.   

EDIT:  I forgot to mention VMLAB which is a really good simulator program, but it's been abandoned by the developer since early 2006 (according to the AVRFreaks wiki).  It also has a number of bugs which get in the way of really being able to confidently test your code before writing it to flash.  I'm not terribly experienced in this, are there any better ones?

[vidam]

For me, this was the single most frustrating part of programming MCUs.  You can't see what's going on.  If you want to see what's going on, you need a JTAG interface ($$$), so you just do without.  Soon I realized that my #1 job was to get a reliable serial interface working.  This way, you can redirect stdout to the serial interface and use printf to send debug messages out to a terminal program on your PC.  It's still not a debugger, but it's better than staring at the board, wondering WTF it's doing and then thinking "well, at least its not smoking...like last time...".

Come to think of it, that's still the single most frustrating part of programming MCUs.   

EDIT:  I forgot to mention VMLAB which is a really good simulator program, but it's been abandoned by the developer since early 2006 (according to the AVRFreaks wiki).  It also has a number of bugs which get in the way of really being able to confidently test your code before writing it to flash.  I'm not terribly experienced in this, are there any better ones?

This post gave me a good laugh. Thanks for the bit of humor... Unfortunately in my newbieness it will take me at least 1 month to figure out how to send debug messages to my PC serial port from my MCU.

[SixRingz]

Don't despair, there are probably lots of people here who has written routines for serial communication ready for most AVR devices. You don't actually need to understand how they work now, just how to use them and then debug away like never before!  I would love to have posted one of mine, but the thing is I haven't one myself... 

[Admin]

 
http://www.societyofrobots.com/microcontroller_uart_50_robot.shtml

[vidam]

UART is a nice idea for debugging. After thinking about it, I realized that my PCB doesn't have a UART. I would have to tap directly off the AT mega 168 pins and the chip has the ball pins which are too tiny.

[krich]

Here's my UART code.  Not sexy, not interrupt based, but functional (barely).  Well, the getchar function may not work.  And I shouldn't be messing with all the pins of all my ports (not sure why that's in there, honestly).  Anyway, this will give you a good idea of where to start.  I should mention that this was based largely on the tutorial at Sparkfun's webiste.  It's also a great reference.

This is the uart.h file

Code: [Select]

#define FOSC F_CPU //onboard osc  note:  best standard clock is 8mHz
#define BAUD 38400
#define MYUBRR (((((FOSC * 10) / (16L * BAUD)) + 5) / 10) - 1)


// Only use the next two lines if you are using C++ compiler
#undef FDEV_SETUP_STREAM
#define FDEV_SETUP_STREAM(p, g, f) { 0, 0, f, 0, 0, p, g, 0 }  //dangerous.  remove when WinAVR supports C++ streams

int uart_putchar(char, FILE *);
int uart_getchar(void);
void uart_init(void);




And the uart.c code

Code: [Select]

#include <avr/io.h>
#include <stdio.h>
#include "uart.h"

static FILE mystdout = FDEV_SETUP_STREAM(uart_putchar, 0, _FDEV_SETUP_WRITE);

void uart_init (void)
{
    //1 = output, 0 = input
    DDRB = 0b11101111; //PB4 = MISO
    DDRC = 0b11111111; //
    DDRD = 0b11111110; //PORTD (RX on PD0)

    //USART Baud rate: 9600
    UBRR0H = MYUBRR >> 8;
    UBRR0L = MYUBRR;
    UCSR0B = (1<<RXEN0)|(1<<TXEN0);
 
stdout = &mystdout;
   
}

int uart_putchar(char c, FILE *stream)
{
    if (c == '\n') uart_putchar('\r', stream);
 
    loop_until_bit_is_set(UCSR0A, UDRE0);
    UDR0 = c;
   
    return 0;
}

int uart_getchar(void)
{
    while( !(UCSR0A & (1<<RXC0)) );
    return(UDR0);
}

Here's the schematic.  It uses a MAX233CPP.  Don't know why so many people use the old MAX232 chips.  You need so many caps for that chip.  For this one, you need...one, and its just a decoupling cap.

[vidam]

Here's my UART code.  Not sexy, not interrupt based, but functional (barely).  Well, the getchar function may not work.  And I shouldn't be messing with all the pins of all my ports (not sure why that's in there, honestly).  Anyway, this will give you a good idea of where to start.  I should mention that this was based largely on the tutorial at Sparkfun's webiste.  It's also a great reference.

This is the uart.h file

Code: [Select]

#define FOSC F_CPU //onboard osc  note:  best standard clock is 8mHz
#define BAUD 38400
#define MYUBRR (((((FOSC * 10) / (16L * BAUD)) + 5) / 10) - 1)


// Only use the next two lines if you are using C++ compiler
#undef FDEV_SETUP_STREAM
#define FDEV_SETUP_STREAM(p, g, f) { 0, 0, f, 0, 0, p, g, 0 }  //dangerous.  remove when WinAVR supports C++ streams

int uart_putchar(char, FILE *);
int uart_getchar(void);
void uart_init(void);




And the uart.c code

Code: [Select]

#include <avr/io.h>
#include <stdio.h>
#include "uart.h"

static FILE mystdout = FDEV_SETUP_STREAM(uart_putchar, 0, _FDEV_SETUP_WRITE);

void uart_init (void)
{
    //1 = output, 0 = input
    DDRB = 0b11101111; //PB4 = MISO
    DDRC = 0b11111111; //
    DDRD = 0b11111110; //PORTD (RX on PD0)

    //USART Baud rate: 9600
    UBRR0H = MYUBRR >> 8;
    UBRR0L = MYUBRR;
    UCSR0B = (1<<RXEN0)|(1<<TXEN0);
 
stdout = &mystdout;
   
}

int uart_putchar(char c, FILE *stream)
{
    if (c == '\n') uart_putchar('\r', stream);
 
    loop_until_bit_is_set(UCSR0A, UDRE0);
    UDR0 = c;
   
    return 0;
}

int uart_getchar(void)
{
    while( !(UCSR0A & (1<<RXC0)) );
    return(UDR0);
}

Here's the schematic.  It uses a MAX233CPP.  Don't know why so many people use the old MAX232 chips.  You need so many caps for that chip.  For this one, you need...one, and its just a decoupling cap.

Nice Krich!

Although I don't have UART on the PCB at work, this past weekend I ordered all the parts from digikey to start making the $50.00 robot. When I get to the part that adds UART, I will take a look at this post again. Till then, many thanks to everyone who replied to my post!!!!!

[bens]

AVR Studio does allow you to run your code in Debug Mode. However - since its running on your PC then its actually not of much use since the sensor inputs, and actuator outputs, aren't connected to your PC.
Its fine if you just want to test stuff that doesn't require I/O - which isn't much

You can manually toggle any register bits you want while using the simulator, so you can simulate things like sensor inputs and interrupts.  The simulator can be a pretty useful tool.

- Ben

[krich]

Although I don't have UART on the PCB at work, this past weekend I ordered all the parts from digikey to start making the $50.00 robot. When I get to the part that adds UART, I will take a look at this post again. Till then, many thanks to everyone who replied to my post!!!!!

I forgot to mention that to use the code I posted, just use a standard printf statement.  It redirects stdout to the serial handling routines.

MAX233 chips are relatively expensive for the $50 robot project, so you might want to socket it so that you can use it in other projects down the road without the stress of desoldering it.

[vidam]

AVR Studio does allow you to run your code in Debug Mode. However - since its running on your PC then its actually not of much use since the sensor inputs, and actuator outputs, aren't connected to your PC.
Its fine if you just want to test stuff that doesn't require I/O - which isn't much

You can manually toggle any register bits you want while using the simulator, so you can simulate things like sensor inputs and interrupts.  The simulator can be a pretty useful tool.

- Ben

Yes I agree the simulator is very useful. You can use it to keep track of your registers while the code is running and verify that what is in the register makes sense with the datasheet. I am using it now for my first time ever.

[Webbot]

AVR Studio does allow you to run your code in Debug Mode. However - since its running on your PC then its actually not of much use since the sensor inputs, and actuator outputs, aren't connected to your PC.
Its fine if you just want to test stuff that doesn't require I/O - which isn't much

You can manually toggle any register bits you want while using the simulator, so you can simulate things like sensor inputs and interrupts.  The simulator can be a pretty useful tool.

- Ben

Yes I agree the simulator is very useful. You can use it to keep track of your registers while the code is running and verify that what is in the register makes sense with the datasheet. I am using it now for my first time ever.

Ok I was a bit harsh !! It is useful !

You can toggle bits and registers but if you have to do it every time around your main loop, or your are reading things in interrputs, then it can be 'awkward' - but possible. But still doesn't help with 'real time' issues, and the sensor readings you are getting in practice. So it helps get the code up and running but having the 'bot dump out actual sensor data etc is then invaluable to debug your algorithm/decision logic.

Wouldn't it be great if you could capture some real time data, say as an XML file, and save it on your PC. For example every time you read a sensor then output the time, port/pin, and value - and every time you write to a register/port/pin then output the the time, port/pin,value. Then if you could plug that data into the simulator - then that WOULD be AMAZING. This would allow you to build up some 'test scripts' - so that if you changed your code you could re-run all of your test files to make sure that the program still works - ie if you read all the Inputs in the correct timing then you should get all the same Outputs as before.

Hmmm - I think I've just convinced myself that it could be worth trying to write such a 'black box' !!! Now all I need is time.........

[Webbot]

After doing some research it turns out that AVR Studio can write out 'stimuli' files during a debug session. These contain the values read from input ports. These can then be 'played back' during later sessions. So thats pretty close to what I was talking about. I'm waiting for Atmel to answer a few questions about how the file is organised so that I can work out how to record such a file myself 'on-the-fly' from a robot that is running. I've got the file format - just waiting for them to answer some 'what if' questions.

So rather that writing my own simulator it may just mean writing a tutorial once I can get it to work.

[Admin]

After doing some research it turns out that AVR Studio can write out 'stimuli' files during a debug session. These contain the values read from input ports. These can then be 'played back' during later sessions. So thats pretty close to what I was talking about. I'm waiting for Atmel to answer a few questions about how the file is organised so that I can work out how to record such a file myself 'on-the-fly' from a robot that is running. I've got the file format - just waiting for them to answer some 'what if' questions.

So rather that writing my own simulator it may just mean writing a tutorial once I can get it to work.

I'd be *very* interested in that tutorial!