Send 24 Bytes RS-232

[sir_jfreyes]

Hello everybody, I have a question. Is it possible to send 24 bytes less than 500us? What would be the setting for this?...

Thanks

[bungee-]

Well let's do the math. 500us for 24 bytes that would be about 20us per byte... so that would be 50000 bytes/sec ---> 400kBaud

[Ttelmah]

Except you need a start bit, and stop bit, so it actually works out at 480Kbaud.

There are so many 'unanswerable' parts to this.
What distance is it to be sent over?. RS232, doesn't actually spcify a useable signal length for rates this high. Something like RS485, or RS422, is really needed.
Most drivers, will not have a fast enough slew rate to support this rate.
How is the data to be 'prepared'. Will it simply be sitting in an array to send, or is other work needed to get it. This may well be the limiting factor.
What is at the other end?. Few RS232 receiver chips will reliably work this fast. Normally around 250Kbps max.

Realistically, 'possible', maybe. Likely to be reliable, easy etc., no.

It is a bit like 'can I make my car do 300mph'. Possible, yes. Attach a Jato unit. However 'useable', not really....

Best Wishes

[FvM]

[sir_jfreyes]

I need to send 24 bytes to the PC, but not if it is possible to use that speed. My program sampled each 1ms and it is necessary first to process and send the data before re-sampled. I am using the dspic 30f4013... Thanks for your answers.

[Ttelmah]

You are not answering the 'critical' parts of the question:

How far do you need to send?.
Is this a 'one off' system, or a limited run system with you controlling everything, or designed to be a 'general purpose' system, going out into general use?.

If the latter, 'forget it'. Though many modern systems 'purport' to offer baud rates at this kind of speed, on many the implementation is poor, and reliability is awful. I have seen a couple of commercial products launched a couple of years ago, that attempted to use RS232 at these high rates, and both ended up being 'scrapped', because of the poor data reliability in the real world....

The fastest you will get with any sort of reliability is 460800bps. Beyond this you run out of slew rate on just about every driver on the market. This is not fast enough to meet your original 'spec', if your data is genuinely 8bit. remember that the higher the driver slew rate, the greater will be problems with ringing etc., on the cable. You are outside the RS232 'specs' anyway, which limit the driver slew rate.....

If you are controlling everything, and the runs are short, then use the next standard rate _faster_ than the calculation says, and with care it can be made to work. If the data requires high reliability though, you may have to consider error recovery coding. Make sure you use a driver like the ST232AB, rather than the MAX232.

However is there anything to stop you overlapping the calculation, and the transmission?. Calculate one lot of data, and send it while you are calculating the next lot. This is what buffers, and interrupt driven transmission are for....

What is the expected 'life' of the product?. Do you really want to commit to an interface that is not directly implemented on most chipsets already?. Personally, I'd use Ethernet 'for preference' if the runs are to be reasonable length, or consider USB, if the device is close to the PC. Don't get hooked on thinking 'USB is cheaper', and try to use it, if the runs are going to be more than a few feet. Remember that Ethernet has error checking 'built in', and is designed to go reasonable distances.

On industrial PC's, many have UARTs supporting these high rates, but they also have jumper options for RS485 or RS422 transmission, rather than RS232. You will also find many USB serial interfaces offering such rates, but in many cases the actual rate achieved _continuously_, will only be a fraction of the claimed rate....

Best Wishes

[Guest]

Thanks for your answer Ttelmah, I don't write english very well but I will try. The distance is 6' to 7' and I'm using USB<->RS-232 FTDI232BL IC. I was trying with 460800bps and the time sending was 400us aprox, then with 921600 and the time sending was 200us. I think it's okay

Thanks for your patience.

[John P]

You've messed everyone up by calling it "RS-232" when it's actually a serial port driving USB. RS-232 means a line with voltage levels swinging between (nominally) +12 and -12 volts. Anyway, it's in the process of disappearing.

I can't answer the question of whether this can work via USB. It's apparently quite tricky to write software at the PC end to get USB ports running an exact emulation of RS-232 ports. It relates to the fact that the RS-232 interface can cause a processor interrupt, and hence very quick service, whereas USB can't. At least, that's my understanding of it. Maybe someone else can explain--I'd be interested to learn more.

[FvM]

Achieving high throughput over USB isn't a problem, but round trip delay is considerably higher than with hardware UART. This can affect the performance of some protocols that are doing a character "ping-pong".

You are right, that the RS232 driver slew rate discussion would be meaningless, if the interface is actually logic level UART.

[bkamen]

I agree with the mention that Ethernet would be a great option.

With one of the 18FxxJ60's, you have built in ethernet. Even better.

You don't HAVE to use TCP/IP (although it could be fun). Ethernet would enough and you'd get free layer 2 benefits.

As for anything high-speed over length, I'm surprised how many people forget about optical.

You can get cheap-o industrial fiber optics Emitters/Detectors that will easily do a megabit -- with much longer runs than copper will allow with the 1000um format that's easy to handle.

Just a thought.

-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D

[18F runner]

I achieved 460800 baud @32MHz.

It works very stable, I use max transceiver.