I wonder if anyone has ideas or suggestions for uart multiplexing,
or possibly switching. The solution I am trying to get to is this:
I have an x-scale host and I have an ARM7 that connects to various
devices. Three of the devices require uart IO. I would like to
find a way to switch modes such that each of these three devices
connects to either of the ARM processors. This way I can have a
low-power mode where the x-scale is sleeping, all control is done
on the ARM7. But for more advanced applications the x-scale wakes
up and takes over control of the three devices.
I have thought about several solutions, including:
1) I found an ARM7 with 4 UARTS, I could connect one to the x-scale
and the other three to the devices. Then I could use embedded
control characters in the serial data to/from the main host to
identify its target device.
However, I'd like the ports to appear as standard uarts on the
x-scale for application use. Is it possible to write a virtual
com driver that presents three uarts to the linux kernel, but
physically there is only one mutiplexed port?
2) An ARM7 with 4 uarts could connect to two devices and two uarts
on the main host. In pass through mode, the ARM7 simply passes
data out the other uart. When the ARM7 is in control is can use
the uarts to control devices instead. This seems simple and easy
but I would likely need more than one ARM7 or some other MCU.
3) I could use an spi-uart IC for connections to devices and real
uarts for connection to main host. But space and cost are a
concern here.
4) A digital switch could be used to physically connect the device
uart to either the ARM7 or xscale. Again space and cost concern.
5) I suppose there are bitbang methods but I don't want to waste
many cycles for this kind of thing.
Does anyone have any suggestions for a solution, or have you tried
any of these methods? Anyone written virtual com port drivers?
Are there any LPCs with 4 uarts. The ST micro STR711 looks pretty
nice for the kind of problem I'm working on.
TIA,
Doug
UART multiplexing or switching
Started by ●August 2, 2005
Reply by ●August 2, 20052005-08-02
Hi Doug,
I've had a quick scan of your post. Make it simple for yourself and talk
to the 3 devices with 3 ports from the host. Then all you need with the
ARM are 3 OR gates plus RS232 buffers to OR the TXs from the ARM and the
host. The RXs can be run directly to both ARM and host. Ditto that for
any additional lines you are running. Of course, the ARM wouldn't try to
talk at the same time as the host and you might have a simple scheme
whereby if the host didn't respond within a certain timeframe then the
ARM could assume responsibility? It would be very app specific of
course. Maybe you could use a single hand-shake line into the ARM to
control the host/ARM thing.
As regards the 3 coms ports you can bit-bang one under interrupts using
an EXTINT plus a timer or some other method. Even easier if it's
effectively half-duplex.
Alternatively, dedicate one UART to the host port and the other to the
device port with simple multiplexer gating. But since I'm not in your
shoes I don't know all the constraints and requirements of the system so
I'll bow out now before I get too deep into the realms of hypotheticals.
*Peter*
Doug Sutherland wrote:
>I wonder if anyone has ideas or suggestions for uart multiplexing,
>or possibly switching. The solution I am trying to get to is this:
>I have an x-scale host and I have an ARM7 that connects to various
>devices. Three of the devices require uart IO. I would like to
>find a way to switch modes such that each of these three devices
>connects to either of the ARM processors. This way I can have a
>low-power mode where the x-scale is sleeping, all control is done
>on the ARM7. But for more advanced applications the x-scale wakes
>up and takes over control of the three devices.
>
>I have thought about several solutions, including:
>
>1) I found an ARM7 with 4 UARTS, I could connect one to the x-scale
> and the other three to the devices. Then I could use embedded
> control characters in the serial data to/from the main host to
> identify its target device.
>
> However, I'd like the ports to appear as standard uarts on the
> x-scale for application use. Is it possible to write a virtual
> com driver that presents three uarts to the linux kernel, but
> physically there is only one mutiplexed port?
>
>2) An ARM7 with 4 uarts could connect to two devices and two uarts
> on the main host. In pass through mode, the ARM7 simply passes
> data out the other uart. When the ARM7 is in control is can use
> the uarts to control devices instead. This seems simple and easy
> but I would likely need more than one ARM7 or some other MCU.
>
>3) I could use an spi-uart IC for connections to devices and real
> uarts for connection to main host. But space and cost are a
> concern here.
>
>4) A digital switch could be used to physically connect the device
> uart to either the ARM7 or xscale. Again space and cost concern.
>
>5) I suppose there are bitbang methods but I don't want to waste
> many cycles for this kind of thing.
>
>Does anyone have any suggestions for a solution, or have you tried
>any of these methods? Anyone written virtual com port drivers?
>
>Are there any LPCs with 4 uarts. The ST micro STR711 looks pretty
>nice for the kind of problem I'm working on.
>
I've had a quick scan of your post. Make it simple for yourself and talk
to the 3 devices with 3 ports from the host. Then all you need with the
ARM are 3 OR gates plus RS232 buffers to OR the TXs from the ARM and the
host. The RXs can be run directly to both ARM and host. Ditto that for
any additional lines you are running. Of course, the ARM wouldn't try to
talk at the same time as the host and you might have a simple scheme
whereby if the host didn't respond within a certain timeframe then the
ARM could assume responsibility? It would be very app specific of
course. Maybe you could use a single hand-shake line into the ARM to
control the host/ARM thing.
As regards the 3 coms ports you can bit-bang one under interrupts using
an EXTINT plus a timer or some other method. Even easier if it's
effectively half-duplex.
Alternatively, dedicate one UART to the host port and the other to the
device port with simple multiplexer gating. But since I'm not in your
shoes I don't know all the constraints and requirements of the system so
I'll bow out now before I get too deep into the realms of hypotheticals.
*Peter*
Doug Sutherland wrote:
>I wonder if anyone has ideas or suggestions for uart multiplexing,
>or possibly switching. The solution I am trying to get to is this:
>I have an x-scale host and I have an ARM7 that connects to various
>devices. Three of the devices require uart IO. I would like to
>find a way to switch modes such that each of these three devices
>connects to either of the ARM processors. This way I can have a
>low-power mode where the x-scale is sleeping, all control is done
>on the ARM7. But for more advanced applications the x-scale wakes
>up and takes over control of the three devices.
>
>I have thought about several solutions, including:
>
>1) I found an ARM7 with 4 UARTS, I could connect one to the x-scale
> and the other three to the devices. Then I could use embedded
> control characters in the serial data to/from the main host to
> identify its target device.
>
> However, I'd like the ports to appear as standard uarts on the
> x-scale for application use. Is it possible to write a virtual
> com driver that presents three uarts to the linux kernel, but
> physically there is only one mutiplexed port?
>
>2) An ARM7 with 4 uarts could connect to two devices and two uarts
> on the main host. In pass through mode, the ARM7 simply passes
> data out the other uart. When the ARM7 is in control is can use
> the uarts to control devices instead. This seems simple and easy
> but I would likely need more than one ARM7 or some other MCU.
>
>3) I could use an spi-uart IC for connections to devices and real
> uarts for connection to main host. But space and cost are a
> concern here.
>
>4) A digital switch could be used to physically connect the device
> uart to either the ARM7 or xscale. Again space and cost concern.
>
>5) I suppose there are bitbang methods but I don't want to waste
> many cycles for this kind of thing.
>
>Does anyone have any suggestions for a solution, or have you tried
>any of these methods? Anyone written virtual com port drivers?
>
>Are there any LPCs with 4 uarts. The ST micro STR711 looks pretty
>nice for the kind of problem I'm working on.
>
