memoria 24FC512

No te preocupes mucho. Coge un buen editor de texto, tipo ultraedit, y te aseguras de poner el fichero de texto en formato DOS-ASCII (1 byte por carácter). Cuando lo tengas, lo editas en hexadecimal y puedes convertir los CR (h0D h0A) por retornos simples (h0D) para ahorrar espacio. Cuando esté a tu gusto, lo grabas como un fichero de texto, pero con extensión .BIN. Lo abres con ICProg y a grabar.

--

Saludos de Jose Manuel Garcia snipped-for-privacy@terra.es http://213.97.130.124

"KT88" escribió en el mensaje news: snipped-for-privacy@uni-berlin.de...

sableada

generar

pez

oxidado

os

El otro día, KT88 nos estuvo contando:

Lo primero, imagínate que en vez de una memoria tienes un archivo. en ese archivo puedes meter 2000 frases, pero el problema es encontrarlas. Por ejemplo si buscar la frase que define el error 24 ¿en qué posición está?

Hay varias soluciones para esto, la más usual es asignar a cada frase una longitud fija, pongamos 255 bytes. Así es fácil encontrar la que buscas con sólo multiplicar. Además podrías aprovechar la paginación de la

24xx512. El problema de eso es si hay frases muy cortas y otras muy largas, pues todas ocuparán tanto como la mayor.

Otra forma es grabar al principio las 2000 posiciones de las 2000 frases por ejemplo en 4 bytes. Cuando necesites una, miras la posición de su dirección multiplicando y cuando la tengas accedes a esa dirección, porque las 24xx soportan acceso aleatorio ¿no? Así se despercicia menois memoria pero es más complicado.

Por último la forma más fácil es usar un carácter delimitador, por ejemplo un cero binario. Vas accediendo secuencialmente hasta que cuentes determinado número de ceros, y la siguiente es la frase que quieres.

Elige la opción que más te convenga y si hace falta me explica más detenidamente.

Por otra parte una vez que tengas el fichero en el ordenador, por ejemplo en texto normal usando un editor como el khexedit (o el ultraedit si usas windows) simplemente lo abres en icprog y lo transfieres.

Lógicamente el mismo algoritmo de acceso que usas para acceder a los datos en el archivo de texto, lo tendrás que implementar en el pic para acceder a la memoria, y esto ya puede ser más o menos complicado.

Espero haberte ayudado.

Saludos

--
·········································································
··  Reinoso G.  EA4BAO                      r einoso.bao@wanadoo.e s   ··
··  http://perso.wanadoo.es/reinoso.bao                                ··
·········································································

Bueno, el tema del acceso, es otro problema, que también me estoy planteando, como hacerlo.

La opción de buscar secuencialmente en la EEPROM, lo he descartado, sería lento, y poco práctico. Cuando acceda a la EEPROM para recuperar el texto, ya debo saber por programa, cual es la dirección exacta donde empieza y termina la frase.

Si las frases son de longitud fija, es más sencillo, aunque en efecto se desperdicia mucho espacio, y con 64 mil carácteres, creo que va a ir muy justa, sobre todo para ampliaciones futuras. Aunque ya tengo pensado gestionar varias EEPROM.

Pensaba guardar en programa una tabla fija, con la posición de comienzo de cada frase, y que el final sea un retorno de carro, el mismo que tiene ahora el fichero de texto que contiene las frases.

No he utilizado busquedas en tablas, pero supongo que el C, para PIC, lo permitirá, como todo lenguaje que se precie.

La opción que me comentas de guardar al principio de la EEPROM las posiciones de las 2000 frases, también parece interesante. Aunque pienso usar un PIC18F252, si meto la tabla en programa, ya se me va un buen tajo de flash, con esa tabla, casi mejor ponerla en la EEPROM.

Ok, entonces va a ser bastante sencillo, pasar el fichero a la EEPROM. ¿ el retorno de carro, que mete por salto de campo no era de 1byte, en concreto el código ASCII 13 ? No se que diferencia hay entre los 2 códigos que indicas, a parte de que uno ocupe 1byte y el otro 2.

los

de

frases,

ser

si

una

Otro tema, es que además quiero poner los textos encriptados, para que no me los fusilen, pero ese ya es otro cantar.

ahora

de

ese

una

porque

memoria

cuentes

ejemplo

usas

datos

acceder

········································································· ·· ·· ·········································································

El otro día, KT88 nos estuvo contando:

