Lenguaje C o lenguaje CCS?

[MGLSOFT]

Yes Man !!

[Suky]

Ahora bien si tienes un proyecto grande que te demora varios meses en realizarse y durante el cual la versión del CCS va cambiando de version a version ¿como haces para soportar la incertidumbre? guardas el proyecto junto con el compilador? que tranquilidad hay que más adelante ese proyecto compilará bien o generará un código bueno con un nuevo ccs?

Eso ya se ha visto en comentarios del foro! Al existir una versión nueva generalmente se actualiza, perooo  no siempre el código sigue funcionando  Asi que a revolver el "armario" para encontrar el instalador de la versión antigua 



Saludos!

[Nocturno]

¡¿Qué ven mis ojos?!, el gran Maunix nuevamente al ataque.

Bienvenido. Un fuerte abrazo, compañero.

[maunix]

Ahora bien si tienes un proyecto grande que te demora varios meses en realizarse y durante el cual la versión del CCS va cambiando de version a version ¿como haces para soportar la incertidumbre? guardas el proyecto junto con el compilador? que tranquilidad hay que más adelante ese proyecto compilará bien o generará un código bueno con un nuevo ccs?

Eso ya se ha visto en comentarios del foro! Al existir una versión nueva generalmente se actualiza, perooo  no siempre el código sigue funcionando  Asi que a revolver el "armario" para encontrar el instalador de la versión antigua 


Saludos!

Hola suky, era asiduo visitante del foro hace unos años pero hace tiempo que no participaba... perdón si algo no lo he leído, es que no uso el CCS  y era más para reirme con el amigo MGLSOFT que otra cosa   

Hablando en serio no podría tener un compilador que me juegue esas malas pasadas, por suerte el C18 ha sido una mejora continua, incorporando nuevos micros, nuevas funcionalidades, etc.  Pero sobre gustos... colores como dicen por allí.   

Por cierto tienes lindos proyectos en tu web! Excelente trabajo!!

¡¿Qué ven mis ojos?!, el gran Maunix nuevamente al ataque.

Bienvenido. Un fuerte abrazo, compañero.

Hola manolooooooooooo, si, ando de nuevo por acá, no prometo ser asiduo como antes pero al menos visitarlo de vez en cuando, realmente el foro anda geniall. recuerdo viejas épocas en que queria entrar un ratito y se caía... hablando con Norberto me contó las peripecias que tuvo que sortear y el gran flujo de información que tenía el foro (algo así como 10000 conexiones simultáneas, ojo, no usuarios, sino que cada vínculo, imagen, texto, es un vínculo) por lo cual no cualquier hosting lo soportaba!! ¿será por la sección de chistes? 

[jukinch]

Hola Amigos:
                   viendo la discusión que siempre se genera entre ccs y c18, que ya es como un River - Boca o Ford y Chevrolet, en la cual sólo puedo decir como dice Maunix que sobre gustos no hay nada escrito, me pregunto si se planteó alguna vez la posibilidad de crear dos subforos dentro de "lenguaje c para microcontroladores PIC" - uno de c18-c32 y otro de ccs?
                 Se que ello consumiría más recursos humanos, con lo cual me respondo solo y creo que no sea posible.
                Por lo que sugiero poner una chincheta a un hilo que indique los temas más relevantes sobre c18-c24-c32.
                Allí podríamos hacer una especie de índice, y subir ejemplos funcionales al 100%. Compilados y probados en hardware real, como ser el famoso hola mundo o enciende un led, comunicación i2c, librerias de lcd, bootloader, conversor ad, comunicación usb, entre muchos otros ejemplos.
                Cuanto más comentados estén dichos códigos, mejor. Así resulta práctica su lectura.
                Hasta podríamos agregar archivos *.hex compilados para diferentes micros y cristales. Esto sería muy útil para descartar problemas de hardware.
              Por ejemplo cuantas veces sospechamos de un problema de soft en una conexión por puerto serie, cuando en realidad el problema estaba en el hard o viceversa. De esta manera tendríamos una herramienta muy útil para los que recién arrancamos en c18.
           Algo así como lo que ha hecho Redpic sobre ccs:
http://www.todopic.com.ar/foros/index.php?topic=14427.20

