![]() |
"Tolomeo se mudo al Polo Norte"
|
La variable k, sobra.
De 0 a 15 deberia ser lo mismo que de 0x0000 a 0x000F y vos lo que estas haciendo, es llenar una columa con el final de la cuenta de 0 a 15, entonces, 0x0000 a 0x000F que sigue? 0x0010, y ahi te empieza a escribir. El procedimiento esta "alrevez". Saludos |
Te diste cuenta?, mira la corrección, es muy sencillo.
Saludos |
"Tolomeo se mudo al Polo Norte"
|
Para tratar una serie de 0 a 4095 no hagas dos bucles, haz uno solo.
Asi no pierdes ni uno solo de los valores ni repites ninguno. |
Por cierto, para llenar el memo lo haces cuando la pasada lo piad, al final de cada grupo de 16.
|
"Tolomeo se mudo al Polo Norte"
|
"Tolomeo se mudo al Polo Norte"
|
Cita:
Saludos |
Cita:
|
"Tolomeo se mudo al Polo Norte"
|
"Tolomeo se mudo al Polo Norte"
|
Pero no entiendo cual es la duda.
de 0 a 4095 son 4096 posiciones, en el bucle, carga fila/columa aplicando un mismo valor de j, es decir, de posición. Si el incremento llega a un valor de palabra de 0x000F entonces agrega la linea al Memo. El hecho de usar un solo bucle y no dos, es simplemente para mejorar el procedimiento, porque sino que harias? rellenas todas las columnas y cuando tenes las columnas empezas a cargar una a una las filas, para que? si se puede hacer de un tirón, sin miedo de repetir numeros. Siempre tenes que saber como esta formado el mapa de memoria, y miralo como una matriz de fila por columna, sabiendo eso, son los parámetros que necesitas modificar, asi como el ancho de la palabra (en bytes). Saludos |
"Tolomeo se mudo al Polo Norte"
|
Cita:
No se que uC estás programando, ya que de eso depende las características del mapa de memoria, forma de escritura, etc. Pero te pongo un ejemplo con un uC Pic. El programa puede considerarse que ocupa toda la memoria, puesto a que, donde finaliza la data real del firmware, dicho código escribe un dato de nulidad o conjunto vacío. En el caso de un Pic, (3FFFh=vacío). Por lo que borrar un chip, en el caso de un Pic, es lo mismo que decir, escribir 3FFFh a toda la matriz de memoria de programa, y 00h a cada direccion de la EEPROM. Para resolver esto y que lo vuelques de forma elegante en un StringGrid, que me parece una idea exelente, y de hecho programas como el ICProg lo hacen asi, hay que analizar la situacion de la siguiente forma: 1) Determinar la estructura de la matriz del mapa de memoria del uC. 2) Determinar la estructura de la matriz que ocupa en memoria los datos. Sabiendo estos 2, solo resta hacer la lógica Pseudocódigo Cita:
Saludos |
"Tolomeo se mudo al Polo Norte"
|
Atencion, pregunta, ¿porque vas a guardar en un fichero IntelHex 4Kb de codigo si solo son utiles unos pocos cientos de bytes? ¿es posible grabar solo una parte del chip? ¿Seria mas comodo un StringGrid mas pequeño que 4096 celdas?. Yo hice algo parecido para un PIC y tenia una solucion, el resto de la memoria no ocupada por el programa efectivo no lo llenaba con ceros, simplemente lo dejaba en blanco, es decir, a 3FFF. Asi puedes reconocer donde esta el limite del codigo activo y fijar un limite superior para los bucles de grabacion y de volcado a un fichero IntelHex o para grabar el micro o crear el StringGrid que va a contener los datos.
|
"Tolomeo se mudo al Polo Norte"
|
"Tolomeo se mudo al Polo Norte"
|
"Tolomeo se mudo al Polo Norte"
|
| La franja horaria es GMT +2. Ahora son las 12:10:39. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi