De ASM a JALv2

[Leon Pic]

Hace tres días atrás, volví al mundo de la electrónica  luego de haber estado sin tocar nada desde hace tres años; a excepción de alguna reparación mínima o la creación de unos circuitos para la restauración de mi tocadisco que pronto actualizaré.

He vuelto con el proyecto de invernadero que casualmente, fue en lo último en lo que trabajé.

¿Por qué cuento todo esto? porque me he visto en la necesidad de tratar de entender mi pasos, avances y mis programas, para poder seguir avanzando, y no volver a cometer los mismo errores.

Con esto viene el primer concejo, y REGLA DE ORO que deseo transmitirles SIEMPRE COMENTAR LOS PROGRAMAS.
Por suerte, es algo que yo siempre hice, hasta incluso anoto los pasos a seguir para hacer dicha tarea. Esto es un ejemplo de lo que hablo:

;MEDIMOS LA HUMEDAD.
;------------------
;PASOS A SEGUIR.
;
;1- CONFIGURAR EL CANAL A SENSAR.
;2- MEDIR EL ADC DE LA HUMEDAD Y GUARDAMOS EL VALOR EN RAM
;   TENEMOS QUE APLICAR LA FÓRMULA SIGUIENTE PARA OBTENER LA HUMEDAD HR = (Vout - 0,8) / 0,031
;3- PARA ELLO, DEVEMOS MULTIPLICAR EL ADC POR 196 PARA PASARLO A TENSIÓN (EN REALIDAD DEBERÍA SER 195 PERO CON ESTE, EL ERROR ES MAS GRANDE).
;4- LUEGO LO VOLVEMOS A MULTIPLICAR POR 1.000 PARA TRABAJAR CON LA SIGUIENTE FÓRMULA HR = (Vout - 800) / 31
;5- APLICAMOS LA FORMULA HR = (Vout - 800) / 31,
;5- EL RESULTADO LO DIVIDIMOS POR 10.000 PARA OBETENER LA HUMEDAD RELATIVA EN 2 DÍGITOS (O 1.000 PARA OBTENER 3 DÍGITOS, ANALIZAMOS MAS ADELANTE ESTO)
;6- LO GUARDAMOS EN LA RAM
;7- TOMAMOS 42 MUESTRAS
;8- HACEMOS EL PROMEDIO, PARA ELLO SUMAMOS LAS 42 MUESTRAS ENTRE SI Y LUEGO LA DIVIDIMOS POR 42
;9- EL RESULTADO DEL PROMEDIO LO GUARDAMOS EN LA RAM humedad

Nunca estuve más contento de haber echo esto, que al principio me pareció una gran estupidez y pérdida de tiempo, ahora me quiero auto-besar.

Si bien no soy una persona experta en programación, sino más bien un aficionado en la programación con experiencia casi nula; recuerdo más como se programa en ASM (que fue el primer lenguaje que aprendí para los PIC y en mi vida) que el JALv2. Uno diría, seguí en ASM y listo; pero sería tonto, porque jamás pude ni intenté hacer un programa en ASM y conectar el pic al USB, pero que en JALv2, se hace muy simple; al igual que con cualquier lenguaje de alto nivel.
Así que, el siguiente tutorial será un equivalente del ASM a JALv2. Intentaré ser lo más claro posible y dar ejemplos.

Para finalizar mi primer mensaje de este tema, quiero pedirles que participen; me corrijan; me den concejos; o cualquier otra cosa que haga, de este tutorial, una herramienta útil para cualquiera.

[Leon Pic]

Lo primero que hay que hacer, es descargar la última versión del compilador JALv2 e integrarlo al entorno IDE MPLAB

Para los que quieran ir aprendiendo a programar en JALv2, les dejo este tutorial donde hay muchos ejemplos para hacer. Se los recomiendo.

Software, herramientas y ejemplos de programación para JALv2

NOTA MUY IMPORTANTE:

Si ustedes tienen una entrenadora o alguna placa lista para practicar la programación del PIC con este lenguaje; y por consiguiente es distinto al mío, tengan la precaución de cambiar los pines a utilizar según su placa; y garanticen que no se produzca un cortocircuito al hacer un cambio. Por supuesto que no me hago cargo de cualquier cosa que se les pueda romper. Esa es su responsabilidad.

