sprintf/fprintf behaviour

[newguy]

A soft UART is a "bit banged" pseudo-UART. Transmits are handled basically by setting the transmit line, waiting the bit time, then setting/resetting as required. Reads are handled by polling the receive line at least as often as the expected bit time.

A hardware UART handles all that for you. Need to transmit a byte? Hand it to the UART and it will automatically "clock it out" for you. It also continually listens to the receive line without any need for you to "micro manage" the transaction. If it receives a valid byte (something it recognized as valid, anyway), it will put it in the queue. If you have interrupts enabled, the receive interrupt (receive data available, or INT_RDA) will "fire". If you don't have interrupts enabled, you need to periodically check to see if a byte is waiting for you in the queue.

Now think about this, very carefully. A soft UART requires very strict timing - the processor basically needs to focus its attention on the soft UART leaving very little time for anything else. If that's all you're asking the processor to do, chances are it will manage to keep up with the demands of the soft UART and not miss characters (coming or going). If, however, you now start enabling other interrupts, as you have done, what do you think will happen if your soft UART, in the middle of transmitting a character, gets "pulled aside" by an interrupt which takes a relatively "long" time? What happened to the bit-banged timing of the transmitted sequence? How will the device on the other end of the line like/handle/interpret that pause? Same goes for data the soft UART is receiving.

[Ttelmah]

