OK so I am a dork, and I neglected to remember that you can't use both I2C
on UART0 as well as the UART function.....
I need to access (multiplex) a number of serial communication devices to the
same (UART) port so plan on doing that with analog switches (and control lines
for routing).
So now what I am thinking, is to use an inexpensive MSP like 2132 as a I2C/UART
bridge, meaning that the main MSP will query it over the I2C, the 2132 will
route the query to the relevant peripheral over UART (and using the relevant
analog switch configuration), and send back the reply to the master MSP.
Sound like an OK design?
Also, is it possible to take the master clock from the main MSP and this way
save a crystal on the 2132?
Thanks for your comments on this idea/design.....
I2C / UART bridge?
Started by ●August 17, 2009
Reply by ●August 17, 20092009-08-17
Hi merapcb,
> I need to access (multiplex) a number of serial communication
> devices to the same (UART) port so plan on doing that with analog
> switches (and control lines for routing).
Your analog switches solution will only help if there is only one uart port sending data at once, or if you use hardware flow control.
You could instad use an MSP and have multiple software UARTs so all ports can be received at the same time. I just implemented this solution with 8 UARTs (RX only) and it works flawlessly. In my case the low datarate of only 300bps on each port (althought constantly transmitting data) was low enought not to arise any time constraint issues. Upon reception of a complete packed on each of the uarts, the packed was checked for integrity (simple XOR CRC) and then retransmitted throught the hardware 115200bps UART.
> Also, is it possible to take the master clock from the main MSP and
> this way save a crystal on the 2132?
As I rememberm the XT OUT pin can drive one CMOS gate when there is a clock being fed to the XTIN pin, but I don't know it this is true when using a crystal.
But the alternative should be as simple as outputting the corresponding MCLK, SMCLK or ACLK signal (using the atlernate function of the respective I/O pin) and feeding it into the other chips XTIN input. I've not tried it and I'm not absolutely sure of the voltage level compatibilities of the XTIN input when not using a crystal. You'd have to check that.
Regards,
Michael K.
--- In m..., "merapcb" wrote:
> OK so I am a dork, and I neglected to remember that you can't use both I2C on UART0 as well as the UART function.....
>
> I need to access (multiplex) a number of serial communication devices to the same (UART) port so plan on doing that with analog switches (and control lines for routing).
>
> So now what I am thinking, is to use an inexpensive MSP like 2132 as a I2C/UART bridge, meaning that the main MSP will query it over the I2C, the 2132 will route the query to the relevant peripheral over UART (and using the relevant analog switch configuration), and send back the reply to the master MSP.
>
> Sound like an OK design?
>
> Also, is it possible to take the master clock from the main MSP and this way save a crystal on the 2132?
>
> Thanks for your comments on this idea/design.....
>
> I need to access (multiplex) a number of serial communication
> devices to the same (UART) port so plan on doing that with analog
> switches (and control lines for routing).
Your analog switches solution will only help if there is only one uart port sending data at once, or if you use hardware flow control.
You could instad use an MSP and have multiple software UARTs so all ports can be received at the same time. I just implemented this solution with 8 UARTs (RX only) and it works flawlessly. In my case the low datarate of only 300bps on each port (althought constantly transmitting data) was low enought not to arise any time constraint issues. Upon reception of a complete packed on each of the uarts, the packed was checked for integrity (simple XOR CRC) and then retransmitted throught the hardware 115200bps UART.
> Also, is it possible to take the master clock from the main MSP and
> this way save a crystal on the 2132?
As I rememberm the XT OUT pin can drive one CMOS gate when there is a clock being fed to the XTIN pin, but I don't know it this is true when using a crystal.
But the alternative should be as simple as outputting the corresponding MCLK, SMCLK or ACLK signal (using the atlernate function of the respective I/O pin) and feeding it into the other chips XTIN input. I've not tried it and I'm not absolutely sure of the voltage level compatibilities of the XTIN input when not using a crystal. You'd have to check that.
Regards,
Michael K.
--- In m..., "merapcb" wrote:
> OK so I am a dork, and I neglected to remember that you can't use both I2C on UART0 as well as the UART function.....
>
> I need to access (multiplex) a number of serial communication devices to the same (UART) port so plan on doing that with analog switches (and control lines for routing).
>
> So now what I am thinking, is to use an inexpensive MSP like 2132 as a I2C/UART bridge, meaning that the main MSP will query it over the I2C, the 2132 will route the query to the relevant peripheral over UART (and using the relevant analog switch configuration), and send back the reply to the master MSP.
>
> Sound like an OK design?
>
> Also, is it possible to take the master clock from the main MSP and this way save a crystal on the 2132?
>
> Thanks for your comments on this idea/design.....
>
Reply by ●August 17, 20092009-08-17
--- In m..., "tintronic" wrote:
>
>
> Your analog switches solution will only help if there is only one uart port sending data at once, or if you use hardware flow control.
> You could instad use an MSP and have multiple software UARTs so all ports can be received at the same time. I just implemented this solution with 8 UARTs (RX only) and it works flawlessly. In my case the low datarate of only 300bps on each port (althought constantly transmitting data) was low enought not to arise any time constraint issues. Upon reception of a complete packed on each of the uarts, the packed was checked for integrity (simple XOR CRC) and then retransmitted throught the hardware 115200bps UART.
>
Yes, basically all are slave devices so the "Master" MSP can chose when to poll them.
Regarding clock, I don't know, probably better just to throw in another crystal at the moment.... :-)
>
>
> Your analog switches solution will only help if there is only one uart port sending data at once, or if you use hardware flow control.
> You could instad use an MSP and have multiple software UARTs so all ports can be received at the same time. I just implemented this solution with 8 UARTs (RX only) and it works flawlessly. In my case the low datarate of only 300bps on each port (althought constantly transmitting data) was low enought not to arise any time constraint issues. Upon reception of a complete packed on each of the uarts, the packed was checked for integrity (simple XOR CRC) and then retransmitted throught the hardware 115200bps UART.
>
Yes, basically all are slave devices so the "Master" MSP can chose when to poll them.
Regarding clock, I don't know, probably better just to throw in another crystal at the moment.... :-)
Reply by ●August 17, 20092009-08-17
Do these have to be serial comms devices? ie Are they devices that you
have no control over? If you have control over them there are simpler
ways to overcome this. If not then it depends largely on how many of
them there are, what baud rates they are running at, and how many
different baud rates there are, as to how best to go about it. To some
extent packet size may also have an effect, as will full duplex or half
duplex operation, since you will need to buffer data if you wish to
handle multiple channels simulateously, and will need double the buffers
and buffer management if you want to run full duplex.
Depending on these factors, if you didn't have too many channels, large
data packets or full duplex, with a hardware UART, 8k of Flash and 512
bytes of RAM plus 20 other I/O pins and 5 timer channels the 2132 could
probably handle this, so don't be so vague if you want accurate advice.
Al
merapcb wrote:
> OK so I am a dork, and I neglected to remember that you can't use
> both I2C on UART0 as well as the UART function.....
>
> I need to access (multiplex) a number of serial communication devices
> to the same (UART) port so plan on doing that with analog switches
> (and control lines for routing).
>
> So now what I am thinking, is to use an inexpensive MSP like 2132 as
> a I2C/UART bridge, meaning that the main MSP will query it over the
> I2C, the 2132 will route the query to the relevant peripheral over
> UART (and using the relevant analog switch configuration), and send
> back the reply to the master MSP.
>
> Sound like an OK design?
>
> Also, is it possible to take the master clock from the main MSP and
> this way save a crystal on the 2132?
>
> Thanks for your comments on this idea/design.....
>
have no control over? If you have control over them there are simpler
ways to overcome this. If not then it depends largely on how many of
them there are, what baud rates they are running at, and how many
different baud rates there are, as to how best to go about it. To some
extent packet size may also have an effect, as will full duplex or half
duplex operation, since you will need to buffer data if you wish to
handle multiple channels simulateously, and will need double the buffers
and buffer management if you want to run full duplex.
Depending on these factors, if you didn't have too many channels, large
data packets or full duplex, with a hardware UART, 8k of Flash and 512
bytes of RAM plus 20 other I/O pins and 5 timer channels the 2132 could
probably handle this, so don't be so vague if you want accurate advice.
Al
merapcb wrote:
> OK so I am a dork, and I neglected to remember that you can't use
> both I2C on UART0 as well as the UART function.....
>
> I need to access (multiplex) a number of serial communication devices
> to the same (UART) port so plan on doing that with analog switches
> (and control lines for routing).
>
> So now what I am thinking, is to use an inexpensive MSP like 2132 as
> a I2C/UART bridge, meaning that the main MSP will query it over the
> I2C, the 2132 will route the query to the relevant peripheral over
> UART (and using the relevant analog switch configuration), and send
> back the reply to the master MSP.
>
> Sound like an OK design?
>
> Also, is it possible to take the master clock from the main MSP and
> this way save a crystal on the 2132?
>
> Thanks for your comments on this idea/design.....
>
Reply by ●August 17, 20092009-08-17
--- In m..., OneStone wrote:
>
> Do these have to be serial comms devices? ie Are they devices that you
> have no control over? If you have control over them there are simpler
> ways to overcome this. If not then it depends largely on how many of
> them there are, what baud rates they are running at, and how many
> different baud rates there are, as to how best to go about it. To some
> extent packet size may also have an effect, as will full duplex or half
> duplex operation, since you will need to buffer data if you wish to
> handle multiple channels simulateously, and will need double the buffers
> and buffer management if you want to run full duplex.
>
> Depending on these factors, if you didn't have too many channels, large
> data packets or full duplex, with a hardware UART, 8k of Flash and 512
> bytes of RAM plus 20 other I/O pins and 5 timer channels the 2132 could
> probably handle this, so don't be so vague if you want accurate advice.
>
> Al
>
Sorry, Al. No intention to be vague. Very sorry.
All devices are under my control (not to mean I make them) and they all are on 19,200bps. They are all "slaves" in that they have to be queried. So that makes them half duplex.
What I figured is that with two dual analog switch ICs and two control lines (because you always switch Tx and Rx together) I could use a single UART on the 2132 and then from there over I2C to the main MSP. Rather, the master MSP will send a I2C message with the device it would like to query and the query string, and the 2132 would switch the switches to route the UART to that device, send the query, get the reply, and send it back to the master MSP over I2C.
Hope the intention is clearer now.
Not sure what you mean by the 20 other I/O pins.
>
> Do these have to be serial comms devices? ie Are they devices that you
> have no control over? If you have control over them there are simpler
> ways to overcome this. If not then it depends largely on how many of
> them there are, what baud rates they are running at, and how many
> different baud rates there are, as to how best to go about it. To some
> extent packet size may also have an effect, as will full duplex or half
> duplex operation, since you will need to buffer data if you wish to
> handle multiple channels simulateously, and will need double the buffers
> and buffer management if you want to run full duplex.
>
> Depending on these factors, if you didn't have too many channels, large
> data packets or full duplex, with a hardware UART, 8k of Flash and 512
> bytes of RAM plus 20 other I/O pins and 5 timer channels the 2132 could
> probably handle this, so don't be so vague if you want accurate advice.
>
> Al
>
Sorry, Al. No intention to be vague. Very sorry.
All devices are under my control (not to mean I make them) and they all are on 19,200bps. They are all "slaves" in that they have to be queried. So that makes them half duplex.
What I figured is that with two dual analog switch ICs and two control lines (because you always switch Tx and Rx together) I could use a single UART on the 2132 and then from there over I2C to the main MSP. Rather, the master MSP will send a I2C message with the device it would like to query and the query string, and the 2132 would switch the switches to route the UART to that device, send the query, get the reply, and send it back to the master MSP over I2C.
Hope the intention is clearer now.
Not sure what you mean by the 20 other I/O pins.
Reply by ●August 17, 20092009-08-17
Why bother with a second micro? It seems pointless to me. You still
haven't said how many devices you plan to have talking to the micro, but
lets assume no more than eight, and more than 4. If less than 4 you can
use a 4052 dual 4:1 mux rather than a pair of 8:1's, which are
physically smaller and cheaper than a dual 8:1. use a pair of 4051's. In
fact you can run 3 if you want, one serving as the chip select. they are
cheap and come in small packages. Then you only need 4 signals in total,
3 to select the multiplexer channel. And these can simply count from
0-7, and 1 to strobe the enable pin on the mux used for Chip select.
This would have its 8 outputs tied one to each of the slaves. the rest
is easy, no need for another micro to hanlde this simple function. as I
said depending on the complexity of the rest of the application you
could handle this with a 2132. In fact you could handle this with a 2012
if this was all it had to do. As for the 20 I/O pins you can run a UART
on apair of I/O pins, one for TX, one for RX. It's easier if they have
interrupt on change, so ports 1 & 2. Even though you don't have all the
dedicated timers by using a fast crystal and a 32 bit clock extender you
can, with a bit of care, share just 1 timer across multiple software uarts.
Cheers
Al
merapcb wrote:
> --- In m..., OneStone wrote:
>> Do these have to be serial comms devices? ie Are they devices that you
>> have no control over? If you have control over them there are simpler
>> ways to overcome this. If not then it depends largely on how many of
>> them there are, what baud rates they are running at, and how many
>> different baud rates there are, as to how best to go about it. To some
>> extent packet size may also have an effect, as will full duplex or half
>> duplex operation, since you will need to buffer data if you wish to
>> handle multiple channels simulateously, and will need double the buffers
>> and buffer management if you want to run full duplex.
>>
>> Depending on these factors, if you didn't have too many channels, large
>> data packets or full duplex, with a hardware UART, 8k of Flash and 512
>> bytes of RAM plus 20 other I/O pins and 5 timer channels the 2132 could
>> probably handle this, so don't be so vague if you want accurate advice.
>>
>> Al
>>
> Sorry, Al. No intention to be vague. Very sorry.
>
> All devices are under my control (not to mean I make them) and they all are on 19,200bps. They are all "slaves" in that they have to be queried. So that makes them half duplex.
>
> What I figured is that with two dual analog switch ICs and two control lines (because you always switch Tx and Rx together) I could use a single UART on the 2132 and then from there over I2C to the main MSP. Rather, the master MSP will send a I2C message with the device it would like to query and the query string, and the 2132 would switch the switches to route the UART to that device, send the query, get the reply, and send it back to the master MSP over I2C.
>
> Hope the intention is clearer now.
>
> Not sure what you mean by the 20 other I/O pins.
>
haven't said how many devices you plan to have talking to the micro, but
lets assume no more than eight, and more than 4. If less than 4 you can
use a 4052 dual 4:1 mux rather than a pair of 8:1's, which are
physically smaller and cheaper than a dual 8:1. use a pair of 4051's. In
fact you can run 3 if you want, one serving as the chip select. they are
cheap and come in small packages. Then you only need 4 signals in total,
3 to select the multiplexer channel. And these can simply count from
0-7, and 1 to strobe the enable pin on the mux used for Chip select.
This would have its 8 outputs tied one to each of the slaves. the rest
is easy, no need for another micro to hanlde this simple function. as I
said depending on the complexity of the rest of the application you
could handle this with a 2132. In fact you could handle this with a 2012
if this was all it had to do. As for the 20 I/O pins you can run a UART
on apair of I/O pins, one for TX, one for RX. It's easier if they have
interrupt on change, so ports 1 & 2. Even though you don't have all the
dedicated timers by using a fast crystal and a 32 bit clock extender you
can, with a bit of care, share just 1 timer across multiple software uarts.
Cheers
Al
merapcb wrote:
> --- In m..., OneStone wrote:
>> Do these have to be serial comms devices? ie Are they devices that you
>> have no control over? If you have control over them there are simpler
>> ways to overcome this. If not then it depends largely on how many of
>> them there are, what baud rates they are running at, and how many
>> different baud rates there are, as to how best to go about it. To some
>> extent packet size may also have an effect, as will full duplex or half
>> duplex operation, since you will need to buffer data if you wish to
>> handle multiple channels simulateously, and will need double the buffers
>> and buffer management if you want to run full duplex.
>>
>> Depending on these factors, if you didn't have too many channels, large
>> data packets or full duplex, with a hardware UART, 8k of Flash and 512
>> bytes of RAM plus 20 other I/O pins and 5 timer channels the 2132 could
>> probably handle this, so don't be so vague if you want accurate advice.
>>
>> Al
>>
> Sorry, Al. No intention to be vague. Very sorry.
>
> All devices are under my control (not to mean I make them) and they all are on 19,200bps. They are all "slaves" in that they have to be queried. So that makes them half duplex.
>
> What I figured is that with two dual analog switch ICs and two control lines (because you always switch Tx and Rx together) I could use a single UART on the 2132 and then from there over I2C to the main MSP. Rather, the master MSP will send a I2C message with the device it would like to query and the query string, and the 2132 would switch the switches to route the UART to that device, send the query, get the reply, and send it back to the master MSP over I2C.
>
> Hope the intention is clearer now.
>
> Not sure what you mean by the 20 other I/O pins.
>
Reply by ●August 17, 20092009-08-17
--- In m..., OneStone wrote:
>
> Why bother with a second micro? It seems pointless to me. You still
> haven't said how many devices you plan to have talking to the micro, but
> lets assume no more than eight, and more than 4. If less than 4 you can
> use a 4052 dual 4:1 mux rather than a pair of 8:1's, which are
> physically smaller and cheaper than a dual 8:1. use a pair of 4051's. In
> fact you can run 3 if you want, one serving as the chip select. they are
> cheap and come in small packages. Then you only need 4 signals in total,
> 3 to select the multiplexer channel. And these can simply count from
> 0-7, and 1 to strobe the enable pin on the mux used for Chip select.
> This would have its 8 outputs tied one to each of the slaves. the rest
> is easy, no need for another micro to hanlde this simple function. as I
> said depending on the complexity of the rest of the application you
> could handle this with a 2132. In fact you could handle this with a 2012
> if this was all it had to do. As for the 20 I/O pins you can run a UART
> on apair of I/O pins, one for TX, one for RX. It's easier if they have
> interrupt on change, so ports 1 & 2. Even though you don't have all the
> dedicated timers by using a fast crystal and a 32 bit clock extender you
> can, with a bit of care, share just 1 timer across multiple software uarts.
>
> Cheers
>
> Al
>
I understand what you are saying but the additional micro is required since I don't have a free additional UART on the master MSP. One is running SPI and the other I2C (it's a 169). So that is why I need to "convert" from UART to I2C, it's the only way I can access these serial devices (at least the only way I thought of).
And I have 4 such devices. So I figure I need two TS5A23159.
Yes, I presume all could be bit banged, but: a) I have never done it before, b) I doubt the micro would have the time as it is fairly busy.
Thanks
>
> Why bother with a second micro? It seems pointless to me. You still
> haven't said how many devices you plan to have talking to the micro, but
> lets assume no more than eight, and more than 4. If less than 4 you can
> use a 4052 dual 4:1 mux rather than a pair of 8:1's, which are
> physically smaller and cheaper than a dual 8:1. use a pair of 4051's. In
> fact you can run 3 if you want, one serving as the chip select. they are
> cheap and come in small packages. Then you only need 4 signals in total,
> 3 to select the multiplexer channel. And these can simply count from
> 0-7, and 1 to strobe the enable pin on the mux used for Chip select.
> This would have its 8 outputs tied one to each of the slaves. the rest
> is easy, no need for another micro to hanlde this simple function. as I
> said depending on the complexity of the rest of the application you
> could handle this with a 2132. In fact you could handle this with a 2012
> if this was all it had to do. As for the 20 I/O pins you can run a UART
> on apair of I/O pins, one for TX, one for RX. It's easier if they have
> interrupt on change, so ports 1 & 2. Even though you don't have all the
> dedicated timers by using a fast crystal and a 32 bit clock extender you
> can, with a bit of care, share just 1 timer across multiple software uarts.
>
> Cheers
>
> Al
>
I understand what you are saying but the additional micro is required since I don't have a free additional UART on the master MSP. One is running SPI and the other I2C (it's a 169). So that is why I need to "convert" from UART to I2C, it's the only way I can access these serial devices (at least the only way I thought of).
And I have 4 such devices. So I figure I need two TS5A23159.
Yes, I presume all could be bit banged, but: a) I have never done it before, b) I doubt the micro would have the time as it is fairly busy.
Thanks
Reply by ●August 17, 20092009-08-17
I'm sorry but what you are saying makes absolutely no sense to me. Sure
I get what you have, a 169, running 1? SPI device and 1? I2C device, you
don't say how many, then you have 4 external devices with UARTS. Okay
I'd opt for a single 4052 anyway, its a dual 4:1, but that's a moot
point. Your cramming 4 channels into a shared pipe, which is okay, then
cramming them again down a single shared I2C pipe, which will require
quite a bit of overhead from the master anyway. this seems a less than
efficient way to do things. The first thing I'd do is get away from the
169, but if you're stuck with it, and you shouldn't be if you're in the
hardware design stage, then sit and think carefully about the other
components, why the mix of SPI and I2C, is it necessary, how much
sharing is going on already on those lines? The 169 has a lot of I/o,
and a damned good Timer B that can single handedly implement 4 very nice
Uarts, although you might have to get a bit kludgy with the 4th, since
there are only 7 channels. I believe this will be far more efficient
than what you are planning, and less overhead for the micro.
Al
merapcb wrote:
> --- In m..., OneStone wrote:
>> Why bother with a second micro? It seems pointless to me. You still
>> haven't said how many devices you plan to have talking to the
>> micro, but lets assume no more than eight, and more than 4. If less
>> than 4 you can use a 4052 dual 4:1 mux rather than a pair of 8:1's,
>> which are physically smaller and cheaper than a dual 8:1. use a
>> pair of 4051's. In fact you can run 3 if you want, one serving as
>> the chip select. they are cheap and come in small packages. Then
>> you only need 4 signals in total, 3 to select the multiplexer
>> channel. And these can simply count from 0-7, and 1 to strobe the
>> enable pin on the mux used for Chip select. This would have its 8
>> outputs tied one to each of the slaves. the rest is easy, no need
>> for another micro to hanlde this simple function. as I said
>> depending on the complexity of the rest of the application you
>> could handle this with a 2132. In fact you could handle this with a
>> 2012 if this was all it had to do. As for the 20 I/O pins you can
>> run a UART on apair of I/O pins, one for TX, one for RX. It's
>> easier if they have interrupt on change, so ports 1 & 2. Even
>> though you don't have all the dedicated timers by using a fast
>> crystal and a 32 bit clock extender you can, with a bit of care,
>> share just 1 timer across multiple software uarts.
>>
>> Cheers
>>
>> Al
>>
> I understand what you are saying but the additional micro is required
> since I don't have a free additional UART on the master MSP. One is
> running SPI and the other I2C (it's a 169). So that is why I need to
> "convert" from UART to I2C, it's the only way I can access these
> serial devices (at least the only way I thought of).
>
> And I have 4 such devices. So I figure I need two TS5A23159.
>
> Yes, I presume all could be bit banged, but: a) I have never done it
> before, b) I doubt the micro would have the time as it is fairly
> busy.
>
> Thanks
>
I get what you have, a 169, running 1? SPI device and 1? I2C device, you
don't say how many, then you have 4 external devices with UARTS. Okay
I'd opt for a single 4052 anyway, its a dual 4:1, but that's a moot
point. Your cramming 4 channels into a shared pipe, which is okay, then
cramming them again down a single shared I2C pipe, which will require
quite a bit of overhead from the master anyway. this seems a less than
efficient way to do things. The first thing I'd do is get away from the
169, but if you're stuck with it, and you shouldn't be if you're in the
hardware design stage, then sit and think carefully about the other
components, why the mix of SPI and I2C, is it necessary, how much
sharing is going on already on those lines? The 169 has a lot of I/o,
and a damned good Timer B that can single handedly implement 4 very nice
Uarts, although you might have to get a bit kludgy with the 4th, since
there are only 7 channels. I believe this will be far more efficient
than what you are planning, and less overhead for the micro.
Al
merapcb wrote:
> --- In m..., OneStone wrote:
>> Why bother with a second micro? It seems pointless to me. You still
>> haven't said how many devices you plan to have talking to the
>> micro, but lets assume no more than eight, and more than 4. If less
>> than 4 you can use a 4052 dual 4:1 mux rather than a pair of 8:1's,
>> which are physically smaller and cheaper than a dual 8:1. use a
>> pair of 4051's. In fact you can run 3 if you want, one serving as
>> the chip select. they are cheap and come in small packages. Then
>> you only need 4 signals in total, 3 to select the multiplexer
>> channel. And these can simply count from 0-7, and 1 to strobe the
>> enable pin on the mux used for Chip select. This would have its 8
>> outputs tied one to each of the slaves. the rest is easy, no need
>> for another micro to hanlde this simple function. as I said
>> depending on the complexity of the rest of the application you
>> could handle this with a 2132. In fact you could handle this with a
>> 2012 if this was all it had to do. As for the 20 I/O pins you can
>> run a UART on apair of I/O pins, one for TX, one for RX. It's
>> easier if they have interrupt on change, so ports 1 & 2. Even
>> though you don't have all the dedicated timers by using a fast
>> crystal and a 32 bit clock extender you can, with a bit of care,
>> share just 1 timer across multiple software uarts.
>>
>> Cheers
>>
>> Al
>>
> I understand what you are saying but the additional micro is required
> since I don't have a free additional UART on the master MSP. One is
> running SPI and the other I2C (it's a 169). So that is why I need to
> "convert" from UART to I2C, it's the only way I can access these
> serial devices (at least the only way I thought of).
>
> And I have 4 such devices. So I figure I need two TS5A23159.
>
> Yes, I presume all could be bit banged, but: a) I have never done it
> before, b) I doubt the micro would have the time as it is fairly
> busy.
>
> Thanks
>
Reply by ●August 17, 20092009-08-17
--- In m..., OneStone wrote:
>
> I'm sorry but what you are saying makes absolutely no sense to me. Sure
> I get what you have, a 169, running 1? SPI device and 1? I2C device, you
> don't say how many, then you have 4 external devices with UARTS. Okay
> I'd opt for a single 4052 anyway, its a dual 4:1, but that's a moot
> point. Your cramming 4 channels into a shared pipe, which is okay, then
> cramming them again down a single shared I2C pipe, which will require
> quite a bit of overhead from the master anyway. this seems a less than
> efficient way to do things. The first thing I'd do is get away from the
> 169, but if you're stuck with it, and you shouldn't be if you're in the
> hardware design stage, then sit and think carefully about the other
> components, why the mix of SPI and I2C, is it necessary, how much
> sharing is going on already on those lines? The 169 has a lot of I/o,
> and a damned good Timer B that can single handedly implement 4 very nice
> Uarts, although you might have to get a bit kludgy with the 4th, since
> there are only 7 channels. I believe this will be far more efficient
> than what you are planning, and less overhead for the micro.
>
> Al
>
OK, so you are saying mux/demux them in to a single software UART.... (at least I think that is what you are saying :-)
Well no, actually you are saying implement 4 software UARTS, but hey if it's only one device *at a time* I need to talk with, I guess one software UART would do and mux/demux the Rx/Tx signals, right?
OK it is finally sinking in.... if I can bit bang a single software UART, I can use your 4052.... (pity, I liked the 1:3 TS5A3359 I just found! ha)
And yes, away from the 169.... far far away.... :-) But, not possible at the moment due to other dependencies. So that's why all of this. Else, I have my eye on a F5x or F24x with plenty of UARTs to go around...
Thanks
>
> I'm sorry but what you are saying makes absolutely no sense to me. Sure
> I get what you have, a 169, running 1? SPI device and 1? I2C device, you
> don't say how many, then you have 4 external devices with UARTS. Okay
> I'd opt for a single 4052 anyway, its a dual 4:1, but that's a moot
> point. Your cramming 4 channels into a shared pipe, which is okay, then
> cramming them again down a single shared I2C pipe, which will require
> quite a bit of overhead from the master anyway. this seems a less than
> efficient way to do things. The first thing I'd do is get away from the
> 169, but if you're stuck with it, and you shouldn't be if you're in the
> hardware design stage, then sit and think carefully about the other
> components, why the mix of SPI and I2C, is it necessary, how much
> sharing is going on already on those lines? The 169 has a lot of I/o,
> and a damned good Timer B that can single handedly implement 4 very nice
> Uarts, although you might have to get a bit kludgy with the 4th, since
> there are only 7 channels. I believe this will be far more efficient
> than what you are planning, and less overhead for the micro.
>
> Al
>
OK, so you are saying mux/demux them in to a single software UART.... (at least I think that is what you are saying :-)
Well no, actually you are saying implement 4 software UARTS, but hey if it's only one device *at a time* I need to talk with, I guess one software UART would do and mux/demux the Rx/Tx signals, right?
OK it is finally sinking in.... if I can bit bang a single software UART, I can use your 4052.... (pity, I liked the 1:3 TS5A3359 I just found! ha)
And yes, away from the 169.... far far away.... :-) But, not possible at the moment due to other dependencies. So that's why all of this. Else, I have my eye on a F5x or F24x with plenty of UARTs to go around...
Thanks
Reply by ●August 17, 20092009-08-17
If the OP's hardware is already done maybe the best solution is muxing the
serial
lines. I would go for a 3V compatible 4052 as All pointed out. The TS5A23159 is a
cute device but more expensive, single supplier (4052 alike you find in baskets on
fish market) and demands 3 devices to handle 4 channels (if you need to switch
both TX and RX lines).
If the hardware is still under test/development then consider changing all....
-Augusto
On Seg 17/08/09 15:33 , OneStone o...@bigpond.net.au sent:
> I'm sorry but what you are saying makes absolutely no sense to me.
> Sure
> I get what you have, a 169, running 1? SPI device and 1? I2C device,
> you
> don't say how many, then you have 4 external devices with UARTS.
> Okay
> I'd opt for a single 4052 anyway, its a dual 4:1, but that's a moot
> point. Your cramming 4 channels into a shared pipe, which is okay,
> then
> cramming them again down a single shared I2C pipe, which will
> require
> quite a bit of overhead from the master anyway. this seems a less
> than
> efficient way to do things. The first thing I'd do is get away from
> the
> 169, but if you're stuck with it, and you shouldn't be if you're in
> the
> hardware design stage, then sit and think carefully about the other
> components, why the mix of SPI and I2C, is it necessary, how much
> sharing is going on already on those lines? The 169 has a lot of
> I/o,
> and a damned good Timer B that can single handedly implement 4 very
> nice
> Uarts, although you might have to get a bit kludgy with the 4th,
> since
> there are only 7 channels. I believe this will be far more efficient
>
> than what you are planning, and less overhead for the micro.
> Al
> merapcb wrote:
> > --- In m..., OneStone wrote:
> >> Why bother with a second micro? It seems pointless to me. You
> still
> >> haven't said how many devices you plan to have talking to the
> >> micro, but lets assume no more than eight, and more than 4. If
> less
> >> than 4 you can use a 4052 dual 4:1 mux rather than a pair of
> 8:1's,
> >> which are physically smaller and cheaper than a dual 8:1. use a
> >> pair of 4051's. In fact you can run 3 if you want, one serving as
> >> the chip select. they are cheap and come in small packages. Then
> >> you only need 4 signals in total, 3 to select the multiplexer
> >> channel. And these can simply count from 0-7, and 1 to strobe the
> >> enable pin on the mux used for Chip select. This would have its 8
> >> outputs tied one to each of the slaves. the rest is easy, no need
> >> for another micro to hanlde this simple function. as I said
> >> depending on the complexity of the rest of the application you
> >> could handle this with a 2132. In fact you could handle this with
> a
> >> 2012 if this was all it had to do. As for the 20 I/O pins you can
> >> run a UART on apair of I/O pins, one for TX, one for RX. It's
> >> easier if they have interrupt on change, so ports 1 & 2. Even
> >> though you don't have all the dedicated timers by using a fast
> >> crystal and a 32 bit clock extender you can, with a bit of care,
> >> share just 1 timer across multiple software uarts.
> >>
> >> Cheers
> >>
> >> Al
> >>
> >
> >
> > I understand what you are saying but the additional micro is
> required
> > since I don't have a free additional UART on the master MSP. One
> is
> > running SPI and the other I2C (it's a 169). So that is why I need
> to
> > "convert" from UART to I2C, it's the only way I can access these
> > serial devices (at least the only way I thought of).
> >
> > And I have 4 such devices. So I figure I need two TS5A23159.
> >
> > Yes, I presume all could be bit banged, but: a) I have never done
> it
> > before, b) I doubt the micro would have the time as it is fairly
> > busy.
> >
> > Thanks
> >
> >
> >
> >
> >
> >
> >
> >
> >
lines. I would go for a 3V compatible 4052 as All pointed out. The TS5A23159 is a
cute device but more expensive, single supplier (4052 alike you find in baskets on
fish market) and demands 3 devices to handle 4 channels (if you need to switch
both TX and RX lines).
If the hardware is still under test/development then consider changing all....
-Augusto
On Seg 17/08/09 15:33 , OneStone o...@bigpond.net.au sent:
> I'm sorry but what you are saying makes absolutely no sense to me.
> Sure
> I get what you have, a 169, running 1? SPI device and 1? I2C device,
> you
> don't say how many, then you have 4 external devices with UARTS.
> Okay
> I'd opt for a single 4052 anyway, its a dual 4:1, but that's a moot
> point. Your cramming 4 channels into a shared pipe, which is okay,
> then
> cramming them again down a single shared I2C pipe, which will
> require
> quite a bit of overhead from the master anyway. this seems a less
> than
> efficient way to do things. The first thing I'd do is get away from
> the
> 169, but if you're stuck with it, and you shouldn't be if you're in
> the
> hardware design stage, then sit and think carefully about the other
> components, why the mix of SPI and I2C, is it necessary, how much
> sharing is going on already on those lines? The 169 has a lot of
> I/o,
> and a damned good Timer B that can single handedly implement 4 very
> nice
> Uarts, although you might have to get a bit kludgy with the 4th,
> since
> there are only 7 channels. I believe this will be far more efficient
>
> than what you are planning, and less overhead for the micro.
> Al
> merapcb wrote:
> > --- In m..., OneStone wrote:
> >> Why bother with a second micro? It seems pointless to me. You
> still
> >> haven't said how many devices you plan to have talking to the
> >> micro, but lets assume no more than eight, and more than 4. If
> less
> >> than 4 you can use a 4052 dual 4:1 mux rather than a pair of
> 8:1's,
> >> which are physically smaller and cheaper than a dual 8:1. use a
> >> pair of 4051's. In fact you can run 3 if you want, one serving as
> >> the chip select. they are cheap and come in small packages. Then
> >> you only need 4 signals in total, 3 to select the multiplexer
> >> channel. And these can simply count from 0-7, and 1 to strobe the
> >> enable pin on the mux used for Chip select. This would have its 8
> >> outputs tied one to each of the slaves. the rest is easy, no need
> >> for another micro to hanlde this simple function. as I said
> >> depending on the complexity of the rest of the application you
> >> could handle this with a 2132. In fact you could handle this with
> a
> >> 2012 if this was all it had to do. As for the 20 I/O pins you can
> >> run a UART on apair of I/O pins, one for TX, one for RX. It's
> >> easier if they have interrupt on change, so ports 1 & 2. Even
> >> though you don't have all the dedicated timers by using a fast
> >> crystal and a 32 bit clock extender you can, with a bit of care,
> >> share just 1 timer across multiple software uarts.
> >>
> >> Cheers
> >>
> >> Al
> >>
> >
> >
> > I understand what you are saying but the additional micro is
> required
> > since I don't have a free additional UART on the master MSP. One
> is
> > running SPI and the other I2C (it's a 169). So that is why I need
> to
> > "convert" from UART to I2C, it's the only way I can access these
> > serial devices (at least the only way I thought of).
> >
> > And I have 4 such devices. So I figure I need two TS5A23159.
> >
> > Yes, I presume all could be bit banged, but: a) I have never done
> it
> > before, b) I doubt the micro would have the time as it is fairly
> > busy.
> >
> > Thanks
> >
> >
> >
> >
> >
> >
> >
> >
> >
