Forums

I2C master

Started by David Lesher September 22, 2017
On Sat, 23 Sep 2017 00:39:43 -0400, rickman <gnuarm@gmail.com> wrote:

>Tim Williams wrote on 9/22/2017 10:42 PM: >> "rickman" <gnuarm@gmail.com> wrote in message >> news:oq49e4$tqk$1@dont-email.me... >>>> Thanks, we'll eschew. RS-232 may be old and slow but works.... >>> >>> It's also not multi-master... I guess you can roll your own. >> >> RS-485 is a solved problem, cheap, and noise tolerant. Or CAN, if you don't >> mind a little more hardware (often provided in MCUs) and more automation as >> far as the bus dealing with bus-y problems all by itself. >> >> These might be a little hungry, or overly robust. If you need lower current >> consumption, and the signal doesn't have to leave the board, an open >> collector bus (like I2C) is still a good idea. > >RS-485 is an electrical interface, nothing more. It doesn't solve the >multi-master problem any more than RS-232 does.
RS-485 is half-duples master-slve systems. With a single master, it will access slave(s) sequentially by polling with some protocol. With multi-master the only extra thing that is needed is some coordination between the master, no need to coordinate the slaves, since it is already handled by the basic poll protocol. Since all masters are on the same RS-485 bus, they will hear each others transmissions. For instance, active master can send a handover telegram on the bus, which the passive master intercepts and becomes active and starts polling the slaves. A more formal method is to use token passing (as in Profibus-DP) between the masters and then let each master do its own slave polling.
On Fri, 22 Sep 2017 23:55:13 -0500, "Tim Williams"
<tmoranwms@gmail.com> wrote:

>"rickman" <gnuarm@gmail.com> wrote in message >news:oq4oif$20s$1@dont-email.me... >> RS-485 is an electrical interface, nothing more. It doesn't solve the >> multi-master problem any more than RS-232 does. > >Well, RS-232 is an anti-solution, as it's always asserted. Point to point >only. There's a reason I said 485 and not 422.
RS-232 multidrop would require a isolation diode for each port and a common pull-down resistor, effectively creating a wired-OR system. But this doesn't solve the arbitration problem. I have used this for connecting a dumb terminal and an external digitizing table into a single serial line. No problem with arbitration, since the operator operated the terminal or table with the same hand :-).
On Fri, 22 Sep 2017 21:42:32 -0500, "Tim Williams"
<tmoranwms@gmail.com> wrote:

>"rickman" <gnuarm@gmail.com> wrote in message >news:oq49e4$tqk$1@dont-email.me... >>> Thanks, we'll eschew. RS-232 may be old and slow but works.... >> >> It's also not multi-master... I guess you can roll your own. > >RS-485 is a solved problem, cheap, and noise tolerant. Or CAN, if you don't >mind a little more hardware (often provided in MCUs) and more automation as >far as the bus dealing with bus-y problems all by itself. > >These might be a little hungry, or overly robust. If you need lower current >consumption, and the signal doesn't have to leave the board, an open >collector bus (like I2C) is still a good idea.
Open collector wired-OR doesn't solve the arbitrary issue by itself. If the power consumption for a standard compliant CAN transceivers is too much, low power consumption non-compliant CAN networks can be implemented with practically any full duplex transceivers with a Transmitter Enable (TE) pin. The CAN controller drives the TE pin when actively sending the Dominant ("0") state on the wire. To send the Recessive ("1") the transmitter goes three-state and the passive pull-up resistor generates the "1" state on the wire. Before the first official CAN transceivers were available, ordinary RS-485 transceivers were used. I would not be surprised, if some LVDS transceivers could be used as well.
On Sat, 23 Sep 2017 01:58:06 -0400, rickman <gnuarm@gmail.com> wrote:

