El retardo de tiempo es aleatorio para el comando de lectura / escritura SPI

0

Estoy usando el comando SPI ioctl () half duplex (base de Linux) para enviar un comando y leer el resultado del ADC del chip ADC (esclavo) a una MCU (maestra). Sin embargo, la lectura de ADC en algún momento me mostrará un valor incorrecto, de 1000 datos y obtengo 5 datos no válidos ("255"), aproximadamente un 0,5% de error. ¿El ADC y el SPI deberían estar funcionando al 100% todo el tiempo? No estoy seguro de qué está causando el problema.

Con el analizador lógico, observo que el tiempo de demora entre el envío y la lectura del resultado del ADC no siempre es consistente. No estoy seguro de que sea un síntoma común para la comunicación SPI o qué, y sospecho que esta es la causa principal de la lectura del error.

paso de programación:

  1. iniciar ADC
  2. retraso para completar ADC
  3. enviar comando de lectura // Se produce un retraso incoherente entre los pasos 3 y 4, aunque mi codificación no haya establecido ningún retraso en el medio.
  4. recibir el resultado ADC
  5. vuelve al paso 3 y continúa con la siguiente lectura. // También se producen retrasos inconsistentes entre los pasos 5 y 3.

La lectura de error aparece cada vez que el tiempo de retardo desconocido (aprox. 1-12 ms) es más largo de lo normal. (El tiempo de retardo normal debe estar en el rango de 40us según otra lectura exitosa)

Desde el sitio web o el material de lectura sobre SPI, la mayoría de ellos muestran la condición perfecta / ideal, el tiempo es tan preciso como pensamos, pero creo que la aplicación real no sería el caso. O me equivoco al respecto, no estoy seguro, esta es la primera vez que intento implementar SPI para la comunicación de datos en mi pequeño proyecto.

Comparta su experiencia si ha encontrado el mismo problema al que me estoy enfrentando ahora.

    
pregunta danteDev

1 respuesta

0

El supuesto es que una aplicación que accede al puerto SPI se está ejecutando en un sistema operativo Linux. Linux es un sistema operativo en tiempo real. Como tal, no es razonable esperar que la aplicación se ejecute ininterrumpidamente. En un momento dado, es probable que haya docenas de aplicaciones ejecutándose en un sistema operativo Linux. El sistema operativo utiliza una técnica de división de tiempo para permitir a cada aplicación una pequeña cantidad de tiempo de procesador.

El código de la aplicación, para poder leer los datos de manera confiable, debe esperar el retraso mínimo para que los datos sean válidos. De esta manera, si el sistema operativo Linux no se adelantó a la aplicación, el retraso debería ser suficiente.

El autor ha indicado (más adelante) el uso de un chip de administración de paquetes de varias celdas 6804. Este es un ADC dual complejo, auto temporizado con entradas multiplexadas 6: 1 capaz de monitorear hasta 12 baterías. De ninguna manera es este un simple chip ADC.

Es improbable que la interfaz SPI sea la responsable de la pérdida de datos. Más bien, como el 6804 es un chip complejo, es probable que se trate de un problema de administración del 6804. Investigue los registros de control 6804 o el control de pines externos 6804.

Dado que hay muchos ajustes de registro y pines para investigar, sería imposible sugerir una solución específica. Más bien, aquí hay dos ideas al leer las especificaciones del 6804:

  1. ¿Se duerme el 6804? ¿En qué configuraste t-IDLE?
  

Los puertos serie (SPI o isoSPI) entrarán en el estado IDLE de bajo consumo   si no hay actividad en el puerto A durante un tiempo de t-IDLE. El despertar   El circuito supervisa la actividad en los pines 41 y 42.

  1. ¿Se está administrando correctamente el temporizador del software?
  

Si el temporizador de software se activa en medio del comando RDCFG, el   el grupo de registro de configuración se reinicia según la Tabla 14. Como resultado,   Los datos de lectura de los bytes CRFG4 y CRFG5 podrían estar dañados.

    
respondido por el st2000

Lea otras preguntas en las etiquetas