Trying to send RS232 with PIC sends incorrect data in TeraTerm

wrote in message news: snipped-for-privacy@o5g2000hsb.googlegroups.com...

Hint. Common mistake. Same one in CCS. They have their setup line called '#use RS232', but in fact it sets the chip up to produce TTL asynch serial, which _requires_ the MAX232 (or similar), to 'generate' RS232 signalling. In fact the same software setup is used with different hardware, to provide RS485, or a number of other similar standards. The CP2102, is exactly the same. It _does not_ provide USB to RS232 functionality, it provides USB to asynch TTL serial, and also requires a MAX232 or similar transceiver to generate 'RS232'. If you look at the data sheet for the chip, it shows an 'external RS232 transceiver' _after_ the chip, to generate RS232 signalling levels, and signal polarity. Now you are talking about a 'breakout board', which suggests you are accessing the CP2102 directly. If so, it's connections, want to go _directly_ to the PIC, without the MAX232 transceiver. This would explain the signals being inverted, since each MAX232 inverts the signals, as well as shifting the voltage levels used, and you have one missing. You need to either run with none (TTL signalling), or with _two_ - RS232 signalling between these. Check the voltages being produced from the 'breakout box', with the scope. I suspect you are going to find these are basically 5v levels. If so, get rid of the MAX232. I just hope you have not damaged the chip, since the MAX232, delivers +/-12v signalling, and if I am right, you have been feeding this into a chip rated for 5v signalling...

Note that this _correctly_ says this is a _USB to serial_ adapter,_not_ a USB to RS232 adapter. Get rid of the MAX232 on the PIC.

The problem is that you don't need the MAX232, since you are not using RS232 signalling anywhere...

Best Wishes

Wow, I even impressed my self !!!

Ok, the PIC board works as programmed.

So whats wrong with the CP2102 board.

I have these CP2102 boards here as well. Works fine for me.

By your scope trace I see that this is a 5 volt system.

The CP2102 is a 3 volt system. Are the CP2102s 5V tolerant ??

So, I imagine that you had the CP2102 board connected directly to the Sin and Sout pins of the PIC.

Are these scpoe traces with the CP2102 and PIC connected together ??

Just guessing, check that loading of the CP2102 and PIC.

donald

usingRS232signalling anywhere...

I will definitely check the voltages coming out of the Tx pin on the USB to serial board. We actually ruined a PIC and we had assumed it was because the Tx pin was delivering 12V, and thus added the Max; but I guess it was some other mistake. I will let you know what I find.

The chips have worked fine when shorting the lines, as late as today, so I hope that means that the incorrect delivery voltage has not hurt it.

I guess the old saying, about what happens when you assume, is true. I had assumed that since it was creating 9 pin serial it was creating RS232 level signals. It will be interesting to see if removing the middle man is the solution we were hoping for.

As Roger pointed out above somewhere, we were running our signals through a max 232, when apparently the cp2102 wants 5v signals. Tomorrow we will try out removing the Max chip.

Or even a PC with a real serial port...

Not true. more than 10% total timing error will break any baud rate (assuming 8n1 line discipline)

Bye. Jasen

Less than this. Assuming the receiver tries to sample at the centre of the bit time, and synchronises from the falling edge of the start bit, the maximum total error allowed, is enough to cause 1/2 bit time error in 8

1/2 bit times (it is like the difference between the number of fence posts, and fence panels - you sample in the middle of each bit time, so for 8 bit data, there are just 7.5 bit times from the end of the start bit to the last sampling location). 6.25%. Even using 7bit data, you still only have a maximum of 7.14%. Less in both cases with parity enabled (5.5% for 8 bits with parity). Remember also that the clocks on UART's on a normal PC, are often slightly in error (systems with the 'spread spectrum' feature enabled in the BIOS, often exhibit a percent or more timing error...), and you can see why an absolute 'maximum' error of 4% in the timings at the other end, is often used as a good guide.

Best Wishes

I forgot to respond on here, but this was indeed the issue. Removing the Max removed the problem. Now on to more important coding!

Thanks much.