SEROUT being unreliable

[Kamikaze47]

Hi,

I'm having a problem with SEROUT. When I use HSEROUT it works perfectly, but when I use SEROUT or SEROUT2 I get errors in the data. I'd guess that about 5% of the characters are corrupted.

PIC: 18F4550
Clock: 48Mhz

HSEROUT code (works):

DEFINE HSER_TXSTA  24h
DEFINE HSER_RCSTA  90h
DEFINE HSER_BAUD   2400
DEFINE HSER_SPBRG  25
DEFINE HSER_BITS   8

HSEROUT ["This is a test."]

SEROUT code (5% of characters are corrupted):

SEROUT PORTB.3,0,["This is a test."]

Does anyone have any ideas as to why this would be happening?

[skimask]

I'm having a problem with SEROUT. When I use HSEROUT it works perfectly, but when I use SEROUT or SEROUT2 I get errors in the data. I'd guess that about 5% of the characters are corrupted.
PIC: 18F4550
Clock: 48Mhz
Does anyone have any ideas as to why this would be happening?

Cable straight from PIC to PC?
DEFINE OSC 48 used?
Do higher/slower baud rates work better/worse?

[falingtrea]

HSERIN and HSEROUT use the built in UART of some PIC parts to communicate. SERIN(2) and SEROUT(2) I believe are software emulations of a UART. At the clock speed you are running at I would probably be better to use the UART. The software emulation uses up too much of the PIC resources anyway.

[Kamikaze47]

Its a cable going directly to a DoubleTalk text-to-speech board.

I am defining OSC 48 yes.

I initially started at 9600 baud, and lowered to 2400 to see if that would fix it, which it didn't.

When i use SEROUT or SEROUT2 the corrupted characters cause the text-to-speech to mispronounce the words. HSEROUT is flawless. No issues at all.

The reason I need this is I need at least 2 serial outputs and this PIC only has 1 hardware USART.

[skimask]

The reason I need this is I need at least 2 serial outputs and this PIC only has 1 hardware USART.

Semi-silly idea for you...but might be easier than you think. Might even be able to write a macro to handle the switching for you...
Use the HSEROUT for your serial out as you've already planned it out...
Get your hands on a couple of AND gates, or whatever works...
Use another PIC pin or two as STEERING LOGIC.

[Kamikaze47]

I just lowered the SEROUT2 baud to 600 and it works by the look of it. But that is much too slow and it holds up my program.

With a 48Mhz clock, i'm not sure why it would struggle with 9600 baud, let alone 2400.

[Kamikaze47]

Semi-silly idea for you...but might be easier than you think. Might even be able to write a macro to handle the switching for you...
Use the HSEROUT for your serial out as you've already planned it out...
Get your hands on a couple of AND gates, or whatever works...
Use another PIC pin or two as STEERING LOGIC.

Thats a pretty good idea.

[skimask]

Thats a pretty good idea.

Well, heck, glad I could help...
Generally I'm useless
Does your program have any interrupts running in it?

[Kamikaze47]

Actually, i do have 3 interrupts in this program. Maybe SEROUT is getting interrupted and thats messing with the data.

I'm gonna try disabling the interrupts while I run SEROUT... Not the best long term solution as It wouldnt be good to miss one of those interrupt events, but its worth a try to see if thats whats causing my problem.

[skimask]

Actually, i do have 3 interrupts in this program. Maybe SEROUT is getting interrupted and thats messing with the data.

I'm gonna try disabling the interrupts while I run SEROUT... Not the best long term solution as It wouldnt be good to miss one of those interrupt events, but its worth a try to see if thats whats causing my problem.

Are you using assembly int's (i.e. DT's fast ints) or the ON INTERRUPT types?

[Kamikaze47]

I tried to test the interrupt theory with a simple GIE=0 before SEROUT and GIE=1 after it, but disabling the interrupts makes my program do unexpected things and makes it impossible to test. But i'd say its a high probability that the interrupts are the issue.

So I guess i'll have to stick with the hardware USART and, as skimask suggested, multiplex its output.


*edit*: Using ASM interrupts as timing is important.

[b1arrk5]

