Curso de programación en C para microcontroladores PIC

D@rkbytes

Moderador
Con respecto al compilador XC8 (Uso MPLAB como entorno de desarrollo)es una versión actual ya que lo volví a descargar desde la página de Microchip hace 1 mes , es la versión actualizada que está en su página oficial
Por eso te digo, MPLAB ya es obsoleto, Microchip ya no da soporte desde hace algunos años, la última versión fue la 8.92.
Ahora el entorno usado (IDE) es MPLABX, pero eso no es lo importante, sino la versión de ToolSuite, que para esta fecha es XC8 v2.10
Para el uso de interrupciones puedo escribirlo por ejemplo como INTCONbits.GIE=1 asi como GIE=1 igual me lo permite así como colocar dentro del __delay_ms () una variable.
No me refiero a eso, sino a la sintaxis actual.
En XC8 v2.10 el servicio de interrupciones ya no es soportado como se hacía antes: "void interrupt nombre_x (void)"
Ahora debe ser algo así: "void __interrupt () nombre_x (void)"
Si compilo tu programa con la versión actual esto es lo que sucederá:
Error 1 (Servicio de interrupciones).jpg
Entonces tendría que solucionarlo cambiando la sintaxis por la actual.

Y lo mismo pasaría con __delay_ms() como lo mencioné...
Error 2 (__delay_ms()).jpg
Esto lo resolvería creando una función similar pero que sí me acepte variables como parámetro.
¿Qué versión de compilador usas?
MPLABX v5.30 con XC8 v 2.10
¿Usas MPLAB para programar en C?
No, el MPLAB solo lo uso para programar en ensamblador.

Y aunque MPLAB y MLABX soporten plugins para trabajar con otros compiladores, prefiero usar el IDE del creador.
No me gustan las cosas complicadas para llegar a un mismo fin, por eso mi compilador favorito es PIC C Compiler de CCS
 
Saludos, tengo una pregunta.

Es el lenguage C el mejor lenguange de programacion para microcontroladores?
muchas gracias

Hola, ... mis saludos a los foristas ...
A lo que ya se ha dicho, sólo quería agregar que en aplicaciones donde se requiere el uso de variables de punto flotante, el lenguaje C permite operar directamente. Hacer lo mismo en assembler sería un trabajo tedioso.
Ahora, que lo pienso: ¿ cómo sería guardar una variable de punto flotante en la EEPROM ? Por ejemplo coeficientes de algún control PID, o algo similar que tenga redes neuronales.
La EEPROM es un recurso propio de los pic, que no tiene que ver con el lenguaje de programación.
¿ Tal vez separando mantisa y exponente y guardando por separado para rearmar al leer ?
Habrá alguna función ya definida. Hasta ahora nunca tuve que hacerlo ...
 
los micros de Microchips cada día tienen menos EEPROM, incluso ahora los AVR, los recortaron y parecen pic con míseros 128 ó 256 de eeprom, en vez de mejorar empeoran.

A tu duda... básicamente es falta de conocimiento del lenguaje C, es fácil, los números flotantes suelen ser de 32, 64 ó 80 bits, o más con las arquitecturas de 32bits o 64! , entonces con un puntero encontrás la dirección de la variable flotante, con un sizeof, de cuantos bytes es, ahora lees sucesivamente el número de bytes requeridos, y los guardas, uno a uno en la eeprom.

La lectura es lo mísmo, pero desde la eeprom a la ram, pensando siempre en sucesión de bytes, y punteros que indican donde están guardados.
 
...
¿ Tal vez separando mantisa y exponente y guardando por separado para rearmar al leer ?
Habrá alguna función ya definida. Hasta ahora nunca tuve que hacerlo ...
Depende con qué programes.
Si fuera CCS tenés las funciones write_eeprom(addr,val) y read_eeprom(addr).

Como escriben de a 1 byte , podés usar un union , ej:

C:
union FLN { float f ; struct {int8 b3,b2,b1,b0;};} ;
union FLN float1 , float2 , float3 ;    // las que uses...

....

    float1.f = 4.1 ;    // la trabajás como punto flotante

    // pero la guardás/leés de a byte
    write_eeprom(  0, float1.b3 );  
    write_eeprom(  1, float1.b2 );
    write_eeprom(  2, float1.b1 );
    write_eeprom(  3, float1.b0 );

    float1.b3 = read_eeprom( 0) ;
    float1.b2 = read_eeprom( 1) ;
    float1.b1 = read_eeprom( 2) ;
    float1.b0 = read_eeprom( 3) ;
 
los micros de Microchips cada día tienen menos EEPROM, incluso ahora los AVR, los recortaron y parecen pic con míseros 128 ó 256 de eeprom, en vez de mejorar empeoran.

A tu duda... básicamente es falta de conocimiento del lenguaje C, es fácil, los números flotantes suelen ser de 32, 64 ó 80 bits, o más con las arquitecturas de 32bits o 64! , entonces con un puntero encontrás la dirección de la variable flotante, con un sizeof, de cuantos bytes es, ahora lees sucesivamente el número de bytes requeridos, y los guardas, uno a uno en la eeprom.

