Quick rs232 question

[apampe]

I'm very familiar with the 18f4550, and have the compiler, so I'd like to stick with it on my current project. The problem is that I need 2 rs232 interfaces. So my 2 questions...

Is there any disadvantage to using one software and one hardware UART? aka should I just use 2 software ones instead? How taxing on interrupts is the software compared to the hardware? Note that I'm reading 6 ADC ports at 50 Hz and a 20 MHz crystal, but I am still in early stages and can easily change the hardware plans.

I haven't been able to find but is there any IC's which combine 2 rs232's? In other words use the one hardware UART on the PIC to talk to this separate IC, which then has 2 rs232 connections. Note that outgoing messages can go out both rs232 connections and I will easily be able to tell which device incoming messages come from due to it's content.

I'm new to serial so thanks for this help in advance!

[Ttelmah]

The software 'UART', uses _all the processor performance, to perform just one job, either sending data or receiving data. It is 'half duplex' (can't receive at the same time as sending), and requires that you reach the 'getc' code, no more than about 1/3rd of a bit time, after the falling edge of the start bit. This requires you either to poll at a very short interval, or use an interrupt to service it. Once inside that interrupt, you will have to stay in there, for the entire byte time. It is almost impossible to use other interrupts at the same time as using software serial (remember it takes a lot of machine cycles to get into, and out of an interrupt, making the timing requirements very hard to meet.
Software serial, is 'fine', with a number of caveats:
1) Data is only sent, when nothing else needs servicing.
2) Data is only received, when nothing else needs servicing.
3) If not using interrupts to actually handle the software serial, you are in a tight loop, waiting for data to arrive.

If you cannot meet those restrictions, then I'm afraid you need to add a second external UART, or switch to a PIC with another UART....

Best Wishes

[John P]

Sorry to be pedantic, but the term RS-232 refers to a set of electrical standards for serial data transmission, and not the actual operation of the link. See the Wikipedia entry.

You didn't say what the baud rate(s) is/are for your two ports, but if you're willing to write your own code for the software port, you can make a half-duplex link at 19.2KB. I wouldn't know how to set up a faster UART or full duplex, unless it's very slow. I've never liked the CCS way of making a serial port, which ties up the processor for the duration of every character (unless newer versions of the compiler do it differently).

[mskala]

Depending on your project's environment, one other idea would be to use both the HW UART as well as USB CDC, with the obvious restriction that the other end is coming from a host like a PC.

[Ttelmah]

Yes.
I have moaned about this in the past.
Unfortunately, it is made all the more 'common', by CCS, insisting on calling the setup for the async serial logic I/O 'RS232', which can then be used to actually drive RS232, RS485, or similar interfaces. Also many modern PC's (especially laptops), don't themselves actually generate RS232....

On the original question, I'd suggest looking at the NXP (Philips) SC16IS7xx, or the MAX3110 (but the latter has the common problem of Maxim IC's, of long lead times, and large MOQ's).

Best Wishes

[treitmey]

Sorry for being dense here,.. is MOQ= minimum ordered quantity?

[Ttelmah]

Yes.
Generally, except for the 'common' Maxim IC's, which are held by other companies, they tend to have things like 500off minimum order, and 12week lead times....

Best Wishes

[romertz]

So the recommendation when it's necesary to listen and write two uarts (one for hardware and one for software) is to use two mcus, one for each uart? I am making a project with a 2550 to listen and write two devices at 115,2kbauds. But I am facing some interrupts problems and it's not a beauty solution to use two mcus, if it is possible to use only one.

[dyeatman]

Ttelmah,
Are you seeing these MOQs on the Maxim site? I order and one, two and three offs all the time straight from the Maxim web store site and have never encountered that problem (so far!).

[asmboy]

There is another alternative that is very powerful as an add on UART option.

Namely the 16c550 650 750 850 950 etc family.

Also see the national semi (ns) 16550A - etc will steer you to appropriate data sheets
Very full featured very robust UART with much capability and reasonably simple IFC - I've used it - sharing the D port of a 16887 with an ADS8717 and both the A/D and UART were made to play nicely together.

Containing an on board TX and RX FIFO's from 16 bits deep to 256 bits deep - depending on the part number - nice monitoring and multi function interrupt output.

I've used the 550 and 750 in various projects and was very pleased.

[Ttelmah]

[Ttelmah]

The 'downside' of the 16xx0 UART's, is the number of interface lines involved. They are nice cheap, traditional UARTs, but on most PIC projects, the need for eight data lines, plus addresses, and a couple of controls, tends to 'rule them out'. If you have lots of pins to spare (only using a few pins on a larger PIC), I'd definately consider them, but for most PIC projects, solutions using less lines, really have to be the 'norm'.

Best Wishes

[John P]

Earlier I claimed it's possible to write your own software UART, but I wouldn't care to try it above 19.2KB. That was based on a scheme with an interrupt to detect the start bit (lowgoing edge) of a character, then a timer-based interrupt for the 8 data bits. I've done that a few times, and it works fine, but obviously the interrupt rate limits the frequency, and hence the 19.2KB limit.

Then I got to thinking, maybe the CCS method, or something like it, actually works better at higher baud rates. The faster the data comes in, the sooner the processor can go off and do something else.

Now I'm wondering if it's reasonable to start an incoming character with an interrupt on a low-going edge, but then continue it either by staying in that interrupt until the entire character has arrived, or depending on how the main() function works, return from the int with a repetitive timer set, and just poll the timer flag to know when to grab the arriving data, 8 times for the 8 data bits. Either way, there ought to be enough cycles available to monitor the other serial port (data to be stuffed into a buffer) and perhaps to do a few other tasks, like maybe operate the A/D. Anyway, a character at 115.2KB is over and done with in less than 100usec.

I think a lot depends on whether the software serial port has to deal with characters arriving one after another with no break indefinitely, or whether the data comes in with separated characters or in short bursts.

A lot also hangs on the circumstances of the project. Is this a hobby design where you can take your time and make it a learning experience, or is the boss breathing down your neck to have it done the right way, right now?

[asmboy]

since , as mentioned before - i was already using a parallel A/D - SHARING the D & E port of the PIC and using a lonely inverter on pin_a-7 and ONE int input on B port - flipping the NOT CS control on each was not a hardware burden for me -
the BIG feature everybody is kinda missing is the VALUE of a big, deep fifo - as the post above this - recognizes. when you can buffer ( and control the FILL level before interrupt ) - you bring a powerful ally to not losing data if you are slow to service the UART . and hi baud rates are no biggie.

i urge anybody who want to do excellent serial i/o to check the spec sheet
and see what the fuss is about.

[andrewg]

While I've tried the external Maxim SPI UARTs, I've also had success using a 16F88 as a slave SPI "UART". I passed off all the checksumming in my protocol to it too.

I've also recently done what John P outlined - an interrupt-driven software UART, operating at 38400. Very reliable too, probably because I'm using a 18F2455 at 48MHz. However, I found that ANY other interrupts would noticeably reduce the quality of the comms. It wasn't too bad, but I did notice dropped packets due to data corruption. Now that the only interrupts are for the software UART, I can't say I've noticed any dropped packets - it feels just like a hardware UART.
_________________
Andrew