Eso es todo por hoy. En el siguiente mensaje, empezaremos a ver como pasar de ASM a JALv2.

[KILLERJC]

Mi pregunta es... que ventaja tiene el JALv2 con respecto a C ?

[Leon Pic]

Que es gratuito. Por lo demás, no tengo ni idea porque jamás lo usé.

[Leon Pic]

Variables; constantes y posiciones de memoria RAM.

En ASM es raro hablar de variables y/o constantes sino que se habla de posiciones de memoria. Esto es así, porque es el usuario (el que programa) como se van a usar las diferentes posiciones de memoria. El usuario puede tratar a una posición de memoria como constantes, y luego cambiarla; lo que haría perder el estado de constante para convertirse en una variable.
En JALv2, esto no pasa. Si el usuario nombra a una posición de memoria (o varias) como constante, así quedará por todo el programa. Si uno intenta modificar una constante, el compilador dará un error; pues para ello tenemos variables, en las que una posición de memoria puede cambiar todo el tiempo. Justamente una variable no garantiza que el valor de la memoria se mantenga por todo el programa. En ASM, es el usuario quien debe tomar la precaución de no modificar una posición de memoria que se necesita en algún momento.

Veamos como se nombran y trabajan las posiciones de memoria.

ASM

El MPASM, o sea, el compilador de assembler de Microchips, acepta dos formas básicas de nombrar posiciones de memoria RAM con nombres.

La primer manera es:

CBLOCK H'xx'

Lo que hace es renombrar las posiciones de memoria, en forma consecutiva a partir de lo especificado en H'xx'
Veamos un ejemplo.

CBLOCK H'20'
rotar
subir
bajar
ENDC

rotar es la posición de memoria 0x20
subir es la posición de memoria 0x21
bajar es la posición de memoria 0x22

ENDC indica que se terminó de renombrar posiciones de memoria. Su uso es obligatorio.

La segunda opción es:

nombre EQU H'xx'

A diferencia de la anterior, aquí solo se puede renombrar una posición de la RAM de una vez por vez; teniendo que repetir toda la misma sentencia por cada posición de memoria a renombrar. Por ejemplo

subir EQU H'30'
bajar EQU H'25'
rotar EQU H'50'

Como podrán observar, se puede asignar nombres en forma desordenada, y no como la anterior que es consecutiva.
Hay que prestar atención a que posición de memoria estamos nombrando, porque sin querer podemos estar trabajando sobre un registro sin darnos cuentas. El usuario tiene que asegurarse de que esté haciendo la reserva en la posición de memoria asignada para el usuario.

JALv2

Hay que tener en claro que es lo que se necesita, si los datos de la posición de memoria a usar sea momentánea o fija.
En el caso de que sea fija, la posición de memoria deberá ser llamada como constante, pero si es momentánea o varía su valor, se debe llamar variable.
Veamos un ejemplo de su uso.

var byte subir
var byte rotar

const byte bajar

Noten que aquí, no se asigna la dirección de la memoria. JALv2, es el que se encarga de asignar la dirección de la memoria a renombrar.

Como se han dado cuenta, var indica que subir/bajar es una variable; mientras con bajar es una constante.

Byte indica el tamaño de la posición de memoria a usar.
Algo que hay que tener en cuenta es que el tamaño de cada posición de la RAM de un PIC, es de un byte (8 bit), pero el compilador nos permite nombrar una variable más grande que un byte; por ejemplo del tamaño de un WORD. ¿Cómo hace esto? muy fácil, utiliza tantas posiciones de memoria consecutivas según lo especificado.
Por ejemplo VAR WORD TEMPORAL.
La variable temporal, va a ocupar dos posiciones de memoria; ya que word equivale a dos BYTE.

[stk500]

Me alegro Leon de verte por estos lares de vuelta 

un Saludos

[Leon Pic]

Muchas gracias SKT.
Si bien pasaba casi todos los días, no respondía mucho por falta de tiempo (me sirvió para no olvidar al foro que tanto me enseñó).

[Leon Pic]

Continuación de variables, constantes y posiciones de memoria RAM

JALv2

Veamos a continuación, de que tamaño pueden ser las variables o constantes y sus signos.


