No hay una respuesta directa a esta pregunta porque solo depende del tipo de sistema al que esté asociado el controlador. Más a menudo, el controlador es un sistema de adquisición de datos a través de algunos sensores (analógico / digital) y / o es el autor de la activación o activación de algún otro dispositivo. Al estar sentado en medio de dos secciones (cada sección tiene más de un dispositivo: eléctrico / electrónico / mecánico / químico, etc.) podría haber n! razones que molestan la ejecución normal del controlador.
Es mejor primero evaluar cómo funciona ‘cualquier controlador’ … (los detalles pueden estar disponibles en los libros estándar) pero en términos de operación en el núcleo, la ejecución de cada instrucción ocurre dentro del acumulador y el disparador para que la siguiente instrucción sea automática se realiza mediante un sistema de contabilidad llamado ‘contador de programa’. Si el contador del programa se reinicia (dependiendo del diseño del controlador por parte del fabricante, generalmente en RESET o Power on Reset en términos de activación de hardware) a través del firmware mediante condiciones de restablecimiento como Brown-out Reset, Watchdog Reset, etc., la ejecución es repetición. Ahora para condiciones de bajo voltaje, se activa el restablecimiento de caída de voltaje; si el sistema se cuelga en un bucle while, el reinicio de vigilancia se activa; y así sucesivamente por cualquier otro tipo de razones.
Si todo está bien, el sistema no se reinicia pero continúa su actividad.
La pregunta aquí es ‘¿y si no se reinicia ni continúa su negocio?’ y eso es lo que definimos como “colgar”. La causa podría ser
- Mala lógica de programación
- Si el controlador está accediendo a los datos a través de un protocolo y el tiempo de respuesta del resultado del sondeo no está bien planificado con respecto a maestro y esclavo, con una declaración ilógica de tipos de datos de variables que se rellenan (por ejemplo, para un valor de voltaje que será flotante / double, si la variable que lo captura se declara como tipo entero (incluso entero de 32 bits), está en serios problemas) y los tipos de datos de variable que se inicializan desde el adquirente, esto da como resultado una construcción errónea repetida del byte conversión y que corrompe la memoria donde el controlador almacena el valor antes de enviarlo o mostrarlo.
- Conexiones flojas
- Bajo voltaje al nivel de reinicio por caída de tensión, pero lo suficientemente pequeño como para que el controlador intente conectar la corriente y, por lo tanto, se calienta.
- Si el acceso a la memoria no está definido en función del mapa de memoria del chip de memoria.
- Si el chip de memoria es EEPROM y la protección contra escritura en el chip no se realiza mediante firmware, lo que podría provocar que una señal indebida corrompa el chip.
- Si alguno de los circuitos integrados es CMOS y los motivos habituales de CMOS LATCH-UP.
- Coordinación asincrónica repetida entre elementos de arquitectura maestro / esclavo
- Calibración incorrecta para el DAQ.
- Si hay comunicación en serie usando UART, entonces NO se abrirá el canal UART cuando el sistema esté conectado al bucle.
- Inicialización de usuario no coincidente o inicialización del sistema que funcionó inicialmente pero después de una prueba acelerada los factores incrementados están más allá del tamaño de bytes del tamaño de matriz de la variable.
- Si el controlador está buscando varias interfaces, por ejemplo, Módulo GSM y el módulo no responde o tarda un tiempo debido a su propia corrupción de firmware.
- En ocasiones, los cálculos matemáticos como seno / coseno o logaritmos se realizan en entradas en tiempo real (lo que obviamente se realizará mediante la expansión de Taylor o la gestión de una tabla de búsqueda o tabla hash que está codificada).
- Las comunicaciones cronometradas pero basadas en un indicador de tiempo empírico, dicen que una respuesta frecuente a un sistema que se envía cada 3 minutos es demasiado lenta pero eficiente, pero enviar el mismo cada 1 minuto es demasiado infantil cuando hay 100 de esos sistemas. Los 100, enviando mensajes (sin solicitud) – transmitiendo a un dispositivo maestro y el dispositivo maestro tiene demasiado para manejar. No calcula la frecuencia de envío versus la capacidad de recepción.
- Iniciando la generación de múltiples relojes pero sin sincronizar sus ritmos.
- Si el ciclo while es autónomo (generalmente prefiero que no sea autónomo), entonces puede entrar en un código que se ejecuta para siempre con su propio problema de resolverlos a través de WDT Restart, pero si se controla a través del temporizador y si el temporizador interrumpe no se genera cada número decidido de mili / micro-segundo, tiene un tiempo que está siempre en el limbo y, por lo tanto, se ‘cuelga’
y así sucesivamente …
Por lo tanto, aunque es una pregunta válida, pero un ingeniero de firmware inteligente, mitigaría todos los escenarios anteriores y más (el que no he experimentado) y, en consecuencia, creará una solución para encontrar nuevas posibilidades o situaciones que causen situaciones de punto muerto.