Bueno, depende de lo importante que sean usa algo sencillo, por ejemplo se me ocurre un cifrado en flujo:

programas un generador seudoaleatorio en el pic (por ejemplo uno de tipo registro de desplazamiento que es muy sencillo), o uno modular. E inventas un método para buscarte una semilla en relación a la frase que sea, así cada frase tiene una semilla distinta. Y luego vas haciendo xor del número aleatorio i con cada caracter de la frase, tanto para cifrar como para descifrar.

Si quieres algo más complicado sería plan de implementar un RC4 que tampoco es muy complicado de hacer en C (en ASM te puedes morir).

Y si quieres algo más simple pues un sencillo xor con la clave que tú quieras.

Date cuenta de que si cifras todas la frases con la misma clave, en cuanto tengan una pueden obtener las demás.

Saludos.

--
·········································································
··  Reinoso G.  EA4BAO                      r einoso.bao@wanadoo.e s   ··
··  http://perso.wanadoo.es/reinoso.bao                                ··
·········································································

KT88 expuso:

Eso en Unix (o Linux). En DOS o Windows el retorno de carro siempre han sido dos caracteres, el ASCII 10 y el 13 seguidos (cuestiones históricas). La idea es que uno desplaza el cursor hacia abajo una línea y el otro lo vuelve al inicio de la línea en antiguos sistemas de texto (pantallas y impresoras), así al volcar el texto en un dispositivo de texto salían bien los retornos de carro. Para tu aplicación puedes guardar el fichero en modo Unix, así te ahorras un carácter. Si no tienes esa opción puedes usar un editor hexadecimal para reemplazar la secuencia ASCII 13-10 (0Dh-0Ah en hexadecimal) por un ASCII 13 (0Dh).

donde piensas guardar el algoritmo ?

-- "Por cierto, de sobra es conocido que no hay quien entienda lo que escriben los médicos a mano, pero resulta curioso comprobar que tampoco se les entiende al escribir a máquina." J. M. García

Saludos.

El monstruito toma "forma", f*ck it...

snipped-for-privacy@ozu.es Spam-Mail

"KT88" escribió en el mensaje news: snipped-for-privacy@uni-berlin.de...

Bueno, es que la mayoría de editores de texto, para un retorno usan dos caracteres especiales, ASC(13) que es el retorno al comienzo de la línea y ASC(10) que es salto a la linea siguiente (la secuencia en hexadecimal es 0D

0A), y es un desperdicio. Te interesa usar sólo uno de los dos.

De todas formas, para lo que creo que era tu duda, un fichero de tipo BIN de los que se usan para almacenar el contenido de las EEPROM, no es más que una sucesión de todos los bytes que contiene (o quieres que contenga) la EEPROM, desde el primero al último. No hay estructura, ni formato, ni checksum, ni nada. Si te fijas, al leer una EEPROM y grabar su contenido en formato BIN (por ejemplo con ICProg), el fichero que obtienes tiene exactamente el mismo tamaño que la EEPROM. Por ejemplo, para una 24LC512, tendrá 64536 bytes.

En cuanto a la forma de acceder, lo lógico parece usar un índice, una tabla de punteros a cada una de las frases. En este sentido, al usar 512 kbits, tienes 64kbytes, es decir, cada puntero te ocupará 16bits. Dependiendo del micro que uses para manejar todo esto, y de la forma en que vayas a usar esas frases, quizás te interese meter esa tabla en la propia memoria de programa (por ejemplo en un 18F te cabría un puntero por dirección), o usar una parte de la 24c512 para eso.

También tendrías que estudiarlo con detenimiento, porque si te das cuenta, al tener 2000 punteros, necesitarás 11 bits para decirle al programa donde está cada puntero, lo que a efectos prácticos, es casi lo mismo que decirle directamente al programa donde está la frase. En fin, todo depende de qué vayas a hacer con esas frases.

En cualquier caso, si vas a usar una tabla de punteros, y a encriptar las frases, teniendo en cuenta el número de frases, yo me haría un programilla en VB o Delphi para generar el fichero binario, que incluyera ya el índice de punteros y las propias frases. Es bastante simple, y te ahorrarás muchos quebraderos de cabeza si tienes que hacer luego modificaciones.

--

Saludos de Jose Manuel Garcia snipped-for-privacy@terra.es http://213.97.130.124

"KT88" escribió en el mensaje news: snipped-for-privacy@uni-berlin.de...

uno

te

que

pero

como

que

Eso es fácil, en un micro con la memoria protegida contra lectura.

--