BIT1    1 bit boolean  value 0..1
SBIT1   1 bit signed   value -1..0
BYTE1   8 bit unsigned value 0..255
SBYTE1  8 bit signed   value -128..127
WORD   16 bit unsigned value 0..65,535
SWORD  16 bit signed   value -32,768..32,767
DWORD  32 bit unsigned value 0..4,294,967,296
SDWORD 32 bit signed   value -2,147,483,648..2,147,483,647

Recuerden que esto lo maneja el compilador; y no podremos saber en que posición de memoria estamos trabajando. De echo, no es importante saberlo. Para ello se le asigna nombre para poder recordarlo mejor. Lo importante, es no sobrepasar la cantidad de memoria utilizada según la capacidad del pic a trabajar.

Hay que saber también, que como el compilador trata de optimizar todo, incluso el uso de la memoria de programa, hay que indicarles que deseamos hacer para que no haga nada indebido. Es muy importante indicar todo y no dejar que el compilador adivine. Si hacen esto, puede llegar a pasar que el programa no ande bien y no puedan encontrar el error.

Por ejemplo, en el manual de JALv2, dice que si a una variable del tipo booleano (1;0) se asigna 0; el valor de dicha variable (BIT) será  0; pero que si le agregamos un valor distinto a cero, por ejemplo 32 (no importa si es en decimal, hexadecimal, octal, ect) el compilador lo asignará 1. Por lo tanto, hay que prestar atención a estos detalles.
Las posiciones de memorias que nombramos, pero que no asignamos ningún valor, serán cargadas con valor 0; y si no la utilizamos nunca, no serán compiladas.

Constantes

Las constantes, tiene además una función más. Se les puede o no agregar lo siguiente:


Secuencia   Valor
"\0qqq"     Constante Octal (octal constant)
"\a"        Campana (hace sonar un tono de aviso por los parlantes)
"\b"        Espacio (backspace) es el valor 0x20 en ASCII
"\f"        Formateado (formfeed)
"\n"        Avance de linea (line feed)
"\r"        Retorno del carro/cursor (carriage return)
"\t"        Tabulación horizontal (horizontal tab)
"\v"        Tabulación vertical (vertical tab)
"\xdd"      Constante hexadecimal (hexidecimal constant)


ASM

En Assembler, esto no existe. Todo esto se hace a nivel de programación. De echo, en JALv2 (como en cualquier otro lenguaje de alto nivel) esto también se traduce en líneas de programa, solo que es el compilador lo hace por nosotros.

[Leon Pic]

JALv2

Variables volátiles (var volatile)

Esto es un verdadero dolor de cabeza tanto para ser explicarlo como para entenderlo. De echo, en el día de la fecha, me parece que lo he entendido; pero que lamentablemente no estoy seguro.
He estado buscando explicación por internet, y he dado con las siguientes páginas donde lo explican mejor:

Página 1
Página 2

Algo que hay que dejar en claro, es que la palabra VOLATILE no es una instrucción; por lo tanto no aparece en ASM pero si se trabaja; incluso sin que el usuario lo sepa. Esto es a nivel de compilación.
Las ventajas que tienen los lenguajes de alto nivel, es la optimización de nuestro programa escrito. Incluso, hay compiladores en que se puede desabilitar la optimización y ver si nuestro programa funciona. Por ejemplo, tenemos dos variables asignadas de tamaño byte y llamadas AA y ZZ respectivamente. De acuerdo a nuestro programa, estas dos variables pueden llegar a compartir la misma posición de memoria RAM
Otra optimización muy importante, es la generación del código en lenguaje de máquina, y es en ASM donde el usuario debe buscar una buena optimización.

Volatile, que puede ser traducido como temporal (ya que se evapora), es en realidad la indicación a nuestro compilador que deseamos que NO se debe optimizar. En el ejemplo de las dos variables anteriores (AA y ZZ) si las declaramos como volatile obligamos al compilador que no compartan la misma ubicación en la RAM (por dar un ejemplo).

NOTA: En la optimización de las variables, no quiere decir que todas las variables que creamos vayan a compartir una sola dirección en la memoria RAM. Esto lo analizará el compilador, viendo si se afectan unas con otras; si se cruzan o no, ect.