La lectura es lo mísmo, pero desde la eeprom a la ram, pensando siempre en sucesión de bytes, y punteros que indican donde están guardados.

Gracias por la respuesta.
Hace un par de años tuve a la vista la implementación de un módulo multiplicador de p.f. de 16 bits pensado para FPGA.
Ahí trabajaban con mantisa y exponente porque esa es la norma IEEE para guardar los números de p.f.
No sabía eso de los punteros para los pics, pero resulta entendible (hasta para un "outsider" como yo).

Me han quedado algunos pics un poco obsoletos (16F877A) como para probar este tipo de cosas raras.
De hecho, a partir de este tema se me ha ocurrido una aplicación para probar hasta qué punto una red neuronal puede facilitar y/o mejorar el rendimiento de un controlador pequeño dedicado a unos sensores ópticos.
Hace unos años por aquí se planteó el problema de triangulación a partir de solo 3 sensores. Las fórmulas que surgen de la geometría son sencillas, ... hasta que uno las quiere implementar en un pic. Ahí aparecen propagaciones de errores desde cada cuenta que se hace.
Cuantas menos cuentas mejor.
Con redes neuronales "debería" ser más simple de implementar y hasta me animo a decir más preciso. Digo más simple porque uno se evita las cuentas de todos los procesos intermedios, y se centra en adquirir la señal y utilizar las coordenadsa que da la RN. Digo más preciso porque las cuentas son menos y más simples. Pero no lo he hecho aún.
Lo que sí es que requiere trabajar en punto flotante, y guardar y leer los coef. en EEPROM.
La etapa de entrenamiento conviene en una pcy luego devolver al pic los coeficientes y guardarlos en EEPROM.
Ya me está agarrando ganas de probar ...
Un saludo !

... y siempre recuerden que "Yo sólo sé ce, no ce más más, ... y no sé más ..."
Depende con qué programes.
Si fuera CCS tenés las funciones write_eeprom(addr,val) y read_eeprom(addr).

Como escriben de a 1 byte , podés usar un union , ej:

C:
union FLN { float f ; struct {int8 b3,b2,b1,b0;};} ;
union FLN float1 , float2 , float3 ;    // las que uses...

....

    float1.f = 4.1 ;    // la trabajás como punto flotante

    // pero la guardás/leés de a byte
    write_eeprom(  0, float1.b3 );
    write_eeprom(  1, float1.b2 );
    write_eeprom(  2, float1.b1 );
    write_eeprom(  3, float1.b0 );

    float1.b3 = read_eeprom( 0) ;
    float1.b2 = read_eeprom( 1) ;
    float1.b1 = read_eeprom( 2) ;
    float1.b0 = read_eeprom( 3) ;
Gracias Eduardo, hace años que no programo en pic ... ni me imagino las cosas nuevas que habrá ...
En algún momento probé CCS por las bibliotecas para display grafico, pero siempre me abrí con mis propias rutinas y el viejo "HI-TECH C".
 
Última edición:
Gracias por la respuesta.
Hace un par de años tuve a la vista la implementación de un módulo multiplicador de p.f. de 16 bits pensado para FPGA.
Ahí trabajaban con mantisa y exponente porque esa es la norma IEEE para guardar los números de p.f.
No sabía eso de los punteros para los pics, pero resulta entendible (hasta para un "outsider" como yo).

Me han quedado algunos pics un poco obsoletos (16F877A) como para probar este tipo de cosas raras.
De hecho, a partir de este tema se me ha ocurrido una aplicación para probar hasta qué punto una red neuronal puede facilitar y/o mejorar el rendimiento de un controlador pequeño dedicado a unos sensores ópticos.
Hace unos años por aquí se planteó el problema de triangulación a partir de solo 3 sensores. Las fórmulas que surgen de la geometría son sencillas, ... hasta que uno las quiere implementar en un pic. Ahí aparecen propagaciones de errores desde cada cuenta que se hace.
Cuantas menos cuentas mejor.
Con redes neuronales "debería" ser más simple de implementar y hasta me animo a decir más preciso. Digo más simple porque uno se evita las cuentas de todos los procesos intermedios, y se centra en adquirir la señal y utilizar las coordenadsa que da la RN. Digo más preciso porque las cuentas son menos y más simples. Pero no lo he hecho aún.
Lo que sí es que requiere trabajar en punto flotante, y guardar y leer los coef. en EEPROM.
La etapa de entrenamiento conviene en una pcy luego devolver al pic los coeficientes y guardarlos en EEPROM.
Ya me está agarrando ganas de probar ...
Un saludo !

... y siempre recuerden que "Yo sólo sé ce, no ce más más, ... y no sé más ..."

Gracias Eduardo, hace años que no programo en pic ... ni me imagino las cosas nuevas que habrá ...
En algún momento probé CCS por las bibliotecas para display grafico, pero siempre me abrí con mis propias rutinas y el viejo "HI-TECH C".
ja ja ja, si lo tuyo es renegar con números flotantes, y fuerza bruta por culpa de las " comas", te conviene re-estudiar con los ARM, son directamente de 32 bits, existen placas de desarrollo, y muchos son más económicos que los PIC (o AVR de Microchips), creeme, los ARM son la onda por estos momentos.
 
Arriba