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.
I've skipped through the thread, so maybe I'm repeating something already mentioned.
RS-232 is a physical interface standard.
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.
JC
Edit:
Cross post with others who are less wordy than I am...
A device which accepts 0/5 V (logic level) signals can generally be considered TTL compatible.
This doesn't take into account whether or not the signal was inverted somewhere along the data processing chain.
There are lots of "details" about specific switching thresholds and current drive capabilities, but for a simple analysis on your connectivity issue they aren't important.
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?
That picture (ie the text) is misleading. Sure it says "inverted-TTL" but it is immediately preceded by "RS-232".
Actually, my little red box highlighting is obscuring a slash between "RS-232" and "inverted-TTL"; it actually says, "RS-232 / inverted-TTL" - which is, presumably, intended to mean, "works with both RS-232 and inverted TTL"
On the 'Hardware Reference' page, Seetron wrote:
Serial Input
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.
PIC microcontrollers with the "enhanced" USART (EUSART) can be configured for inverted output by setting the SCKP bit of the BAUDCON register during USART initialization.
*RS-232 serial signals often use ±10V signals. These voltages will not harm the BPI-216, which has a protective "clamp" circuit on its serial input.
Sorry, I got here via the OP's recent (now Locked) re-post of the same question - and missed the fact that there was another page of stuff after Cliff's comment!
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.
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.
Not really, and in post #58 you tell us that you bought a new LCD from Adafruit so there was no need to start a new thread.
dabineri wrote:
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.
What do you call Posts # 59, 60 and 61?
dabineri wrote:
Is there any way that I can respond to those who had replied to the newer thread?
Your answer is:
awneil wrote:
Simply copy what they posted there, paste it here as a quote, and reply ... EDIT Oh - and include a link.
Jim
If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman
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!
If Atmel had alerted users to the importance of the Error% in the datasheets it could have prevented a lot of problems!
Or if people would do some basic electronics and programming courses......
I'll almost always "up vote" Cliff's responses. In this case, though, I cannot agree.
-- 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.
My first encounter with UARTs was at a time before micros were very popular, the UART was being clocked by CMOS logic and the data (switches status) was selected in with gates and latches.
This run Westmead hospital in western Sydney, (the largest in the southern hemisphere at that time) for decades, I guess the stuff may have upgraded by now .
So I learned the hard(ware) way about serial comms.
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.
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.
- Log in or register to post comments
TopI think what it's saying is that it will accept either TTL (unipolar) or RS232 (bipolar) levels.
RS232 transmitters are usually inverting - so, if you skip the transmitter, you still need to provide an inverter...
Top Tips:
- Log in or register to post comments
TopI've skipped through the thread, so maybe I'm repeating something already mentioned.
RS-232 is a physical interface standard.
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.
JC
Edit:
Cross post with others who are less wordy than I am...
- Log in or register to post comments
TopSo any device that accepts a converted TTL signal should be described as a device that accepts TTL?
Thanks,
Dave
David Abineri
- Log in or register to post comments
TopA device which accepts 0/5 V (logic level) signals can generally be considered TTL compatible.
This doesn't take into account whether or not the signal was inverted somewhere along the data processing chain.
There are lots of "details" about specific switching thresholds and current drive capabilities, but for a simple analysis on your connectivity issue they aren't important.
JC
- Log in or register to post comments
TopWhat the device sees needs to be a TTL-level signal; that is all - it neither knows nor cares if that signal has been "converted" from something else.
Top Tips:
- Log in or register to post comments
TopI 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.
Many thanks, Dave
Attachment(s):
David Abineri
- Log in or register to post comments
TopOne 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?
- Log in or register to post comments
TopCan you post a link to the LCD you bought from ADA?
Jim
If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman
Please Read: Code-of-Conduct
Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user
- Log in or register to post comments
TopActually, my little red box highlighting is obscuring a slash between "RS-232" and "inverted-TTL"; it actually says, "RS-232 / inverted-TTL" - which is, presumably, intended to mean, "works with both RS-232 and inverted TTL"
EDIT
Sorry, I got here via the OP's recent (now Locked) re-post of the same question - and missed the fact that there was another page of stuff after Cliff's comment!
Top Tips:
- Log in or register to post comments
TopJim, 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?
Dave
David Abineri
- Log in or register to post comments
TopThanks, Kartman, I am investigating these ideas now and had not found them elsewhere when googling.
I appreciate your comments, Dave
David Abineri
- Log in or register to post comments
TopI googled avr 1MHz 9600
Get a feeling of deja vu?
- Log in or register to post comments
TopSimply copy what they posted there, paste it here as a quote, and reply ...
EDIT
Oh - and include a link.
Top Tips:
- Log in or register to post comments
TopKartman, 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.
Thanks again. Dave
David Abineri
- Log in or register to post comments
TopNot really, and in post #58 you tell us that you bought a new LCD from Adafruit so there was no need to start a new thread.
What do you call Posts # 59, 60 and 61?
Your answer is:
Jim
If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman
Please Read: Code-of-Conduct
Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user
- Log in or register to post comments
TopKartman, 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?
Looking back now at what has been said, it is obvious that that might have been a good search.
I find that one of the values of a forum like this is to be pointed in the right direction.
But when just starting out it is very difficult to know what to search for you answer your particular problem.
Thanks again for your help. Dave
David Abineri
- Log in or register to post comments
TopAs 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.
- Log in or register to post comments
Topwhat if you googled mega32 uart problems?
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.
- Log in or register to post comments
Topbut 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!
- Log in or register to post comments
TopOr if people would do some basic electronics and programming courses......
John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
- Log in or register to post comments
TopI'll almost always "up vote" Cliff's responses. In this case, though, I cannot agree.
-- 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.
- Log in or register to post comments
TopMy first encounter with UARTs was at a time before micros were very popular, the UART was being clocked by CMOS logic and the data (switches status) was selected in with gates and latches.
This run Westmead hospital in western Sydney, (the largest in the southern hemisphere at that time) for decades, I guess the stuff may have upgraded by now
.
So I learned the hard(ware) way about serial comms.
John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
- Log in or register to post comments
TopLee, 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!)
- Log in or register to post comments
TopBut only if people bothered to read it ...
Top Tips:
- Log in or register to post comments
TopDidn't I post a paragraph warning of gross discrepancies?
And there is a detailed section that follows that paragraph, with the math.
And...
...for those people there is a picture.
Just one sentence, eh? Like this one (in the paragraph following the tables):
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.
- Log in or register to post comments
TopPages