A nivel de generación del código en lenguaje de máquina, lo que también se garantiza es que no se modifique dicha varaible declarada volatile.
Por ejemplo, podemos hacer lo siguiente en ASM:

AA equ 0x20  ; AA ubicada en la posición de memoria RAM 0x20
MOVLW 0X10 ; Cargo con W 0x10
MOVWF AA   ; Y se lo paso a AA
MOVLW 0x09 ;Cargo con W 0x09
ADDWF AA,F ; Sumo 0x09 + 0x10 (AA) y el resultado lo guardo en AA

O lo siguiente:

AA equ 0x20  ; AA ubicada en la posición de memoria RAM 0x20
MOVLW 0X10 ; Cargo con W 0x10
MOVWF AA   ; Y se lo paso a AA
MOVLW 0x09 ;Cargo con W 0x09
ADDWF AA,W ; Sumo 0x09 + 0x10 (AA) y el resultado lo guardo en W

No hay nada raro en hacer esto, y lo escribiremos de una manera u otro si necesitamos o no, que la variable AA sea o no sea modificado.
Al menos en JALv2 (y versiones anteriores) esto no se puede elegir. En ningún momento podemos optar si queremos que un resultado sea guardado en el registro de trabajo en la memoria RAM. De echo, cada vez que hagamos una operación matemática, siempre guardaremos el resultado en la RAM:

X = X +1
X = C + B
X = B + X
W = W + X (W es una variable y no el registro de trabajo).

Concejos:

Todas las variables que tiene un efecto (cuando se lee o se escribe) que es leída fuera del programa debe ser declarada volátil. Ejemplos evidentes son los registros de funciones especiales. Para mostrar el caso extremo: un programa que no accede a las variables volátiles también podría estar vacío, ya que no tiene efectos leídos. En otras palabras, si no se la declara volatile, el compilador lo puede omitir no generándola y haciendo que nuestro programa funcione mal y no saber por que es.

Ante la duda, declarar las variables como volatile; o al menos las que más se usan o son de mayor importancia; por ejemplo, la variable que se le carga un valor para ser enviado por el puerto serial; o donde se le cargan los valores de lectura a través del puerto serial.

Si un programa no funciona como debe ser y no es posible encontrar el error, hacer las variables volátiles. Esto es un motivo por el cual, la creación de variables deben ser echas todas juntas, o en el mismo lugar y no desparramado por todo el programa.

[Miquel_S]

Excelente tutorial y muy bien explicado.

Saludos!

[Leon Pic]

Muchas gracias Miguel.
En la semana, trataré de continuar.

[Leon Pic]

Aún no se ha terminado con las variables y constantes en JALv2.
Vimos como el compilador de JALv2, trata de ahorrar toda posición de memoria RAM para no derrochar posiciones de memoria. Incluso, si creamos una variable pero no la usamos, no la compilará. Esto no es algo maravilloso, ya que nombrar una posición de RAM no la reserva. En ASM pasa lo mismo; yo puedo asignarles nombres a todas las posiciones de la RAM pero eso no quiere decir que las vaya a usar a todas.

La optimización en ASM pasa por el programador. Alguien que anota para que es cada uso de posiciones de RAM podrá usar muy poca memoria. Todo dependerá de cuantos valores en RAM necesitamos que se mantengan intactas a lo largo de nuestro programa. Cualquier programador en ASM nombrará una o varias posiciones de la RAM como temporal1; temporal2, ect. (o parecido) en que solo la usará para hacer operaciones matemáticas; por dar un ejemplo. Es normal que estas posiciones de memoria la utilicen muchas rutinas y/o subrutinas. Justamente esto, es una optimización por parte del programador.

