Need help in usb to serial converter

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

Hi i need some useful links to learn pc interfacing with avr atmega32. I want to know if i use a usb to serial converter, do i need to use a logic converter like max232 to feed data to microcontroller?

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

Quote:

do i need to use a logic converter like max232 to feed data to microcontroller?

You have two options. Either get a USB-RS232 cable (of which their are tons everywhere including $2-$4 ones on ebay) and then because it contains both a USB-UART and a MAX232 (equivalent) within the cable this means you have to put a MAX232 down next to your AVR on your own circuit to bring the signal levels back to TTL (and invert them).

The other alternative is to try and find a much rarer beast - a USB-TTL_Uart cable that only contains the USB-UART chip but has no MAX232 within it. As these are only really for use by embedded programmers (most commercial devices with serial have RS232 so require USB-RS232) then they are much rarer which means there won't be as much price competition so ironically, even though they contain less components they are likely to be higher priced.

EDIT: having said that my first ebay hit was:

http://www.ebay.co.uk/itm/RS232-...

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

And if you want one which apart from TxD, RxD and GND also has a power supply wire (the PC USB is the originator of this supply) then Adafruit has one, as pointed out to me just the other day:

https://www.avrfreaks.net/index.p...

(Remove all the spaces in the above and you should have a god URL to the place where I was pointed to Adafruits device. [cliff: edited to do that for you - I HAVE THE POWER! ;-)])

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Thank you for your help. I need to ask you one thing more. Can parallel communication of mcu with pc be said RS 232? Or just only the serial can be said so?

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

Quote:

Can parallel communication of mcu with pc be said RS 232? Or just only the serial can be said so?

Not sure what you are asking here. The language barrier and all that.. Anyway:

No, "parallel" is not "RS-232".

Yes, you can most likely get a dongle that does USB-to-"parallel". ("Parallel" is a very general term. When used in PC/Windows context it usually refers to a "Centronics printer port", perhaps with added capabilities.)

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Additionally, FTDI has an 8-bit parallel I/O to USB chip available.

JC

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

JohanEkdahl wrote:
Yes, you can most likely get a dongle that does USB-to-"parallel".
I looked into this a while ago, trying to get an old piece of parallel-connected equipment working with a modern PC, and all of the commercial USB-parallel adapters out there enumerate specifically as printer adapters, NOT generic parallel ports, due to the limitations of standard USB profiles. I found one that had a proper virtual parallel port driver, but that function was only supported in Win9x, not in XP or later. AFAIK, the only option on a modern OS (short of a proper expansion card) would be this AVR-based project, but you'll have to build it yourself, as it doesn't look like anyone's selling the hardware anymore.

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

JohanEkdahl wrote:
Quote:

Can parallel communication of mcu with pc be said RS 232? Or just only the serial can be said so?

Not sure what you are asking here. The language barrier and all that.. Anyway:

No, "parallel" is not "RS-232".

Yes, you can most likely get a dongle that does USB-to-"parallel". ("Parallel" is a very general term. When used in PC/Windows context it usually refers to a "Centronics printer port", perhaps with added capabilities.)

I meant parallel as printer port/ parallel port. 25 pin. Is this port can be said RS 232 port?

I have another question . what these code mean? Using avr studio 4

while(UDataAvailable()!=3);

_delay_loop_2(0);

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

Quote:

Is this port can be said RS 232 port?

No. There was a confusion in that the very early PCs used a 25 pin connector for both parallel and serial but when the IBM AT appeared it reduced the serial ports to just 9 pin connectors.

The PC1512 that our company designed (and sold several million of) was an IBM PC XT clone so it had D25's for both:

http://www.seasip.info/AmstradXT...
http://www.seasip.info/AmstradXT...

Quote:

what these code mean?

The function UDataAvailable() is called and as long as the value it returns is not 3 it will keep being called. When it does return 3 execution will continue to the next line where it does the delay. The function called this time is documented in the user manual:

http://www.nongnu.org/avr-libc/u...

As it says there:

Quote:
Delay loop using a 16-bit counter __count, so up to 65536 iterations are possible. (The value 65536 would have to be passed as 0.)
so it will execute 65536 times and as it says the loop takes 4 CPU cycles so this will delay for 65536 * 4 = 256K machine cycles.

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

I have another question. I have seen the commercial pcb's are green, red and blue. Where these coloured pcb boards are found? I saw arduino's blue, extremelectronics' green and sparkfun's red.

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

Many online PCB ordering services simply have a drop-list on the ordering page where you can specify what colour you would like. I think there's a sticky at the top of General Electronics to various "hobby" PCB prototyping services.

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

Thank you very much . Those were really helpful

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

