Path: ...!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Don Y <blockedofcourse@foo.invalid>
Newsgroups: sci.electronics.design
Subject: Re: Gah! Data sheets.
Date: Fri, 27 Sep 2024 04:40:04 -0700
Organization: A noiseless patient Spider
Lines: 82
Message-ID: <vd65it$ndac$2@dont-email.me>
References: <llk78cFl0tbU1@mid.individual.net> <vd3f3e$59sf$1@dont-email.me>
 <vd3p5g$6sgj$1@dont-email.me> <llnemgF5brvU1@mid.individual.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 27 Sep 2024 13:40:14 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="394ebe2770cbb925225038e6aeeaf10a";
	logging-data="767308"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+l3hhvQe6l98RjnIsUO9/l"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Cancel-Lock: sha1:TeXzgLYr/Z9PXlaE2NnYQaGaOjM=
Content-Language: en-US
In-Reply-To: <llnemgF5brvU1@mid.individual.net>
Bytes: 5464

On 9/27/2024 3:11 AM, Sylvia Else wrote:
> On 26-Sept-24 9:55 pm, Don Y wrote:
>> On 9/26/2024 4:04 AM, Don Y wrote:
>>> On 9/25/2024 9:46 PM, Sylvia Else wrote:
>> You should also always be wary of the many ways I2C-type buses can screw you
>> during development and after release.  As it is effectively a multimaster
>> bus, the CPU/MCU doesn't have the final say in bus operations.  It's
>> possible that the CPU/MCU and one (or more!) devices on the bus have a
>> different notion of reality, at this point in time.  Getting them back in
>> agreement is usually something that requires bit-banging the i/f
>> (instead of using it at a higher level of abstraction).  It's always
>> wise (with ANY interface) to include a daemon that periodically verifies
>> (and potentially rejiggers) the i/f to prevent these kinds of problems.
>>
>> (Of course, if you could verify every transaction, that may be even better!)
> 
> Hard to know what to do if the hardware misbehaves. Even if one can get another 
> device to let go of the data line, and stop messing with the clock, one still 
> doesn't know what its internal state is.

Often it is NOT the hardware "glitching" but, rather, the software forgetting
that operations don't execute in the time of an opcode fetch.  If you
are relying on a library function to perform these operations, are you
sure it is reentrant /from the standpoint of the hardware/ (which won't
be obvious from inspecting the library routine, in isolation).  Likewise, if
you are relying on an "I2C interface" onboard.

E.g., I have seen folks access I2C (et ilk) peripherals in the foreground
AND background without encapsulating as atomic operations.  So, one
transaction "interrupts" another -- leading to neither being correct
AND the controlling software getting confused ("Where's the expected ACK?")
They forget that there is shared state in the *hardware* even if none in
the *software*!

If the CPU/MCU can be reset "asynchronously" (wrt the I2C bus), then
it's easy for the I2C devices to think they are still IN a bus cycle
even though the software/hardware in the CPU/MCU has "forgotten".
This most often manifests as a shitty job initializing the I2C
subsystem so a watchdog or other reset is a roll of the dice.  (esp
during development where one often resets the processor without
power cycling the board -- which is the only way to "reset" the I2C
devices)!

As most programmers resort to using I2C support subsystems present
*in* the MCU, once this happens, using those same subsystems often
just perpetuates the state disagreement (because the I2C hardware
in the MCU assumes legitimate I2C transactions... not "partials").
The remedy (and at POST) is to bit-bang the interface until you are
sure it is behaving as expected.

> Not that I have any experience of doing this. I've only once got the point of 
> dealing with physical I2C hardware, and it behaved as expected, at least for 
> the time I was trying it.

My rule is to eschew I2C as a fault, there, is a real PITA to
reproduce and isolate.  "I dunno... it just stopped working.
But, now it /seems/ to be.  I dunno *why*..."  When you encounter
a device that thinks an "access" can be 100 or more clocks and
you had only planned on *8* to recover...

> Either way, if I had to design something, I would avoid as far as possible 
> creating a multi-master system, even at the cost of higher complexity 
> elsewhere, and if no slave device was even capable of clock-stretching, I'd be 
> much happier.

I2C is *effectively* a multimaster (due to the control each "slave"
can exert over the SHARED bus).  Imagine if your memory chips could
control the shared read and write lines into their array...

A *real* I2C multimaster system is more challenging as you
have to effectively implement CSMA/CD in the software (no idea
if there is hardware support for this in any of the existing
onboard peripheral drivers).

Note that the device you mentioned appears not to be truly I2C;
I see no mention of an ACK/NAK capability -- the pin is input
only (!).  If you use it, you should carefully consider how it
will interact with other "real" I2C devices.  And, if they could
muck up interractions with it.