NOTA y ACLARACIÓN A TENER EN CUENTA: Si tienes un pic que trabaja por años (o cualquier otro microcontrolador), notarán que de un momento a otro empieza a fallar, y da la impresión de ser sin motivo alguno. El hardware anda bien, no hay interferencias y aún así no hay explicaciones para saber la falla. Son esas fallas en la que se soluciona cambiando el pic. Lo que puede estar fallando es que estas posiciones de la RAM que se utilizan muchísimos, leyendo y escribiendo, han sobrepasado su límite de escritura/lectura. En ASM se soluciona fácil. Solo se debe asignar estas posiciones de la RAM a otra dirección en donde no se utilicen y listo. En JALv2, no es posible hacer esto. Pero hay otra manera. Se puede acceder al ASM generado por el compilador, cambiar las posiciones de memoria y compilar el ASM modificado y regrabar al pic.
Esta solución es temporal, pero útil cuando no se dispone de otro pic de iguales características y el hardware debe ser arreglado enseguida. Es temporal porque será cuestión de tiempo en que empiece a fallar otra posición de la RAM.

Continuemos con las variables y constantes.

Alias; Locación; Tablas o arreglo (array).

JALv2

Alias.

Esto es aplicable a VARIABLES, CONSTANTES y SUB-PROGRAMAS (las veremos más adelante).
Lo importante a tener en cuenta sobre un alias, es que solo se hereda la DIRECCIÓN, y si una constante o variable a sido asignada como volatile, esto no se hereda. Por lo tanto la indicación de la NO OPTIMIZACIÓN, no será ejecutada.

Su aplicación es muy sencilla. Se coloca un IS entre las variables, constantes o subprogramas y listo.

var byte volatile i2c_clock is pin_a3
var byte volatile i2c_data_in is pin_a4
var byte volatile i2c_data_out is pin_a4_direction

La variable i2c_clock, hereda la dirección de pin_a3; lo mismo le sucede a 12c_data_in que hereda la dirección de pin_a4; e i2c_data_out que hereda la dirección de pin_a4_direction.
Noten que, si bien pin_a3 pudo haber sido declarada como volatile, 12c_clock no lo heredará; entonces, en la creación de dicha variable, se la declara como volatile.

Supongamos lo siguiente:

var byte volatile carga -- Se crea la variable carga como byte y que no sea optimizada.

var byte recarga is carga -- Se crea la variable recarga como byte y hereda la dirección de carga; pero recarga no es volatile.

Pero si hacemos lo siguiente:

var byte volatile recarga is carga -- Se crea la variable recarga como byte, es volatile y hereda la dirección de carga.

Locación

El compilador nos permite dar la dirección de una variable o constante dentro de la misma variable o constante respectivamente, o sea, a que bit hacemos referencia; o incluso podemos darle la dirección a una memoria RAM. La forma de hacerlo es interponiendo la palabra AT entre las variables o constantes.
Por ejemplo:

var byte volatile port_a at 0x06    -- pic IO port A
var bit    volatile status_z at 3 : 2 -- pic zero flag

El ejemplo no requiere de explicación, ya que es muy evidente. No obstante, para aquel que está aprendiendo, lo explicaré.

Creamos la varaible byte port_a y le asignamos la dirección 0x06 (hexadecimal). Este corresponde a las entrada y salida del puerto A.
Para el segundo ejemplo, vemos que creamos una variable bit con el nombre status_z y lo asignamos a la dirección 3 (0x03 (status)) bit 2.

En este ejemplo, también se lo puede escribir así, y que será más legible: var bit volatile _z at _status : 2

Incluso, se pueden dar múltiples direcciones:

var volatile byte _status AT {0x0003, 0x0083, 0x0103, 0x0183} -- noten que se han encerrado en llaves para indicar varias direcciones.

Tablas o arreglos (array)

Las tablas pueden ser con variables o con constantes. No son iguales unas a otras y hay que tenerlo en cuenta. Por lo general, es recomendable hacer tablas con constantes; pero la circunstancia nos dirán cual utilizar.
Si utilizamos tablas con constantes, las mismas se grabarán en la memoria de programa, tal como en ASM; pero si usamos tablas con variables, las mismas serán echas en la memoria RAM, que también se utilizan en ASM.

Tablas con constantes.

Es la más común y la más usada. Está limitada a un tamaño máximo de 255 valores.
Su estructura es simple:

const byte mensaje [5] = {"M", "2", 24, 3, 10}

Cuando creamos una tabla, no es obligatorio darle inmediatamente los valores, pudiendo crearlo de la siguiente manera:

const byte mensaje [5]

Como notarán, creamos un arreglo o tabla llamado mensaje con una longitud 5. Como mensaje es un byte, quiere decir que utilizamos 5 posiciones de memoria de programa.

