de Freescale 8bits a PIC32...

[dongustavo]

Hola DonGustavo, creo que nos conocemos, si sos quien creo que sos puedo decir que realmente sabes del tema de ruidos y esas cosas. Con respecto a tu pregunta inicial, aunque todavía no uso los Pic32 los consejos que te puedo dar, es primero acostumbrarte a la herramienta, no creo que exista un IDE en pic que sea similar al CodeWarrior, con respecto a la migración todo el código escrito en C debería ser migrable sin mayor esfuerzo. Eso sí tendrás que lidiar con todos los periféricos que son propios de la arquitectura.

Saludos !

Hola Richard... sí, soy yo, Gustavo.... Cómo te va?

La migración es más o menos directa, casi no tengo nada en ASM, todo en C...


Saludos!

[RICHI777]

La migración es más o menos directa, casi no tengo nada en ASM, todo en C...

Excelente !!!. Entonces suerte con la migración. Mi consejo en general es que en este mundo actual nos tenemos que acostumbrar a los cambios de arquitecturas, cuando mas escribamos en ANSI C ( lo uso pero tengo serias criticas hacia él ) mejor preparados para un cambio de arquitectura sin demasiado esfuerzo.

Saludos !

PD. Como renege con las memorias chinas que me diste !!!, sabes que no pude crear un código universal que se banque a todos los tipos, después me separé y tuve que congelar las cosas, en algun momento te las devuelvo.

[dongustavo]

La migración es más o menos directa, casi no tengo nada en ASM, todo en C...

PD. Como renege con las memorias chinas que me diste !!!, sabes que no pude crear un código universal que se banque a todos los tipos, después me separé y tuve que congelar las cosas, en algun momento te las devuelvo.

Hola...

naaahhh quedate con las tarjetas, no problema.

Bueno, encargue a Microchip direct:


PIC18F46J50 FS USB PIM DEMO BOARD
   
PICkit 3 In-Circuit Debugger

PIC18F46J50-I/PT 5 piezas

Voy a arrancar con un sencillo cronómetro de mano, nada para poner arriba de un auto.

Cuando llegue actualizo...

Saludos!

   

[RICHI777]

Hola...

naaahhh quedate con las tarjetas, no problema.

Bueno, encargue a Microchip direct:


PIC18F46J50 FS USB PIM DEMO BOARD
    
PICkit 3 In-Circuit Debugger

PIC18F46J50-I/PT 5 piezas

Voy a arrancar con un sencillo cronómetro de mano, nada para poner arriba de un auto.

Cuando llegue actualizo...

Saludos!

Joya !!!, aca hay mucha gente que sabe muchisimo y de seguro te va a dar una mano ... a mi no me quieren mucho porque soy un FreeScalero confeso      

Saludos !

[MGLSOFT]

A RICHI cuando entro, le sentimos el olor a Chotorola ahi al toque !!

Despues con el tiempo le fuimos tomando cariño, y ahora le perdonamos su equivocacion !!! 

[RICHI777]

A RICHI cuando entro, le sentimos el olor a Chotorola ahi al toque !!

Despues con el tiempo le fuimos tomando cariño, y ahora le perdonamos su equivocacion !!! 

jajajaja siiii es mas con vos nos peleamos mal !

Saludos !

[dongustavo]

Hola gentes,

bueno, me llegó:

PIC18F46J50 FS USB PIM DEMO BOARD
PICkit 3 In-Circuit Debugger

Instalé MPLAB IDE y C18.

Ya prendí y apagué un led.

Recuerden que estoy acostumbrado al CodeWarrior (CW) de freescale...

Ahora bien, en CW compilo y tengo debugger en tiempo real donde puedo ver toda la memoria RAM,FLASH,SP, Registros, variables, globales, locales, break points, trace, etc etc etc todo en tiempos real... ¿Cuál es el equivalente en MPLAB IDE? He buscado y no lo he encontrado...

Saludos, Gustavo.

[planeta9999]

Ahora bien, en CW compilo y tengo debugger en tiempo real donde puedo ver toda la memoria RAM,FLASH,SP, Registros, variables, globales, locales, break points, trace, etc etc etc todo en tiempos real... ¿Cuál es el equivalente en MPLAB IDE? He buscado y no lo he encontrado...

Compila el fuente, con la opción "Debug" en vez de la opción "Release", en el desplegable que tienes en la cabecera del MPLAB.
Para conectar el Pickit3 en modo debug, selecciona Debugger > Select Tool > Pickit3.
Los Breakpoints puedes marcarlos y desmarcarlos, pinchando 2 veces sobre la linea.
Las ventanas para ver el estado de variables, memoria, etc.. puedes seleccionarlas desde el menú "View" (Locals, Memory, SFR, Watch, Program Memory).