Saludos de Jose Manuel Garcia snipped-for-privacy@terra.es http://213.97.130.124

"RooT" escribió en el mensaje news: snipped-for-privacy@uni-berlin.de...

no me

sería

frase.

se

muy

comienzo de

lo

pienso

tajo

en

Por

está?

frase

buscas

frases

su

········································································· ·········································································

"Reinoso G." escribió en el mensaje news: snipped-for-privacy@EA4BAO.PLLANO.ESP.EU...

de

sableada

frases,

Y si las haces de longitud fija, pero de la longitud de la menor? Yal final, en el último caracter, indicas el desplazamiento al resto de la frase. Tendrías que añadir un byte por frase.

El otro día, ReSeT nos estuvo contando:

El problema es cómo localizar el principio de la frase pedida. Por ejemplo si cada frase ocupa 100 bytes, y tu quieres la frase n-esima sabes que comienza en 100*(n-1)

Si tienes fragmentos de frases desperdigados para las 2000 frases que son te ocuparán bastante y te complicaría el algoritmo al tener que buscar y recomponer la frase. Por otra parte, tal vez no te baste con un sólo bit al acabar la frase, y tal vez no baste con sólo dos fragmentos.

Creo que el algoritmo se complica bastante así o es que yo no lo he entendido.

--
·········································································
··  Reinoso G.  EA4BAO                      r einoso.bao@wanadoo.e s   ··
··  http://perso.wanadoo.es/reinoso.bao                                ··
·········································································

Usando C te puedes armar directamente un archivo que que ya contenga los textos y los indices.

Por ejemplo, un archivo 'frases.c' que contenga solamente un vector de punteros.

char * Texto[]={ "El Mensaje Uno", "El Mensaje Dos" , "El Mensaje Tres" } ;

Lo compilas con: bcc -c frases.c Y lo linkeas con: tlink /t frases,frases.bin

La estructura del archivo generado es:

[0000] - Puntero al mensaje 1 , = 6 [0002] - Puntero al mensaje 2 , = xx [0004] - Puntero al mensaje 3 , = yy [0006] - Texto Mensaje 1 terminado en 0 [00xx] - Texto Mensaje 2 terminado en 0 [00yy] - Texto Mensaje 3 terminado en 0

Para la proteccion de los mensajes una opcion a la encriptacion puede ser usar un checksum medio retorcido, podran verlos pero no modificarlos.

Saludos. Eduardo.

sableada

generar

pez

oxidado

os

"Reinoso G." escribió en el mensaje news: snipped-for-privacy@EA4BAO.PLLANO.ESP.EU...

Por eso te digo que los fragmentos han de ser de longitud fija y que en el último caracter de cada fragmento le has de indicar a la rutina que las lee dónde tiene que seguir. Supongamos que sólo necesitas los primeros 128 caracteres ASCII. Supongamos también que necesitamos i frases y la frase más corta tenga j caracteres. Pues haces una tabla de i filas de j columnas. En el caracter j pones el primer bit a 1 para marcar que la frase sigue y, con los 7 bits restantes le indicas el código del caracter. La rutina que lee sabe que, para leer la frase n, ha de ir a j * ( n - 1). Si la frase no ha terminado, porque se encuentra el 1 en el primer bit del j-ésimo caracter, seguirá en j * (n-1) + i * j, .., si sigue sin terminar, el siguiente fragmento será j * (n - 1) + 2 * i * j , etc. Con este sistema sólo necesitas tantos bytes como caracteres.

2000 frases es una cantidad muy grande, así que también se podría reducir la memoria utilizada empleando una lista de palabras, ya que muchas de ellas se repetirán. Si te apañas con 255 palabras (creo que mis hijos no utilizan tantas), con 1 byte por palabra tendrías suficiente y con 2 bytes por palabra podrías direccionar un diccionario bastante respetable. Cada frase te ocuparía 2 bytes por palabra + 1 para indicar que se ha terminado, en lugar de 1 byte por caracter. A esto tendrías que añadir la memoria ocupada por la propia tabla de palabras pero creo que sacarías bastante ventaja. Incluso podrías utilizar 1 byte por cada dos caracteres .... Según lo que quieras hacer, lo que no te preocupe la facilidad de modificarlo luego o lo que quieras complicar la rutina de leer las frases, se puede comprimir bastante.

Saludos Joan

