On that note, you might also consider changing the I2C device (or devices?
usually an EEPROM?) for an SPI version of the same device. Furthermore, the SPI
and UART signals of both USARTs on the 169 are on different pins. You could
change the configuration of the USART between UART and SPI depending on what
device you need to communicate with.
It's quite simple to bitbang an SPI, so you might free the USART hardware
for UART operation.
But I can understand the use of an extra MSP. For one, it might be academically
interesting (not sure if you are a student) and it helps breaking down the
software into less interacting and time consuming/racing functions, which might
significantly reduce the developing time if you have not much experience or if
you are unsure if you can cram all the functions into a single MSP. Efficiency
is, after all, dependent on the perspective you are measuring it from. You might
use one single MSP more efficiently, but the cost of the time spent developing
the code might make it less efficient than a mayor cost in hardware would.
If you go with the additional MSP solution, I'd use SPI instead of I2C,
since it's far more simple, can be 10 times as fast (4MHz v/s 400kHz), and
will probably take you far less time to implement and debug (less overhead).
Regards,
Michael K.
--- 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
>
> 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
> >
> >
> >
> >
> >
> >
> >
> >
> >
I2C / UART bridge?
Started by ●August 17, 2009
Reply by ●August 17, 20092009-08-17
Reply by ●August 17, 20092009-08-17
>
> 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)
>
Regardless of all the other architectural options being thrown around, I'd like to make one point... perhaps in the form of a question to the more experienced folk on here.
If I need to "switch" logic paths to/from a set of external devices, why would I choose to use an analog like the 4051/4052/4053 family? Wouldn't a set of data selectors/demuxes ('151, '153, '138, etc) be the purer design choice? I recall years ago, the FET analog switches were associated with latchup problems, ESD sensitivities, etc.
Wouldn't you prefer logic gates to FET switches for logic steering?
Dave
> 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)
>
Regardless of all the other architectural options being thrown around, I'd like to make one point... perhaps in the form of a question to the more experienced folk on here.
If I need to "switch" logic paths to/from a set of external devices, why would I choose to use an analog like the 4051/4052/4053 family? Wouldn't a set of data selectors/demuxes ('151, '153, '138, etc) be the purer design choice? I recall years ago, the FET analog switches were associated with latchup problems, ESD sensitivities, etc.
Wouldn't you prefer logic gates to FET switches for logic steering?
Dave
Reply by ●August 17, 20092009-08-17
Just an idea that might be useful: Since all the devices are slaves, if you use
one TTL-232 driver for each slave, you can group all the RX signal using a big
AND gate or a combination of AND gates. Since RX line is on a logic
'1' while idle, any RX line that goes down to zero will produce a zero
on the output of the AND gate (or array of gates). You would then only need a
digital mux for the TX part (or you could do it with OR gates depending on how
many slaves we're talking about).
I'm curious about the analog switch/mux you plan to use. Did you make sure they support the whole voltage range of the RS-232 standard? I suppose your UART slaves are RS-232 because you talk about an analog switch.
Regards,
Michael K.
--- In m..., "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.
>
I'm curious about the analog switch/mux you plan to use. Did you make sure they support the whole voltage range of the RS-232 standard? I suppose your UART slaves are RS-232 because you talk about an analog switch.
Regards,
Michael K.
--- In m..., "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
What I'm actually saying is that perhaps you should review the whole
design. How many SPI devices are you using. How many I2C, what sort of
rate do these need to be accessed at. What sort of rate do the UART
devices need to be accessed at. It may well be that you are better off
allocating your hardware resources to the hardware UART rather than the
hardware SPI or I2C for example. OR ir may well be that you are better
off implementing a VERY simple UART using a timer on the 169 and EITHER
doing one UART and muxes, which takes a bit of management and overhead,
or doing it directly, if you have the I/O capacity, if you use a single
UART you can allocate a single timer A channel and use single duplex or
allocate 2 channels and go full duplex. You can do the same with Timer
B, except that timer B has only a single allocated pin per channel. You
can also allocate one capture pin per UART for receive mode and use the
same timer to time transmissions, without having to allocate a second
timer, but you then need to watch interrupt latency at higher baud
rates. Basically there are many wasy to resolve this issue, and I don't
think a second micro is up there as one of the best.
Al
merapcb wrote:
> --- 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
>
design. How many SPI devices are you using. How many I2C, what sort of
rate do these need to be accessed at. What sort of rate do the UART
devices need to be accessed at. It may well be that you are better off
allocating your hardware resources to the hardware UART rather than the
hardware SPI or I2C for example. OR ir may well be that you are better
off implementing a VERY simple UART using a timer on the 169 and EITHER
doing one UART and muxes, which takes a bit of management and overhead,
or doing it directly, if you have the I/O capacity, if you use a single
UART you can allocate a single timer A channel and use single duplex or
allocate 2 channels and go full duplex. You can do the same with Timer
B, except that timer B has only a single allocated pin per channel. You
can also allocate one capture pin per UART for receive mode and use the
same timer to time transmissions, without having to allocate a second
timer, but you then need to watch interrupt latency at higher baud
rates. Basically there are many wasy to resolve this issue, and I don't
think a second micro is up there as one of the best.
Al
merapcb wrote:
> --- 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
>
Reply by ●August 17, 20092009-08-17
Dave,
> If I need to "switch" logic paths to/from a set of external
> devices, why would I choose to use an analog like the
> 4051/4052/4053 family?
I don't recall anyone saying the slaves siganals were 0 - 3V in nature. What we know is they are UARTs, but not the voltage of the slaves. If there is a single TTL-232 transceiver, you'd need an analog switch capable of switching at least +12V and -12V. As I remember, the 405x family needs to be fed with a negative supply bigger in magnitude than the analog signal to be able to switch negative analog voltages, which I don't know if the OP is taking into accound.
Regards,
Michael K.
--- In m..., "David Boyd" wrote:
>
> >
> > 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)
> > Regardless of all the other architectural options being thrown around, I'd like to make one point... perhaps in the form of a question to the more experienced folk on here.
>
> If I need to "switch" logic paths to/from a set of external devices, why would I choose to use an analog like the 4051/4052/4053 family? Wouldn't a set of data selectors/demuxes ('151, '153, '138, etc) be the purer design choice? I recall years ago, the FET analog switches were associated with latchup problems, ESD sensitivities, etc.
>
> Wouldn't you prefer logic gates to FET switches for logic steering?
>
> Dave
>
> If I need to "switch" logic paths to/from a set of external
> devices, why would I choose to use an analog like the
> 4051/4052/4053 family?
I don't recall anyone saying the slaves siganals were 0 - 3V in nature. What we know is they are UARTs, but not the voltage of the slaves. If there is a single TTL-232 transceiver, you'd need an analog switch capable of switching at least +12V and -12V. As I remember, the 405x family needs to be fed with a negative supply bigger in magnitude than the analog signal to be able to switch negative analog voltages, which I don't know if the OP is taking into accound.
Regards,
Michael K.
--- In m..., "David Boyd" wrote:
>
> >
> > 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)
> > Regardless of all the other architectural options being thrown around, I'd like to make one point... perhaps in the form of a question to the more experienced folk on here.
>
> If I need to "switch" logic paths to/from a set of external devices, why would I choose to use an analog like the 4051/4052/4053 family? Wouldn't a set of data selectors/demuxes ('151, '153, '138, etc) be the purer design choice? I recall years ago, the FET analog switches were associated with latchup problems, ESD sensitivities, etc.
>
> Wouldn't you prefer logic gates to FET switches for logic steering?
>
> Dave
>
Reply by ●August 17, 20092009-08-17
--- In m..., "tintronic" wrote:
>
> I don't recall anyone saying the slaves siganals were 0 - 3V in nature. What we know is they are UARTs, but not the voltage of the slaves. If there is a single TTL-232 transceiver, you'd need an analog switch capable of switching at least +12V and -12V. As I remember, the 405x family needs to be fed with a negative supply bigger in magnitude than the analog signal to be able to switch negative analog voltages, which I don't know if the OP is taking into accound.
>
> Regards,
> Michael K.
>
I am the OP (phew...), so let me clarify again. There are three serial devices. Two of them are coming in via a 3232 (which gives us 3v TTL) and one is natively TTL also. So the muxing that is being talked about is not at the RS232 levels but at the 0-3v TTL levels. I hope this clarifies?
(and this is turning in to a very interesting discussion... at least for me, thank you everyone! Keep it coming)
>
> I don't recall anyone saying the slaves siganals were 0 - 3V in nature. What we know is they are UARTs, but not the voltage of the slaves. If there is a single TTL-232 transceiver, you'd need an analog switch capable of switching at least +12V and -12V. As I remember, the 405x family needs to be fed with a negative supply bigger in magnitude than the analog signal to be able to switch negative analog voltages, which I don't know if the OP is taking into accound.
>
> Regards,
> Michael K.
>
I am the OP (phew...), so let me clarify again. There are three serial devices. Two of them are coming in via a 3232 (which gives us 3v TTL) and one is natively TTL also. So the muxing that is being talked about is not at the RS232 levels but at the 0-3v TTL levels. I hope this clarifies?
(and this is turning in to a very interesting discussion... at least for me, thank you everyone! Keep it coming)
Reply by ●August 17, 20092009-08-17
They are no longer the wimpy things they once were that fainted at the
sight of a finger. They come in automotive Hi-rel specs, 3.3V 5V
tolerant, CD74LVfamilies, HC, HCT etc. They are dirt cheap, and
bidirectional, perfect for this sort of app. There are even versions
around that take 3V control signals and can switch 40V signals.
Al
David Boyd wrote:
>> 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)
>> Regardless of all the other architectural options being thrown
> around, I'd like to make one point... perhaps in the form of a
> question to the more experienced folk on here.
>
> If I need to "switch" logic paths to/from a set of external devices,
> why would I choose to use an analog like the 4051/4052/4053 family?
> Wouldn't a set of data selectors/demuxes ('151, '153, '138, etc) be
> the purer design choice? I recall years ago, the FET analog switches
> were associated with latchup problems, ESD sensitivities, etc.
>
> Wouldn't you prefer logic gates to FET switches for logic steering?
>
> Dave
>
sight of a finger. They come in automotive Hi-rel specs, 3.3V 5V
tolerant, CD74LVfamilies, HC, HCT etc. They are dirt cheap, and
bidirectional, perfect for this sort of app. There are even versions
around that take 3V control signals and can switch 40V signals.
Al
David Boyd wrote:
>> 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)
>> Regardless of all the other architectural options being thrown
> around, I'd like to make one point... perhaps in the form of a
> question to the more experienced folk on here.
>
> If I need to "switch" logic paths to/from a set of external devices,
> why would I choose to use an analog like the 4051/4052/4053 family?
> Wouldn't a set of data selectors/demuxes ('151, '153, '138, etc) be
> the purer design choice? I recall years ago, the FET analog switches
> were associated with latchup problems, ESD sensitivities, etc.
>
> Wouldn't you prefer logic gates to FET switches for logic steering?
>
> Dave
>
Reply by ●August 17, 20092009-08-17
On Mon, 17 Aug 2009 14:55:54 -0000, you 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 hope you will forgive my late arrival on this topic. A few years
ago, I had a similar problem (as I read it, anyway.) You can tell me
just how similar after I describe my earlier situation:
We had developed a completed system which included a single RS-232
port. But we later needed to hook up a bunch of them to a PC for data
logging and later analysis of the measurement samples from them. The
obvious idea was to consider some specialty RS-232 board for the IBM
PC, but at the time these were expensive and would require custom
software that would monitor all the ports and merge the data into a
single file. Another possible approach was to do what you are
suggesting above. But that would be yet another development project,
time was short, and we needed to set something up in a day or two --
not weeks. In the end, I thought for a little bit and suggested a
means by which we could hook up all the boards to a single RS-232 port
and co-mingle the outputs.
We had extra pins on the processors. Not many, and besides we didn't
want to have to do much 'wiring' to get this going. So I set up two
port pins on each board as 'grant' and 'address' as wire-or electrical
arrangements (using the PIC's ability to operate its own outputs as an
open-drain, if programmed that way.) We also wire-or'd the RS-232
drive/receive lines (the software on each board would only enable
their RS-232 pins [high impedance, otherwise] if and only if they were
granted access by the other two wires they shared.) We kept the
RS-232 electrical signal chips on all the boards (no mods other than
the wires to connect them) and just selected any one of the driver
chip pins to connect to the PC.
The software modification I made was trivial, really. And it took me
only a few hours to add. (Reprogramming the boards was easy.) Each
board's software had a unique (and short) coded binary address. Any
board ready to send output would first sample the grant line. If it
was already low, it held back and waited. If the grant line was
observed to be high, then the board would drive the grant line low and
then attempt to drive the address line bits on the address line. At
each bit time, it would either drive an active low (for a '0') or a
tristate high (for a '1'.) Then it would sample the address line. If
it matched what it thought it should be, it would drive out the next
address bit. If all the bits matched, it then decided that it owned
the RS-232, held the grant line, and operated the RS-232. Then
released the grant line.
Many times, as soon as a processor 'sees' the grant line high and
takes control by driving it low, all the other processors don't
interfere at all because when they see the grant line low they hold
off. So the one board seeking access just shifts out its address bits
with no competition. However, since the boards are running asynch
with each other, it's possible that two boards (or more) will both
observe the grant line 'high' around the same time and all decide to
drive the grant line low and start shifting out their address bits
near the same start time. (One must account for variations and this
is why such code cannot easily use C but must use assembly, so that
the cycle time for sample-to-grant-hold is known and precise, as well
as the bit shifting process that must take the same time regardless of
the bit time if you want the address-shift-out process to be faster.)
The design can be made entirely robust against variations between the
processors in their sampling time on grant and bit shifting. (Allow
enough time for each bit.) A processor driving an address 0 bit will
always observe a 0, obviously (don't need to look), so the processor
with the entire address of 0000, for example, will always "win" in
such a competition. However, there are '1' bits, then other
processors that also felt they might own the grant line may lose out.
When they drive a '1' and observe a '0', their software is set up to
then release both the address and grant lines to high impedance and
return to the wait-and-see condition before trying, once again.
It worked, superbly, and we could use any one of the working RS-232
outputs from any of the boards (as they were all driven exactly the
same, obviously.) Hardware mods were minimized (just a 4-wire ribbon
tapped to each board so that the RS-232 pair and the grant/address
pair were shared (Vcc logic levels only... the RS-232 chips and their
external RS-232 signaling level pins were left untouched.)
Jon
>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 hope you will forgive my late arrival on this topic. A few years
ago, I had a similar problem (as I read it, anyway.) You can tell me
just how similar after I describe my earlier situation:
We had developed a completed system which included a single RS-232
port. But we later needed to hook up a bunch of them to a PC for data
logging and later analysis of the measurement samples from them. The
obvious idea was to consider some specialty RS-232 board for the IBM
PC, but at the time these were expensive and would require custom
software that would monitor all the ports and merge the data into a
single file. Another possible approach was to do what you are
suggesting above. But that would be yet another development project,
time was short, and we needed to set something up in a day or two --
not weeks. In the end, I thought for a little bit and suggested a
means by which we could hook up all the boards to a single RS-232 port
and co-mingle the outputs.
We had extra pins on the processors. Not many, and besides we didn't
want to have to do much 'wiring' to get this going. So I set up two
port pins on each board as 'grant' and 'address' as wire-or electrical
arrangements (using the PIC's ability to operate its own outputs as an
open-drain, if programmed that way.) We also wire-or'd the RS-232
drive/receive lines (the software on each board would only enable
their RS-232 pins [high impedance, otherwise] if and only if they were
granted access by the other two wires they shared.) We kept the
RS-232 electrical signal chips on all the boards (no mods other than
the wires to connect them) and just selected any one of the driver
chip pins to connect to the PC.
The software modification I made was trivial, really. And it took me
only a few hours to add. (Reprogramming the boards was easy.) Each
board's software had a unique (and short) coded binary address. Any
board ready to send output would first sample the grant line. If it
was already low, it held back and waited. If the grant line was
observed to be high, then the board would drive the grant line low and
then attempt to drive the address line bits on the address line. At
each bit time, it would either drive an active low (for a '0') or a
tristate high (for a '1'.) Then it would sample the address line. If
it matched what it thought it should be, it would drive out the next
address bit. If all the bits matched, it then decided that it owned
the RS-232, held the grant line, and operated the RS-232. Then
released the grant line.
Many times, as soon as a processor 'sees' the grant line high and
takes control by driving it low, all the other processors don't
interfere at all because when they see the grant line low they hold
off. So the one board seeking access just shifts out its address bits
with no competition. However, since the boards are running asynch
with each other, it's possible that two boards (or more) will both
observe the grant line 'high' around the same time and all decide to
drive the grant line low and start shifting out their address bits
near the same start time. (One must account for variations and this
is why such code cannot easily use C but must use assembly, so that
the cycle time for sample-to-grant-hold is known and precise, as well
as the bit shifting process that must take the same time regardless of
the bit time if you want the address-shift-out process to be faster.)
The design can be made entirely robust against variations between the
processors in their sampling time on grant and bit shifting. (Allow
enough time for each bit.) A processor driving an address 0 bit will
always observe a 0, obviously (don't need to look), so the processor
with the entire address of 0000, for example, will always "win" in
such a competition. However, there are '1' bits, then other
processors that also felt they might own the grant line may lose out.
When they drive a '1' and observe a '0', their software is set up to
then release both the address and grant lines to high impedance and
return to the wait-and-see condition before trying, once again.
It worked, superbly, and we could use any one of the working RS-232
outputs from any of the boards (as they were all driven exactly the
same, obviously.) Hardware mods were minimized (just a 4-wire ribbon
tapped to each board so that the RS-232 pair and the grant/address
pair were shared (Vcc logic levels only... the RS-232 chips and their
external RS-232 signaling level pins were left untouched.)
Jon
Reply by ●August 17, 20092009-08-17
Hello,
Based on what you're writing and guessing a bit into your application, do you have both I2C devices as well as serial?
Let me outline your options:
1. You have both I2C and Serial (0-3TTL) devices:
-Solution: Based on the knowledge that you have a 169, you have both a UART and an I2C at your disposal. Use them both, and utilize a mux or two for Rx and Tx on your devices (I'm not a fan of wired-OR solutions, but this is your project here).
-Solution 2: Both interface modules are tied up for some reason, your original post is the next best solution.
2. You have JUST Serial (0-3TTL) devices:
-Solution: Mux it. I2C may have fewer lines for transmission on this, but muxing will be easier in the long run.
-Steve
________________________________
From: m... [mailto:m...] On Behalf Of merapcb
Sent: Monday, August 17, 2009 10:56 AM
To: m...
Subject: [msp430] I2C / UART bridge?
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.....
Based on what you're writing and guessing a bit into your application, do you have both I2C devices as well as serial?
Let me outline your options:
1. You have both I2C and Serial (0-3TTL) devices:
-Solution: Based on the knowledge that you have a 169, you have both a UART and an I2C at your disposal. Use them both, and utilize a mux or two for Rx and Tx on your devices (I'm not a fan of wired-OR solutions, but this is your project here).
-Solution 2: Both interface modules are tied up for some reason, your original post is the next best solution.
2. You have JUST Serial (0-3TTL) devices:
-Solution: Mux it. I2C may have fewer lines for transmission on this, but muxing will be easier in the long run.
-Steve
________________________________
From: m... [mailto:m...] On Behalf Of merapcb
Sent: Monday, August 17, 2009 10:56 AM
To: m...
Subject: [msp430] I2C / UART bridge?
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
> There are three serial devices. Two of them are
coming in via a
> 3232 (which gives us 3v TTL) and one is natively TTL also.
So, for mixing the 3 UARTs into one:
1) You don't need an analog mux, a digital mux or switches (like the 4066) will suffice. Even 3 OR gates will do it (inputs are MSP-TX and #SELx signal, outputs go to the 3 slaves RX signals).
2) You can use a 3-input AND gate (or two 2-input AND gates) for mixing the slave TX lines into the MSP RX line.
We still don't know what your I2C and SPI devices are.
Regards,
Michael K.
--- In m..., "merapcb" wrote:
>
> --- In m..., "tintronic" wrote:
> > > I don't recall anyone saying the slaves siganals were 0 - 3V in nature. What we know is they are UARTs, but not the voltage of the slaves. If there is a single TTL-232 transceiver, you'd need an analog switch capable of switching at least +12V and -12V. As I remember, the 405x family needs to be fed with a negative supply bigger in magnitude than the analog signal to be able to switch negative analog voltages, which I don't know if the OP is taking into accound.
> >
> > Regards,
> > Michael K.
> > I am the OP (phew...), so let me clarify again. There are three serial devices. Two of them are coming in via a 3232 (which gives us 3v TTL) and one is natively TTL also. So the muxing that is being talked about is not at the RS232 levels but at the 0-3v TTL levels. I hope this clarifies?
>
> (and this is turning in to a very interesting discussion... at least for me, thank you everyone! Keep it coming)
>
> 3232 (which gives us 3v TTL) and one is natively TTL also.
So, for mixing the 3 UARTs into one:
1) You don't need an analog mux, a digital mux or switches (like the 4066) will suffice. Even 3 OR gates will do it (inputs are MSP-TX and #SELx signal, outputs go to the 3 slaves RX signals).
2) You can use a 3-input AND gate (or two 2-input AND gates) for mixing the slave TX lines into the MSP RX line.
We still don't know what your I2C and SPI devices are.
Regards,
Michael K.
--- In m..., "merapcb" wrote:
>
> --- In m..., "tintronic" wrote:
> > > I don't recall anyone saying the slaves siganals were 0 - 3V in nature. What we know is they are UARTs, but not the voltage of the slaves. If there is a single TTL-232 transceiver, you'd need an analog switch capable of switching at least +12V and -12V. As I remember, the 405x family needs to be fed with a negative supply bigger in magnitude than the analog signal to be able to switch negative analog voltages, which I don't know if the OP is taking into accound.
> >
> > Regards,
> > Michael K.
> > I am the OP (phew...), so let me clarify again. There are three serial devices. Two of them are coming in via a 3232 (which gives us 3v TTL) and one is natively TTL also. So the muxing that is being talked about is not at the RS232 levels but at the 0-3v TTL levels. I hope this clarifies?
>
> (and this is turning in to a very interesting discussion... at least for me, thank you everyone! Keep it coming)
>
