¿Hay alguna instancia de un microcontrolador explotando al ejecutar un programa que se divide por cero?

Lo que voy a decirte es un secreto. Es algo que juré nunca revelar, pero supongo que ahora que has hecho la pregunta, es hora de revelarla.

La Segunda Guerra Mundial nunca sucedió. Fue una conspiración. ¿Crees que Japón se convirtió en una empresa de súper tecnología de la noche a la mañana?

A las 8:15 a.m., el 6 de agosto de 1945, Hiroshima Calculator Industries demostró el primer microcontrolador del mundo. Consumía 496 válvulas y era pequeña: cabía en un maletín. Para lograr este objetivo, tuvieron que cortar esquinas, y dejaron la verificación de límites de valores cero para el programador.

Fue un terrible error. Mientras demostraba este dispositivo, un programador dividió accidentalmente entre cero mientras confundía los números big-endian con los números complementados. El resultado final fue una explosión que destruyó Hiroshima y mató a miles de personas. No fue sino hasta una recreación en Nagasaki tres días después que la verdad se dio cuenta.

Para encubrirlo, a las personas se les dijo que habían estado peleando una guerra durante cinco años y que era un arma secreta que causó la explosión. La mayoría lo creyó. Desde ese día, todos los microcontroladores han sido equipados con un control de límites que devuelve datos aleatorios si se intenta dividir por cero.

Si eso suena demasiado increíble para creer, bueno, eso es porque es ficción. Para que ocurra una explosión, debe haber algún tipo de reacción que haga que se acumule presión, pero lo que hay dentro de un microcontrolador es solo un montón de puertas electrónicas. Las operaciones de división se producen rápidamente y están limitadas por el número de puertas dentro de un procesador, por lo que no sucede mucho cuando intenta dividir por cero en un microcontrolador.

Sin embargo, los resultados suelen ser impredecibles. No se sabe qué resultado final quedará en los registros de salida, y esto puede hacer que los programas se vuelvan locos y hagan cosas impredecibles, o simplemente se bloqueen, por lo que generalmente se evita en lugar de depender de un resultado inesperado que no va a ser consistente incluso de procesador a procesador en la misma familia.

Por lo tanto, se debe evitar dividir por cero: no dañará la computadora en absoluto, pero las aplicaciones que usan esos datos pueden no funcionar correctamente.

Un proceso como dividido por cero no causará ningún problema en el microcontrolador. Ni siquiera calefacción.

Razón
Bueno, dividir por cero es un programa, la mayoría de los compiladores / hardware generarán una excepción y lo manejarán adecuadamente.

Algunos compiladores o ensambladores que no atraparán este error pueden devolver un valor incorrecto o entrar en un bucle sin fin.

En ambos casos no pasará nada. En el peor de los casos, un sistema mal diseñado dejará de responder. Sin calefacción, sin explosión.

Generalmente los microcontroladores no “explotan”. No hay nada inflamable o altamente reactivo dentro de ellos. Pueden calentarse y derretirse internamente, incluso calentarse tanto como para quemar otras cosas a su alrededor, pero nunca he oído hablar de una explosión.

Además, con la excepción de las grandes CPU y GPU, son dispositivos de baja potencia, por lo que no se les suministra una gran cantidad de energía eléctrica.

Un microcontrolador puede explotar si U lo está alimentando de manera incorrecta. Un firmware incorrecto puede dañar su microcontrolador dependiendo de su interfaz de hardware. Por ejemplo, en avr, si se produce un desbordamiento de RAM debido a funciones recursivas o de llamadas dentro de una función que puede alterar los registros de control de puerto que pueden hacer que el puerto de entrada a la salida pueda provocar un cortocircuito … Estos son todos los posibles daños que pueden ocurrir debido a error de código … Pero para que un controlador explote, U debe conectar una fuente de alimentación de polaridad incorrecta o un alto voltaje … Estoy seguro de que U ha visto un video en YouTube que muestra que un atmega32 explotó y lo escribieron se debe dividir por cero 😉 Es porque aplicaron un voltaje muy alto al microcontrolador solo para tomar video para engañar a otros … 🙂

No, esto, o algo así, era la premisa ridícula de la serie de televisión “Halt and Catch Fire”. Si el micro tiene una interrupción de captura, dividir por 0 invocará la interrupción, pero de lo contrario la operación solo devolverá un resultado indefinido. Eso supone que el micro tiene una instrucción de división, por supuesto. La mayoría no lo hace, y cualquier operación de división es un bloque de software vinculado desde la biblioteca del compilador. Lo que sucede en ese caso depende de cómo se escriba la función de la biblioteca, pero le aseguro que no dañará el micro.

Bueno, no, no dividir por cero; los primeros uC no tenían instrucción de división.

Sin embargo, para abordar específicamente esta deficiencia, tanto Motorola como Intel diseñaron las instrucciones de HCF en las arquitecturas de las series 6800 y 8080. Esto a veces se alias a la instrucción SDI en microcódigo.

Aunque impopular con los ingenieros de software embebidos (retardados, sobre pagados y propensos a errores), la inclusión de HCF / SDI impulsó enormemente las ventas de chips.

Mucho más tarde, Motorola, en colaboración con IBM en el PowerPC ISA, agregó la instrucción EIEIO. Siendo un esfuerzo típico de diseño por comité, esta instrucción no tenía casi la utilidad de la combinación temprana de HCF / SDI. También fue el centro de una demanda por infracción de propiedad intelectual.

Lanza un error cuando se intenta dividir por cero. El programa deja de ejecutarse a menos que se maneje.

El video muestra acerca de esta excepción, pero necesito probarlo por mi cuenta.