Sujet : Re: Gah! Data sheets.
De : sylvia (at) *nospam* email.invalid (Sylvia Else)
Groupes : sci.electronics.designDate : 27. Sep 2024, 11:11:28
Autres entêtes
Message-ID : <llnemgF5brvU1@mid.individual.net>
References : 1 2 3
User-Agent : Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1
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:
How many designers would conclude that this could be more trouble than it's worth, and find something else?
>
I always like using LDRs for variable audio gain. But, my applications are
usually for smooth muting and not specific gain settings.
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.
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.
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.
Sylvia.