Another Usart problem

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

so I have seen a number of threads with usart problems, but nne are helping me iron out alittle bug.

I am trying to implement a wireless device. My wireless modules work. I am able to connect them to the usart and see that they are sending stuff.

The problem is when I try to send anything I cant get it to show up the same on the recieving side.

im using a atmega128

so heres some test code from my program

btw #define F_CPU 8000000 is on both

//USART DEFINES
#define USART_BAUDRATE 9600 
#define BAUD_PRESCALE (((F_CPU / (USART_BAUDRATE * 16UL))) - 1)


void Usart_Init(){
	UBRR0L=BAUD_PRESCALE;			//for this one the define calc will give 51 or 0x33
	UBRR0H=BAUD_PRESCALE >> 8; 
  	UCSR0B=0x08; 		//sending only
	UCSR0C=0x06;		//asynchronous - no parity - 8bit
}//Usart_Setup

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


void _Send(int temp){
		Usart_Send(1);
	}//send()

and the reciver side


//USART DEFINES
#define USART_BAUDRATE 9600 
#define BAUD_PRESCALE (((F_CPU / (USART_BAUDRATE * 16UL))) - 1)


//usart stuff
void Usart_Init(){
	UBRR0L=BAUD_PRESCALE;			//for this one the define calc will give 51 or 0x33
	UBRR0H=BAUD_PRESCALE >> 8; 
  	UCSR0B=0x10; 		//recieving only
	UCSR0C=0x06;		//asynchronous - no parity - 8bit
}//Usart_Init
unsigned char Usart_Recieve(){
while ((UCSR0A & (1 << RXC0)) == 0) {}; // Do nothing until data have been received and is ready
return UDR0; // Fetch the received byte value
}//Usart_Recieve

void Error_Correction(){

	while (Usart_Recieve()!=1){}
	
C_SETBIT(r20);
}//Error_Correction

so I used to have a checksum algorithim in error correction.
Now I am just trying to get the same data. that function hangs and never gets the 1 I send..

why?

The txd pin of my stk501 is the sender side

and the rxd pin of another is my recieve[/code]

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

You may have verified the clock speed of the transmitter and set the fuses on that correctly. But is even basic comms on the receiver working? Is it clocking at the right speed. As a test write a program on it to TRANSMIT not receive and check that it's working in a PC terminal or similar

Cliff

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

i can verify the reciever side is recieving something....isnt my code to set up the usart all i need or is there some special com speed settings nestled away somewhere

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

Quote:
The txd pin of my stk501 is the sender side
and the rxd pin of another is my recieve

Actually you may have to explain your connection in more detail. For the simplest test I would expect you connect PE1 (TXD0) on one stk501 to PE0 (RXD0) on the other (+ a GND connection also), is this what you have?
/Lars

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

yup thats what i have

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

hmm...now that i think about it..i dont have the port e gorunds connected between the 2

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

hmm same thing...im recieveing stuff...just not the value i put in

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

If you are using the internal RC oscillators, then the baud rates are probably not matching. The internal oscillator can be as much as 10% off the nominal value.

Regards,
Steve A.

The Board helps those that help themselves.

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

osccal then? something tells me your right

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

But what do you use to 'cal' your oscal?

(for an easy life comms is 1000% easier with an accurate crystal or other accurate timing reference)

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

well...as soon as realized why things kinda fell into place.....i set the calibration bytes on both sides and got a few transmissions....later that night I kinda fudged it by setting int0 to rxd of the recieving side and implemented something close appnote avr054 ....incremented osccal till i was within range to properly communicate....but after having nearly gotten that to fully work I remembered this is a wireless device(when I dont have the usarts directly connected to get them working first...so today Im buying external crystals for both sides....

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

im afraid wireless intereference might hurt the sync routine...(my linx wireless modules talk via the usart)

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

could someone reccomend a good CHEAP crystal/oclliator that isnt temperature sensitive?

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

What do you mean "cheap"? "Inexpensive" in qty. 100 or 1000 may have no bearing on the price of obtaining one.

>>Is<< there one that >>isn't<< temperature sensitive? Are we supposed to answer your question, or put it into the context of this thread? The thread has been discussing gross deviations, way off, and the like. A normal crystal may be like 20ppm per degree C worst case. Over the range of temperatures on your bench the deviation won't mean spit for serial comms. An oscillator has more drift but again will not deviate enough to make a difference.

I'll bet there are over 100 to choose from at your desired frequency at DigiKey alone.

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

your right..i worded that wrong...i meant along the lines of if anyone had a favorite brand of crystal that had a good spec in terms of deviance from frequency as a result of temperature

...and yes i looked at digikey before asking the question in the first place

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

well i ordered the full gamit.....

1 2 XC945-ND CRYSTAL 3.6864MHZ 18PF CYLINDER
2 2 CTX401-ND CRYSTAL 3.6864 MHZ 20PF LOAD CAP
3 2 631-1079-ND CRYSTAL 3.6864 MHZ SERIES

the datasheet for the atmega128 said 22pf load capacitence ...but didnt see any 22pf...but i bet i can make it work with an external circuit....