Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

Time multiplexing 2 UART streams into 1

Status
Not open for further replies.
F

faisal78

Member level 3
Joined
Aug 27, 2004
Messages
62
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,286
Activity points
592
Hi
My host MCU is limited to only 1 UART port.
I am trying to hookup to a Bluetooth module & a separate GPS module.
Both of these modules communicate to host via UART.

This system needs to be able to stream the GPS NMEA via BT, so technically both modules needs to be talking to host all the time.
I will not be able to use a UART switch per say.

Is my only solution to implement another secondary MCU in between which is capable of 3 UART ports, and for me to connect each port to each module?
for example if both GPS & BT modules operate at 115kbps UART, the host would need to have a 1 Mbps UART stream to ensure the data throughput for time mutiplexing is possible.

Any comments or better solutions?
 

One hardware UART and one soft UART. If you use ARM, you'll have enough time to do the soft UART
 

Can you reduce baudrate? If you reduce baudrate to 9600 (or lower is possible), software UART is relative easy to implement and lower baudrates are less sensitive on baudrate error. Fastest baudrate implementation depends on the rest of the application and MCU speed and sometime is hard to implement or impossible. Another important thing is what type communication you can expect from your modules. If you have situation to receive byte while sending another byte or vice versa, your implementation can be more complicate. One way to solve problem is sampling your data stream with timer tick interrupt with e.g. 4x (or more is better) baudrate speed. send and receive function in one interrupt. First, you should be detail analyse your protocol with modules and it will start point for design.
 

actually no need of arm. depends on the clock and peripheral speed of micro. which micro do you have?
of course you have to BIT BANG for other uarts, if you have not many.
 

Have you done any systems analysis on the data? Exactly how much and how often will each device need to transfer
data and what capability does your existing system have to process this.
You might find that your standard interrupt routine with something as simple as a digital switch is all you need.

On the other hand you seem to indicate you could use a more suitable processor if you have to - so why not do that?
There are many PIC chips with multiple uarts.
That being said - even "bit banging" as suggested above can be done fast enough to beat even a fast uart you want to go that way.
 
daniel_edb said:
Can you reduce baudrate? If you reduce baudrate to 9600 (or lower is possible), software UART is relative easy to implement and lower baudrates are less sensitive on baudrate error. Fastest baudrate implementation depends on the rest of the application and MCU speed and sometime is hard to implement or impossible. Another important thing is what type communication you can expect from your modules. If you have situation to receive byte while sending another byte or vice versa, your implementation can be more complicate. One way to solve problem is sampling your data stream with timer tick interrupt with e.g. 4x (or more is better) baudrate speed. send and receive function in one interrupt. First, you should be detail analyse your protocol with modules and it will start point for design.
Click to expand...

Hello daniel,
When you mention about software UART, it is to hook up the "secondary" UART port to GPIO's of my host processor right?
THen just oversample, i.e. read, the GPIO (bit-bang) for the UART_RX.

Correct me if I am wrong, but, for most GPS modules, after being initialized, we would only receive NMEA data. and we shouldn't need to Tx any UART to the module.
However, I believe during initialization, we would still need bi-directional UART.

Comments?
 

BIT BANG means you have to use your own UART logic on any 2 GIPO instead using hardware UART. you have to implement full UART protocol for that..

you can do both RECEIVE and TRANSMIT simultaneously, (I.E. FULL DUPLEX) if your HOST uc is fast enough..

by the way what do you means by "over sample" and "hookup"??
 
Last edited:

Just an FYI - the mikro compilers have software uart libraries that are easy to use.
It would help to know what processor you are using.
 

123jack said:
Just an FYI - the mikro compilers have software uart libraries that are easy to use.
It would help to know what processor you are using.
Click to expand...

but he has only 1 hardware UART. and i think mikroe does support only that one. for second UART, he should go for BIT BANGING, unless he changes his controller.
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top