de Freescale 8bits a PIC32...

[MGLSOFT]

A esto te referis ??

http://en.wikipedia.org/wiki/Wrapper_library

[MerLiNz]

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]

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!

[MGLSOFT]

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...

[RICHI777]

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 !

[RICHI777]

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 !

[RICHI777]

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 !

[dongustavo]

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.

[MGLSOFT]

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.

[dongustavo]

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.

[MerLiNz]

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.

[dongustavo]

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!

[MGLSOFT]

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.

[MerLiNz]

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.

[dongustavo]

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.