There was a fault on many V4 compilers that they accidentally disabled the global interrupt inside printf. Caused a huge number of problems, but would allow this to work. I don't remember V3 doing this, but it is possible he had a version that did.
You can get a better version of the same behaviour, by adding the command 'DISABLE_INTS' to each software UART #USE RS232.
It's awful programming. At least one of the UART's could be using the hardware (it's there to do the job better)....
I assume he has other interrupts (with the single ones shown, using 'high' would be pointless, and this is short enough that it probably would not interfere too badly with the serial).
Using the software UART's, in any code that does work, Interrupts, will be being missed, unless the frequency is very low.

The whole thing is an abortion.

[BLL]

Hi Jeremiah, Thanks for the reply. I have a knowledge problem here! Ever since I started with PICs (the ones with the uv window on top), I configured serial ports as in my current program. I was not aware of the HW UART or how to use it! I have googled and searched the CCS user forums and info is sparse to say the least! The help file also says little. It seems, if I have it right, that I need to add uart1 to the #use_rs232 statement, to tell it to use the HW uart? This I have done and it has made absolutely NO difference, so I am still in the dark! I am only a hobbyist PIC programmer and don't have the knowledge some obviously have, hence my pleas on the forum. My program needs 3 serial ports:
One for the CS5490 - this is working fine using RC0 xmit from 5490, RC1 for receive and RB0 for pulse output.
One to send/receive data from the connected Raspberry Pi at 9600Bd. RasPi requests data once a second and PIC sends a comma delimited string.
Finally, the pain, the LCD.
Now from what I glean, the display does most work so it should have the h/w usart?
What, other than adding uart1 to the

[Ttelmah]

To use the hardware UART, you need to use the pins on the chip that have this.
Using 'UART1', will automatically use these pins.

No, if you use the DISABLE_INTS option on the software UARTs, the ones that most need the hardware, are those receiving, and taking the longest time. Probably the Rasperry Pi?.

[Ttelmah]

As a further comment, increase the baud rates if you can.

The CS chip will happily run at something like 57600bps. Using 'disable_ints' at this rate, will only disable interrupts for 0.1736mSec at a time

[newguy]

[BLL]

Hi both
Thanks Ttelmah, I'll look into this. However, the PIC isn't even coded in my test program and the LCD is completely happy with the 5490 running. It's as soon as I try and use the RB0 interrupt that everything goes awry. Unless I comment out the isr, the LCD is a mess.

As for newguy, it all works fine already if I compile with v3.248, so it's possible! It's only in trying to update to v5 that the wheel has come off, BADLY!
Seems like reverse progress to me!
Worst come to the worst, it's the bin for v5 and I'll just have to stay old-fashioned!

Brian

[jeremiah]

[Ttelmah]

Good follow up. Some more to this:

First of all, we can ignore the 600baud stream. This is only used initially to configure the CS5490, so it'd be perfectly reasonable to only enable interrupts at all, after this has been configured.

Then the key points Jeremiah is making are about receive, and time.
With a software UART, the code has to be sitting 'waiting' for bytes to arrive. There is no receive buffer, or receipt of data if it arrives 'unprompted'.
Hence we need to be looking at using the hardware for any streams that may deliver data 'unprompted'.

So the CS5490, makes good sense for a device to use a software serial, since it will only send data 'when asked'. If this is made to have each byte transaction run faster than anything happening 'unprompted' (so a baud rate faster than 9600bps), then the hardware buffer will be able to cope with any data arriving on the 'unprompted' stream, while this is occurring. The baud rate this uses is programmed in the initial setup, and can go up to 500Kbaud. The value loaded into the BRG bits in the configuration determine this, with the formula:

BRG=baud*(524288/Mclk)

So assuming the standard 4.096MHz Mclk, a baud rate of 19200bps, would just involve loading the BRG with:

19200*(524288/4096000) = 2457

Similarly, the LCD, only requires transmit, and again this can therefore be easily handler by the software, especially given that the data rate being used is already twice that involved in the PI link.

Then add an interrupt ring buffer to the hardware UART (PI) - look at ex_sisr.c, and anything that arrives while the LCD and CS5490 are being handled, will be buffered in the gaps between the individual characters.

[BLL]

Hi all, Thanks again for the replies. I have now increased the CS5490 to 57600Bd from 9600. As I suspected, it has made not one jot of difference.
Next, I removed the input to RB0, which gets pulses from the 5490's DO output. This did not cure the display problem, even though now the isr should not be called and should therefore have no effect. However, if I comment out the isr code, the display is fine! Why? This suggests that this function is being called even though no interrupt has been requested. This surely suggests that the PIC is polling, not acting on interrupts?
If the problem with the display is lost characters, as it appears, then I am surprised that the wrong display is ALWAYS the same with the SAME characters being lost. I would have expected changing lost characters, but this is not so.
Also, if disable_interrupts does as it says on the tin, the isr should not surely be called whilst the display is being written to?
The PIC is a red herring at the moment as it isn't coded in my test program yet.
So, I still don't understand fully what is happening.

My head hurts!!

Brian

[PCM programmer]

[BLL]

Hi,
I left it unconnected! I'll try again with it grounded.

I have also discovered that in the code at the start of the loop, the display is OK provided I rem out the

[jeremiah]

That's probably because taking it out changes "when" the interrupt occurs relative to the display routine. Before the interrupt was happening at the same time as the display routine. With the (slow) division operation gone, they now happen at different times.

EDIT:

We've discussed a lot of things and you've made some various changes. Can we get a point of reference? From your earlier post you had a point where leaving in an interrupt (even with the hardware disconnect) resulted in the display being wonky but when you commented out the interrupt it worked fine. Can you post the "working" version of that post in compilable form. Leave in the interrupt code (still commented out though).

[BLL]

Hi all, The whole thing is on a knife edge. If I rem out parts of main and leave in the isr, it's fine. If I rem out the isr, it will work with all in main!
Changing the LCD to the h/w uart made no difference; upping the 5490's baud rate made no difference!" It's crazy.
The following code works as shown:

[Ttelmah]

I have to ask a question.

Why on earth are you using interrupts at all?.

If all you are ever doing with interrupts, is counting pulses, then the PIC has hardware to do this. You can just feed your pulse into a timer input and count them. No interrupts needed at all.....

On your chip either timer1, or timer3, can be set to count external pulses.

You seem determined to 'not use hardware' at every opportunity, even if this makes the job harder.....