Need help multiplexing EUSART output

Hi, The PIC i'm using has only 1 EUSART and I need to send data to 2 different devices without using software serial like SEROUT or SEROUT2.

This is what I want to do:

<img src="http://ii.net/~steven/files/pic1.jpg">

And thus PORTB.6 would control which of the 2 outputs receive the data, and the other output would just be +5v which is the idle voltage anyway.

However i'm having trouble getting it to work. I tried this as a first step:

<img src="http://ii.net/~steven/files/pic2.jpg">

But the data is not getting through. I'm using a Phillips HEF4071PB IC for the OR gates.

Does anyone have any idea why this would not work?

Those look like AND gates to me and I guess that is what you need to have if you want to use PORTB.6 as enable.

Since you have GND to one side of the AND gate in your pricture.... GND AND anyvalue is still ZERO.

Try to connect one side to 5V or use the PIC connection and set the pin accordingly.

But if you use AND gates the output that is NOT enabled will be low. but if you want the opposite use a NAND.

/me

They are OR gates.

AND gates would be idle low so they wont work.
NAND gates would be idle high, but the 1s and 0s of the serial transmission would be inverted, so that wont help.

That is why I went with OR gates - idle high, non-inverted signal, logic 0 to enable, logic 1 to disable.

It seemed like a perfect plan, so i don't know whats going wrong.

The obvious number is ...

4081 AND Gates ...
or
4052 Triple 2 Input multiplexer

or two series resistors, one to each addressed device ... and grounding ( or VCCing ) the signal ( past the resistor ! ) with another PIC pin , if NO transmission, and use the PIC pin as an input for transmission.

may be too simple ?

Alain

Quote:

---

Originally Posted by Acetronics

or two series resistors, one to each addressed device ... and grounding ( or VCCing ) the signal ( past the resistor ! ) with another PIC pin , if NO transmission, and use the PIC pin as an input for transmission.

may be too simple ?

---

I just did a few tests. This idea seems to be working. The signal would not get through the series resistor until i reduced the value to about 200 ohms. That means a 25mA draw whenever the signal is low. I guess that's not too bad.

The only thing that worries me is the possibility of reduced reliability due to the series resistors.

74ls 425/426 ???

Cant seem to find any info on the 74LS425/426 chips.

But I think i'll pick up a 74LS139. The data sheet says its designed for high speed data, so it should be perfect.

I still have no idea why my circuit in my OP does not work tho. As far as I can tell, it should.

How outlandish is this idea?

I notice you only want to transmit, not receive.

So, how about sending the same data to *both* your recipients, with an extra starting character that acts as a qualifier that decides which of the recipients would accept the data as valid? Assuming, of course, that you are in a position to modify the code at the target units as well.

Regards,

Anand

Maybe because the 2 units can't be altered... my own and personal guess :o

Unfortunately I can't change the code of the targets.

How frequent would the changeover(s) be?

If not too often, how about using a small relay with its n/o, n/c contacts?

Anand

Any specific reason why you don't want to use any Software Serial command (DEBUG, SEROUT, SEROUT2) ?

Switching is likely to be once per second or so.

I would much prefer a solid state solution.

I'm thinking the 74LS138 multiplexer is the way to go.

Quote:

---

Originally Posted by mister_e

Any specific reason why you don't want to use any Software Serial command (DEBUG, SEROUT, SEROUT2) ?

---

Because I have 4 different interrupts going off all the time and they interrupt any software based serial comms and causes significant data corruption.

Sounds reasonable indeed. Did you tried with Darrel's instant interrupts?

What's your baudrate?

Quote:

---

Originally Posted by mister_e

Sounds reasonable indeed. Did you tried with Darrel's instant interrupts?

What's your baudrate?

---

I am using DTs instant interrupts.
Baud rate is 9600.

Okay, here's another thought.

Use 2 optos; each output feeds each target.

The serial out goes to the anodes of both the opto inputs; the 2 cathodes go to 2 separate pins, each of which can be selectively pulled low to allow transmission to the corresponding target.

