¿Por qué todas las líneas de selección de esclavos son altas en un chip SC18IS602B?

0

El chip SC18IS602B es un dispositivo esclavo I2C que se une a varios dispositivos SPI. Estoy usando esto para hablar con 3 dispositivos SPI que usan controladores de fregadero de LED de corriente constante TLC5925. Estos dispositivos se conocen bien (probados en otra configuración). El problema que estoy tratando de resolver es que cuando envío datos desde el primer puerto SPI, todos los anillos LED cambian a la vez. He confirmado con un multímetro que todas las líneas de selección de esclavo (SS [0-2]) son altas. Y usando un pirata de autobús confirmé que permanecen altos la mayor parte del tiempo. Bajando brevemente cerca del punto de transmisión SPI.

Este es el circuito:

Cableado http://memecode.com/hw/mc2/images/i2c-spi- wiring.png

El código que estoy usando para configurar el puente:

        uint8 MsbOrder = 0, Mode = 2, SpiClockRate = 1;
        WriteI2C(SC18IS602B_ADDR,
                 0xf0,
                 (uint8)
                 (
                    (MsbOrder << 5) |
                    (Mode << 2) |
                    (SpiClockRate)
                ));

        // Enable GPIO on SS3
        WriteI2C(SC18IS602B_ADDR,
                 0xf6, // GPIO enable
        #if DEBUG_USE_GPIO
                 (uint8) 0x0F); // All SS pins GPIO
        #else
                 (uint8) 0x08); // SS3 is GPIO (output enable)
        #endif

        // Set mode on SS3
        WriteI2C(SC18IS602B_ADDR,
                 0xf7, // GPIO config
        #if DEBUG_USE_GPIO
                 (uint8) ((1 << 6) | (1 << 4) | (1 << 2) | (1)) ); // Push pull mode for all SS pins
        #else
                 (uint8) (1 << 6) ); // Push pull mode for SS3
        #endif

Intenté configurar las líneas de selección para GPIO y simplemente elevarlas cuando fuera necesario. Ese código se selecciona al definir DEBUG_USE_GPIO en 1. Sin embargo, cuando intento que no se transmitan datos SPI a los chips del controlador LED.

Estoy usando la última línea de selección como GPIO para apagar los LED hasta que haya terminado de actualizar todas las cadenas de datos.

El código para transmitir realmente los datos es:

    typedef char LedRingBits[6];
    LedRingBits r[2];

    ZeroObj(r);

    #if DEBUG_USE_GPIO
    // Turn off output enable, turn on select line        
    WriteI2C(SC18IS602B_ADDR,
            0xf4, // GPIO write
            (uint8) (LED_OUTPUT_DISABLE | Channel) );
    #else
    EnableLedRing(false);
    #endif

    #define SetLedBit(out, in, comp) \
        if (Col##in.comp()) \
        { \
            int Bit0 = LedRingAddr[Led##in].comp; \
            r[out][(Bit0>>3)] |= 1 << (Bit0&0x7); \
        }

    if (Led0 >= 0 && Led0 < 16)
    {
        SetLedBit(1, 0, r);
        SetLedBit(1, 0, g);
        SetLedBit(1, 0, b);
    }

    if (Led1 >= 0 && Led1 < 16)
    {
        SetLedBit(0, 1, r);
        SetLedBit(0, 1, g);
        SetLedBit(0, 1, b);
    }

    if (WriteI2C(SC18IS602B_ADDR,
                 Channel,
                 (uint8*) &r[0], sizeof(r)))
    {
        // This forces the SPI transfer to complete before we do anything else
        ClearIntLedRing();
    }

    #if DEBUG_USE_GPIO
    // Turn on output enable, turn off select line
    WriteI2C(SC18IS602B_ADDR,
            0xf4, // GPIO write
            (uint8) 0);
    #else
    EnableLedRing(true);
    #endif

Donde 'canal' es 0x1, 0x2 o 0x4. Básicamente, el bit que debe conducir solo una línea de selección de esclavo (no todas).

Ni siquiera sé si puedo decir que es hardware o software en este momento. He revisado tres veces para detectar cortocircuitos o líneas mal colocadas en el hardware. Los voltajes parecen buenos (excepto por las líneas de selección de esclavos).

No estoy seguro si necesito una tapa de desacoplamiento en los rieles de alimentación de este chip. ¿Podría ser un problema?

La línea de barra / reinicio se adjunta a + V ... ¿cuál asumo que está bien? (Activo bajo según la especificación).

He cambiado el chip SC18IS602B por otro, y obtuve los mismos resultados. (En caso de que el chip se haya estropeado).

Editar: Aquí está v2 de la placa de pruebas:

Cableado http://memecode.com/hw/mc2/images/i2c- spi-wiring-v2.png

Esto está funcionando mejor. La principal diferencia es que las líneas de selección de esclavos se invierten con un 4011 NAND IC. También ahora hay un límite de 100 nF entre los pines GND y + V del chip de puente. El resultado es que la salida SPI # 1 ahora es independiente de # 2 ... pero el cambio de # 2 afecta al # 1. Así que a mitad de camino.

Editar2:

El problema final en el que el cambio del anillo de LED # 2 también afectó al anillo de LED # 1 se remonta a un corto intermitente en la placa de LED # 1 que solo ocurre cuando la placa PCB está ligeramente flexionada, ya que está en el chasis (los tornillos están en los bordes, tirando de la PCB hacia el chasis, y los LED en el medio actúan para evitar eso). Esto haría que la línea de habilitación del pestillo (LE) esté alta todo el tiempo, lo que resultaría en que la placa siempre responda a los datos SPI, incluso cuando esté diseñada para otra placa de anillo LED. ¡Dios mío, funciona!

    
pregunta fret

2 respuestas

4

Sin embargo, esas partes funcionan exactamente como deberían, pero no son realmente compatibles con el chip habilitado.

Como es estándar tanto con I2C como con SPI, los chips habilitados en el SC18IS602B son todos de baja calidad. Todos serían altos cuando estén inactivos, y solo uno (el seleccionado) debería ser bajo al transferir datos.

El TLC5925, por otro lado, tiene un pestillo que es transparente cuando LE es alto, y trabado cuando está bajo. Es la polaridad opuesta de los chips habilitados. Es por eso que estás viendo lo que estás viendo.

Lo que necesita es un inversor entre cada chip habilitado y su respectivo LE.

    
respondido por el Mark
1

SIEMPRE tienen tapas de desacoplamiento. Whack unos 100n y 1uf en esa placa. También intente hacer algunos pull-ups débiles en las líneas de selección de chips, de modo que solo una lógica fuerte BAJA lo derribará. También intente configurarlos como salidas de drenaje abierto en lugar de push-pull. Esto, más las resistencias de pull-up (definitivamente requeridas si se realiza un drenaje abierto) debería impedir que los otros dispositivos respondan a los mismos comandos al mismo tiempo.

    
respondido por el KyranF

Lea otras preguntas en las etiquetas