Durante el proceso de Debug, conviene que no utilices la optimización del compilador o muchas variables no sacarán su valor, aunque sean globales o locales dentro de la función que estas debugeando. Aún así, el mensaje "Out of Scope" es frecuente, en ese caso hay que mirar el valor de una variable por la dirección de memoria que ocupa.

[dongustavo]

Ahora bien, en CW compilo y tengo debugger en tiempo real donde puedo ver toda la memoria RAM,FLASH,SP, Registros, variables, globales, locales, break points, trace, etc etc etc todo en tiempos real... ¿Cuál es el equivalente en MPLAB IDE? He buscado y no lo he encontrado...

Compila el fuente, con la opción "Debug" en vez de la opción "Release", en el desplegable que tienes en la cabecera del MPLAB.
Para conectar el Pickit3 en modo debug, selecciona Debugger > Select Tool > Pickit3.
Los Breakpoints puedes marcarlos y desmarcarlos, pinchando 2 veces sobre la linea.
Las ventanas para ver el estado de variables, memoria, etc.. puedes seleccionarlas desde el menú "View" (Locals, Memory, SFR, Watch, Program Memory).

Durante el proceso de Debug, conviene que no utilices la optimización del compilador o muchas variables no sacarán su valor, aunque sean globales o locales dentro de la función que estas debugeando. Aún así, el mensaje "Out of Scope" es frecuente, en ese caso hay que mirar el valor de una variable por la dirección de memoria que ocupa.

Gracias planeta, ya lo veo... es bastante peor que el CW, pero bueno... es lo que hay

Los que me mató es lo de "el mensaje "Out of Scope" es frecuente": es un debugger "más o menos"?  es un problema general?, no les importa?, es el pickit3? es un problema tipo Homero ("cuando yo llegué ya era asi")...

Efectivamente no me deja ver las variables, tampoco funcionan los break points...

Seguiré investigando.

Saludos, Gustavo.

[planeta9999]

Gracias planeta, ya lo veo... es bastante peor que el CW, pero bueno... es lo que hay

Los que me mató es lo de "el mensaje "Out of Scope" es frecuente": es un debugger "más o menos"?  es un problema general?, no les importa?, es el pickit3? es un problema tipo Homero ("cuando yo llegué ya era asi")...

Efectivamente no me deja ver las variables, tampoco funcionan los break points...
Seguiré investigando.
Saludos, Gustavo.

Yo todavía no he conseguido domar el Debug de Microchip, acostumbrado al Visual Studio que funciona de fábula, lo de Microchip es una auténtica castaña o hay alguna configuración "secreta" que desconozco.

El "Out of Scope" se puede aliviar, evitando compilar el fuente con optimización, los arrays por el motivo que sea siempre se ven, pero las variables son una lotería, yo he tenido que hacer auténticos malabarismos para poder ver algunas variables, como moverlas a otras variables de tipo global dentro de la función, parece absurdo, pero suele funcionar, y en última instancia mirar el listado de la compilación para averiguar la dirección que ocupa una variable y ver directamente el contenido de esa dirección.

Tampoco te guies demasiado por los BreakPoints, llegado a cierto punto, mejor usar el "Paso a paso" para que se visualicen el contenido de las variables, porque el código objeto no aparenta ejecutarse en secuencia con respecto al fuente, si le das al "paso a paso", pega unos saltos bastante absurdos, alante y atrás sobre el fuente, supongo que tendrá que ver con la conversión que hace el compilador de código C a assembler.

[MerLiNz]

los out of scope son por la optimizacion y es bueno que suceda porque si no la optimizacion seria nula ocurre por ejemplo en este caso:

int x;
x=1;
x=50;
while(x==50) {
}

el x=1 lo ELIMINA
el x=50 tambien
y en el  while mientras no exista alguna modificacion de la X lo tomaria como while(1).

Si ponemos un breakpoint en el x=1 por ejemplo nos dara out of scope, esto es porque ese codigo ha sido eliminado, es codigo inutil.

Sobre IDE esta el MPLABX que es bastante mejor que el MPLAB normal.

Planeta9999 declara las variables como volatile y veras que siempre las podras ver, en caso de querer verlas en la memoria en una funcion (no global) usamos el modificador static. Se trata de leer un poco el manual del compilador y no echarle las culpas a este xD
Por ejemplo, no es logico que si utilizamos una variable en una funcion y solo la usamos para hacer un simple calculo se declare esta variable en memoria, para ello se utilizan los registros auxiliares Wx

[dongustavo]

Ah no... hay que leer el manual? jajaja

Interrupciones: he programado el timer0.

