silly question about rs232 port

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

hello, i am using usart of Atmega32. and i have this question: according to the datasheet, the highest baud rate is 1M. this 1M means 1000000 or 1024*1024? and the error is said to be 0%. is it real? on the PC side, i use a RS232 to usb cable, whose highest speed is also said to be 1M. does it mean my device can work at 1Mbps stably?

thanks

nancy :P

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

this 1M means 1000000 or 1024*1024?

It means decimal 1,000,000.

 

The issue you may have is whether your PC end can be set to an accurate 1M too.

 

The next issue you have is how can a mega16 actually handle sending or accepting data at that rate. It's just short of 100,000 bytes per second. What on earth is the AVR producing or consuming to maintain that kind of data rate?

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

I think you'll find it is 1000000. 16MHz divided by 16 gives 1000000.
You'll need a chip to give you RS232 levels - depending on your choice, it may or maynot do 1Mbit.

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

Yes.  Most USB cables can manage this speed.    A regular RS232 cable is supposed to limit the slew rate (which effectively means a maximum of 230kbaud)

 

OTOH,  is your typing fast enough?

 

David.

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

is a rs232 to usb cable a 'regular RS232 cable '? 

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

max232 is the chip i use. does this chip affect the highest baud rate? 

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

nancy0116 wrote:
max232 is the chip i use. does this chip affect the highest baud rate?

In any communications link, the maximum achievable speed is limited by the slowest thing in the link - just as a chain is only as strong as its weakest link.

 

 The max232 datasheet will tell you its maximum speed

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

the mcu is atmega32 and it's sending out data when data is ready. in the datasheet it says when the baud rate is 1M (16M external crystal), the error is 0%. someone told me 1M is hard to reach in harsh circumstances. so i'm confused if the data i recieve is realiable on PC...

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

No the MAX232 should not affect things.

 

BTW you do know that you don't actually NEED a MAX232 don't you? If you use a USB-TTL (about $2 ebay) rather than USB-RS232 adapter cable between PC and AVR then you can just connect it direct to the Tx/Rx pins of the AVR. As it stands your AVR has a MAX232 and so does the USB-RS232 cable so you are making a needless transition from TTL->12V->12V->TTL when it could just be TTL->TTL.

 

I'm still intrigued to know how this mega16 is going to be able to produce/consume data at that rate.

 

We see many "boy racer" (and "girl racer" I guess!) threads here from AVR users who are either trying to make their AVR go as fast as possible or their comms link go as fast as possible and yet when you explore what they are actually doing you often find the CPU could be running at 1MHz and the comms link at 300 baud or similar. Certainly if there is a human involved they just cannot consume (read) characters delivered very much faster than 300 baud. As David said:

is your typing fast enough?

EDIT:

 someone told me 1M is hard to reach in harsh circumstances. so i'm confused if the data i recieve is realiable on PC... 

Which just adds to the question - "why do you think you need to  run the link so fast?" They are right that the link will be more susceptible to electrical effects at that kind of speed.

Last Edited: Fri. Jun 26, 2015 - 09:10 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ach so! MAX232 says:' Maximum recommended bit rate is 120 kbps.' that is the highest baud rate!

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

You didn't answer clawson's question: why do you want to go that fast anyhow??

 

Did you also note the point about the MAX232 being a needless translation?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

the usart is waiting for the data to be ready and then send it out asap. the data is ready like every 0.5ms. in order to acquire as many as data in as little as time, i hope the baud rate is highest as possible.. max232 is already on the evaluation board and i cannot change it...i learned that the max rate of max232 is 120Kpbs. is this the highest baud rate i can use?

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

Sorry but you are only sending data every 0.5ms but it has to be 1M ?!?

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

because the host needs data urgently...so i hope the transmission is as fast as possible...the usb to ttl advice is great but i am limited to rs232...

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

i hope the mcu send out the data as fast as possible.. at 16M cpu frequency i thought the baud rate is 1M highest. but it is limited to 120 Kbps due to max232....

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

How much data?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

32bits, every 0.5ms...

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

At 115,200 those 32 bits (assuming 8N1 framing - so 11 bit frames) would be at the destination 382us later.

 

At 1,000,000 they would be there after 44us. So does their arrival 338us later using a "sensible" baud rate make a difference?

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

yeah you are right... 

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

If you can't live with a delay, you have to use a real RS232 on your PC, the converter and windows drivers will add a delay. 

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

There are different MAX232 chips, the one I use (from TI), can do 250K(that means 230400) 

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

it does not matter as long as the data are right received... several ms delay is ok..

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

damn it.. i thought there is only one kind of max232...thanks for your info!

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

several ms delay is ok..

I love threads like this cheeky

 i thought there is only one kind of max232

