USART stk500 terminal issues

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DARN DARN DARN! I spent way to much of my afternoon trying to lick this one and am submitting it to yall out of frustration....

I'm getting the relatively common bad output usart problem. Ive tried searching the forum( where i found many threads on the subject but nothing that helped,)
On top of that Ive tried doing about everything I can think up and have failed thus far...

heres some details

HARDWARE:
atmega 128
stk 500/501
Serial cable connected to rs232 spare

FUSES:
103 compatibility is off
using external 3-8 mhz 4ms startup fuse
useing the stk onboard oscillator frequency at 3.6864

CODE:
In this block I set up my usart

/*
This function sets up the Usart for use
It uses:
2400bpm
8bit send
no parity
1 stop bit
no handshaking
*/
#define F_CPU 3686400
#include
#include "delay_x.h"
#include


//usart stuff
void Usart_Init(){
	UBRR0L=0x5F;	//the Baud_Prescale macro could be used here
	UBRR0H=0x5F >>8; //but i felt I should calculate it myself to be sure
  	UCSR0B=0x08; 		//sending only
	UCSR0C=0x06;		//asynchronous - no parity - 8bit
}//Usart_Setup

/*
This function sends chars through the Usart
module
*/
void Usart_Send(unsigned char data){
while ((UCSR0A & (1 << UDRE0)) == 0) {}; // Do nothing until UDR is ready for more data
UDR0 = data ; // Send out the byte value
}//Usart_Send

In this block I call to send out the usart



for (int i=1; i<=5; i++){
			
			Usart_Send(3);
			
			
			}//for

notice all i want to send is that 3 for testing at the moment...I believe Id do a right jiggy dance for joy if the 3 would show up on the terminal

So I get her fired up, pop up brays terminal and get a big wad of 0's (or 30 in hex)
Same thing for hyper terminal

note that if i try '3' i still get nothing good..it gives me hex 78

Also note that it consistently gives me a corresponding value to whatever Im sending (albeit a wrong one but at least its repeatable.) So whatever Im screwing up I dont believe it has to do with timing.

Please please ...any help would be greatly appreciated..Im feelin a bit low that I cant overcome such a common problem at this point....

Thanks yall[/code]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Try this...

