ATMega168 - RS-232 and USART

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

Hi All,

I've run into an issue trying to connect the ATMega168 micro with a PC's RS-232 via USART. I've been attempting to follow tutorials on both this site and a few others.

My hardware setup is as follows:

PC --> USB to RS-232 converter --> DB9 connector

DB9 connector --> Op amp level converter (using TL082 op amp)

The level converter circuit is attached below. I've checked the properties of the port to make certain that the baud rate of the port matches the baud rate in br@y's terminal.

The IN4004 diodes are being used in the level converter circuit.

The AVR is using an external crystal at 8MHz, with the CKDIV/8 fuse set, running at 1MHz. The F_CPU value is set to 1000000 within AVR Studio 6 "AVR/GNU C compiler" section, under "symbols".

The baud rate is set for 4800 for a 1MHz clock rate. I selected this rate as I do not have any 7.3728MHz crystals available.

Within br@y's terminal, the baud rate is set at 4800, data bits = 8, parity = none, and stop bits = 1. The test program is expected to echo back the received value, however there is no response.

When measuring voltage, there is 5V present at the TXD pin of the AVR, and -0.5V at the RXD pin of the AVR.

Below is the full code that I'm attempting to use:

# include 
# define USART_BAUDRATE 4800UL
# define BAUD_PRESCALE (((F_CPU / (USART_BAUDRATE * 16UL))) -1)


int main ( void )
{
	
	char ReceivedByte ;
	UCSR0B = (1 << RXEN0 ) | (1 << TXEN0); // Turn on the transmission and reception circuitry
	UCSR0C = (0 << UMSEL00) | (0 << UPM00) | (0 << USBS0) | (2 << UCSZ00) | (0 << UCPOL0);  //Set the USART to asynchronous at 8 bits no parity and 1 stop bit
	
	UBRR0H = (BAUD_PRESCALE >> 8); // Load upper 8- bits of the baud rate value into the high byte of the UBRR register
	UBRR0L = BAUD_PRESCALE; // Load lower 8- bits of the baud rate value into the low byte of the UBRR register
	
	for (;;) // Loop forever
	{
		while (( UCSR0A & (1 << RXC0 )) == 0) {}; // Do nothing until data have been received and is ready to be read from UDR
		ReceivedByte = UDR0; // Fetch the received byte value into the variable " ByteReceived "
		while (( UCSR0A & (1 << UDRE0 )) == 0) {}; // Do nothing until UDR is ready for more data to be written to it
		UDR0 = ReceivedByte; // Echo back the received byte back to the computer

	}
}

Thanks,
Ben

Attachment(s): 

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

I'll let others look at your code.

One of the first trouble shooting steps you can take is to disconnect your op amp circuit from your micro and just connect the Serial to Pic and Serial from Pic lines together.

If you type on the PC the data should go out the USB, through the USB to RS-232 converter, then through the RS-232 to TTL level converter, and then get echoed back.

This confirms the PC's terminal program is connected to the USB port, and that the USB to RS-232 converter and RS-232 to TTL level converters are all working.

You don't generally need the DTR & RTS handshaking signals, at least to get started.

This doesn't verify the PC's baud rate, but it doesn't matter, as it echos back whatever it is being sent.

JC

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

Thanks for the info JC.

I tied the Serial-to-PIC and Serial-from-PIC together and did not get an echo on the terminal.

I was suspecting that the level converter might be at fault but didn't realize it could be tested this easily.

I'm assuming then that the Serial-from-PC and Serial-to-PC could be tied together, omitting the ttl-RS232 converter, to verify that the adapter on the PC is functioning properly? If so, I'll test and either build a two-transistor style level converter (have the parts on hand) or wait a few days and pick up a MAX232.

-Ben

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

Quote:
I'm assuming then that the Serial-from-PC and Serial-to-PC could be tied together, omitting the ttl-RS232 converter, to verify that the adapter on the PC is functioning properly?
Yes, you can short pins 2-3 on DB9 (better disconnected from all).

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

Yes, this is referred to as "loop back". It is a legitimate and important test.

However, it also has its short comings. for example, it will not verify correct baud rate, because the receive and transmit will always be at the same baud rate, no matter what the baud rate is.

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

it also will not verify that the levels are correct, both in amplitude and in logical level.

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

After testing, the level conversion circuit is not functioning. The loopback test yields no echo. I'm going to try the circuit attached below and see what comes about.

Attachment(s): 

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

When all is said and done, will you look back and say "Gee; I should have just used MAX232 or equivalent"?

And/or, take USB from the PC into FT232RL or equivalent with logic-level output and connect that to the AVR's USART? (i.e., skip the RS232 part)

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

For one off projects I don't know why anyone bothers taking things up/down to +12/-12V these days? It used to be that all you could buy on ebay were USB-RS232 cables so at the "RS232" end the AVR had to present +/-12V so it had to have a MAX232 or some cheap imitating circuit. These days "USB TTL" will hit a thousand <$3 cables on ebay so you just connect the "TTL" direct to the TXD/RXD pins of the AVR and forget about all the level translation nonsense. For a solder-phobic like me it's the perfect solution!

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

theusch wrote:
When all is said and done, will you look back and say "Gee; I should have just used MAX232 or equivalent"?

And/or, take USB from the PC into FT232RL or equivalent with logic-level output and connect that to the AVR's USART? (i.e., skip the RS232 part)

I completely agree, and that's what I'll be doing for the prototypes to be tested (around qty 10). Because I have these parts on hand, it's faster for me to throw together a circuit (assuming it works) then to order an IC at the moment. Digikey is 4-5 days typically for me, although I do have a few on order in the event I can't pull something together in the mean time.

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

I've used your second circuit, it works.

JC

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

Thanks clawson, I wasn't aware there were such converters. I've ordered one from ebay for the future to save this hassle.

Quote:
I've used your second circuit, it works.

JC

Thanks for letting me know JC!

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

The second circuit that was posted does work, and my comm issues have been resolved.

Thanks for the help all!

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

Just a quick message to anyone using this setup in the future.

For the USB to RS232 converter, I am using a Dynex brand model UBDB9 with the prolific driver v.1.9.0 (Windows 7 - 64bit). This model of converter seems to be very sporadic when doing a simple loopback test. When more than 4 characters are sent, the echo received is not consistent. You can send the phrase "testingtesting" and sometimes the entire string will be returned, and other times you may only get "tes". This is with trying several different baud rates, data bits, parity, and stop bit combinations.

I've tested this device on several other PC's (Windows XP, Windows 7 - 32 bit) with the same driver and still have similar issues.

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

You have not tested with speeds higher than 155Kbps I assume and I wonder what are the output voltage levels of that converter?