And why do you think you even need a MAX232 at all? Is this AVR going to be connecting to something that really does use -12V/+12V signalling? If it's just a (modern) PC you don't need one (if you get the right kind of USB cable).

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

it does not matter as long as the data are right received... several ms delay is ok..

!!!!!

So why does 300 us matter but ms don't ? 

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

actually the project is applied in industrial field.. rs232 is needed.. later maybe rs485...but not usb...

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

The next issue to consider is how to determine which is the first byte and how to determine if you've received them correctly. You need a means to synchronise the receiver and a checksum or crc to validate the data.

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

eh...because it's periodic?  the converter delays every frame. but the frame interval is still 300us...right?

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

nancy0116 wrote:
I thought there is only one kind of max232...

If in doubt, always visit the Manufacturer's website

 

There you will see that there is a MAX232 and also a MAX232A - plus a whole range of other RS232 Transceivers:

 

http://www.maximintegrated.com/e...

 

And there are also "2nd-source" MAX232 from other manufacturers; eg, http://www.ti.com/lit/ds/symlink...

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

how to determine which is the first byte? first received by the PC is the first byte, isn't it?

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

wait mine is also from TI. max232n...but the datasheet says "Operates up to 120 kbit/s''...how come..

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

Andy - Maxim was the second source! Intersil was the first with the icl232. Maxim second sourced it. One of the few instances where the original is not the one that became the generic.

Nancy - because it's periodic? What happens when your PC application fires up and starts counting four characters from the second one? How is the PC going to be able to accurately measure the timing? You'll find most communication schemes have a method of synchronisation. What happens when you get a transient that upsets your communication? How will the PC be able to detect this?

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

that's also my concern! it's disaster if the PC starts counting 4 bytes from the second one! i have already done some tests with the help of LabVIEW(whose duty is to receive the bytes onPC and combine them every four).  i did clear the serial port buffer(on PC) to guarantee the first byte received is the first byte sent out..  but the problem exists! sometimes the data look right, sometimes seem wrong. how do i actually synchronize?

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

I still want to hear why you can live with n ms delay, but not 300 us delay made by the baud rate? 

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

if this this slow (a lot of nothing) the easy way is to send a break between each packet.

 

but just a timeout (no chars for n ms) flush the buffer, if the packet aren't correct. 

 

and then add CRC and all the good stuff, look at some existing protocols. 

Last Edited: Fri. Jun 26, 2015 - 11:56 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

baud rate will affect the sending interval. the higher the baud rate is, the shorter is the sending interval. the delay from the converter will delay every frame, won't it? if every frame is delayed, then it make no difference for the sending interval.   i guess...

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

Short no

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

what is a 'break between each packet'?

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

higher baud rate will not shorten the sending interval? 

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

I can think of a case when Real Fast serial is useful.... I had a gizmo with displays and buttons and encoders and leds talking to a host computer with ethernet... I used an mega1280 with 4 uarts... one went to the xport ethernet module at 230,000 bps, ttl level. Back of the envelope calcs... 230,000 bits per sec...23,000 bytes per sec... 23 bytes per ms... 43 usecs per byte. Avr can interrupt, grab char, stick it in an array and return in about 4 usecs, so about 10% of the cpu is used for comms. Good numbers?

 

Imagecraft compiler user

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

how to determine which is the first byte? first received by the PC is the first byte, isn't it?

What you are talking about there is "endianism". I think all the AVR C compilers use little endian and so does the PC. So if you send 0xBAADFOOD then first the 0x0D then 0xF0, then 0xAD and finally 0xBA might be sent. But it's really in your control - you are the one stuffing 8 bits at a time into UDR and you can choose to do it in either BA,AD,FO,OD or OD,FO,AD,BA order. It's up to you.

 

(and I know the next question is going to be how to split BAADFOOD into OD, FO, AD, BA ;-)

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

I aways thought that 0xBAADFOOD is a result from eating 0xDEADBEEF

 

 

Imagecraft compiler user

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

My usual favourites are

 

0xBABFACE ("Babe Face"), 

0xAFFEC7ED ("Affected"), 

0x5CA1AB1E ("Scaleable"), 

0xACEB1ADE ("Ace Blade"), 

0xBA5EBA11 ("Baseball")

 

but I came across "Bad Food" the other day when debugging code in Microsoft Visual Studio. It seems that like they flood the stack with 0xCCCCCCCC to catch use of uninitialized locals they flood the member variables of a C++ class with 0xBAADFOOD at the time of allocation so that use of uninitialized members can be easily spotted.

 

(I was looking at code where the "Debug" build worked but the "RelWithDebInfo" build did not and trying to work out how they differ).

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

nancy0116 wrote:
baud rate will affect the sending interval.

