TODOPIC
Microcontroladores PIC => Lenguaje C para microcontroladores PIC => Mensaje iniciado por: marvicdigital en 19 de Mayo de 2011, 08:17:52
-
:?
Hola a todos.
Lo primero es que lo que voy a escribir lo hago con el mayor respeto que les tengo a todos y al foro.
La pregunta la hago, por que cuando busco ejemplos en lenguaje C para los PIC, lo único que encuentro(salvo algunas librerías globales) son ejemplos en CCS, y a mi modo de ver, son ejemplos incompletos, carentes de lenguaje C para aprender...
Como es posible que, quiera saber como implementar una comunicación RS-232 en un PIC como el 12F509 y me encuentre con lo siguiente:
#use rs232(baud=9600, xmit=PIN_B1, rcv=PIN_B2, FORCE_SW) //[size=10pt][b]manejo del RS232[/b][/size]
Me pregunto, "manejo del RS232"?..o será más bien "manejo del CCS sobre el RS-232...? por que me atrevería a decir, que más del 80% que solo han usado el CCS para PIC, no saben como hacer la rutina en lenguaje C fuera del CCS :oops: ....que son rutinas ya implementadas, para que reinventar la rueda...pero no les parece mucho mejor, saber como se hace en lenguaje C y variar parámetros a tu antojo, mejor dicho tener el control absoluto de tu código?
Yo no uso CCS, por que simplemente hay que pagar por él, y asi sepa donde conseguirlo ilegal, tampoco lo hago, uso Soft libre, de hecho solo uso Linux, uso el SDCC en PIK lab, no seré muy ducho en C, como los verdaderos maestros del lenguae C, pero estoy en esa linea de aprendizaje y puedo decir que el CCS, no pertenece a esa linea de aprendizaje, más bien lo pondría en la linea del facilismo el cuál ayuda solo en aquellos momentos en donde nos veamos apurados o falta de tiempo.
Saludos
-
Hola marvicdigital
yo alguna vez logré implementar una rutina en asm para transmitir datos en un 16f84a, después usando el modulo usart que vienen en otros pic, y después cuando me pasé al C, me conseguí que el ccs ya traía las funciones built-in, que no son mas que funciones que hacen la mayor parte del trabajo.
lo que tu dices sobre tener el control absoluto sobre nuestros códigos es cierto, aún en ccs cualquiera puede dejar de usar las built-in y escribir sus propias funciones desde cero, es cuestión de gustos y de conveniencia. yo por ejemplo no he tenido tanto problemas con las funciones compiladas, así que mientras hagan lo que quiero, las seguiré usando.
también hay que decir, que tener el control sobre el código, no es sinónimo que nunca tendremos problemas, porque en los pics existen los llamados silicon errata y también pueden dar malas jugadas a veces.
En fin se trata de reducir el tiempo de trabajo, reducir el stress de la programación y lograr la satisfacción del funcionamiento.
-
Me uno a lo que dice Pedro, puede que el CCS no sea el programa perfecto pero no podemos demeritar las ventajas que trae, en CCS bien podemos obviar las funciones compiladas y crear las nuestras, o si lo que se quiere es acariciar la arquitectura intrínseca del PIC lo podemos hacer en ASSEMBLER. pues finalmente todos los compiladores lo que hacen es traducir el código asm.
Saludos.
-
Hola.
Debe ser porque no colocas una descripción mas para el lenguaje jeje ... si colocas en el buscador rutinas C + HiTech ... debe aparecer algo diferente.
Creo que CCS es el mas usado acá en el foro, pero también he visto que el C18 toma fuerza ...
Saludos
-
Yo programe rutinas de comunicación en assembler, no quiero acordarme lo que renegué.
Después hice lo mismo en Basic para PIC y por ultimo lo hice en CCS.
Olvidarme de configurar registros según el cristal que utilices, ver el tiempo de bit, los tiempos de pausa, tratamiento de errores, cambios de velocidad, etcétera.....es impagable !!!
Solo digo que cada uno elige que quiere, no hay un concepto absoluto en programación.
Para mi la optimizacion del código es despreciable cuando comparo el tiempo de desarrollo, y eso que vivo en Argentina, donde nuestro tiempo es mas barato!!
Imagínate en Europa o EEUU, donde la hora del programador es mas cara.
Ponerse a depurar rutinas de comunicación serial !!
Ya es tiempo de otras tecnologías de comunicación, como son el USB y ethernet o wifi, yo no le dedico ni un minuto a hacerlo en codigo, por mas que sea una practica...
Ademas que puertos vas a usar de los PC modernos, que ya no traen seriales??? :D :D :D
-
Tienen, razon si tu usas c para programar, aun asi estas haciendolo de la forma "facilisima", si quieres hacerlo con un "control total" entonces usa ensamblador, si lo que te gusta es batallar haslo, como tu lo mencionas, se usa para reducir tiempos de programacion, y es lo mismo qu tu estas haciendo al usar c.
-
La respuesta es fácil, CCS tiene algo de C, creo las estructuras de control, nada más! :D Si quieres aprender C aplicado a los PICs, CCS no es lo adecuado, mejor busca Hi-Tech, peroooo vas a encontrar poco :?
CCS es un lenguaje muy facil de usar y por ello abarco mucho en los hobbista, el 95% de lo que ronda por la red, entonces hay información de todo tipo.
Saludos!
-
Debería haber un C16 jeje, para programar desde plataforma MPLAB en el C estandar como C18.
Estoy trabajando bastante seguido con C18, y simplemente me parece genial, tiene sus huevadillas al principio pero cuando te acostumbras lo ves bastante útil.
Lo único q me gusta del CCS es la facilidad, hace ver q la programacion de pics es muuy sencilla.
CCS talvez para iniciar viene muy bien, después hay q pasar a un mejor nivel.
-
Por el tiempo que llevo en C puedo decir lo siguiente:
Realmente en CCS las funciones facilitan mucho las cosas, pero no sabes realmente como van los registros del pic, aun no dejo CCS por lo rapido que se hacen las cosas pero ahora que ando con C30 de a pocos a mi parecer es mejor ya que sabes que registro estas usando y que le estas haciendo, mejor dicho el control del pic lo tiene uno.
Ademas con lo barato que esta un pic24 o un dspic, comparando con las caracteristicas entre estos y pics de gama menor, pues la diferencia es enorme.
Por eso mejor de apocos voy con el C30, de alli a saltar a C32 no hay mucho y si quieres pasarte a otra marca que use el standard C, no hay mucho por hacer mas que conocer los registros de chip a usar.
Saludos
-
...Ademas que puertos vas a usar de los PC modernos, que ya no traen seriales??? :D ..
Marcos pero recuerda que los puertos virtuales son el sustituto del COM, fíjate la cantidad de dispositivos que existen hoy día que crean puertos seriales virtuales. :)
Por el tiempo que llevo en C puedo decir lo siguiente:
Realmente en CCS las funciones facilitan mucho las cosas, pero no sabes realmente como van los registros del pic, ...
yo cuando veo que algo anda mal, paso el código por un simulador y veo el comportamiento de los SFR usando breakpoints y por ahí voy analizando fallas y depurando.
por ejemplo, en ccs existen las funciones setup_xxxxx que sirven para configurar los módulos que traen los micros, cuando quiero saber que hace cada setup_xxx, miro el asm generado o veo los SFR en la simulación.
hasta ahora no he tenido tantos problemas por fallas extrañas que introduce la gente que creó el compilador.
soy fan del ccs, pero también soy bastante critico por la cantidad de bugs que trae (y vaya que me burlo bastante por la cantidad de bugs que salen en cada versión).
-
Tienen, razon si tu usas c para programar, aun asi estas haciendolo de la forma "facilisima", si quieres hacerlo con un "control total" entonces usa ensamblador, si lo que te gusta es batallar haslo, como tu lo mencionas, se usa para reducir tiempos de programacion, y es lo mismo qu tu estas haciendo al usar c.
Lllevas razón amigo dolphin; yo he usado ASM desde 1.995, hice una pausa muy larga con microcontroladores y el mundo del diseño, por varios años, ahora vuelvo, aunque lo he hecho muy pausadamente y hasta interrumpidamente, por eso he querido aprovechar al máximo cada minuto y por eso he querido aprender lenguaje C, pero siempre enfocado a que ese código que haga lo haga pensando en ensamblador, y que me sirva para aplicarlo a otras familias o marcas como Freescale, Atmel...
Sobre lo del RS-232 en el 12F509, lo puse a modo de ejemplo, hay veces donde hago código para mis Freecale y necesito alguna guía o truco de como hacer determinada función, y como lo más común es ver código para PIC, pues vengo y consulto algunos ejemplos que puedan darme alguna idea, truco para el código y me encuentro con pragmas ya hechos por un programa llamado CCS, y que para poder ver esas rutinas tengo que pagar o bajarmelo ilegalmente..entonces paso de hacer eso, y mejor me pongo a experimentar, a perder tiempo para algunos..pero a mi modo de ver, aprender y poder eso código aplicarlo en otro chip de otra marca, de hecho así tengo algunos código de cosas muy básicas como controladores de temperatura, contador de turnos, timers y una que otra cosa por ahí..los tengo listos para poderlos grabar en un Atmel, PIC o Freescale, solo tengo que cambiar los #define al principio por los registros que use la marca de microcontrolador..esto es algo que me imagino no es muy fácil de hacer si solo te limitas a usar CCS.......
Ejemplo de esto es la maravillosa librería para LCD que hizo nuestro amigo Suky, de donde se puede aprender mucho..y es una librería universal, te sirve para PIC, Freescale, Atmel y otras familias que no recuerdo, con 11 pines, 7 y hasta con solo 3 pines según tus necesidades..eso es algo que yo quiero hacer, aprender...por eso me refiero al CCS no como un lenguaje C si no como un lenguaje CCS...
Saludos.
-
Hola, mi opiniones.
Todo depende de cuales sean tus aspiraciones, si lo tuyo es el hobby te recomiendo CCS, es la manera más fácil y rápida de concretar proyectos con PICs. Ahora si pensas en dedicarte profesionalmente a programar micros y con la posibilidad de trabajar con otras marcas tal vez la elección pase por otro compilador que se ajuste más el estandart. CCS es casi una excepción ya que no conozco paquetes de compilación que traigan tanta funcionalidad, eso si hay muchas versiones lo que no habla bien del producto final. Si te queres dedicar profesionalmente, primero debes aprender C básico, y en una PC es lo mejor, con respecto al manejo de puertos series, debes leer algún libro sobre embebidos y no viene mal una lectura sobre estructuras de datos ( colas, pilas, listas linkeadas, etc, etc ).
Saludos !
-
Como es posible que, quiera saber como implementar una comunicación RS-232 en un PIC como el 12F509 y me encuentre con lo siguiente:
#use rs232(baud=9600, xmit=PIN_B1, rcv=PIN_B2, FORCE_SW) //[size=10pt][b]manejo del RS232[/b][/size]
Me pregunto, "manejo del RS232"?..o será más bien "manejo del CCS sobre el RS-232...? por que me atrevería a decir, que más del 80% que solo han usado el CCS para PIC, no saben como hacer la rutina en lenguaje C fuera del CCS
Yo no uso CCS, por que simplemente hay que pagar por él, y asi sepa donde conseguirlo ilegal, tampoco lo hago, uso Soft libre, de hecho solo uso Linux, uso el SDCC en PIK lab, no seré muy ducho en C, como los verdaderos maestros del lenguae C, pero estoy en esa linea de aprendizaje y puedo decir que el CCS, no pertenece a esa linea de aprendizaje, más bien lo pondría en la linea del facilismo el cuál ayuda solo en aquellos momentos en donde nos veamos apurados o falta de tiempo.
Hola marvicdigital, creo que podemos coincidir en muchas cosas pero también es cierto que el CCS tiene muchos adeptos y mientras haya adeptos y dispuestos a compartir, allí estara CCS para los que quieran usarlo.
Hasta donde recuerdo este debate ha surgido una y otra vez con cierto período de tiempo.
Es cierto que no es un C muy estandar, pero en mis años que participé en el foro noté que a mucha gente le caía bien y si a ellos les cae bien y les parece útil, entonces se cumplió el cometido. Además esa gente a las que les caía bien compartía y publicaba el código, de allí la mayor fuerza del CCS es la participación de su gente.
Si has notado que no te sirve, pues bien, ve por otro camino como hicimos varios. En lo personal uso C18 y es bastante ANSI C, tienes versiones gratuitas también de C18 que no optimizan tanto pero vamos, que el SDCC tampoco es la panacea optimizando :mrgreen:
Una jugada en contra para el PikLab creo que es que el nuevo MPLAB X IDE es multiplataforma y corre muy bien en Linux (lo probé personalmente), incluso con el C18 y otros compiladores... y si bien soy fan del software libre a la hora de trabajar uno tiene tan poco tiempo que a veces cuesta encima participar en el desarrollo/colaboración del IDE, por ahi prefiero tomar atajos como el uso de un IDE que ya sea conocido, probado y con muchas más opciones de allí que en Linux empecé a usar eL MPLAB X IDE (y conste que usaba el Piklab, con mi ICD2).
Un punto muy a favor del C18 es que tienes rutinas para todo y tienes el código fuente de todo, no hay rutinas 'embebidas' que no sepas como es el código y recién te das cuenta que hicieron cuando aparece el assembler generado. Además el C18 es muy flexible y te permite hacer miles de cosas, de hecho yo que provengo del assembler más crudo encontré el C18 muy útil justamente porque me permitía combinar ambos mundos de manera sencilla y transparente. Lo mismo ocurre con el PICC de hitech (aunque ahora lo compró microchip)
hasta ahora no he tenido tantos problemas por fallas extrañas que introduce la gente que creó el compilador.
soy fan del ccs, pero también soy bastante critico por la cantidad de bugs que trae (y vaya que me burlo bastante por la cantidad de bugs que salen en cada versión).
Hola PalitroqueZ, tantos años!! La verdad admiro tu paciencia jiji, yo no podría tener un compilador que en cada versión introduzca bugs nuevos y que además deba saber cuales son... pero si eres tolerante a estas cosas, pues los de CCS estan de parabienes :D . Osea eres crítico pero lo sigues usando encima en cosas que por ahí son complejas cuando te juegas tu prestigio técnico.
Además, que seguridad o tranquilidad se puede tener, si con cada versión hay tantos nuevos bugs?
De hecho, vengo leyendo de eso desde que conozco usuarios de CCS e incluso en algú momento lo usé pero me cansé porque un codigo sencillo no se comportaba en forma clara y seguro era debido a un bug, cambié de compilador con la misma estructura de código y anduvo de primera mano...
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?
Estoy solo suponiendo, sé que muchos lo usan y les va muy bien pero bueno son dudas que siempre tuve de cómo un puede combinar ambas cosas, la incertidumbre y el conocimiento certero de que cada nueva versión contiene nuevos bugs... y la tranquilidad que uno debe tener al hacer un sistema embebido ya que uno vende algo y por ahi termina a cientos de km de distancia (incluso a paises lejanos) y me sería muy costoso tener que probar todo nuevamente con cada cambio del compilador.
Un abrazo y a seguir opinando con tan buenos argumentos que es lo que enriquece el debate!
-
Je..je..
Nos encanta sufrir los Bugs del CCS :D :D :D :D
-
Je..je..
Nos encanta sufrir los Bugs del CCS :D :D :D :D
¿Algo asi como masoCCSista? :D :D :D
-
Yes Man !! :mrgreen: :mrgreen:
-
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 :D no siempre el código sigue funcionando :z) Asi que a revolver el "armario" para encontrar el instalador de la versión antigua :undecided:
Saludos!
-
¡¿Qué ven mis ojos?!, el gran Maunix nuevamente al ataque.
Bienvenido. Un fuerte abrazo, compañero.
-
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 :D no siempre el código sigue funcionando :z) Asi que a revolver el "armario" para encontrar el instalador de la versión antigua :undecided:
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 :mrgreen: :mrgreen:
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í. 8)
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? :D :D
-
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
-
:-/ :-/ me alegra muchos de ver por aqui nuestros gran amigos Maunix :-/ :-/
un gran saludo gran amigo
-
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. :5] :5]
Salu2 a todos.
-
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!
-
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ó! :) :)
-
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 !
-
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
#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.
-
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
-
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!!! :P
-
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!!! :P
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!
-
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.
-
Pero sin dudas que es más fácil partir de un lenguaje "más" ANSI-C, que uno totalmente diferente, que lo único que implementa son las estructuras de control. Después a medida que vas adquiriendo conocimientos en los distintos compiladores, puedes ir dotando a tus librerías de cierta independencia con ayuda de las directivas de pre-procesador. Esta bien que teniendo una librería realizada en C18, no la vas a poder implementar directamente en C30, C32 o CodeVisionAVR, pero si casi el 90% y eso ayuda mucho. A mi me paso cuando realice la librería de FAT16 y la fui probando en distintos compiladores.
Hay que aprender a dividir entre código a nivel hardware y código de alto nivel. Yo lo divido en dos archivos fuentes distintos, entonces generalmente el de alto nivel no va a ser necesario tocarlo, pero si acomodar el de nivel hardware según el microcontrolador que dispongas.
Saludos!
-
Sisi, está claro que la parte de la lógica, salvo algunos posibles cambios de variables por cambios de arquitectora, pero lo básico se mantiene.
Lo de realizar varios archivos, lo hago, de hecho mis soft para c18 tienen decenas de archivos, cada uno con tareas muy pequeñas y específicas jeje.
Por spuesto que depende mucho dle tipo de aplicaciones en las cuales uno esté inmerso, en lo mío en general se tratan de aplicaciones de control o protocolos de comunicación, donde prima mayoritariamente el hardware. Si fueran aplicaciones diferentes, por ej, con interfaz de usuario,etc, o donde deba hacer algún cálculo entonces sí, la portabilidad sería mucho mayor. No obstante apuntaba a desmitificar el famoso latiguillo "El ANSI C es portable" porque muchos se atan de eso y luego cuando les toca la realidad se frustan , queria notar eso nomás, no cómo codificar :)
-
Hola, lo que yo entiendo de portabilidad es lo que tiene que ver con el alto nivel de una aplicación, digamos parandonos desde el uso de las funciones que provee la plataforma. Para este tipo de cosas se modulariza el código en diferentes capas o layers, la capa más baja corresponde a la interacción con el hardware( se llama HAL hardware asbtraction layer ) y ahí no te queda más remedio que hacer todo lo que decís y terminas reescribiendo todo o casi todo. Normalmente en los proyectos de mi trabajo oficial como lo de freelance que desarrollo la capa de más bajo nivel termina ocupando menos de un 20% del código total que es lo que termino reescribiendo cuando paso de arquitectura lo demás queda sin cambios. Con respecto a Linux esa es otra historia para otro post...
Saludos !
PD. Con respecto al comentario el ANSI C es portable, todo depende del compilador, pero es bastante portable, lo que no es portable es el hardware.
-
Así es, coincido con Richi... Igualmente aprender a trabajar de esa forma lleva su tiempito, pero que a la larga tiene sus frutos ;-)
Saludos!
-
Creo que se mal interpretan mis posts o no soy claro. Mis ejemplos apuntan a desmitificar la frase tan comun de que el C es portable... la gente cuando lee esa frase imagina que su código andará en todos los micros y está muy contenta...
En la realidad esto no es así y requiere varios cambios y esfuerzo para que así sea, solo eso quería rescatar, entonces quería dejar eso en claro para la gente que entra al foro y lo lee, sepa de que estamos hablando. Cuando escribo trato de pensar que el que lee no siempre es el que se las sabe todas y a veces aclarar lo que para los mas experimentados sean obviedades no está de mas.
Con lo de linux al lado de RTOS me refería al tema de que cuando uno tiene muchas tareas concurrentes se termina decantando por una solución que por debajo nos resuelva el problema, sino uno se la pasa lidiando con cosas que no hacen a la aplicación en sí perdiendose tiempo y dinero, no era la idea hablar de linux o rtos, simplemente enunciarlo en el ejemplo tal cual lo di
Saludos
-
Entiendo bien lo que decis Maunix y creo que tenes razón, e leído muchos post tuyos y se que la tenes super clara, pero eso no quita que a veces no coincida con tu forma de ver las cosas, personalmente se que soy bastante escueto al exponer mis ideas y no brindo demasiados ejemplos. Igual la idea de modularizar tiene su desventaja, ya que el código es mas grande debido que se termina llamando a una cadena de funciones y por ende menos eficiente que si lo desarrollo exclusivamente para esa aplicación.
Saludos !
PD sigamos discutiendo asi llego a los 1000 post jejejeje :P
-
Entiendo bien lo que decis Maunix y creo que tenes razón, e leído muchos post tuyos y se que la tenes super clara, pero eso no quita que a veces no coincida con tu forma de ver las cosas, personalmente se que soy bastante escueto al exponer mis ideas y no brindo demasiados ejemplos. Igual la idea de modularizar tiene su desventaja, ya que el código es mas grande debido que se termina llamando a una cadena de funciones y por ende menos eficiente que si lo desarrollo exclusivamente para esa aplicación.
Ji!, no hace falta estar de acuerdo en todo, de hecho creo que se aprende más cuando se está en desacuerdo y se exponen diferentes visiones con argumentos valederos! He aprendido mucho de los desacuerdos con otras personas, y cuando uno coincide es poco lo que se aprende :)
Incluso de un desacuerdo se puede llegar a un acuerdo en común, diferente a las 2 posturas iniciales pero que englobe lo mejor de ambas opciones planteadas !
PD sigamos discutiendo asi llego a los 1000 post jejejeje :P
jaja, dale, sino anda a la seccion de chistes y mandate uno a cada ratito y listo jajaja
yo soy viejito por aquí... es más hasta puedo decir que lo conocí a manolo en el foro cuando el todavía tenia menos de mil posts :D :D :D
-
Se entiende ;-) Por eso digo, que hay que aprender a trabajar de la manera que haga sencillo la portabilidad, no mezclar código a nivel hardware con código de alto nivel... Y que eso lleva tiempo... Quien viene y le pega una miradita a lo escrito sin entender de que se habla, no debe preocuparnos :mrgreen: pronto chocará contra una pared...
Y lo que comenta Richi también es cierto!! Que se pierde eficiencia, así que volvemos a lo mismo de siempre, la elección depende de la aplicación :tongue:
Saludos!
Edit:
yo soy viejito por aquí... es más hasta puedo decir que lo conocí a manolo en el foro cuando el todavía tenia menos de mil posts :D :D :D
Ufff.... Manolo es cosa seria! :D
-
yo soy viejito por aquí... es más hasta puedo decir que lo conocí a manolo en el foro cuando el todavía tenia menos de mil posts :D :D :D
Jajaa, me conoció con los pañales puestos :D
-
yo soy viejito por aquí... es más hasta puedo decir que lo conocí a manolo en el foro cuando el todavía tenia menos de mil posts :D :D :D
uuuf esa si que es antigüedad... yo recuerdo que nocturno apenas estaba llegando a los 4K cuando entre al foro. Uff ahora ya tiene los 4k más 10k :shock: cuántos teclados haz cambiado nocturno?? yo no se debería incrementar el contador de nocturno, o debería resetarse y volver de cero :D
-
...
hasta ahora no he tenido tantos problemas por fallas extrañas que introduce la gente que creó el compilador.
soy fan del ccs, pero también soy bastante critico por la cantidad de bugs que trae (y vaya que me burlo bastante por la cantidad de bugs que salen en cada versión).
Hola PalitroqueZ, tantos años!! La verdad admiro tu paciencia jiji, yo no podría tener un compilador que en cada versión introduzca bugs nuevos y que además deba saber cuales son... pero si eres tolerante a estas cosas, pues los de CCS estan de parabienes :D . Osea eres crítico pero lo sigues usando encima en cosas que por ahí son complejas cuando te juegas tu prestigio técnico.
Además, que seguridad o tranquilidad se puede tener, si con cada versión hay tantos nuevos bugs?
De hecho, vengo leyendo de eso desde que conozco usuarios de CCS e incluso en algú momento lo usé pero me cansé porque un codigo sencillo no se comportaba en forma clara y seguro era debido a un bug, cambié de compilador con la misma estructura de código y anduvo de primera mano...
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?
Estoy solo suponiendo, sé que muchos lo usan y les va muy bien pero bueno son dudas que siempre tuve de cómo un puede combinar ambas cosas, la incertidumbre y el conocimiento certero de que cada nueva versión contiene nuevos bugs... y la tranquilidad que uno debe tener al hacer un sistema embebido ya que uno vende algo y por ahi termina a cientos de km de distancia (incluso a paises lejanos) y me sería muy costoso tener que probar todo nuevamente con cada cambio del compilador.
Un abrazo y a seguir opinando con tan buenos argumentos que es lo que enriquece el debate!
Saludos Gran Maestre Mauricio!!!
lo mejor que tengo a mi defensa.... es que no tengo nada como defensa :D
pero para tratar de justificarlo un poco, te diré, que para mi conveniencia laboral, usar ccs es como usar windows, y todavía no me he visto en la obligación de cambiarme a ubuntu