I have a new question. how can i use start bit,stop bit and parity bit in sending data serially? say we are communicating with one microcontroller to another. one mcu will send data 0x52 and another mcu will light up 8 led's in portc. i have searched lot but couldn't understand the uses of these 3 bits. if possible, can you give me some example codes for helping me to use these bits?

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

The start and stop bits are generated and used by the UART hardware - The start bit is the sending UARTs way to signal to the receiving UART that transmission of a byte starts. The stop bit is a timed delay so that the receiver has some time to process the bit-train it just shifted in (and that is why you can find that there, for some UARTs, exists a setting called "1.5 stop bits").

The parity bit is an error detection mechanism. If you set the UART to even or odd parity then the hardware will compute the parity bit and send it. At the receiving end the UART checks that the parity bit is correct - if not it flags a parity error.

UARTs have a limitation on how many bits they can send, and the parity bit is often included. E.g. the classic UART in a PC could do 8 bits, but if you wanted a parity then there was only 7 bits left for data.

Short answer: Set your UARTs for 8 bits, no parity. With that you can send 8 bits of data to light up 8 LEDs.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Quote:

Short answer: Set your UARTs for 8 bits, no parity.

Even shorter answer: don't do anything - the AVR UARTs already default to 8-N-1

So just TXEN, set UBRR then load bytes into UDR each time UDRE says it's OK. At the receiving end set RXEN and UBRR then wait for RXC and when set read UDR and put it into PORTC. Nothing more is required (well apart from DDRC).

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

I have written codes for both transmitter and receiver and trying to communicate between two atmega 32. but i cannot . i haven't used level converter.

Code for transmitter is

#include 
#include 
#include 


void USART_Transmit( unsigned char data );
void USART_init(void);


void delay_(unsigned int i){
	while(i--){
		_delay_ms(10);
	}
}




void USART_Transmit( unsigned char data )
{
	/* Wait for empty transmit buffer */
	while ( !( UCSRA & (1<<UDRE)) )
	;
	/* Put data into buffer, sends the data */
	UDR = data;
}



void USART_init(void) {
	/* First init for the UART */

	UBRRL = 12;	 //4800 Kbps
	UCSRB = (1<<RXCIE)|(1<<TXEN)|(1<<RXEN);  //(1<<RXCIE) (1<<TXCIE)|			// 8 Databits, receive and transmit enabled, receive and transmit complete interrupt enabled
	sei();	// Global interrupt enable
}




int main(void) {
	 
    USART_init();
	
	delay_(100);  // 1s delay


	while(1) {
		
	   
		USART_Transmit(0xFF);
		 delay_(100);
		 
	}
} 

Code for Receiver

#include 
#include 
#include 

unsigned char USART_Receive( void );

void USART_init(void);

unsigned int rx_data;
void delay_(unsigned int i){
	while(i--){
		_delay_ms(10);
	}
}


ISR(USART_RXC_vect){
	
	rx_data = USART_Receive();
	
	} 

unsigned char USART_Receive( void )
{
	/* Wait for data to be received */
	while ( !(UCSRA & (1<<RXC)) )
	;
	/* Get and return received data from buffer */
	return UDR;
}
/*	ISR(USART_TXC_vect){

	} */



void USART_init(void) {
	/* First init for the UART */

	UBRRL = 12;	 //4800 Kbps
	UCSRB = (1<<RXCIE)|(1<<TXEN)|(1<<RXEN);  //(1<<RXCIE) (1<<TXCIE)|			// 8 Databits, receive and transmit enabled, receive and transmit complete interrupt enabled
	sei();	// Global interrupt enable
}




int main(void) {

    DDRC=0xFF;
	 
    USART_init();
	
	delay_(100);  // 1s delay


	while(1) {
		
	    PORTC=rx_data;
		delay_(100); 
		 
	}
} 

what's wrong here?? please help

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

I'm trying to light up 8 led's in portc of 2nd microcontroller

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

You transmitter code enables the RXCIE interrupt and does sei() yet there is no ISR() (and no point!). As soon as the UART receives a character the AVR will crash because of the "catch all" mechanism to catch unhandled interrupts (by doing a JMP 0).

The RX code gets closer to being right but you are using a non-volatile so you are subject to FAQ#1. Also why an int to transport an 8bit?

BTW I did say

Quote:
So just TXEN, set UBRR then load bytes into UDR each time UDRE says it's OK. At the receiving end set RXEN and UBRR then wait for RXC and when set read UDR and put it into PORTC. Nothing more is required (well apart from DDRC).

If you had done exactly what I said there it probably would have worked ;-)

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

Clawson, you are a genius..!!! Thanks a lot man!!! I can really communicate now between mcu's... :D :D :D