TODOPIC
Microcontroladores PIC => Pic32 => Mensaje iniciado por: dongustavo en 09 de Abril de 2013, 15:16:58
-
Hola a todos,
les comento, uso micros de freescale desde siempre. Tengo el problema del ruido eléctrico en mis aplicaciones (KART, autos de competición) que me resetean los micros y ya me casó...
Hablando con un autopartista me dijo que migraron de freescale a PIC por ese problema y, no se lo voy a discutir, voy a hacer lo mismo.
Bien, esto es un mundo nuevo y la verdad no se bien por donde entrar.
Viendo la web de microchip, me interesé en los micros de 32bits PIC32, parecen que sobran para lo que necesito, por lo que prefiero juntar experiencia entrando por ahí, pagando de más tal vez y con el tiempo usar otros que maximicen la relación costo/beneficio.
Queriendo hacer el pase lo menos traumático posible:
Herramientas de desarrollo, la MPLAB ICD 3 parece una buena opción, necesito varios breakpoints y los tiene.
La gran duda que no termino de entender es con qué compilador puedo programar en C y que sea perecido al Codewarrior que uso para freescale.
En la web ofrecen el MPLAB C Compiler for PIC32 MCUs, le doy "Buy it now" y sale 895U$S!!! Además hay opciones y versiones y upgrades... que meten miedo.
Con freescale y codewarrior antes de programar ya se cuanta flash voy a usar, cuanta ram, etc, pero esto es nuevo para mí y no tengo ni idea.
Los compiladores de linea de comando son insoportables, tampoco se si hay para PIC...
En definitiva, si me pueden guiar un poco en el tema, se agradece y ya me verán pasar seguido por acá.
Saludos, Gustavo.
-
Herramientas de desarrollo, la MPLAB ICD 3 parece una buena opción, necesito varios breakpoints y los tiene.
Yo utilizo Pickit3 por ICSP, y va perfecto, tanto para programar, como para Debug, tiene la función Standalone, que permite programar el PIC sin necesidad de usar el PC, muy interesante para programar pequeñas tiradas de placas con el mismo HEX.
La gran duda que no termino de entender es con qué compilador puedo programar en C y que sea perecido al Codewarrior que uso para freescale.
En la web ofrecen el MPLAB C Compiler for PIC32 MCUs, le doy "Buy it now" y sale 895U$S!!! Además hay opciones y versiones y upgrades... que meten miedo.
C32 v2.2 de Microchip va muy bien, lo puedes usar desde MPLAB o MPLABX, y en "la mula" está muy "barato".
En cuanto a XC32, demasiado caro para mi, y no creo que aporte nada sobre C32 que merezca el "desembolso adicional", se comentaba que soportaría C++, no se que hay de cierto.
-
segun tengo entendido los freescale son mas inmunes al ruido que los pics, son utilizados en mayor parte por los fabricantes de automovil (freescale), los pics aun no he visto ninguno. De todas formas el problema de ruidos suele ser mas problema del diseño que de los mcu's, en caso de ruidos por bobinas como suele ser en un kart es importante meter el circuito en una caja metalica conectada a masa y retirar la unidad de las posibles fuentes de ruido (bobina/alternador).
Para los pics tienes lo siguiente:
MPLAB X: este es el ide grafico para tu proyecto
XC32: compilador para pics32, lo puedes usar en modo prueba optimizado de 1 mes, o bien en modo "free" que no optimiza tanto el codigo.
-
segun tengo entendido los freescale son mas inmunes al ruido que los pics, son utilizados en mayor parte por los fabricantes de automovil (freescale), los pics aun no he visto ninguno. De todas formas el problema de ruidos suele ser mas problema del diseño que de los mcu's
+1
Otro IDE/Compilador a utilizar puede ser el de Mikroelektronika.
Saludos!
-
Bueno, gracias por las respuestas!
sin irme del tema, lo del la jaula de faraday para las aplicaciones, es relativo, en cuanto ponés un display abrís un ventana (literalmente) al ruido. Los fabricantes con recursos (Italia, Inglaterra, Australia), usan gabinetes plásticos inyectados con un compuesto de carbón y no se qué más que los hace inmunes al ruido en cierto rango de frecuencias, en el display ponen un plástico transparente también conductor... acá en Argentina eso es imposible.
La gente que consulté hace toda la electrónica automotriz para las terminales argentinas (peugueot, fiat, renault, citroen, etc). No la ECU, sino todos los sistemas de control de ventanas, alarmas, detector de lluvia, cierre centralizado, luces, etc.
He desarmado varios tacómetros de competición y ... tienen PIC.
He probado con micros LPC y fallan.
De Freescale he usado varios de varias tecnologías, con y sin oscilador interno y han fallado.
He implementado desde el diseño todo lo que recomiendan, pero todo todo, mejoró, pero falla de vez en cuando.
En los autos, el problema es el par PLATINO/DISTRIBUIDOR sobre todo, pero se le suma: cables de bujía no-antiparasitarios, altas RPM, mala distribución de las masas, bobinas de competición (80000 a 120000V) y aveces la bobina está en el habitáculo!
Pero bueno, gracias de todos modos.
Saludos!
Gustavo.
-
Abalo lo del mal diseño, pero esto al revés ya se trato antes, que los PICs no se usan en el área industrial, y eso es simplemente una burda mentira.
Tal como decís, los vi puestos en miles de cosas que trabajan dia y noche en ambientes de alto ruido eléctrico, encima esto es Argentina, donde no hay legislación al respecto, al punto que las mismas fabricas de inverters que en Europa ponen filtros EMI en sus inverters, aquí los venden sin ni siquiera avisar que no los tienen.
Lo que no se es si necesitas pasarte al PIC32 de una, no se si te habrán dicho, pero esa arquitectura es diferente totalmente a la de 8 y 16 bits.
Yo estoy usando ahora PIC24 y me enamore, ademas la linea PIC18 es fantástica también, no le tienen envidia a ninguna marca, por otro lado encontraras en estas dos lineas PIC específicamente diseñados para algunas aplicaciones en especial.
Yo te sugiero que mires bien esas dos lineas, porque luego en el foro vas a consultar y no hay mucha gente que ya lo trabaja aquí, por lo tanto tendrás pocas respuestas a tu consulta, mientras en las lineas de 8 y 16 bits, vas a tener medio foro leyéndote y varios miles en capacidad de ayudarte.
Aprovecha esa ventaja de los PICs, que la cantidad de información, notas de aplicación oficiales, y material gratuito es muy abundante...
-
Yo ya te digo, problemas de ruidos tendras tanto en pic, como freescale, ti.... El problema no son los MCUs sino los diseños, filtrados, apantallamiento... La mayoria usan pics porque son lo mas sencillo, lo que hay mas documentacion, miles de tutoriales... sin embargo, hablando de MCUs suministrados para automocion en el mercado de 2011 freescale tiene el 21% del mercado, y el mayoritario renesas con un 42%, microchip nisiquiera aparece en el listado, esta en el grupo de otros (9%). Sin contar que por ejemplo freescale tiene integrados dedicados unicamente a la automocion (serie MC33*) para el control de bobinas, actuadores, sensores, mcus... Al contrario que microchip que no tiene nada dedicado a la automocion, en su catalogo solo incluyen 3-4 diseños pero nada dedicado.
-
Nada pierdes probando algo con PIC. Como dice MGLSOFT yo tambien te recomiendo un PIC18 o PIC24, creo que se serán de sobra. Comentanos. Exitos.
-
En el trabajo usamos PIC18 en equipos para leer datos de buses de tractocamiones y han aguantado bastante bien, se está pensando pasar a PIC32, pero también tengo la duda de si estarán mejor preparados los de Freescale para este tipo de aplicaciones, así que me mantengo atento a sus comentarios al respecto :).
-
Me interesa saber porque están pensando pasarse a PIC32 Geo. Tal vez por necesidad de mayor velocidad u otra cosa en especial?
-
Hola,
en una aplicación automotriz típica, el principal problema es el ruido inducido a travez de la fuente de alimentación. El alternador suele generar picos de 60 a 80V, sumados al ruido de las chipa.
En un auto de competición no hay alternador, el ruido es inducido (EMF) además de las altas frecuencias a alta potencia de las bujiías.
Gente, muchas gracias, voy a considerar lo de la familia PIC18. Una cosa que me llamó la atención es que en MOUSER.COM hay modelos de PIC18 con 11semanas de plazo de entrega...
Saludos, Gustavo.
-
Depende de que auto de competicion, porque desde un F1 hasta un nascar llevan alternador, ni estos generan picos tan altos, mas que nada porque la electronica no lo soporta y mucho menos en automoviles nuevos que estos son mas delicados en estos temas. El ruido de unas bobinas no es problema, si lo fuese los automoviles no llevarian electronica y no es asi, es mas, pones hasta aparatos "chinos" de mala calidad y mal diseño y funcionan sin problemas, asi que poniendole un poco mas de empeño no habria ningun problema.
Que un automovil este potenciado no quiere decir que tengas que triplicar el voltaje en las bobinas, conozco autos de 170cv puestos a 300cv y 500cv y las bobinas son las originales, solo se de un caso que lo puso a 800cv y le tuvo que cambiar las bobinas, pero tampoco son unas bobinas (segun el fabricante un 20% mas) del otro mundo, lo importante es que el arco salte siempre.
En fin, no le voy a dar mas vueltas al tema, solo te digo que tendras los mismos problemas con microchip que con freescale y mucho mas si pasas de 8bits a 32bits, mas que nada porque los pics de 32bits son mucho mas delicados con el ruido, sobretodo a grandes frecuencias, yo he probado a poner un dspic33e a mas de 40mips en una protoboard y se reiniciaba constantemente o no arrancaba, sin embargo un pic18 a 48mhz no me ha dado nunca problemas.
Sobre los plazos de entregas de mouser es porque quizas estas buscando un pic18 que no es comun, que esta descatalogado, o que es nuevo, lo normal es que en stock tengan solo los que mas venden.
-
Me interesa saber porque están pensando pasarse a PIC32 Geo. Tal vez por necesidad de mayor velocidad u otra cosa en especial?
El diseño actual utiliza tres microcontroladores, la idea es migrar a uno solo que tenga la suficiente potencia para manejar todo.
-
Me interesa saber porque están pensando pasarse a PIC32 Geo. Tal vez por necesidad de mayor velocidad u otra cosa en especial?
El diseño actual utiliza tres microcontroladores, la idea es migrar a uno solo que tenga la suficiente potencia para manejar todo.
Ah, que interesante. Y podrías decirnos que función cumple cada MCU? Todos son 18F?
Saludos.
-
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 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!
-
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.
-
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!
-
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 :D :D :D
Saludos !
-
A RICHI cuando entro, le sentimos el olor a Chotorola ahi al toque !! :D :D :D
Despues con el tiempo le fuimos tomando cariño, y ahora le perdonamos su equivocacion !!! :D :D :D :D
-
A RICHI cuando entro, le sentimos el olor a Chotorola ahi al toque !! :D :D :D
Despues con el tiempo le fuimos tomando cariño, y ahora le perdonamos su equivocacion !!! :D :D :D :D
jajajaja siiii es mas con vos nos peleamos mal !
Saludos !
-
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.
-
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.
-
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.
-
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.
-
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
-
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 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.
-
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.
-
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 !
-
Me olvide ... Gustavo todos los IDE, debuggers, etc para embebidos son una porquería, están a años luz de MicroSoft ... El debugger del CodeWarrior era otra porqueria ...
Saludos !
-
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 !
Para hacer un buen Debug, hay que ser expertos en Bugs!! :D :D :D :D
-
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 !
No es una optimizacion el hacer operaciones por registros, es lo normal, la optimizacion es algo distinto en el caso de los compiladores de microchip, siempre puedes ver el codigo asm con optimizacion y sin optimizacion, en ambos modos se utilizan los registros Wx.
Si no leemos el manual y cogemos un poco la idea entonces vamos dando palos de ciego, yo lo veo cuestion de leer el manual, porque yo he aprendido con el manual delante, cuando migre a C30 me ocurrio lo mismo, tuve que leer el manual porque muchas cosas eran distintas al C18 si no hubiese leido el manual aun estaria descubriendo como funcionan las interrupciones en el C30...
El C y el C para MCU solo se parece en lo basico, migrar de freescale a microchip no es tan sencillo, ambos compiladores no utilizan la misma sintaxis para muchas funciones y si ya hablamos de librerias menos aun, los registros son distintos y la forma de usarlos tambien son distintos.
-
ok, respeto tu opinión pero no es lo que yo pienso.
Saludos !
-
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 !
+1 Si es una aplicación donde se requiera optimizar para el recurso que se usa si se puede pensar en eso, sino hay que hacerlo lo mas estándar posible para una posible futura migración, sino vas a tener que re-escribir todo :x
Saludos!
-
ok, respeto tu opinión pero no es lo que yo pienso.
Saludos !
No es una opinion, es una realidad, te voy a poner ejemplos y ya me dices si tengo o no razon:
-Usar una UART en pic, es igual que en freescale??
-Interrupciones en freescale igual que en microchip?
-Registros de puertos PORTx... en pic es igual que en freescale?
-Configuracion no tiene nada que ver en pic con freescale
-Perifericos (timers, ccp...) no son iguales en pic que freescale
Yo no creo que sea tan facil migrar de freescale a pic, las funciones serviran todas, pero, el procedimiento sera distinto cuando hablamos de un codigo especifico para freescale a uno para pic.
-
Gracias Suky !!!, voy a contestar un poco mas, hoy x hoy con los cambios de tecnología que se vienen, siempre es recomendable escribir en C plano, obvio que las cosas de hardware o arquitectura tiene que ser resueltas para cada micro. Hay info en le web sobre como construir un HAL ( Hardware Abtsraction layer ) lo que significa es hacer una serie de funciones que maneje todas las particularidades de la arquitectura. Cuando cambias de micro solo re escribís esta parte del código y tenes el problema resuelto.
Saludos !
-
Por supuesto, para mediar, ya que están hablando de lo mismo con palabras diferentes, lo que están diciendo ambos es que Hay que conocer la arquitectura y los detalles para poder migrar código de uno a otro micro. :mrgreen:
-
Hola MGLSOFT, si eso es así. Ejemplo de lo que digo, Uart, tendrás funciones como open, close, write, read, etc. Esas son las que tenes que rescribir, código de mas alto nivel terminan llamando a estas "primitivas" y eso no cambia. Algunos consejos para escribir código migrable.
- Casteos
- Padding en la estructuras o uniones
- Alineación
- Precedencia de operadores
- Tamaño de los tipos de datos canónicos
Saludos !
-
Puedes citar links de esa info??
O donde encontrar literatura??
esta interesante...
-
Dame tiempo, muchas cosas fueron a pulmón, por favor respeto muchisimo a este foro y no quiero generar malos pensamientos, pero hace casi 20 años que lidio con estos problemas...
Saludos !
-
:shock: :shock: :shock: :shock: :huh: :huh: :huh: :z) :z) :z)
-
:shock: :shock: :shock: :shock: :huh: :huh: :huh: :z) :z) :z)
siii mal que me pese soy un viejo de mierda ....
Saludos !
-
RICHI eso seria usando librerias y que las librerias fuesen iguales para ambos mcus pero esto no es asi, microchip pone sus librerias y el orden de los operadores puede cambiar, incluso el nombre de las funciones por lo cual ya tenemos que cambiar el nombre y orden de operadores. Ahora bien cuando nosotros hacemos el codigo, por ejemplo un PWM, CCP, TIMER... o algo asi no utilizamos libreria alguna yo por ejemplo no utilizo ninguna libreria para mis proyectos utilizo mis propias funciones adaptadas a mi proyecto, entonces al ser asi no podria migrar las funciones tal y cual, tendria que reescribir el codigo especifico para este hardware.
Entiendo como quieres enfocar la situacion, pero resulta que no es solo cuestion de cambiar de pic y ya esta, ni tampoco nadie hace un codigo generico que se pueda migrar entre fabricantes, porque requiere mas tiempo hacer esto que hacerlo para un unico hardware. Microchip por ejemplo hace placas de entrenamiento para distintos pics y estos codigos son migrables entre pics sin problema, aun asi no es del todo tan sencillo aunque ellos nos lo pongan asi, han tenido que cambiar funciones entre pics para hacerlo de tal forma y eso les ha costado el doble de tiempo.
-
No voy a discutir con vos ... lee un poco del concepto llamado "wrappers"
Saludos !
-
A esto te referis ??
http://en.wikipedia.org/wiki/Wrapper_library (http://en.wikipedia.org/wiki/Wrapper_library)
-
Esto no es una discusion que yo sepa, otra cosa distinta es que no quieras darme la razon y eludas la conversacion con otros terminos que no tiene nada que ver a lo que yo me he referido. Aun asi si tu dices que migrar de freescale a microchip es tan simple como hacer un click suerte con tu aventura... A ver si a dongustavo le resulta igual de facil migrar un proyecto como tu estas exponiendo aqui.
-
Esto no es una discusion que yo sepa, otra cosa distinta es que no quieras darme la razon y eludas la conversacion con otros terminos que no tiene nada que ver a lo que yo me he referido. Aun asi si tu dices que migrar de freescale a microchip es tan simple como hacer un click suerte con tu aventura... A ver si a dongustavo le resulta igual de facil migrar un proyecto como tu estas exponiendo aqui.
DonGustavo tiene una sola premisa: "que funcione". Sí, soy un mercenario jejeje.
Me refiero a que si funciona el punto está logrado. Si el código es ANSI C, ASM, c+- o lo que fuere o si ahorra o no memoria o si es lindo o feo o elegante.. pasa a segundo plano.
Ahora si trabajás en una empresa y tenés que hacerlo como dice richard porque así te lo exigen o porque filosóficamente te apegás a esa forma de trabajo, está perfecto.
Son diferentes formas de trabajar. La mía es extremadamente pragmática: que primero funcione y después, si hay tiempo vemos porqué salió andando.
Con respecto a la otimización del código: que funcione, con o sin optimización. Si funciona, listo. Si entra en la flash, es lo que quiero. Si usa más o menos flash o ram... no me importa, es más ni me lo pregunto. Anda?, a otra cosa.
O sea: "palos y a la bolsa".
Saludos!
-
Ja, ja !!
Entonces encajas con el CCS !!
Puedes usarlo dentro del IDE de Mplab y programar y haacer debug con las herramientas que ya tienes... ;-)
-
a mía es extremadamente pragmática: que primero funcione y después, si hay tiempo vemos porqué salió andando.
jajajaja me mato esa frase !!!
Coincido con MGLSOFT sos el usuario ideal para CCS es más si pienso un poco podrías usar Niple.
A esto te referis ??
http://en.wikipedia.org/wiki/Wrapper_library
Si, bastante bien explicado el concepto.
Saludos !
-
Esto no es una discusion que yo sepa, otra cosa distinta es que no quieras darme la razon y eludas la conversacion con otros terminos que no tiene nada que ver a lo que yo me he referido. Aun asi si tu dices que migrar de freescale a microchip es tan simple como hacer un click suerte con tu aventura... A ver si a dongustavo le resulta igual de facil migrar un proyecto como tu estas exponiendo aqui.
No te enojes, solamente es que pienso diferente y nunca nos pondríamos de acuerdo. Tampoco digo que sea tan fácil como hacer un click
Saludos !
-
Igual Gustavo es medio jodido ser así, trasladado al termino de mujeres le entrarías a lo que sea ... hasta a un pobre bombero quemado ... jajajaja !!!
Perdón por el off-topic !!!
Saludos !
-
Igual Gustavo es medio jodido ser así, trasladado al termino de mujeres le entrarías a lo que sea ... hasta a un pobre bombero quemado ... jajajaja !!!
Perdón por el off-topic !!!
Saludos !
No no richard, ahí no se aplica el pensamiento lateral...
------------------------------------------------------------------------------
Copio unas dudas:
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í?
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.
Saludos, Gustavo.
-
No, no, entendiste o leiste mal.
No tenes que chequear el bit, sino para que la interrupcion.
Te lleva directamente al codigo que programaste para cada interrupcion, y alli si depues de hacer lo tuyo, debes borrar el flag de esa interrupcion.
-
No, no, entendiste o leiste mal.
No tenes que chequear el bit, sino para que la interrupcion.
Te lleva directamente al codigo que programaste para cada interrupcion, y alli si depues de hacer lo tuyo, debes borrar el flag de esa interrupcion.
Ok ok. Si, entiendo que el vector tiene un goto a la funcion de atención de la interrupción. Pero esa función debe "ver" qué fuente de interrupción habilitada fue la que disparó la interrupción, ahora, si no entendí mal, debo ver uno por uno qué flag de interrupción fue la que la disparó... se entiende?
Osea:
Supongamos, programo 2 interrupciones de alta prioridad.
1-Entra la INT.
2-Salta a la función que atiende las interrupciones.
3-Leo cual de las dos fue la que interrumpió, leyendo el flag correspondiente y lo bajo.
4-Llamo a la función que hace lo que tiene que hacer para esa interrupción.
5-retorno.
Es decir: desde que se generó la INT, hasta el punto 4 hay un delay para determinar cuál fue la fuente de interrupción.
Eso es lo que entendí.
Saludos, Gustavo.
-
El paso 4 esta mal hecho, no debes llamar a una funcion dentro de una interrupcion, lo normal es atenderla en la misma funcion de la interrupcion, se puede hacer como dices, pero seria mas lento, ademas de tener que salvar mas datos para evitar luego corrupcion en los registros, vamos que bien hecho seria hacerlo directamente dentro de la misma interrupcion.
-
El paso 4 esta mal hecho, no debes llamar a una funcion dentro de una interrupcion, lo normal es atenderla en la misma funcion de la interrupcion, se puede hacer como dices, pero seria mas lento, ademas de tener que salvar mas datos para evitar luego corrupcion en los registros, vamos que bien hecho seria hacerlo directamente dentro de la misma interrupcion.
Si, el punto 4 es como decís vos, esta bien.
Pregunto estas cosas para ir planeando el programa, supongo que ese delay es despreciable serán unos pocos uS o ni eso.
Por ejemplo tengo una aplicación que lee por interrupciones la entrada de un GPS vía UART. Ahora lo que tengo es una INT que mete en una cola los caracteres hasta recibir un \n.
Saludos!
-
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.
No es asi.
Varios timer pueden generar interrupciones muy precisas, segun un tiempo programado.
yo hago mi motor de tiempos en base a una interrupcion del timer 2 (que esta en casi todos los pics y es de 16 bits), como la uso de proposito general hago que interrumpa cada 1000 microsegundos, o lo que es lo mismo, cada 1 milisegundo.
Con esta base de tiempo, la rutina de interrupcion es solo un incrementador de 3 o 4 contadores, que uso en diferentes rutinas, ya ademas compara contra un preset o base de tiempo, marcando flags diferentes, segun sea la cuenta superada.
Luego en el main(), leo esos flags y ejecuto las acciones segun una temporizacion deseada, ya que el maximo error sera de 1 milisegundo.
-
El paso 4 esta mal hecho, no debes llamar a una funcion dentro de una interrupcion, lo normal es atenderla en la misma funcion de la interrupcion, se puede hacer como dices, pero seria mas lento, ademas de tener que salvar mas datos para evitar luego corrupcion en los registros, vamos que bien hecho seria hacerlo directamente dentro de la misma interrupcion.
Si, el punto 4 es como decís vos, esta bien.
Pregunto estas cosas para ir planeando el programa, supongo que ese delay es despreciable serán unos pocos uS o ni eso.
Por ejemplo tengo una aplicación que lee por interrupciones la entrada de un GPS vía UART. Ahora lo que tengo es una INT que mete en una cola los caracteres hasta recibir un \n.
Saludos!
Es mejor hacer las cosas desde un principio bien y asi nunca tendras problemas, las interrupciones deben ser lo mas pequeñas posibles, nada de hacer divisiones dentro, multiplicaciones ni cosas complejas, ni mucho menos llamar funciones, te pongo un ejemplo para que me comprendas:
-Imagina que en el main tienes una division y justo interrumpe una interrupcion a mitad de la division, si en la interrupcion haces una division los datos de la division del main se corrompen ya que pisas los registros que estabas haciendo en la anterior division. Para evitar esto lo que se hace es guardar los datos de la division (memoria math) en una memoria para ello, y una vez acaba la interrupcion se restauran los datos (todo esto se traduciria en interrupciones con mas lag y mas largas). Muchos compiladores lo hacen automaticamente cuando ven una division dentro (existen mas posibilidades de corromper datos, como llamar a una funcion dentro de una interrupcion) pero el de microchip no lo hace asi, para ello debes decirle que salvar (en el manual del C18 viene explicado) habia que ponerle un atributo a la interrupcion.
Esto te lo digo porque debes tener mucho ojo, a veces te vuelves locos con datos extraños que no sabes de donde salen y resulta ser por tonterias aleatorias de este estilo, por eso como te indico lo mejor es evitar hacer cualquier operacion compleja en la interrupcion.
Si te explico esto es porque no se si en freescale esto ocurria y no se si lo sabias.
-
OK.
A medida que vaya usando el micro voy a ir leyendo el manual. Ví lo de salvar los registros pero no lo entendí muy bien, es mucho todo junto...
En Freescale los timers se ejecutan como si "fueran otro CPU". Es decir, interrumpe luego de ejecutar un intrucción, hace un guarda los registros en el stack.
Pero el concepto es ese : otra cpu.
Saludos, Gustavo.
-
Hola Gustavo, te resumo un poco. Diferentes arquitecturas poseen diferentes estrategias con respecto a las interrupciones. Vos sabes bien que en los FreeScale cuando una interrupcion es disparada, el micro automaticamente guarda en el stack todos todos los registros, en el caso del S08 por una cuestión de compatibilida para atras, el único que no se guarda es el HX. Al contrario la linea 8051 únicamente guardaba el contador de programa y el registro de estado. Si vos ibas a usar otro registo dentro del handler es tu responsabilidad pushearlo y popearlo. Probablemente en el caso MicroChip se este último. Después se puede discutir que es mejor o que es peor, algo similar pasa con el tema del endian. Normalmente cuando trabajas en un compilador C, este define la estrategia a utilizar, algunos son bastante inteligentes y pueden detectar que cuando se usan funciones dentro del handler automáticamente pushean y popean todo. Con respecto a lo comentas del timer no es que haya otra CPU, sino que justamente todos los registros son preservados y restaurados a la salida del handler, esto es para que no provoque discrepancias en el programa principal.
Saludos !
-
Hola Gustavo, te resumo un poco. Diferentes arquitecturas poseen diferentes estrategias con respecto a las interrupciones. Vos sabes bien que en los FreeScale cuando una interrupcion es disparada, el micro automaticamente guarda en el stack todos todos los registros, en el caso del S08 por una cuestión de compatibilida para atras, el único que no se guarda es el HX. Al contrario la linea 8051 únicamente guardaba el contador de programa y el registro de estado. Si vos ibas a usar otro registo dentro del handler es tu responsabilidad pushearlo y popearlo. Probablemente en el caso MicroChip se este último. Después se puede discutir que es mejor o que es peor, algo similar pasa con el tema del endian. Normalmente cuando trabajas en un compilador C, este define la estrategia a utilizar, algunos son bastante inteligentes y pueden detectar que cuando se usan funciones dentro del handler automáticamente pushean y popean todo. Con respecto a lo comentas del timer no es que haya otra CPU, sino que justamente todos los registros son preservados y restaurados a la salida del handler, esto es para que provoque discrepancias en el programa principal.
Saludos !
Me hiciste acordar de un cartel tamaño A4 que tenía pegado al lado de la PC "en INT guardar HX"... Sí guarda el X, no el H.
Sabés que se me pasó ese detalle...xD... a revisar todo jajaja. Me quiero matarrrrrr...
saludos!
-
Igual fijate si no existe alguna palabra reservada del compilador que lo haga por vos, normalmente la palabra interrupt, __interrupt o algo parecido hacen eso, como no es algo que el ANSI C soporte cada compilador le da el uso que quiere.
Saludos !
-
Yo desde que probe un dspic no quiero otra cosa, son bastante mas sencillos de manejar, las interrupciones van por vectores, se puede hacer un guardado rapido usando los registros shadow... Desde que los llevo usando me han parecido mas complicados los pic12...pic18 que los dspic.
-
Yo desde que probe un dspic no quiero otra cosa, son bastante mas sencillos de manejar, las interrupciones van por vectores, se puede hacer un guardado rapido usando los registros shadow... Desde que los llevo usando me han parecido mas complicados los pic12...pic18 que los dspic.
Al igual que los PIC24, tienen características similares, salvo claro el DSP.
Saludos!
-
Yo desde que probe un dspic no quiero otra cosa, son bastante mas sencillos de manejar, las interrupciones van por vectores, se puede hacer un guardado rapido usando los registros shadow... Desde que los llevo usando me han parecido mas complicados los pic12...pic18 que los dspic.
Al igual que los PIC24, tienen características similares, salvo claro el DSP.
Saludos!
Dejemoslo en la familia de 16bits ;-)
-
Hola MerLinz,
Yo desde que probe un dspic no quiero otra cosa, son bastante mas sencillos de manejar, las interrupciones van por vectores, se puede hacer un guardado rapido usando los registros shadow... Desde que los llevo usando me han parecido mas complicados los pic12...pic18 que los dspic.
Lo de los registros shadow es algo similar a registros alternativos ? Te comento esot porque algunas arquitecturas tienen esta caracteristica, los registros del micro estan replicados en una serie de bancos 1,2,4, etc. Cuando ingresas en una interrupcion lo único que haces switchear el banco, de esta manera te ahorras todo el proceso de pusheo y popeo.
Saludos !
-
Hola MerLinz,
Yo desde que probe un dspic no quiero otra cosa, son bastante mas sencillos de manejar, las interrupciones van por vectores, se puede hacer un guardado rapido usando los registros shadow... Desde que los llevo usando me han parecido mas complicados los pic12...pic18 que los dspic.
Lo de los registros shadow es algo similar a registros alternativos ? Te comento esot porque algunas arquitecturas tienen esta caracteristica, los registros del micro estan replicados en una serie de bancos 1,2,4, etc. Cuando ingresas en una interrupcion lo único que haces switchear el banco, de esta manera te ahorras todo el proceso de pusheo y popeo.
Saludos !
Los dspic no usan "bancos" :D
El registro es asi de simple: push.s y pop.s y lo que haces es guardar los principales registros W0->W3 y STATUS (ahora mismo no caigo en cuenta si se guarda algo mas), es decir, con una simple instruccion guardas los principales registros y con otra instruccion los restauras. La ventaja es esa, poco lag en la interrupcion, creo que variaba unos 7Tcy o algo asi cuando estuve trasteando con el simulador.
-
Oka, gracias por la respuesta !
Saludos !
-
Hola, como están?
Bueno pude hacer algo con el PIC:
-Parpadear un LED con varios timers
-Leer teclado
-controlar un display NOKIA5110 (SPI)
Uso el micro a 24MHz, con un cristal de 4MHz
Ahora bien, lo que no me entra en la cabeza es que no pueda hacer un timer de 1mS+- un ciclo.... No más o menos 1mS, sino 1mS a secas.
Usé el time de 8 bits con pre y post scaler y con ese registro de comparacion y siempre le falta o le sobra algo... ya desde la tabla de excel.
Tengo que hacer un cronómetro que cuente milisegundos y que el error en 2 minutos no supere el milisegundo.
Saludos, Gustavo.
-
porque no usas un timer de 16bits y lo pones a 24000? Es justo 1ms aun asi siempre hay unos Tcy de lag hasta que llega a la interrupcion y tambien hasta que llega a la funcion, es algo que lo debes calcular y tener en cuenta
-
OK, gracias...
hice eso, o algo parecido, porque lo que hay que cargar es 0xFFFF-el valor, ya que el contador es incremental.
if (PIR1bits.TMR1IF)
{ //check for TMR1 overflow
PIR1bits.TMR1IF = 0; //clear interrupt flag
WriteTimer1(value);
LATEbits.LATE0 = !LATEbits.LATE0; //toggle PIN
}
Como debug, el valor lo modifico en el main.
WriteTimer1 sale de timers.h
De todas maneras, esto es un timer como los de Motorola U3 o R3 del año 1985... un mamarracho (opinión totalmente subjetiva, por supuesto...).
Por supuesto siempre hay una solución.
-----------------------------------------------------------------------------------------------
Otra consulta con respecto al IDE:
Estoy usando el MPLAB X IDE, el compilador es el C18.
Hay alguna manera de ver variables o registros (por ej. el TMR1) sin tener que pausar la ejecución? Osea que se refresque el valor por ejemplo cada 100mS o cuando varía...
Pongo watchs pero se refrescan sólo pauso, lo mismo con los registros.
Saludos, Gustavo.
-
OK, gracias...
hice eso, o algo parecido, porque lo que hay que cargar es 0xFFFF-el valor, ya que el contador es incremental.
if (PIR1bits.TMR1IF)
{ //check for TMR1 overflow
PIR1bits.TMR1IF = 0; //clear interrupt flag
WriteTimer1(value);
LATEbits.LATE0 = !LATEbits.LATE0; //toggle PIN
}
Como debug, el valor lo modifico en el main.
WriteTimer1 sale de timers.h
De todas maneras, esto es un timer como los de Motorola U3 o R3 del año 1985... un mamarracho (opinión totalmente subjetiva, por supuesto...).
Por supuesto siempre hay una solución.
-----------------------------------------------------------------------------------------------
Otra consulta con respecto al IDE:
Estoy usando el MPLAB X IDE, el compilador es el C18.
Hay alguna manera de ver variables o registros (por ej. el TMR1) sin tener que pausar la ejecución? Osea que se refresque el valor por ejemplo cada 100mS o cuando varía...
Pongo watchs pero se refrescan sólo pauso, lo mismo con los registros.
Saludos, Gustavo.
Perdón la segunda pregunta ya la había planteado... con el PICKIT 3 no se puede...
Saludos!
-
Hola,
bueno actualizo cómo me fue con el PIC18f46j50:
Hice en cronómetro con un display NOKIA 5110 (SPI), 4 botones, todo montado de la peor manera con respecto a la EMI...
Puse en crototipo al lado de mi simulador de chispa de bujías (con bobina de competición 95000V@22000RPM!)
Como soy jodido, enrrosqué el PIC con el cable de HV jejeje Y NO SE COLGÓ. El display si se fue a la mierda, pero el PIC siguió corriendo.
Saludos, Gustavo.
-
jajajajaa !!!! Te felicito !!! Igual ya te dije que sos un kamikaze !!!!
Saludos !
-
Jajaj que interesantes pruebas... Te va de sobra con el pic que estas usando para tu aplicación? O piensas migrar a los pic24?
-
Mi primera placa, la puse a andar al lado de un inverter Hitachi muyyy viejo, alimentada su fuente de la misma linea, y sin el Watchdog activado.
Nunca se colgo !! :D :D :D
Tenia un temido PIC16F84 !! :D :D :D
-
Mi primera placa, la puse a andar al lado de un inverter Hitachi muyyy viejo, alimentada su fuente de la misma linea, y sin el Watchdog activado.
Nunca se colgo !! :D :D :D
Tenia un temido PIC16F84 !! :D :D :D
jajajaja vos sos un 840 de los PICS :P