Una pregunta acerca del ICD2 y comentarios al que me pueda responder

[misterweb]

Hola  mi pregunta es la siguiente, trabajando con  el ICD2  de microchip y no hay pobrema con nada estoy programando y trabajando con un 16F873 y sin problema.

 Pero mi posible decepcion es que yo pensaba es que en el modo Debbuger el microcontrolador no programaba el microcontrolador y simulaba mediante el pequeño programa que le metia la parte de programa que queriamos, de tal forma que  una vez simulado y visto que funciona lo que hariamos es pogramarlo de verdad.  No se si estoy en lo correcto o es que yo lo estoy haciendo mal.

 Todo esto viene por que ha base de programar y desprogramar los Pics se van a la mierda, yo nunca he llegado a las 1000 veces esas que dicen se van pero muchisimo antes, bien es verdad que los he programado con el TE-20 y puede que esto les acorte bastante la vida, no se haber que tal con el ICD2.

 Seria Maravilloso que existiera un micorcontrolador que aparte de la memoria Flash de programa se pudiese ejecutar aunque fuera una pequeña parte de programa desde la memoria Sram, de tal forma que si entrariamos en un verdadero debbuger y cuando ya el programa estuviera suficientemente probado se grabaria en la flash, esto seria mas limpio, mas rapido y mas economico.

 He visto con la familia 18F hay algunos pics que pueden correr programas con memoria externa, pero ne deja de ser un coñazo,  tener que montar memoria esterna.

 Realmente estoy estoy pensando hacerme un debbuger yo que se ejecute en la memoria sram del microcontrolador, aunque esto no fuese tan rapido.

 Me hice un entrenador que atraves del puerto serie del ordenador conectaba con el microcontrolador y lo programaba y le hacia correr programas, desde pogramas creados en Visual Basic, que hize y va de maravilla, aprovecha el echo de que la familia 16F873 se puede autoprogramar, fue una experiencia bastante gratificante aunque me llevo meses de duro trabajo, hacer programas, protocolos comunicacion etc.... 

 La unica pega que tiene es que le  pasa lo mismo que al TE-20 que no se pueden programar los microcontroladores ni por asomo a los 100 veces.

 Lamento haberme enrollado tanto, pero bueno puede que a alguien le interese este tema, gracias en cualquier caso por su atencion y espero que alguien le interese esto agradeceria que alguien me contestara acerca del ICD2 en modo debbuger


 Muchas gracias a todos y saludos.

[maunix]

Yo uso el ICD2 como debugger y como programador y no he experimentado que me dañe los pics.  De hecho he programado cientos de veces cada pic antes de considerar que un firmware está listo.

Hacer 'otro debugger' implicaría tener que lidiar con el MPLAB y con sus protocolos que no están documentados para el modo debugging.  ¿De qué sirve un debugger si no se pueden ver las variables en el MPLAB?

Además hacerlo para un pic, y luego moverlo a otro pic implicaría tener que cambiar varias cosas.  En resumen estaríamos trabajando mucho cada vez que se quiera programar algo.

No se si el problema que tienes es el debugger o de confundir lo que es un debugger.  Es cierto que no es la panacea y tiene sus limitaciones pero si lo que buscas es "full power" con tu debugger, tal vez estás necesitando un EMULADOR.  Esos son bastante más caros pero simulan a tu pic en tiempo real.

Saludos

[LABmouse]

tampoco creo el problema sea el ICD2, es posble que tengas mal diseñada la etapa de acople al ICD2, si puedes montar el esquema de como lo conectas al PIC, estaria bien, para descartar eso.

[misterweb]

Mi problema es cuando yo modifico el programa y lo pongo a correr bajo debugger, no ejecuta la parte de programa modificada sin antes desde debbuger ejecutar la orden de programar, entonces lo que hace realmente es programar el pic, y ya entonces si lo ejecuta el programa bien........ Esto es correcto hoy hay alguna otra forma de hacerlo.

 Maunix con respecto  a lo que decias de hacer un nuevo Mplab estoy contigo que es un lio y no merece la pena, de todas formas, con los programas en Visual Basic que me hize, la verdad es que llego hacer muy comodo, ya que tenia un control total atraves del puerto RS232 del pic, y pogramaba el Pic, y ejecutaba el programa haber que pasaba, y si no iba lo volvia a modificar, y todo en caliente, mediante unos menus que me hacia en el Pic.

 Yo utilizaba la opcion de programar el propio microcontrador desde su opcion de autoprogramacion, pero no se por que se acaban jodiendo de esta forma, lo cual me descoloca bastante, por que ahi, no hay tensiones altas ni nada, es el propio microcontrolador el que se autoprogramaba.....

 En fin tendre que seguir investigando, lo malos es el tiempo..... trabajar, hacerse una casa, y demas.... no deja mucho tiempo para nada........ Muchas gracias a todos..... Nos vemos.

[maunix]

Mi problema es cuando yo modifico el programa y lo pongo a correr bajo debugger, no ejecuta la parte de programa modificada sin antes desde debbuger ejecutar la orden de programar, entonces lo que hace realmente es programar el pic, y ya entonces si lo ejecuta el programa bien........ Esto es correcto hoy hay alguna otra forma de hacerlo.

Es que tu te estas confundiendo debugger con emulador.  Un debugger hace correr el programa en el PIC y tiene un microcódigo que permite interactuar con el MPLAB para agregar breakpoints y actualizar el contenido de los registros para poder ser visualizados en el MPLAB. 

Es normal que tengas que reprogramar.