Eso es facil. Cuando tengas el texo a cada caracter le haces un XOR con una mascara, o inviertes los bits o alguna perreria por el estilo. Jugando con los diferentes parametros queda algo muy rapido y sencillo. ¿Inviolable?. No, claro. Inviolable no hay NADA en esta vida. Pero da un adecuado termino medio

Saludos

Cristobal

Haz un estudio. Dependiendo del tamaño de las frases, puede ser una opcion interesante. A lo mejor 256 caracteres son muchos.

Es lo mas rapido para buscar.

Podrias usar un sistema por clusters, como el pc. Seria algo asi:

a) Divides la zona de frases en trozos de una longitud dada: por ejemplo, 32 bytes. El tamaño del cluster estara en relacion con el tamaño de las frases: cuanto mas cortas sean de media las frases, mas pequeños seran los cluster. b) Creas una tabla en la que se indica el cluster inicial de cada tabla c) Al final de cada frase insertas un caracter de "fin" (por ejemplo,

0xFF). Si no finaliza, se lee el siguiente.

La ventaja es que al direccionar por cluster necesitas menos espacio de direccionamiento. Para 2000 frases gastarias poco mas de 2Kb en la tabla. Pues aunque bajaras el tamaño del cluster a 32, la tabla apenas te ocuparia, empaquetada, 2750 bytes. Ademas, no se en el C del PICC, pero en C estandar puedes definir tablas con entradas de n bits y el programa las gestiona como tablas normales de modo transparente.

Saludos

Cristobal

"KT88" schreef in bericht news: snipped-for-privacy@uni-berlin.de...

Yo creo que la mejor opcion es incluir la tabla de direcciones de mensajes en la misma memoria, con largo fijo por direccion y cada mensaje que termine en LF CR.

A proposito de esto, creo que pepitof dijo que la secuencia es 0Dh 0Ah, ...(o sea CR LF, Carriage Return, Line Feed). Pepitof estas 200% seguro de eso? yo creia que era LF CR pero ahora tengo la duda...

Ademas un comentario: Me pregunto si tene sentido encriptar los mensajes que se visualizaran en un display o alguna pantalla por el estilo. A parte supongo que tu "chisme" funcionara en base a un PIC el cual le protegeras la memoria de programa. Esa me parece solucion suficiente. Pues llegado el caso que los rusos crackeen tu pic y lean el programa, con solo copiar la serial eprom y grabar una nueva, mirarian el conetenido con un editor de texto pero al estar encriptado seria incoprensible para ellos, pero no para el pic clonado.

Saludos, Dario

Eso tiene una explicación muy sencilla.

De los más de 7000 códigos de averías (genéricos + códigos de fabricantes), ¿ cuantos crees que podrás ver por el LCD, cuando conectes el chisme a tú automóvil, para que haga un chequeo ?

Si sufres una avería, como mucho, verás 1 ó 2, el correspondiente a la avería del vehículo.

Dejar en abierto los 7000 códigos, es decirle a los espabilaos, "tomad y comed todos de él...... es gratis, aunque a mi me haya costado mucho tiempo y dinero recopilar la información". Hay muchos aplicativos, que cuestan no menos de 4000 euros, y TODOS llevan encriptados los ficheros de los códigos y mensajes de averías.

la

Eso no impide en absoluto (me sorprende que no le sepas), leer el contenido de una EEPROM I2C externa.

serial

pero

Eso es una capullada propia de MrPmosh o Juvenal, parece mentira que la digas tú. Si alguien, ruso o de Madagascar, volcase la Flash, podría desencriptar sin problema alguno el contenido de la 24FC512, que contendrá el algoritmo para desencriptar.

Por cierto, ¿ sabes porque no he empleado un Atmega128, para este proyecto ?, porque no hay manera de conseguirlos en pequeñas cantidades para hacer prototipos, y ARROW mi proveedor como mayorista, me exige la compra de 300 unidades mínimo.

Solo una cosa más.

Tú absurda e infantil dualidad, Microchip-Atmel, que en principio me resultaba graciosa y pintoresca, cada vez me parece más fruto de una actitud enfermiza y plagada de traumas que solo distorsiona la realidad, por dios sabrá que bizarras manías.

Ni Microchip es el diablo, ni Atmel el arcangel San Gabriel, despega de tú biblia particular, porque conversar contigo con esa actitud, es tan irritante, como tratar de convencer a un niño de 2 años, que pipi se hace en la taza del bater y no en los pañales.

"KT88" escribió en el mensaje news: snipped-for-privacy@uni-berlin.de...

mensajes

fabricantes),

tiempo

protegeras

contenido

sin

para