while (!(UCSR0A & (1 << UDRE0)); // Do nothing until UDR is ready for more data 

And the following is from some code that I've used with my LynxMotion SSC-32 Thirty Two channel hobby serve controller.

The is written using the ImageCraft ICCAVR C compiler, v7.13

You can simply change it to USART0

#include  
// Crystal Frequency = 7.3728MHz

UCSR1A = NULL; // U2X = 0 = Single speed, MPCM = Single Processor
UCSR1B = (1<<RXEN1) | (1<<TXEN1); // RXEN = Enable, TXEN = Enable
UCSR1C = (1<<UCSZ11) | (1<<UCSZ10); // No Parity Bit, 8 Data Bits, 1 Stop bit
UBRR1H = 0x00; // 115.2K BAUD, 0% error @ 7.3728MHz
UBRR1L = 0x08; 	   



void USART1_Tx(char sendbyte) { 
    while (!(UCSR1A & (1 << UDRE1))); 
    UDR1 = sendbyte; 
}

char USART1_Rx(void) {
    while (!(UCSR1A & (1 << RXC1))); // RXC1: USART Recieve Complete
    return UDR1;
}

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I believe Id do a right jiggy dance for joy if the 3 would show up on the terminal

But 3 is not a printable character, so I would not expect that to work. '3' should, however.

I would try blinking an led at a particular frequency and see if you get the blink rate that you expect.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Koshchi wrote:
Quote:
I believe Id do a right jiggy dance for joy if the 3 would show up on the terminal

But 3 is not a printable character, so I would not expect that to work. '3' should, however.

Yeah... I forgot to mention that.

Try:

Usart_Send('3'); // ASCII equivalent for the decimal number 3.

or:

Usart_Send(0x33); // Hexadecimal equivalent for the decimal number 3.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

grr i get the exact same output...which I guess is comforting since I assume that code has worked....I guess that tells me its as timing issue....but why oh why would the 3.686 deafault stk 500 osc frenq not be comptable with usart comms...I mean its a usart magic number for christ sake

microcarl wrote:
Try this...

while (!(UCSR0A & (1 << UDRE0)); // Do nothing until UDR is ready for more data 

And the following is from some code that I've used with my LynxMotion SSC-32 Thirty Two channel hobby serve controller.

The is written using the ImageCraft ICCAVR C compiler, v7.13

You can simply change it to USART0

#include  
// Crystal Frequency = 7.3728MHz

UCSR1A = NULL; // U2X = 0 = Single speed, MPCM = Single Processor
UCSR1B = (1<<RXEN1) | (1<<TXEN1); // RXEN = Enable, TXEN = Enable
UCSR1C = (1<<UCSZ11) | (1<<UCSZ10); // No Parity Bit, 8 Data Bits, 1 Stop bit
UBRR1H = 0x00; // 115.2K BAUD, 0% error @ 7.3728MHz
UBRR1L = 0x08; 	   



void USART1_Tx(char sendbyte) { 
    while (!(UCSR1A & (1 << UDRE1))); 
    UDR1 = sendbyte; 
}

char USART1_Rx(void) {
    while (!(UCSR1A & (1 << RXC1))); // RXC1: USART Recieve Complete
    return UDR1;
}

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

so i changed the fuses to use 4mhz set the ubrr properly set the osccal and it works......(i guess I shoulda tried that earlier but I took for granted that the skt500 osc was stable enogh to accomplish my goal)

BUT I feel a bit pissed the stk 500 oscillator circuit that is supposed to use the magic number usart comm frenq by default failed me....

I mean i have crystals....and apparently for this slow transmission internal osc is fine...but thats all beside the point...did i use the stk 500 osc circuit wrong? is it just not that stable? WTF!!

Its a matter wanting to know at this point...

Thank yall for the advice btw!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Grrr all you like--the STK500 oscillator at its highest setting of 3.6864MHz (derived from a CTC timer off the controlling '8535 with 7.3728MHz crystal) will be right on.

I'd look at your STK500 jumper setup, and follow the signal from the OSCSEL jumper through to your target chip.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

STK500 Help-

Quote:
When using the STK500 software generated clock system as main clock, the target AVR microcontroller fuses should be configured for "external clock" as clock source.

Quote:
using external 3-8 mhz 4ms startup fuse
it sounds like you were not using 'external clock'. I don't know if that makes a difference or not, as I have no first hand experience running from the external clock on the stk500.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

curtvm wrote:
STK500 Help-
Quote:
When using the STK500 software generated clock system as main clock, the target AVR microcontroller fuses should be configured for "external clock" as clock source.

Quote:
using external 3-8 mhz 4ms startup fuse
it sounds like you were not using 'external clock'. I don't know if that makes a difference or not, as I have no first hand experience running from the external clock on the stk500.

I only run the STK500 on the external clock. That's because I'm always using different crystal frequencies.

Unlike Lee's "Old Fogey " Sunday afternoon drive tactics, I LIKE SPEED, and lots of it - just not in a car!

Why, just yesterday, I was running a Mega644 at 28MHz - purely experimental... I need a 33MHz crystal to do what I really want to do.

So, guess what? You have to set up the fuses in the target controller for an external oscillator of some sort. I usually just select the very last fuse option - for all of the micro-controllers that I use.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

see the thing is i set the external oscillator fuse....and heres the really wierd one..if i connect a 3.686 crystal aand proper set fuses/jumpers it works....but still nothing good from the stk's clock when i set its fuses jumpers correctly...maby mine is borked???

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

it sounds like you were not using 'external clock'. I don't know if that makes a difference or not, as I have no first hand experience running from the external clock on the stk500.

I've never seen where it mattered. In my experience the STK500 clock blasts the signal nicely into XTAL1 (or whatever it is on your AVR model) with a lot of drive so it overwhelms an AVR that is trying to crystalize. But maybe that isn't rue in all cases, such as with modern P chips and the like.

To rube--what DO you see on the pin on the OSCSEL header with a 'scope?

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.