Maunix con respecto  a lo que decias de hacer un nuevo Mplab estoy contigo que es un lio y no merece la pena, de todas formas, con los programas en Visual Basic que me hize, la verdad es que llego hacer muy comodo, ya que tenia un control total atraves del puerto RS232 del pic, y pogramaba el Pic, y ejecutaba el programa haber que pasaba, y si no iba lo volvia a modificar, y todo en caliente, mediante unos menus que me hacia en el Pic.

De seguro solo modificabas variables pero no código.  Para modificar código tenes que cambiar la flash si o si.

He hecho este tipo de cosas innumerables veces, firmwares en PIC que puedan ser controlados externamente y que explayen datos más allá de lo mínimamente necesario como para poder saber qué esta haciendo el software.  Puedo modificar variables para cambiar el funcionamiento de una cierta rutina y ver muchas variables incluso durante la ejecución sin intervención mía.  También me permite llevar un historial de algunas cosas.

Una faceta más simple de esto es hacer un dump de lo que hace el programa en modo ascii a un hyperterminal.

Un modo de debugging no excluye al otro, lo complementa.  Habrá casos en que solo el debugger te permitirá ver algunas cosas y en otros casos en que solo una aplicación externa puede hacerlo.

Saludos

[elmasvital]

Y para que necesitas modificar tantas veces el programa?. No se creo que el problema es que igual has aprendido a programar pics como se programa en visual basic y eso es un problema pq te crea vicios. Debes aprender a programar un poco a "ciegas" e intentar pensar como lo hace la máquina y detectar fallos analizando el circuito y el programa no tanto por el método del prueba y fallo.

Un microcontrolador no es un ordeandor y cada fallo puede resultar fatal... Recuerda que los pics son de la familia cmos y cualquier entrada al aire puede provocar su destrucción o malfuncionamientodel mismo.

A todo esto todavia no me he cargado ningun pic de tanto grabarlo y borrarlo.

1 saludo.

[maunix]

Y para que necesitas modificar tantas veces el programa?.

Jeje, mis software los grabo una y otra vez.  Si es algo simple es cierto, no hace falta hacerlo andar tanto pero si tienes un 18F que hace montones de tareas en simultáneo, es sabio ir programando las tareas una a una e ir probándola cada una como funciona y no todo junto de una sola vez.

Cuando esas tareas dependen de respuestas de hardware externo, una simulación poco sirve y por ende hay que grabar y volver a grabar una y otra vez el software.

Saludos

[misterweb]

Maunix
 Gracias Maunix por aclararme el tema de que el Debbuger tiene que programar para poder hacer el Debbuger en si.

 Con respecto a si mi programa solamente variaba variables de codigo, que va mi programa en Visual Basic variaba la flash del microcontrolador osea la memoria de programa y se basaba, en el echo de que los microtroladores de esta familia se puede autoprogramar la memoria de Programa desde el propio programa lo cual me parece estupendo.

[misterweb]

Elmasvital

 No Elmasvital no programo los microcontroladores como Visual Basic, de echo creo que seria muy dificil hacerlo.... los programo y en  ensamblador, y con respecto a si modifico los programas muchas veces te respondo igual que Maunix.... Jejeje... Cuando estas haciendo un programa sobre todo ya un poco complejo es muy dificil que te se salgan bien las cosas ya no digo la primera vez si no mas de 40 veces......
  Ademas el proyecto que estoy haciendo es un entrenadore... en el cual el microcontrolador se encarga de Juegos de luces....(sencillito), Grabacion de Sonido y Reproduccion, Encender panel de displays, cargar ficheros de datos PC a memoria SRAM de entrenador y viceversa, Cominicacion RS232, Comunicacion ICD2, control panel LCD, etc... y esto es una pequeña parte de lo que pienso meterle al pequeñin. Todo esto lo eligo atraves de un menu en Visual Basic con el ordenador y interactuo con el Pic, lo voy programando y leyendo el programa Flash y comprobando que funciona,
y volviendo a programarlo, tengo que mejorar muchas cosas ..... pero en ello estamos...

 Un saludo y gracias por vuestras contestaciones.

[misterweb]

 Es verdad que tambien el ICD2  hasta ahor y con el poco tiempo que llevo trabajando con el se mantiene muy estable, pero no me deja interactuar de forma tan rapida como yo quiero.... Lastima que mi sistema no sea estable, los pic se me acaban jodiendo.... y la verdad es que no se por que... por que no hay tensiones altas por ningun lado.... me tendre que volver ha hacer la placa del entrenador de nuevo.... puede que haya por ahi alguna tension que me este jodiendo.

 Buen saludos....

[maunix]

Es verdad que tambien el ICD2  hasta ahor y con el poco tiempo que llevo trabajando con el se mantiene muy estable, pero no me deja interactuar de forma tan rapida como yo quiero....

Si, no es la cosa más veloz del mundo pero como te dije antes, es que uno está acostumbrado tal vez a debuggear en la PC en donde uno debuggea en el propio entorno en el que está trabajando, osea, tu debuggeas sobre la PC con el Sistema Operativo.  En un microcontrolador estas debuggeando contra él y por ende hay mucha información que se debe pasar hacia la PC una vez que insertas un breakpoint o bien una ejecución paso a paso.

En general, el desarrollo de aplicaciones con microcontroladores demanda tanto tiempo por esas sencillas razones.  El debugger de por sí, vino a acelerar muchísimo los tiempos de desarrollo, sin él las tareas llevarían mucho más tiempo.