Hardware and Software Uart Problem

[arunkish]

Hello

I am using PIC18F4620 @ 4Mhz and using both software and hardware UARTS.

[Ttelmah]

Start with the basic mantra:

INT_RDA, _must_ do just one thing. Receive _one_ character, and exit. Nothing else.

INT_RDA, says that a _single_ character is waiting to receive. The handler needs to just receive this one character.

This can be done is a few _uSec_. However as currently written, your INT_RDA, sits for 20+mSec waiting for characters. This destroys any ability to do anything else.

Then, you need to be giving both streams names, and using fgets everywhere you want to talk to the streams. When using more than one stream, you must use names throughout.

Now, handled properly INT_RDA, will take about 80 CPU cycles. At 4Mhz, this is 80uSec. Serial requires timing accuracy at about 4% error to be acceptable. If a character arrives while sending a bit on the software UART, this would give a bit timing error of:
(1/2400)+80uSec = 0.496mSec rather than the 0.416mSec required. Error of 19% in the bit time. Not acceptable.

You could make this work, by increasing the CPU clock.

Alternatively, just use a software UART for the 4800bps link, and the hardware UART for the 2400bps link, with buffer based interrupt transmission. Add the keyword 'DISABLE_INTS' to the software UART definition, and since this is always running _faster_ than the hardware UART link, interrupts will be disabled during the individual character transmission/reception, but will happen at the end of each character, hence fast enough to always keep up with the slower link.

Your approach is currently 'fundamentally flawed'. You need to rethink, and understand the limitations/abilities of the hardware/software.

Best Wishes

[ckielstra]

I have to agree to everything Ttelmah says.

Then my additional comment is that software UARTs are a P.I.T.A. I'm sure you can get them working and many other people created working projects as well, but they imply extra restrictions on your code design and will cost you time & money when not expected. Now there are PIC18 processors with 2 UARTs I would give a strong recommendation to upgrade to a newer PIC model and only use the 2 hardware UARTs. From a quick look it seems like the PIC18F46K22 is pin compatible to your PIC18F4620.

The good news is that these newer PICs have more features, use less current and are cheaper as well. For example, high volume price for the PIC18F4620 = $4.27 and for the PIC18F46K22 = $2.16

[John P]

You can't argue with the point that having two hardware UARTs makes things much easier.

However, people always seem eager to fail when they have to deal with UARTs. It's always "Let's have an interrupt" before thinking for a moment about how the code will run. If you don't plan to have your program run once and then go to sleep, a main() routine is going to be running in a loop. If that loop takes less time to execute than a character takes to come in via the UART, you don't need an interrupt; you can poll the flag instead. That means you can use a single interrupt more productively, to run an accurate timing routine. So you can receive data on a software UART first by responding to the start bit, then counting 8 data bits and grabbing each one right in the center. If you can set up a clock that responds at the right times (meaning no extraneous interrupts!) this will always work.

What you cannot do without some pain is run a software UART in full-duplex mode. That would be more of a gee-whiz stunt than a serious project.

[Ttelmah]

Yes.
This is made worse in this case though by having the software UART running at half the speed of the hardware. Here, in the time taken to send one character using the software, two characters could arrive on the hardware, and you have 'no hope' even with the fastest possible loop sending characters....

Best Wishes

[asmallri]

[Ttelmah]

Yes. I have actually posted here in the past a simplified code for one directional I/O like this, using a timer as you say, just as an example, with the notes on how to upgrade if required.

Best Wishes

[asmboy]

re software uarts.

interrupts ruin everything.

i will not use a soft UART in a 'design for hire'
as i believe it is irresponsible to do so.

the ONLY reliable soft UART is TX only - in an environment where there
are no interrupts possible

just my 2 cents

[asmallri]

[asmboy]

[n-squared]

Hi
I wrote this code for PIC18F87J11 running at 32MHz, but it can be easily modified to run on almost any other device.
This code runs perfectly in a real product.
Notice that both external interrupt and timer interrupt are defined as "high".

[asmallri]

[quote="asmboy"]

[Ttelmah]

Yes.
It is perhaps worth saying I have an old board, designed before any small PIC's had UART's. Used the original 16C84, which was the first chip Microchip did with flash memory. Actually designed a year _before_ Microchip claimed they launched this PIC (code was written in 1992), which does full duplex 9600bps software serial using two state machines in an interrupt called every 34.7uSec, and some examples are still running now, twenty years latter. Didn't have any year 2000 problems (my RTC is based on the Unix model, which will potentially have a wrap problem in 2017 - original spec was for a 25year design life....), which logs around 99.99999% comms reliability, and handles interrupts from half a dozen other devices while this is going on.
I queried with Microchip, when they put up a web page, listing the launch of the chip in 1993, pointing out that this unit was made before this, and they said that the first batch was considered 'engineering samples', and the official launch was the next year.

Best Wishes