Forums

I2C master

Started by David Lesher September 22, 2017
On Sat, 23 Sep 2017 19:08:26 +0100, John Devereux
<john@devereux.me.uk> wrote:

>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?
OK, you got me. ;-)
>>>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.
"Tom Del Rosso" <fizzbintuesday@that-google-mail-domain.com> wrote in 
message news:oq6p70$3dc$1@dont-email.me...
> 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?
Good question -- you use the diode drop to steer to neighbors: https://electronics.stackexchange.com/questions/10864/building-a-passive-ethernet-hub-with-anti-parallel-diodes Tim -- Seven Transistor Labs, LLC Electrical Engineering Consultation and Contract Design Website: http://seventransistorlabs.com
On Sat, 23 Sep 2017 19:20:04 +0300, Tauno Voipio 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.
None of the USB to I2C gizmos I've seen follow the specification. For example, the FTDI ones configure the clock line (SCL) as a push-pull output rather than open drain. I contacted FTDI support about that once and was told "it works fine for other customers". Grrr. Allan
On Saturday, September 23, 2017 at 8:30:06 PM UTC-7, Allan Herriman wrote:
..
> None of the USB to I2C gizmos I've seen follow the specification. For > example, the FTDI ones configure the clock line (SCL) as a push-pull > output rather than open drain. > > I contacted FTDI support about that once and was told "it works fine for > other customers". Grrr. > > Allan
There is an FTDI API library call to enable clock stretching - maybe the default is totem pole to allow faster operation to support high-speed I2C FT4222_STATUS FT4222_I2CSlave_SetClockStretch(FT_HANDLE ftHandle, BOOL enable) kevin
On Sat, 23 Sep 2017 18:47:21 -0400, "Tom Del Rosso"
<fizzbintuesday@that-google-mail-domain.com> wrote:

>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?
You have two separate wired-OR gates, one for the inverted and one for the non-inverted side. On the inverted side, connect the port to the diode anode, connect the cathodes together and to pulldown resistor to V- On the non-inverted side, connect the diode cathode to port, connect anodes together and a pullup to V+
On Sat, 23 Sep 2017 20:50:29 -0700, kevin93 wrote:

> On Saturday, September 23, 2017 at 8:30:06 PM UTC-7, Allan Herriman > wrote: > .. >> None of the USB to I2C gizmos I've seen follow the specification. For >> example, the FTDI ones configure the clock line (SCL) as a push-pull >> output rather than open drain. >> >> I contacted FTDI support about that once and was told "it works fine >> for other customers". Grrr. >> >> Allan > > There is an FTDI API library call to enable clock stretching - maybe the > default is totem pole to allow faster operation to support high-speed > I2C > > FT4222_STATUS FT4222_I2CSlave_SetClockStretch(FT_HANDLE ftHandle, BOOL > enable) > > kevin
Thanks. I was using an FT2232, which didn't seem to have that ability. This was in a design from ~2009, when the '2232 was new. Allan
a) We have 2 boards, both Jedi ^H^H^H I2C masters, talking over RS232

b) We use I2C from one board to talk to I2C accessory boards.

c) I wondered "Can we skip 232 and add the other master to the I2C bus?"

Clearly the answer is "stick to what works...."





-- 
A host is a host from coast to coast.................wb8foz@nrk.com
& no one will talk to a host that's close..........................
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433
On a sunny day (Sat, 23 Sep 2017 20:06:06 -0500) it happened "Tim Williams"
<tmoranwms@gmail.com> wrote in <oq70e5$ahe$1@dont-email.me>:

>"Tom Del Rosso" <fizzbintuesday@that-google-mail-domain.com> wrote in >message news:oq6p70$3dc$1@dont-email.me... >> 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? > >Good question -- you use the diode drop to steer to neighbors: >https://electronics.stackexchange.com/questions/10864/building-a-passive-ethernet-hub-with-anti-parallel-diodes > >Tim
That is a very clever circuit, had not seen it before, no power source needed. OTOH economics: I bought 2 good 8 port switches that each came with a power adaptor on ebay for about 12 $ each... To make a PCB, buy diodes and connectors, housing, time.. would be more expensive.
>-- >Seven Transistor Labs, LLC >Electrical Engineering Consultation and Contract Design >Website: http://seventransistorlabs.com > >
On 23/09/17 04:42, Tim Williams 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.
Or you can use CAN controllers in microcontrollers, but with a simple open collector bus. You get the best of all worlds then - a convenient and reliable multi-master bus without much extra hardware (no components at all for your bus, if your microcontroller has flexible enough pin drivers) and with simple software.
> > Tim >
On Monday, September 25, 2017 at 12:56:18 AM UTC-7, David Brown wrote:
> On 23/09/17 04:42, Tim Williams 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. > > Or you can use CAN controllers in microcontrollers, but with a simple > open collector bus. You get the best of all worlds then
Well, not ALL worlds. Ethernet has better distance, and RS-423 with terminators (sold widely as LocalTalk by Apple, with third parties making ports that work for Windows) does good fast serial with (nominally) about 500m wire limits. Open collector is kinda... IEEE-488. Short distance and low bitrate.