Think about it: Baud rate will obviously limit the minimum sending interval - but, above that, it's irrelevant.

 

higher the baud rate is, the shorter is the sending interval

Not quite: The higher the baud rate, the shorter the minimum sending interval.

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

nancy0116 wrote:
what is a 'break between each packet'?

 

http://www.lmgtfy.com?q=rs232+break+condition

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

nancy0116 wrote:
actually the project is applied in industrial field

That's a bit worrying!

 

surprise

 

Do you not have a supervisor or mentor to help you with basic stuff like this?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If she answers the negatively posed question in the affirmative, then she has given a positive response, and is confirming that she has no mentor. Just us freaks. Who usually give impeccable advice.

 

Imagecraft compiler user

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

The standard RS232 high speed baud rates are 57600*2n e.g. 115200 230400 460800 921600.

http://electronics.stackexchange...

 

Most motherboards can do these rates although the RS232 header is rarely brought to an external connector nowadays.

 

I have connected to USB through the FT2232HL at 921600 with no problem where the RS232 path from the micro (not an atmega32) was 1cm on the PC board. The USB side could have any rate but the virtual port often limits the selection to the above values. That seems to be the case with the current FT232 Windows and *nux drivers.

 

High speed is useful to add a debug channel without slowing the data stream. A data packet in a 20kbps stream might trigger a return burst of 400kbps debug printfs.

 

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

A couple of quick thoughts:

 

Common baud rates at the slower end of the scale are:

110, 300, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115,200.

 

Sending 4 bytes of data 500 times a second isn't a lot of data, and it makes sense to select a slower baud rate.

With a ring buffered, interrupt driven, USART driver in the AVR, the micro isn't going to be very busy with the data transmission part of the project, regardless of the baud rate.

The slower baud rates may have better noise immunity, depending upon the actual cable used, its length, and the environment it is running in. (Industrial, EMI noisy...)

 

Why not start with a baud rate of 19,200, for example, and get the system up and running, then decide if you want a faster communications link.

 

There are many protocols for transmitting data, and lots of info on the web for the various methods.

 

A simplistic approach is to put your data in a "Packet".

A packet might consist of:

 

< DB1 DB2 DB3 DB4 Chksum

 

Where "<" is the Start of Packet Character.

Your receiver code watches for this to know that a new packet of data is arriving.

 

DBx = Data Bytes 1-4, your data

 

Chksum is a CheckSum, with several ways to implement it.

An easy method is to add up the data bytes, 8 bit value, ignoring any carry out.

 

The receiver watches incoming data and ignores it until it sees a "<" start of packet character

It reads in the next 4 data bytes.

It reads in the CheckSum, and calculates the sum of the data bytes it received, to see if the transmitted checksum matches the checksum calculated on the receiver end.

If they match, one assumes the packet was received correctly.

If not, one starts watching for the next Start Of Packet, and tries again.

 

One can start adding features to the basic concept.

There could be a byte that defines the packet type, with different packets having different data lengths, or data, (temperature packet, rpm packet, voltage packet, etc.)

 

One could use a CRC instead of a CheckSum, for a "better" data integrity assessment.

Every once in a while an error in the data and an error in the CheckSum could cancel each other out, and the packet would appear to be good, when in fact it wasn't.

The likelihood depends on the number of data bit errors one is likely to have in the channel.

A CheckSum can detect a single bit error within the packet easily.

If could, possibly, fail at detecting multiple bit errors within the packet.

 

Non-mission critical work, with a low error rate, hard wired system, (not an RF radio linked system), a checksum is often fine.

 

One could add a sequential number to the packet, so the receiver can make sure it is getting all of the packets, packet #1, #2, #3...  and not missing a packet or two: packet #1, #2, #8, #9...

 

One could have the receiver send an acknowledgement back to the transmitter that it received the last packet correctly.

If that Ack isn't received, the sender then re-transmits the last packet a second time...

 

One could send the data load three times within the packet, and the receiver could make sure at least two copies of the data match, within each packet.

 

One could...

One could...

One could...

 

The list of possible improvements goes on and on.

 

The point is, with a data packet one knows the format of the incoming data, and has a measure of data integrity, and can reassemble the data bytes correctly.

Without that formatting, i.e. just sending raw data bytes in a row, the receiver can quickly get out of synch, resulting in garbage in / garbage out.

 

JC

 

 

 

Last Edited: Fri. Jun 26, 2015 - 04:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I always use 115200 for debug. I write the labels once with a line between them, then write a line of 5 or 6 numbers under the labels, one line per pass for as many lines as I have variables to watch.  40 chars at 115200 (83usec per char) is about 3.2ms, so it doesnt slow the looping program down much more than that.

 

Imagecraft compiler user