• Gah! Data sheets.

    From Sylvia Else@21:1/5 to All on Thu Sep 26 12:46:05 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jan Panteltje@21:1/5 to sylvia@email.invalid on Thu Sep 26 08:31:56 2024
    On a sunny day (Thu, 26 Sep 2024 12:46:05 +0800) it happened Sylvia Else <sylvia@email.invalid> wrote in <llk78cFl0tbU1@mid.individual.net>:

    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.

    ebay is full of that sory of things, maybe something like this?
    https://www.ebay.nl/itm/143317203390
    6 dollar 38 cents including 20 cm cable and button...

    googling a bit may be worth it.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Peter Heitzer@21:1/5 to Sylvia Else on Thu Sep 26 08:19:53 2024
    Sylvia Else <sylvia@email.invalid> wrote:
    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.
    S and P are no bits but the start and end conditions of the i2c protocol.

    --
    Dipl.-Inform(FH) Peter Heitzer, peter.heitzer@rz.uni-regensburg.de

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Sylvia Else on Thu Sep 26 04:04:06 2024
    On 9/25/2024 9:46 PM, Sylvia Else wrote:
    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.

    Think: Start and stoP. Similar in function to start and stop
    bits in a UART. "framing" What they refer to as "START" and "STOP"

    Further down the page, it describes an auto-increment function. That is the only mention.

    Likely the presence of multiple "data frames" in a message. So, you would likely send a single message that would include <gain> <volumeA> and <volumeB> parameters in the same packet. This saves the overhead of having to send a second (and third) message to the same <chip_address> with differing <select_address>s.

    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.

    Reading the prose *literally* suggests that the "initial conditions" of
    the three "select address"es as laid out in the "INITIAL CONDITION OF
    CONTROL REGISTER" might not be guaranteed. Asserting the "mute" signals
    during startup would work-around any such transients (until you had
    a chance to intentionally set the control registers' constents)

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Don Y on Thu Sep 26 06:55:53 2024
    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!)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sylvia Else@21:1/5 to Don Y on Fri Sep 27 18:11:28 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Sylvia Else on Fri Sep 27 04:40:04 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From john larkin@21:1/5 to All on Fri Sep 27 10:05:23 2024
    We need two web sites, icbugs.com and stupiddatasheets.com.

    Seriously. They could be popular and profitable.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)