Pages

A common technique for a ‘RS232’ receiver was to use a zener diode, resistor and a ttl inverter. Not quite to spec, but worked in most cases. Similarly, you can use a ttl device to output ‘RS232’ for short distances.

In days gone by it was one of the two many I/O methods for PC's, (the other being the Centronics parallel interface).

RS-232 signal levels are:

0 = +3 to +15 V

1 = -3 to -15 V

These are measured with respect to a common Ground connection between the two devices.

The -3 to + 3 V range is a no man's land, which improves the noise immunity and data integrity for the signal transmission.

In practice, many old RS-232 devices routinely used +/-12V, some original IBM printers and other devices used +/-15V.

When Laptops first starting hitting the market, and size, weight, and power consumption were an issue, many laptops clamped the negative signal to ground, and didn't bother generating a true negative voltage.

Because most devices used a "standard" RS-232 line driver chip set, (1488 and 1489, IIRC), and the receiver worked fine with the ground level replacing the negative level, it worked.

RS-232 inverts the signal. But as one typically has an RS-232 chip driver on both ends of the connection, the signal polarity ends up "correct", (i.e. non-inverted).

TTL is typically 0 and 5 V levels.

So, if one "inverts" the signal, and uses 0/5 V signal levels, one could in fact call it (pseudo) RS-232.

To drive the LCD it appears that one could use the USART module if one inverted the output pin polarity.

On the Xmega's this is a simple set the bit in the register process to invert the I/O pin's polarity.

One could easily do this in hardware with a 2N7000 and a 10K resistor.

This assumes one is only sending data to the LCD, and doesn't need to read data back out from the LCD.

One can often define the output signal polarity when using a software USART, also; which would be another option.

Again, without having read the entire Thread, it looks like the OP might simply have to connect "logic level" (i.e. 5V) signals to the LCD, but INVERT the usual USART output.

I am not sure why this is so difficult to do. I have now purchased an LCD with serial backpack from AdaFruit.

It powers up as it should with the ADAFruit name etc.

I am using an ATMEGA 32A and am taking the output from pin 15 to the input of the backpack.

I then Build and Burn the attached program and I get repeated characters that look like the upper left corner of a square and the lower right corner of a square outlining the 'square' where each character is supposed to show.

I cannot get any other characters to show. Please let me know what I can try to get this thing working, it can't be this difficult. Code attached.

One million divided by 32 divided by 9600 equals? Convert the result to an integer. Reverse the calculation. You get a significant error.
The datasheet has a nice little table of frequencies and baud rates. In that table there is 1MHz and 9600 baud. It tells us the error is too great. This is why your code won’t work. There’s a bit called U2X. Set this bit and recalculate the baud rate divisor.
Note that using the internal oscillator may cause problems- its specified error can to be too large for serial comms. Use a crystal.
Also realise you’re probably the millionth person who has fallen for the same trap. Did you not Google? Or try an online baud rate calculator?

BPI-216s accept inverted serial input, such as the output of an *RS-232 port. The direct output of a UART is noninverted; it is not compatible unless inverted (NOT gate). In some cases, workarounds exist to avoid the additional component:

Basic Stamp SEROUT instructions accept a parameter that inverts the output in software.

Jim, My apologies for starting a new thread. This one had diverged so much from my original question I thought it best to start again especially since I received no responses from here to my new question and I am using a different LCD now.

Thanks for setting me straight on this issue. Is there any way that I can respond to those who had replied to the newer thread?

Kartman, Your suggestions worked and I have an LCD to which I can write now.

Thanks to everyone for your help. The problem seemed to be solved by using the U2X bit set for better accuracy at 9600 baud. I will certaainly use an external oscillator but it is working on the internal clock for now.

Kartman, As a newbie, I had no idea to look for a link between 1MHz and a baud rate of 9600. Why would I connect these two ideas?

