ATMEGA 32A UART Question

Go To Last Post
77 posts / 0 new

Pages

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

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.

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

I 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...

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

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...

 

 

 

 

 

Last Edited: Wed. Oct 4, 2017 - 01:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So any device that accepts a converted TTL signal should be described as a device that accepts TTL?

 

Thanks,

Dave

 

 

David Abineri

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

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.

 

JC

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

dabineri wrote:
any device that accepts a converted (sic) TTL signal

What 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.

 

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

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.

 

Many thanks,  Dave

Attachment(s): 

David Abineri

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

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?

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

Can 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

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

clawson wrote:
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-232inverted-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.
  • Arduino v1.0+ SoftwareSerial supports inverted output: SoftwareSerial(rxPin, txPin, 1); (where 1 sets inverted output).
  • 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.

 

https://www.seetron.com/bpi216/b...

 

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!

 

blush

 

Last Edited: Mon. Dec 4, 2017 - 11:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

 

Dave

David Abineri

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

Thanks, Kartman, I am investigating these ideas now and had not found them elsewhere when googling. 

 

I appreciate your comments, Dave

David Abineri

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

I googled avr 1MHz 9600
Get a feeling of deja vu?

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

dabineri wrote:
Is there any way that I can respond to those who had replied to the newer thread

Simply copy what they posted there, paste it here as a quote, and reply ...

 

EDIT

 

Oh - and include a link.

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

 

Thanks again.   Dave

David Abineri

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

dabineri wrote:
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

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

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?

 

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

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

dabineri wrote:
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.

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

what 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.

 

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

dabineri wrote:
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!

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

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......

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

js wrote:

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.

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

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 cheeky.

 

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

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

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!) 

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

clawson wrote:
just one sentence about the 2% limit could have prevented massive numbers of support queries.  

But only if people bothered to read it ...

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

clawson wrote:
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.

Pages