hasta ahora podemos ver este índice:
http://www.todopic.com.ar/foros/index.php?topic=14634.0
    1.- Ejemplitos en C para 16F648A Autor Vszener
    2.- Microcursillo en C Autor Nocturno
    3.- Mis Funciones favoritas en CCS C Autor Redpic
    4.- Ejemplitos 16F876A: Indice de contenidos Autor Redpic
    5.- Serie Técnicas en C : Presentación e Indice de Contenidos Autor Redpic
    6.- Cursillo en C18 para PICS desde cero Autor Velaki

          O si no fuere posible crear más chinchetas agregar a este hilo http://www.todopic.com.ar/foros/index.php?topic=14634.0
el tutorial de c18 de Suky http://www.todopic.com.ar/foros/index.php?topic=31611.0
                        Saludos a todos.
                                       Jukinch

[stk500]

  me alegra muchos de ver por aqui nuestros gran amigos Maunix 
un gran saludo gran amigo

[DaYeS]

Ummm, pienso como la mayoría, que cada uno utilice es que mejor se adapte a sus necesidades. Si realmente quieres optimizar no te queda más que asm, pero si necesitas rápidez te tienes que pasar a alto nivel.

Personalmente no me gusto CCS, (no se si habrá cambiado) pero Hitech me fue muy bien, además ahora la Lite es gratuita. De todas maneras, no suelo estar muy apurado de espacio, por lo que tampoco necesito un compila de la leche. El piklab esta bastante avanzado, pero con algunos bug´s todabía y no es la panacea compilando.

Ah, las horas de los europeos no se como estarán, pero la de los españoles no te creas que andamos sobrados, y menos ahora. 

Salu2 a todos.

[LABmouse]

Si lo miramos desde un punto de vista mas pragmatico... CCS es la mejor opcion para programar PICs.  

Claro que hasta ahora porque recien salio algo que pretende competir fuertemente con CCS. Hablo de algo como arduino pero para PICs. Eso seria algo mucho mas abstracto, seria casi tirar el lenguaje C a un lado y simplemente dedicarse a crear proyectos con una comunidad que crece y crece sin parar. Creo ese es el potencial de estas nuevas metodologias y lenguajes de programacion, mas faciles de digerir, y con una gran comunidad que los respalda.

Como docente, me enfrente los primeros semestres a enseñar ANSI-C, con resultados buenos pero con un permanente comentario de "No hay muchos ejemplos a seguir en la RED".  Al final llego a una pequeña conclusion personal que procedo a comentarla:

Una persona compra un radio digital para que pueda escuchar sus emisoras. Que si tiene un PIC, AVR, Freescale, no importa, y mucho menos como lo programaron o en que  lenguaje. Si en C, basic, CCS, o arduino, tampoco interesa en lo mas minimo. Al final lo importante es que funciona y que el cliente esta satisfecho con la compra y como ingeniero desarrollaste un radio que funciona, vendiste y ganaste algo de dinero para sobrevivir. En fin, decido ceder ante CCS y enseñar en CCS, como resultado tengo estudiantes que me entregan trabajos mas completos, complejos y con gran conocimiento de causa de su funcionamiento a nivel de hardware.  Teniendo bien claro que si algun dia pretenden cambiar de marca, sera necesario pasar a ANSI-C y crear sus propias librerias.

SALUDOS!

[maunix]

Si lo miramos desde un punto de vista mas pragmatico... CCS es la mejor opcion para programar PICs.  

Creo que si de obtener resultados más rápido te refieres para proyectos simples, creo que estás muy en lo cierto!!

Una persona compra un radio digital para que pueda escuchar sus emisoras. Que si tiene un PIC, AVR, Freescale, no importa, y mucho menos como lo programaron o en que  lenguaje. Si en C, basic, CCS, o arduino, tampoco interesa en lo mas minimo. Al final lo importante es que funciona y que el cliente esta satisfecho con la compra y como ingeniero desarrollaste un radio que funciona, vendiste y ganaste algo de dinero para sobrevivir. En fin, decido ceder ante CCS y enseñar en CCS, como resultado tengo estudiantes que me entregan trabajos mas completos, complejos y con gran conocimiento de causa de su funcionamiento a nivel de hardware.  Teniendo bien claro que si algun dia pretenden cambiar de marca, sera necesario pasar a ANSI-C y crear sus propias librerias.

Por supuesto que es así, pero justamente es ese punto al cual como ingeniero me cuesta usar algo como el CCS q dicho por varios está lleno de bugs. Los proyectos en los que me vi envuelto últimamente manejan varias tareas en simultáneo, atendiendo varias vías de comunicación por hardware, donde un proyecto me puede llevar 1 año (si, no es que hacerlo andar me lleve eso pero implementarle todas todas las funciones que requiere termina llevando ese tiempo, aunque con pocas funciones ya se pueden vender en el mercado).    Entonces con tantos requerimientos el compilador y el IDE se ven actualizados varias veces durante el proceso de desarrollo, si con cada actualización debiera debuguear todo para ver si el compilador ahora introduce un error que antes no introducía realmente sería algo de locos, costosisimo y un riesgo enorme ya que los equipos se exportan y traerlo de vuelta para revisar sale a veces más que el equipo en si, con lo cual está en juego mi pellejo laboral...

Ahora si el código es estable.. por supuesto que es lo mismo que se haya hecho con cualquier lenguaje!! al fin y al cabo lo que termina ejecutándose es código máquina que si está bien generado no es importante con qué compilador/lenguaje se lo generó!   

[RICHI777]

Hola, en mi caso me siento un purista del lenguaje, que no significa nada. Con los años aprendí que mis gustos no tienen porque ser los gustos de todos. Aprendí también que mucha gente necesita soluciones rápidas y no le interesa tanto como se implementan las cosas, según mi punto de vista CCS se encuadra en esto último, que no quiere decir que sea malo o feo, es más lo veo super completo para soluciones rápidas, yo como gusto personal y según mi punto de vista para aprender algo rápido me gusta mas la sintaxis de basic donde no existe punteros y esas cosas que son las mas difíciles de aprender. Con respecto al punto de purista, elijo ANSI C porque me permite compartir código entre diferentes plataformas y eso para mi es tiempo valioso que de por si es escaso y es lo que hago para sobrevir en esta vida. También debo reconocer que el C se quedo un poco en el tiempo, hay cosas de otros lenguajes muy piolas, pero como todos estoy sujeto a la disponibilidad de los fabricantes.

Saludos !

[Diego E.]

Hola amigos, yo pienso que la mayoría de los problemas que se nos presentan con CCS es porque a veces nos volvemos muy CCS dependientes, para los que hemos tracegamos harto con el assembler quizá nos cuesta creer que los programas se puedan resolver tan fácil, pienso que el problema no es tanto el CCS como compilador sino la cantidad de librerias prefabricadas que tiene y que quien las hizo obviamante no puede contemplar todas las variables que aparecerán, igualmente podemos utilizar CCS con la mayoría de las sentencias de C estandar y crear todas las rutinas o funciones que necesitemos o tengamos dudas, de esta forma quedará muy similar a C18 u otros compiladores.

Acá paso un ejemplo del modulo usart sin libreria

Código: [Seleccionar]

#include <16F876A.h>
#use delay(clock=4000000)

#fuses xt,put,brownout,nowdt

#byte porta = 5 //Definicion de variables del pic
#byte portb = 6
#byte portc = 7
#byte intcon = 0x0b
#byte rcsta = 0x18
#byte txsta = 0x98
#byte txreg = 0x19
#byte rcreg = 0x1a
#byte spbrg = 0x99
#byte pir1 = 0x0c
#byte pie1 = 0x8c

#define tecla porta,4
#define fin_tx txsta,1

///////////////////////////////////////////////////////////////////////////////
#int_rda //Vector de interrupcion de la recepcion de datos
void interrupcion_rx() //por el usart
{
portb = rcreg; //Se lee el dato recibido
}
///////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////
#zero_ram //Borrado de la memoria ram