Hay dos cosas a saber al momento de crear una tabla o array. Si al momento de crearla no le asignamos los valores, es obligatorio asignarle un tamaño; pero si al momento de crearlo le asignamos los valores, no es necesario indicar su tamaño. Por ejemplo:

const byte mensaje [5]  -- Aquí indicamos el tamaño de la tabla
const byte mensaje [] = {"M", "2", 24, 3, 10} -- Aquí no le asignamos el tamaño de la tabla ya que le asignamos los valores. El compilador sabrá que el tamaño máximo es de 5 posiciones de memoria de programa.

Para leer y/o escribir en una dirección del array, se procede de una forma muy sencilla. Podemos crear una constante y asignarle un valor; luego crear una variable o constante y guardar el dato.

Leer un array

var byte dato
const byte direccion
direccion = 2

dato = mensaje[direccion]  -- En la variable dato se recuperará el valor que hay en la dirección 3 del array mensaje. Dato obtendrá el valor 24

¿Por qué 3 y no 2? porque la dirección del array arranca desde el 0. No confundir con el tamaño del array que si arranca del 1.

Escribir un array

Es muy parecido. Veamos

var byte dato
const byte direccion
direccion = 2
dato = "H"

mensaje[direccion] = dato  -- Ahora la posición 3 del array mensaje tiene el valor de H (ascii) y no 24.

Por supuesto que el index (lo que está entre corchetes) se puede escribir con el número directamente.

var byte dato

dato = mensaje[2]

Tablas con variables.
Está limitada al tamaño del banco de la memoria RAM. Atento a no abusar de su tamaño, ya que podremos quedarnos sin memoria.

Al igual que las tablas echa con constantes, se lee y se escribe de la misma manera. Hay que recordar que el index (lo que está entre corchetes) debe ser una constante.

var byte mensaje [5] = {3, 25, "H", "C", 0}
var byte mensaje = {3, 25, "H", "C", 0}

var byte mensaje [5]

dato = mensaje[direccion]  -- Recordar que el index (direccion en este caso), debe ser una constante.

mensaje[direccion] = dato

[vixctor]

NOTA y ACLARACIÓN A TENER EN CUENTA: Si tienes un pic que trabaja por años (o cualquier otro microcontrolador), notarán que de un momento a otro empieza a fallar, y da la impresión de ser sin motivo alguno. El hardware anda bien, no hay interferencias y aún así no hay explicaciones para saber la falla. Son esas fallas en la que se soluciona cambiando el pic. Lo que está fallando es que estas posiciones de la RAM que se utilizan muchísimos, leyendo y escribiendo, han sobrepasado su límite de escritura/lectura. En ASM se soluciona fácil. Solo se debe asignar estas posiciones de la RAM a otra dirección en donde no se utilicen y listo. En JALv2, no es posible hacer esto. Pero hay otra manera. Se puede acceder al ASM generado por el compilador, cambiar las posiciones de memoria y compilar el ASM modificado y regrabar al pic.
Esta solución es temporal, pero útil cuando no se dispone de otro pic de iguales características y el hardware debe ser arreglado enseguida. Es temporal porque será cuestión de tiempo en que empiece a fallar otra posición de la RAM.

Increíble lo que acabo de leer!!!

Por favor, si no tienes idea del porque fallan las cosas, no mal informes a los demás usuarios...

La memoria RAM no tiene LIMITES de lectura o de escritura, solamente la memoria FLASH y la EEPROM en menor medida.

El fenómeno que mencionas ocurre después de años de uso más no porque la memoria RAM falle.  Es más factible que la memoria FLASH falle, y no exactamente es una falla, sino el tiempo de preservación de los datos de la memoria FLASH expira.

Actualmente el tiempo que mantiene los datos la memoria FLASH en los pics es de 40 años.

Sin embargo, en versiones previas el tiempo pudo haber sido menos.

El caso que mencionas lo observe alguna vez con un microcontrolador tipo Z80 en un equipo de ultrasonido de los años 80's.

Resulta efectivamente que el equipo dejo de funcionar subitamente a pesar de estar todo en orden, después de revisar todo minuciosamente, se volvió a reprogramar el microcontrolador con el programa original (Sin cambiar las localidades de la RAM) y el equipo volvió a funcionar correctamente...