Bien, pero eso de que el programa debe chequear el flag de la interrupción...y saltar (un GOTO en C, por dios!) a la función (por todos lados leo "rutina", por dios!) es engorroso.
Osea: la función que atiende la interrupción se ejecuta algunos ciclos después de que efectivamente el contador pasó de 0xffff a 0x0000. Ese delay también depende de cuantas banderas de interrupciones lea y en que orden las leo. ¿Es esto así?

Tengan en cuenta que vengo de freescale.

En freescale, por un lado hay un vector por cada interrupción, la prioridad la da la direccion del vector en memoria. Por otro lado puedo programar el contador para que dispare la int cuando llega a ese número. Eso me deja interrumpir a la frecuencia que quiero y no dependo de un prescaler. Si no entendí mal, con el pic no puedo hacer eso, corríjanme si me equivoco.

Lo que me pareció bueno es la forma de setear el hardware con "#pragma config".

Seguiré actualizado...

Gracias!

[planeta9999]

Planeta9999 declara las variables como volatile y veras que siempre las podras ver, en caso de querer verlas en la memoria en una funcion (no global) usamos el modificador static. Se trata de leer un poco el manual del compilador y no echarle las culpas a este xD
Por ejemplo, no es logico que si utilizamos una variable en una funcion y solo la usamos para hacer un simple calculo se declare esta variable en memoria, para ello se utilizan los registros auxiliares Wx

Probaré lo de static y volatile, aunque yo lo estaba resolviendo bastante bien desactivando la optimización del compilador, salvo en el caso del Bootloader que tenía que estar optimizado obligatoriamente o el objeto se salía del espacio asignado, pisando el comienzo de la aplicación de usuario.

En cuanto a leer manuales, el problema es que cuando uno toca tantos palos, no hay tiempo para tanto, cuando ya dominas algo, sale una versión nueva, o un producto nuevo que tira por tierra casi todo lo aprendido y vuelta a empezar.

Lo de los registros auxiliares Wx, ni idea de a que te refieres, a mi el registro W, solo me suena a ensamblador, tendré que leer los manuales.

[MerLiNz]

El principio es el mismo, lo unico que cambia son las declaraciones, es importante leer el manual porque el tiempo que no pierdes en leerlo lo pierdes luego buscando fallos y problemas, yo cuando empece con los compiladores de microchip el manual siempre lo tenia abierto porque las dudas que me podian surgir, ahora ya no lo necesito (aunque a veces me salen otras dudas y lo tengo que volver a ojear).

Los registros Wx son una zona reservada de RAM para hacer operaciones normales, lo unico que queria decirte es que si por ejemplo pones:

int variable 1, variable2;

void funcion() {
int a;
a=variable1+variable2;
if(a==5) variable1=30;
}

entonces la variable 'a' sera un registro auxiliar, el porque, muy simple, para que vamos a designar una nueva zona de memoria pudiendo usar los registros Wx, asi hacemos nuestra operacion sin tener que utilizar una nueva memoria reservada.

si pones static int a; entonces le estaras diciendo al compilador que 'a' es una variable estatica por lo cual le asignara una memoria determinada a esa variable sin usar los registros Wx. Y con volatile le estas diciendo al compilador que esa variable es necesaria asignarle las operaciones pertinentes sin que lo evite el optimizador. Por ejemplo, todos los registros (PORTA, LATD, .....) son variables volatiles (fijate en la declaracion del pic .h) asi el compilador siempre cambiara el valor independientemente si el optimizador lo determina o no.

[RICHI777]

Hola,

o todavía no he conseguido domar el Debug de Microchip, acostumbrado al Visual Studio que funciona de fábula, lo de Microchip es una auténtica castaña o hay alguna configuración "secreta" que desconozco.

jajaja es tal cual, la gente habla pestes de Windows, pero cuando dejas de usar el debug de Visual Studio te das cuenta que algo bueno hicieron.

Para poder debuggear como dijeron acá, deberías deshabiltar todas las optimizaciones.

Planeta9999 declara las variables como volatile y veras que siempre las podras ver, en caso de querer verlas en la memoria en una funcion (no global) usamos el modificador static. Se trata de leer un poco el manual del compilador y no echarle las culpas a este xD

Lo que decís va en contra de los principios de diseño, el uso de la declaración es justamente para otra cosa, y no es cuestión de leer o no el manual, un buen compilador nunca debe optimizar por registros cuando las optimizaciones son deshabilitadas.

Por ejemplo, no es lógico que si utilizamos una variable en una función y solo la usamos para hacer un simple calculo se declare esta variable en memoria, para ello se utilizan los registros auxiliares Wx

El C nacio para independizarte en la medida que pueda de la arquitectura del micro, podes usar cosas de esas, ahora si, olvidate de una buena migración. Si lees el inicio del post Don Gustavo esta migrando código C de un FreeScale a un MicroChip, no le va a costar tanto porque justamente escribió casi todo en C.

Saludos !