void main() //Rutina principal
{
set_tris_b(0b00000000); //Configuracion de entradas y salidas del puerto B
set_tris_c(0b10111111); //Configuracion de entradas y salidas del puerto C

intcon = 0b11000000;
bit_set(pie1,5);

spbrg = 12; //Configuración para 4800 o 19200 bps
txsta = (0b10100000); //Configuracion del módulo de transmisión a 19200
txsta = (0b10100100); //Configuracion del módulo de transmisión a 19200
rcsta = (0b10111000); //Configuración del módulo de recepción
portb = 0;
portc = 0;

while(true) //Rutina general
{
while(!bit_test(tecla));
{

txreg='A';
while(bit_test(fin_tx)==0); //Se envia cada uno de los caracteres

}

while(bit_test(tecla));
}
}

///////////////////////////////////////////////////////////////////////////////
Saludos.

[DaYeS]

Pienso que el problema no es tanto el CCS como compilador sino la cantidad de librerias prefabricadas que tiene y que quien las hizo obviamante no puede contemplar todas las variables que aparecerán, igualmente podemos utilizar CCS con la mayoría de las sentencias de C estandar y crear todas las rutinas o funciones que necesitemos o tengamos dudas, de esta forma quedará muy similar a C18 u otros compiladores.

Creo que siempre que utices librerias de terceros, antes de usarlas hay que echarlas un ojo, para ver si se adaptan a tus necesidades. Igual que tú librería, las mias, etc... Siempre que se las pasamos a alguien las mira, pues las que se utilizan con estos programas también.

Salu2

[LABmouse]

Hola amigos,

Por supuesto que es así, pero justamente es ese punto al cual como ingeniero me cuesta usar algo como el CCS q dicho por varios está lleno de bugs.

Efectivamente amigo maunix, siempre hay un pero en las cosas y nada puede ser tan bonito. hacerlo un poco mas fácil con CCS tiene sus riesgos. Personalmente sufrí 15 días en un proyecto en donde el error era haber instalado la ultima versión de CCS.  Por razones ajenas al proyecto me toco borrar todo en el pc e instalar una vez mas windows y CCS, pero instale la anterior y desde ese momento funciono bien.  luego de terminado el proyecto se me dio por hacer la prueba de instalar una vez mas la nueva versión y con eso confirme que el error era de CCS.

En eso no tengo la menor duda que es un proyecto al que le falta seriedad en los lanzamientos. pero también debo decir que me ha permitido sacar proyectos en 30 minutos que de otra forma tardaría mucho mas. Inclusive en ANSI-C.

Nada podrá pasar por encima de la portabilidad de ANSI-C, es mas si me pregunta alguien, es el que recomiendo. Solo que para una persona que nunca toco un microcontrolador, es mas fácil mostrarle un camino con CCS y que el mismo al ver sus primeros proyectos funcionando se crea una motivacion personal para asi pasarse a lo mejor que es ANSI-C.

Para mi:
Un profesional en el tema de microcontroladores, debe trabajar en ANSI-C,
Una persona que inicia en los microcontroladores, CCS o Arduino es una buena opción para dar sus primeros pasos

SALUDOS AMIGOS!, hoy estoy de buenas pulgas!!!  

[Suky]

Para mi:
Un profesional en el tema de microcontroladores, debe trabajar en ANSI-C,
Una persona que inicia en los microcontroladores, CCS o Arduino es una buena opción para dar sus primeros pasos

SALUDOS AMIGOS!, hoy estoy de buenas pulgas!!!  

Estoy de acuerdo! Como para comenzar nada mejor que esos lenguajes que son sencillos de digerir y que no necesita tanto conocimiento del hardware. Pero para aquel que tenga ansias de dedicarse de manera más profesional debe ir cambiando de lenguaje, principalmente porque va a estar en juego su pellejo   Además del tema de la portabilidad, trabajando en ANSI-C tienen la posibilidad de trabajar con cualquier arquitectura sin hacerse mucho problema, pero si se hacen CCSdependientes, va a costar mucho....


Saludos!


Saludos!

[maunix]

Creo que la portabilidad del ANSI-C es bastante mito entre el mundo de microcontroladores... y me paso a explicar

Es todo muy lindo y me pasó en más de una ocasión poder usar un código hecho en C bajado de la web y adaptarlo a mi propias necesidades... y hago incapié en adaptarlo... es muy dificil que un código que esté pensado para otra arquitectura más allá que sea o no ANSI C sea incorporable a nuestro código sin algún esfuerzo.