Anand

Quote:

---

Originally Posted by ardhuru

Okay, here's another thought.

Use 2 optos; each output feeds each target.

The serial out goes to the anodes of both the opto inputs; the 2 cathodes go to 2 separate pins, each of which can be selectively pulled low to allow transmission to the corresponding target.

Anand

---

Thats pretty much the same result as using a couple of AND gates.

The problem is you end up with idle-low instead of the required idle-high.

Do you have any timers available?
<br>

I have successfully used a 74HCT125 for this purpose. You can selectively enable each gate to drive what you want. If you add a pull up on the output of each gate, you can "idle high".
One package (two gates for TRANSMIT, two devices for RECEIVE) plus an inverter will allow you to use one pin to select which device you want to "speak to".

Connect PIC TXD to the inputs of two gates (call them A & B) Connect the output of A to
device 1, connect the output of B to device 2.

Connect the outputs of gates C & D to the PIC RXD. Connect the input of C to device 1 and the input of D to device 2.

Connect the ENABLES of gates A and C together, and the ENABLES of B & D together.

Put an inverter between the pairs of enables. Drive the input of the inverter from a PIC pin.

How about my favourite STG3157? ok ... a bit much expensive i agree...

Quote:

---

Originally Posted by Darrel Taylor

Do you have any timers available?
<br>

---

I'm using 2 timers, and have 2 free.

Timer1 maybe?

I've been playing with this all day, just got it working a little bit ago.

I don't know if this fits in with your program but I figured, Since the problem is the timing disruption of the SEROUT commands by the interrupts, that a SEROUT equivalent driven by a Timer might solve it. Kind of cross between USART and software serial. Might solve a lot of peoples SEROUT problems.

Still have some more to do on it, but was wondering what kind of data you're sending. DEC, HEX, STR, ??

Are your other Interrupt handlers SHORT?

Which Timer is available?
<br>

Wow. Thats impressive.

I'm sending strings of data. But of course that can be easily accomplished with sending bytes in a loop.

The other interrupt handlers are mostly short. But i guess thats a relative term. Most of them just record an input, or an event and the time that it occurred, and throw that data in a circular buffer to be handled when the main program gets around to it :).

Just strings?
Are the strings in a RAM array.
Or like HSEROUT ["Hello World"]

Which Timer????
<br>

RAM arrays.

I'm using Timer0 and Timer1 at the moment, but i could prob use any for my application.

Kamikaze,

I think this will do what you wanted, without any external OR/AND gates.
There's so much more I could do with it.
But it's already more than you need, so I think I'll stop now.

This is an Include module, that sends Serial data using a Timer as the baud rate generator.
Currently, it will only work on 18F's, and it's only the Transmit side.

It can use any one of Timer 0, 1 or 3. But does not use interrupts.
Outputs on any digital I/O Pin.
Can send Bytes, Words, Strings from arrays, Strings from Flash and ASCII decimal values.
Runs up to 115200 with 32mhz(or higher) OSC.
You can use HSEROUT for the USART, and this as a second UART.


Setup is pretty simple.
Just tell it which Timer to use, the baud rate and the I/O Pin...

Code:

---

;----[Setup Timer based UART]-------------------------------------------------
DEFINE  TX_TIMER 1                ; Timer used for serial UART (0,1 or 3)
DEFINE  TX_BAUD  9600              ; Baud Rate
TX_Pin  VAR PORTB.6                ; Output Pin
INCLUDE "TMR_TX-18.bas"            ; Include the Timed Serial module

---