I've used serout and debug out to run to two different Double-Talk boards at 9600 baud, both performed perfectly, so I'd have to say that you're right, it's probably the interrupts. I tried it using two different LabX-Usb boards, with 18f4550's, with a DEFINE OSC 48. The boards have 20 Mhz crystals, and the oscillator selection is for HS_PLL.

Jerry.

[BrianT]

My serial data errors all went away as soon as I started presetting the data line before transmission.

For example, RS-232 defines the IDLE or MARK state to be negative volts at the RS-232 connector. That means positive volts at the PIC before the MAX232 inverter.

Try something like

HIGH TxData
pause 2
Serout/Serout2/Hserout your message.

It works for me.

HTH
BrianT

[Kamikaze47]

BrianT: I previously tried a non-true driven mode and tied the line to +5 with a 10k resistor, which did not help reliability.

b1arrk5: Yep, in the end I did manage to test it with my interrupts disabled, and it worked, so thats the issue. Disabling the interrupts while I send isn't an option, so no software serial comms for me I guess.

[Kamikaze47]

Ok, i'm looking at the best way of multiplexing the hardware USART's output and this is what I have come up with.

- Use IC with 4 OR gates (only using 2, but they come with 4).
- Gate 1: Input1=USART, Input2=A PIC I/O Pin, Output=One of the serial outputs
- Gate 2: Input1=USART, Input2=Another PIC I/O Pin, Output=Another serial output
- Use software so that only 1 of the I/O pins is ever high at a time

I know I could use a NOT gate which would allow me to use only 1 I/O Pin, but i'd rather use another I/O pin than add another IC.

If anyone can see how this can be done better (and still only using the PIC + 1 IC), feel free to share.

[b1arrk5]

With the Double-Talk chipset you can pre-record your audio, and just send the address for the phrase that you want to play. You might be able to send out the bytes between interrupts. If I remember correctly, (I don't have my book with me here,) you have to end the play address with a 13, and the chipset will play whatever is stored at that address as soon as it sees the 13. This way you would only need to send out a few bytes each time.

Jerry.

[skimask]

Ok, i'm looking at the best way of multiplexing the hardware USART's output and this is what I have come up with.
- Use IC with 4 OR gates (only using 2, but they come with 4).
- Gate 1: Input1=USART, Input2=A PIC I/O Pin, Output=One of the serial outputs
- Gate 2: Input1=USART, Input2=Another PIC I/O Pin, Output=Another serial output
- Use software so that only 1 of the I/O pins is ever high at a time
I know I could use a NOT gate which would allow me to use only 1 I/O Pin, but i'd rather use another I/O pin than add another IC.
If anyone can see how this can be done better (and still only using the PIC + 1 IC), feel free to share.

That's exactly what I was talking about. If you wanted to get rid of the 7402 (?), you could easily do the same thing with a couple of 2N2222's.

[Kamikaze47]

That's exactly what I was talking about. If you wanted to get rid of the 7402 (?), you could easily do the same thing with a couple of 2N2222's.

I know how to use a transistor as an AND gate, but not sure how to do an OR. I need it to be OR because the output should be high when that output is not selected.

I've been trying to work out if I want TTL or CMOS for my OR gates. Ive been looking at the data sheets, but cant really see which would be better for this application.

[skimask]

I know how to use a transistor as an AND gate, but not sure how to do an OR. I need it to be OR because the output should be high when that output is not selected.

Then use the transistor it 'backwards'...(not backwards like C and E are reversed, just use inverted logic on it)
The output that is 'selected' isn't really 'selected'...it's 'unselected'...that way it idles high.
The other output that is actually 'selected' is really 'unselected'...passing the data thru.

If you use TTL, you'll be 'limited' to TTL voltages and switching levels (.8v low - 2.4v high roughly)
If you use CMOS, you'll be 'unlimited' to roughly 1/3 and 2/3 Vcc for your logic levels.
Depends on what you're driving at the outputs and what you're driving it with at the inputs.

But....your run of the mill 2N2222 will open up all sorts of options as far as voltage levels go. I suppose one of the problems with a transistor MIGHT be switching speeds. Go to fast, and the transistor won't switch fast enough (Early effect, Miller effect, etc). Sometimes it can be 'fixed' with a 'speedup' cap across base and emitter, sometimes not.

Again, depends on the final application.