I was looking at building a remote controlled volume control for use at
home. Probably won't happen, but I came across this device:
https://www.nisshinbo-microdevices.co.jp/en/pdf/datasheet/NJU72344_E.pdf
Page 7 gives the serial protocol. It mentions S and P bits, but as far
as I can see they're nowhere else defined.
Further down the page, it describes an auto-increment function. That is
the only mention.
At the bottom of the page it talks about the consequence of an audio
signal being inputted (sic) before (during?) power on. Hard to know
exactly what the intent is, but based on that, I'd be concerned that the >device might latch up, or otherwise misbehave, if there's any input
before power on. Be great to build a bunch of boards with this and then >discover that some proportion are flaky.
How many designers would conclude that this could be more trouble than
it's worth, and find something else?
Sylvia.
I was looking at building a remote controlled volume control for use atS and P are no bits but the start and end conditions of the i2c protocol.
home. Probably won't happen, but I came across this device:
https://www.nisshinbo-microdevices.co.jp/en/pdf/datasheet/NJU72344_E.pdf
Page 7 gives the serial protocol. It mentions S and P bits, but as far
as I can see they're nowhere else defined.
I was looking at building a remote controlled volume control for use at home. Probably won't happen, but I came across this device:
https://www.nisshinbo-microdevices.co.jp/en/pdf/datasheet/NJU72344_E.pdf
Page 7 gives the serial protocol. It mentions S and P bits, but as far as I can
see they're nowhere else defined.
Further down the page, it describes an auto-increment function. That is the only mention.
At the bottom of the page it talks about the consequence of an audio signal being inputted (sic) before (during?) power on. Hard to know exactly what the intent is, but based on that, I'd be concerned that the device might latch up,
or otherwise misbehave, if there's any input before power on. Be great to build
a bunch of boards with this and then discover that some proportion are flaky.
How many designers would conclude that this could be more trouble than it's worth, and find something else?
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.
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!)
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.
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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 418 |
Nodes: | 16 (1 / 15) |
Uptime: | 03:19:10 |
Calls: | 8,787 |
Calls today: | 14 |
Files: | 13,296 |
Messages: | 5,965,648 |