Squirrels have fuzzy tails.
0 Members and 1 Guest are viewing this topic.
int main(void) { configure_ports(); printf("hello world"); }
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?
#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++ streamsint uart_putchar(char, FILE *);int uart_getchar(void);void uart_init(void);
#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 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 fileCode: [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++ streamsint uart_putchar(char, FILE *);int uart_getchar(void);void uart_init(void);And the uart.c codeCode: [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.
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
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!!!!!
Quote from: Webbot on June 10, 2008, 01:05:43 PMAVR 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 muchYou 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
Quote from: bens on June 16, 2008, 11:48:09 PMQuote from: Webbot on June 10, 2008, 01:05:43 PMAVR 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 muchYou 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.- BenYes 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.
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.