Por supuesto que me dirán que gran parte del trabajo está hecha... pues sí, es cierto pero depende mucho del código que querramos reutilizar.  En ocasiones ni mis propios códigos genéricos me sirven en mis propias aplicaciones, por diversas razones: porque no tengo tanta memoria en un hard como en otro, porque el nuevo proyecto tiene que hacer N tareas más, porque tiene funciones bloqueante que debo evitar porque el nuevo sistema debe asistir varias cosas al mismo tiempo prescindiendo de un RTOS, etc.

Ni hablar muchachos si quieren usar la flash de su microcontrolador para guardar información... se las debo jiji.  Hi-tech es también bastante ANSI C sin embargo la forma en que usa los punteros es muy diferente a la del C18 entonces por más que sea todo ANSI C... la reutilización se hace escasa.  Un microcontrolador borra de a 64bytes por vez, otro de a 512, otro de a 1024... eso obliga a muchos cambios en el codigo que no son menores.  Si uno quiere "modificar" 1 sencillo byte de flash en un micro que tiene programación de a 1024 bytes por vez (como los 18f45j10 si mal no recuerdo) habra que primero poner toda eso en ram, modificar en ram el byte en cuestión, borrar la flash y luego mandarla a guardar.  Si todo eso se debe hacer "mientras" no se deja de atender a otros eventos entonces la cosa se complica y mucho. 

Y no hablo del simple soft que envia un caracter por la usart.. hablo de por ejemplo tener un buffer de recepción cíclico de  E/S por usart que se active por interrupción, en algun caso podría ser con RS232 con control de flujo por hardware, en otro por RS485 y si bien son "parecidos" no son iguales y en sistemas embebido las cosas se deben ajustar al hardware.  Lo mismo si quiero reutilizar un código de estas características pero el mismo buffer (por falta de ram) es compartido entre 2 usart por ej, aunque no en simultáneo si se debe "bloquear" el buffer cuando lo usa una usart y evitarselo de usar a la otra... cosas como esas hacen que la migración se complique mas y mas

Otro ejemplo que me viene a la mente y que no es lo mismo guardar por ej, 120 bytes en eeprom todos de una a guardarlos 1 por vez sin dejar de atender el flujo principal del programa.  En un caso podriamos demorar 4x120 = 480mseg, que podría ser crítico o inaceptable para muchas aplicaciones.

Lo mismo ocurre si quieren grabar en la eeprom, he hecho rutinas que puedo reutilizar entre varios pic18 pero si quisiera migrarlas a PIC16 debiera hacer muchas cosas, como por ejemplo "compilaciones condicionales" como hace mirochip en sus stacks de usb, ethernet, etc.  En definitiva es lo mismo que hacer varios codigos en uno... y de acuerdo a como son los defines el compilador compilará una u otra rama del código.  Pero no es ma s que tener varios códigos todos juntos "ifdefiando" (si me permiten el tiempo) las partes que son diferentes justamente para atacar la diferencia que hay entre un hard/compilador y otro.

Lo mismo sucede si queremos operar con modo polling o interrupción, los cambios son importantes.  Entonces no hablamos de una librería portable en forma sencilla, hablamos de varios códigos en uno que se compilan/configuran con los defines. 

Si migramos de arquitecturas y queremos por ejemplo trabajar con la UART, en un micro u otro, habra rutinas que nos serviran pero muchas que no, lo mismo con el A/D, SPI, etc.  La migración/portabilidad termina siendo un mito que si no hay conocimiento desde que arquitectura se viene y a donde se va, se fracasará. 

Esa es la ventaja de usar RTOS o algún otro sistema operativo avanzado como linux (aunque sin RT core).  En caso de linux se necesita un hardware más potente pero mucha gente se inclina hacia allí justamente porque el armado de tareas en simultáneo (hilos de ejecución o threads; o bien procesos en paralelo) es mucho más sencilla en detrimento de mayor latencia a los eventos.


No obstante C es el camino, lo es hace tiempo y los microcontroladores aun creo que estan lejos para que con tareas complejas podamos usar  otro tipos de herramientas que requirirían de un hardware mucho más potente.