[Leon Pic]

Se muy bien, que puedo equivocarme o que puedo mal interpretar las cosas. De echo, esa la razón por la que en la primer publicación, pido que me corrijan cuando me equivoco. Un error lo puede tener cualquiera, y cualquiera pudo haber sido mal enseñado.
Las enseñanza que he tenido en electrónica, ha sido gracias a los foros y libros que he leído; y en menor medida de algunas clases que he tomado al azar, una es reparación de computadoras.

En ella, aprendí que las memorias RAM fallan. Algunas posiciones de memoria no se graban correctamente y/o no dan la información requerida; o en su defecto, con un dato erróneo. Hará un par de años atrás, tuve el típico problema de que la máquina no iniciaba. Era una sola memoria RAM, aprovechando de que las máquinas ya no era un mandato en poner una memoria en el slot 0; sino que puede ir en el 1 también. No obstante, es recomendable poner una memoria en el slot 0. Por lo tanto, decidí cambiarlo de slot sospechando de que el banco esté dañado. Por supuesto, no arrancó. Entonces decido tomar una memoria nueva y la máquina salió andando desde el slot 0.

Es bien sabido que todo tiene un límite, incluso la memoria RAM y que dependerá con qué tecnología está echa. Si es verdad que los ciclos de escrituras y lecturas de una RAM son hasta exageradas comparada con la memoria de programa, o incluso la memoria EEMPROM, pero aún así tienen un límite.
No todos los programas consumen la misma cantidad de memoria, como así también no todos los programas acceden con la misma frecuencia a diferentes posiciones de la RAM.
Hay programas que no utilizan memoria EEPROM, por lo que la características de 1.000.000 de ciclos de lecturas/escrituras, están de gusto. Incluso, no todos los microcontroladores tienen la características de modificar su memoria, e incluso, aquellos que lo tienen, no todos los programas usan esa características; así que aquí también, queda de gusto esa características (a no ser que utilicemos ese pic para practicar).

En mi concejo, también pongo el problema de una falla de fabricación. El echo de que no expresen un límite los fabricantes de la memoria RAM, no quiere decir que no la tengan. Su omisión, a este dato, hace que ellos no se hagan responsables ante la falla de una o varias posiciones de la RAM. No así pasa con la FLASH ROM (memoria de programa) o EEPROM en la que si se hacen responsables. Más en la memoria EEPROM, que no solo se la utiliza para guardar algún código de seguridad, sino también que se la utiliza para guarda por donde estaba el CP por si hay un reinicio inesperado en el microcontrolador y retomar por donde estaba.

Por supuesto que habrá personas que concuerden contigo, vixtor; y que puede deberse a que su límite de ciclos, sea despreciable; pero eso no quiere decir que no tenga un límite.

Para finalizar, como a mi me han enseñado de que toda memoria, tiene un límite de ciclo de escritura/lectura; y que aún nadie me ha demostrado lo contrario (al menos en la RAM) no eliminaré o tacharé esa nota y aclaración.
No obstante, si me lo puedes demostrar; te estaré agradecido. Y para no enseñar mal, tacharé mi nota y agregaré una nota de agradecimiento por tu corrección oportuna.

Si voy a hacer una sola corrección y es por tu ejemplo de la falla del z80. Algo parecido le pasó a un ingeniero electrónico que escribió un libro de microcontroladores (seguro más de uno lo leyó) resulta que él había preparado una clase o exposición de grabación de microcontroladores y en su casa funcionaba bien. A la hora de exponer su clase, el pic no funcionaba. Lo volvió a grabar y probar en su casa y funcionaba correcto. Lo volvió a llevar al siguiente día, y le volvió a pasar lo mismo. La conclusión que él llegó es que su ruta desde su casa hasta la clase, pasaba por debajo de las líneas de alta tensión; y que esta interferencia electromagnética, corrompía la memoria de programa.
La corrección será "Lo que está fallando..." por "lo que puede estar fallando..."

[KILLERJC]

Yo lei que la misma lectura de un flash podria con el tiempo alterar los valores de los registros vecinos lo que le llaman: "Read disturb" y que requiere cada cierto tiempo una grabacion de nuevo