The TX_Pin is automatically set to output and idles high. (assuming there's no A/D etc. enabled on the pin)
Serial signal is 8N1 True. Same as the USART.

If all you are sending is Strings from Array's, then you just need 1 Command...

Code:

---

@  TX_STR?B  _StrArray, _Length

---

Which is functionally the same as,
HSEROUT [STR StrArray\Length]
where Length is a BYTE variable.

A variation of the same thing uses a Constant Length (max 255)

Code:

---

@  TX_STR?C  _StrArray, 16

---

Using just array's, the module will use about 250 bytes of program space.
Using the additional commands may add up to another 200 byes plus string data.
Relatively small, compared to HSEROUT.<hr>Additional commands that are available are...

Code:

---

@  TX?C      Const              ;- send a Char (constant 0-255)
@  TX?B      _Value            ;- Send a byte from a BYTE var
@  TX?W      _Value            ;- Send a binary Word var (LSB first)
@  TX_DEC?B  _Value            ;- Ascii Decimal Byte, no leading 0's
@  TX_DEC?W  _Value            ;- Ascii Decimal Word, no leading 0's
@  TX_DEC?CB  Len, _Value        ;- Ascii Decimal BYTE, Len is a constant
@  TX_DEC?CW  Len, _Value        ;- Ascii Decimal WORD, Len is a constant
@  TX_STR?C  Str, Len          ;- Send an Array, Len is a constant
@  TX_STR?B  Str, _Len          ;- Send an Array, Len is BYTE var
@  LoadStr    _Array, Str, _Len  ;- Load an Array from flash, Returns
                                ;  the length of the string in BYTE var
@  TX_FSTR  Fstr                ;- Send Fixed String from Flash
@  TX_DSTR  Dstr                ;- Send PreDefined String from Flash

---

Examples...

Code:

---

@  TX?C  "A"                    ; same as HSEROUT ["A"]

@  TX?B  _ByteVar              ; same as HSEROUT [ByteVar]

@  TX?W _WordVar                ; HSEROUT [WordVar.LowByte, WordVar.HighByte]

@  TX_DEC?B  _ByteVar          ; HSEROUT [DEC ByteVar]

@  TX_DEC?W  _WordVar          ; HSEROUT [DEC WordVar]

@  TX_DEC?CB  3, _ByteVar      ; HSEROUT [DEC3 ByteVar]

@  TX_DEC?CW  4, _WordVar      ; HSEROUT [DEC4 WordVar]

@  TX_STR?C  _StrArray, 13    ; HSEROUT [STR StrArray\13]

@  TX_STR?B  _StrArray, _ByteVar  ; HSEROUT [STR StrArray\ByteVar]

@  TX_FSTR  "Hello World\r\n"  ; HSEROUT ["Hello World",13,10]

@  TX_DSTR  Wassup            ; no equivilent
@Wassup  string "Hey dude, wasssssup!\r\n"

@  LoadStr    _StrArray, "Put me in Array\r\n", _ByteVar 
                                ; returns length of string in ByteVar 
                                ; To send the array use ...
@  TX_STR?B  _StrArray, _ByteVar

---

It's probably a bit confusing, so let me know if it doesn't make sense.
<br>

All I can say is wow!

Thats some nice work there Darrel.

Thanks very much.

I'll give it a go and report back :)

http://www.mister-e.org/Pics/Bravo1 Yet another nice use & clever of text substitution, macro, include and PBP LIBs.

Is there any baudrate limitation test report for different OSC speed?

Thanks Steve,

I think you picked up on all my little tricks in this one.

Quote:

---

Is there any baudrate limitation test report for different OSC speed?

---

No, not really.
I've run it at 115200 with 32mhz
19200 with 4mhz.

I was a bit worried about what people might try, so I put in ERROR's if you try to use a baudrate that isn't suitable for your OSC freq.
But those are really for "IDEAL" conditions.

The timing will still be affected by the interrupts. The difference is that only the rise and fall times will vary. The overall bit timing will stay consistant (as long as the INT handlers aren't too long). So Lower baud rates will still be "more stable".
<br>

Yup, i've just looked deeper in your code and i'm really confident. Used with simple care, this should solve many extra hardware thingy.

Pretty slick!

Code:

---

clrwdt        ; kick the dog

---

Never heard it put that way before. Clever tho :)

I'm a "Cat person". :D
<br>

<img SRC="http://www.picbasic.co.uk/forum/attachment.php?attachmentid=2479&stc=1&d=120759222 8">