>Tim Williams wrote on 9/23/2017 12:55 AM: >> "rickman" <gnuarm@gmail.com> wrote in message >> news:oq4oif$20s$1@dont-email.me... >>> RS-485 is an electrical interface, nothing more. It doesn't solve the >>> multi-master problem any more than RS-232 does. >> >> Well, RS-232 is an anti-solution, as it's always asserted. Point to point >> only. There's a reason I said 485 and not 422. >> >> As for the protocols traditionally used on these interfaces, asynchronous >> serial with some kind of bus arbitration is standard on 485. >> >> For some strange reason, when you search on "RS-485", you get not just the >> signaling standard, but also a lot of protocols that people use on it... ;-) > >There are plenty of networks based on RS-232. As you say, a little >searching helps a lot. But giving an electrical standard reference is >nothing like actually giving some useful information on the networking issue.
A "network based on RS-232" is an oxymoron. If it's RS-232 it can't be a network. As pointed out above, it's always asserted. Neither a bastardized RS-232 or RS-485 solves the arbitration problem any more than I2C.
On 23.9.17 16:48, krw@notreal.com wrote:
> On Sat, 23 Sep 2017 01:58:06 -0400, rickman <gnuarm@gmail.com> wrote: > >> Tim Williams wrote on 9/23/2017 12:55 AM: >>> "rickman" <gnuarm@gmail.com> wrote in message >>> news:oq4oif$20s$1@dont-email.me... >>>> RS-485 is an electrical interface, nothing more. It doesn't solve the >>>> multi-master problem any more than RS-232 does. >>> >>> Well, RS-232 is an anti-solution, as it's always asserted. Point to point >>> only. There's a reason I said 485 and not 422. >>> >>> As for the protocols traditionally used on these interfaces, asynchronous >>> serial with some kind of bus arbitration is standard on 485. >>> >>> For some strange reason, when you search on "RS-485", you get not just the >>> signaling standard, but also a lot of protocols that people use on it... ;-) >> >> There are plenty of networks based on RS-232. As you say, a little >> searching helps a lot. But giving an electrical standard reference is >> nothing like actually giving some useful information on the networking issue. > > A "network based on RS-232" is an oxymoron. If it's RS-232 it can't > be a network. As pointed out above, it's always asserted. Neither a > bastardized RS-232 or RS-485 solves the arbitration problem any more > than I2C.
The I2C multi-master arbitration does work, if all potential masters follow the specification. I have used it with both bit-banged software implementations and hardware-assisted implementations. For hardware, I used Atmel SAM4 TWI interfaces. ----- 'RS-232' is misused at least as much as 'RS-485'. Most often 'RS-232' seems to imply asynchronous serial data transfer, but the specification does not specify the bit stream in any way. The same applies, to a lesser extent to 'RS-485'. -- -TV
On Sat, 23 Sep 2017 19:20:04 +0300, Tauno Voipio
<tauno.voipio@notused.fi.invalid> wrote:

>On 23.9.17 16:48, krw@notreal.com wrote: >> On Sat, 23 Sep 2017 01:58:06 -0400, rickman <gnuarm@gmail.com> wrote: >> >>> Tim Williams wrote on 9/23/2017 12:55 AM: >>>> "rickman" <gnuarm@gmail.com> wrote in message >>>> news:oq4oif$20s$1@dont-email.me... >>>>> RS-485 is an electrical interface, nothing more. It doesn't solve the >>>>> multi-master problem any more than RS-232 does. >>>> >>>> Well, RS-232 is an anti-solution, as it's always asserted. Point to point >>>> only. There's a reason I said 485 and not 422. >>>> >>>> As for the protocols traditionally used on these interfaces, asynchronous >>>> serial with some kind of bus arbitration is standard on 485. >>>> >>>> For some strange reason, when you search on "RS-485", you get not just the >>>> signaling standard, but also a lot of protocols that people use on it... ;-) >>> >>> There are plenty of networks based on RS-232. As you say, a little >>> searching helps a lot. But giving an electrical standard reference is >>> nothing like actually giving some useful information on the networking issue. >> >> A "network based on RS-232" is an oxymoron. If it's RS-232 it can't >> be a network. As pointed out above, it's always asserted. Neither a >> bastardized RS-232 or RS-485 solves the arbitration problem any more >> than I2C. > > >The I2C multi-master arbitration does work, if all potential masters >follow the specification. I have used it with both bit-banged software >implementations and hardware-assisted implementations. For hardware, I >used Atmel SAM4 TWI interfaces.
Even if the hardware follows the specification, it's doesn't guarantee a competent programmer. Just say *no*.
> >----- > >'RS-232' is misused at least as much as 'RS-485'. Most often 'RS-232' >seems to imply asynchronous serial data transfer, but the specification >does not specify the bit stream in any way.
It does specify the drivers and receivers. It cannot be a network. If it is, it's not RS-232.
> >The same applies, to a lesser extent to 'RS-485'.
Not at all. It was designed to be multi-master (and bidirectional). Anything can be, and is, screwed by software but there is a big difference between RS-485 and RS-232.
krw@notreal.com writes:

> On Sat, 23 Sep 2017 19:20:04 +0300, Tauno Voipio > <tauno.voipio@notused.fi.invalid> wrote: > >>On 23.9.17 16:48, krw@notreal.com wrote: >>> On Sat, 23 Sep 2017 01:58:06 -0400, rickman <gnuarm@gmail.com> wrote: >>> >>>> Tim Williams wrote on 9/23/2017 12:55 AM: >>>>> "rickman" <gnuarm@gmail.com> wrote in message >>>>> news:oq4oif$20s$1@dont-email.me... >>>>>> RS-485 is an electrical interface, nothing more. It doesn't solve the >>>>>> multi-master problem any more than RS-232 does. >>>>> >>>>> Well, RS-232 is an anti-solution, as it's always asserted. Point to point >>>>> only. There's a reason I said 485 and not 422. >>>>> >>>>> As for the protocols traditionally used on these interfaces, asynchronous >>>>> serial with some kind of bus arbitration is standard on 485. >>>>> >>>>> For some strange reason, when you search on "RS-485", you get not just the >>>>> signaling standard, but also a lot of protocols that people use on it... ;-) >>>> >>>> There are plenty of networks based on RS-232. As you say, a little >>>> searching helps a lot. But giving an electrical standard reference is >>>> nothing like actually giving some useful information on the networking issue. >>> >>> A "network based on RS-232" is an oxymoron. If it's RS-232 it can't >>> be a network. As pointed out above, it's always asserted. Neither a >>> bastardized RS-232 or RS-485 solves the arbitration problem any more >>> than I2C. >> >> >>The I2C multi-master arbitration does work, if all potential masters >>follow the specification. I have used it with both bit-banged software >>implementations and hardware-assisted implementations. For hardware, I >>used Atmel SAM4 TWI interfaces. > > Even if the hardware follows the specification, it's doesn't guarantee > a competent programmer. Just say *no*. >> >>----- >> >>'RS-232' is misused at least as much as 'RS-485'. Most often 'RS-232' >>seems to imply asynchronous serial data transfer, but the specification >>does not specify the bit stream in any way. > > It does specify the drivers and receivers. It cannot be a network. If > it is, it's not RS-232.
You can't have a shared bus but you could still make a network I think, using multiple ports per device. Horrible of course :) Come to think of it modern ethernet is also like this isn't it?
>> >>The same applies, to a lesser extent to 'RS-485'. > > Not at all. It was designed to be multi-master (and bidirectional). > Anything can be, and is, screwed by software but there is a big > difference between RS-485 and RS-232.
-- John Devereux
"John Devereux" <john@devereux.me.uk> wrote in message 
news:871smxqodh.fsf@devereux.me.uk...
> You can't have a shared bus but you could still make a network I think, > using multiple ports per device. Horrible of course :) Come to think of > it modern ethernet is also like this isn't it?
Indeed. And you can, in fact, hack a "routerless" network, using diodes (and much shorter cables, under 20m I think). Collisions are frequent if multiple nodes are talking at once, so it's slow (besides the fact that it may not enumerate higher than 10Mb!). So you can do both, yeah, sure! :-) On a related subject, "RS-232 hub" only turns up USB-to-(many serial) boxes. Perhaps a more specific tack is necessary. "Modbus hub" or "modbus router" seems to return useful hits, though Modbus is carried on so many PHYs that it's not obvious you'll find ones made with good old RS-232 on DE-9 connectors. Seems like the nearest thing, though! Tim -- Seven Transistor Labs, LLC Electrical Engineering Consultation and Contract Design Website: http://seventransistorlabs.com
"Tim Williams" <tmoranwms@gmail.com> writes:

> "John Devereux" <john@devereux.me.uk> wrote in message > news:871smxqodh.fsf@devereux.me.uk... >> You can't have a shared bus but you could still make a network I think, >> using multiple ports per device. Horrible of course :) Come to think of >> it modern ethernet is also like this isn't it? > > Indeed. > > And you can, in fact, hack a "routerless" network, using diodes (and > much shorter cables, under 20m I think). Collisions are frequent if > multiple nodes are talking at once, so it's slow (besides the fact > that it may not enumerate higher than 10Mb!).
Yes but then it is not really RS232 any more...
> > So you can do both, yeah, sure! :-) > > On a related subject, "RS-232 hub" only turns up USB-to-(many serial) > boxes. Perhaps a more specific tack is necessary. "Modbus hub" or > "modbus router" seems to return useful hits, though Modbus is carried > on so many PHYs that it's not obvious you'll find ones made with good > old RS-232 on DE-9 > connectors. Seems like the nearest thing, though! > > Tim
-- John Devereux
Tim Williams wrote:
> > And you can, in fact, hack a "routerless" network, using diodes (and > much shorter cables, under 20m I think). Collisions are frequent if > multiple nodes are talking at once, so it's slow (besides the fact > that it may not enumerate higher than 10Mb!).
How can you use diodes to wire-OR the differential pairs, assuming that's what you mean?