As a newbie or experienced guru, you always need to confirm that your UART clock is appropriate for the desired baud rate. On an AVR8, as you know, the UART clock is derived from the system clock, via UBRR (see the datasheet for the gory sampling details).

Pick an AVR clock speed -- any clock speed. So you have your 123456Hz speed. If you want to use that clock and UBRR and send stuff over a UART, you cannot pick just any bit rate, ans the error with the clock divider needs to be within certain limits for usable UART communications.

This is also gone through at some length in the datasheet.

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.

AVRs have been around for about 20 years now, so there's been plenty of others before you trying to do the same thing. Basically, any question you have about AVRs has already been asked and answered - maybe a zillion times. The popular ones are to do with fuses and uart - so much so that there are online tools to calculate fuse values and baud rates. Go and google them. There's also a wealth of tutorials that explain the basics so you can avoid the common problems.

Kartman, As a newbie, I had no idea to look for a link between 1MHz and a baud rate of 9600. Why would I connect these two ideas?

I was going to say that the chapter on UART in the mega32 datasheet would have explained it but I just had a quick scan through and the only relevant thing I can spot right now is:

but as Lee noted the other day, although that says about entries being bold, they aren't!

The key thing about UART use is that it only works up to the point where the timing at either end differs by about 4%. That means there can be an error as great as 2% at either end. Baud rate combinations beyond that will most likely not work. It is a bit of a shame that the Atmel datasheets don't come right out and say this at the very start of the chapters about UARTs in each datasheet as the presence of FAQ#3 in my signature here is because this thing about baud errors is possibly one of the most talked about errors in the whole use of AVR. At this stage I must have read literally hundreds of threads attempting 9600 at 1MHz not realising that without U2X it is -7.0% and will not work. If Atmel had alerted users to the importance of the Error% in the datasheets it could have prevented a lot of problems!

-- Some years back, there was a thread I remember where a poster opined that "important" stuff in the datasheet should be emphasized. Bold, larger type, boxed, similar. [IIRC the poster also did not like the number of datasheet pages -- wouldn't such emphasis take more space/more pages?]

My response at that time was for that poster to list for a datasheet section the information that was >>not<< important, and should thus not be emphasized. The air waves became strangely quiet...

-- A datasheet chapter subsection is devoted to the gory details, and this subsection is linked in Cliff's quoted excerpt above. Newbie or veteran, if there are questions about [in this case] an AVR peripheral subsystem I'd expect a good reading of the pertinent chapter.

I guess the first paragraph isn't dire enough to catch anyone's attention. Not even phrases like "not able"?

Yes, as I dug out in the other thread Cliff mentioned, the claimed highlighting of near-perfect combinations seems to have been lost over the years in AVR8 datasheets. But haven't we learned here that OP never looked at those tables anyway?

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.

Lee, usually I'd agree completely and say that a datasheet is just to present the facts and not attempt to act as a tutorial but on this occasion just one sentence about the 2% limit could have prevented massive numbers of support queries.

(how Freudian, my word predicting keyboard on this tablet had typed "prevent" rather than "present" above. It must know Atmel datasheets!)

but on this occasion just one sentence about the 2% limit could have prevented massive numbers of support queries.

Didn't I post a paragraph warning of gross discrepancies?

And there is a detailed section that follows that paragraph, with the math.

And...

awneil wrote:

But only if people bothered to read it ...

...for those people there is a picture.

Just one sentence, eh? Like this one (in the paragraph following the tables):

There are two possible sources for the receivers baud rate error. The Receiver’s system clock
(XTAL) will always have some minor instability over the supply voltage range and the tempera-ture range. When using a crystal to generate the system clock, this is rarely a problem, but for a
resonator the system clock may differ more than 2% depending of the resonators tolerance. The
second source for the error is more controllable. The baud rate generator can not always do an
exact division of the system frequency to get the baud rate wanted. In this case an UBRRn value
that gives an acceptable low error can be used if possible.

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.