TODOPIC
Microcontroladores PIC => Todo en microcontroladores PIC => Mensaje iniciado por: MA_BLACK en 25 de Enero de 2006, 13:51:00
-
Buenas despues de programar pics en asembler, C, y basic no se por cual decidirme, alguien me puede hechar una mano diciendome las ventajas e incombenientes de cada uno, gracias.
-
Hola MA_BLACK, cada cual tiene sus pro y contra:
El .asm es mas complicado de programar que los otros dos, pero para realizar las mismas funciones el programas en .asm ocupa menos capacidad de memoria del PIC, aparte en el .asm es mas fácil controlar los tiempos de cada proceso.
El C y el Basic son mas sencillos a la hora de realizar un programa, también son mas fáciles al momento de migrar de micros. También por la complejidad del .asm para los programas de la familias superiores (18F, dsPIC, rfPIC, etc) se utiliza mas el C.
Al momento de conseguir información para realizar un programa el .asm lleva la delantera, seguido muy de cerca por el C y por ultimo el Basic.
Creo que si tu sabes programar en los tres idiomas, sabrás cual te conviene usar al momento de realizar un proyecto, tanto por comodidad, precisión o capacidad de memoria.
Espero te sea de utilidad. Suerte.
Atte. CARLOS
-
C
-
Hola:
Eso queda a tu gusto, con el que mas te identifiques y el que mas te guste, yo me quedo con el basic...
-
Buenoooo vengaaaa ... hazle caso a LordLafebre y su PicBasicPro (él es sabio) pero después trabaja con C (







)
-
Je je....
Pese a que fue C el primer lenguaje que aprendi, pero nunca a nivel de pics, sino solo a nivel de PC... me gusta tambien C... pero para los que no sabemos mucho de pics, el basic tiene funciones muy sencillas y completas que hacen que la programacion sea mas facil y rapida... pero no descarto migrar a C en un tiempo no muy lejano...
-
Hola:
Esto de los lengujes ya se trató en otra pregunta y la conclusión es:
el que programa en C se queda con C y que no le den otro.-
el de basic igual.-
el de assembler sigue defendiendo el tema de vlocidad,espacio de memoria y todo eso.-
Me parece que el ideal para programar es el que a uno le viene cómodo ,aunque consuma mas memoria o sea mas lento ¿?.
Lo que muchos dejan de lado y se habría que aprender bien es el tema del diagrama de flujo ,que es lo nos permite estructurar mejor los programas .-
Saludos
Jorge
-
Escrito originalmente por MA_BLACK
Buenas despues de programar pics en asembler, C, y basic no se por cual decidirme, alguien me puede hechar una mano diciendome las ventajas e incombenientes de cada uno, gracias.
Mira, siempre es depende el gusto.... pero no siempre.
Si yo fuera tu, te diría USA el C en casi todos los casos y cuando tu software no quepa en el pic que estes usando y "se justifique" por costos no cambiar el PIC entonces usa el assembly.
Para aplicaciones de mucha E/S de datos lo mejor es el assembly.
Para aplicaciones donde el manejo de informacion o de operaciones lógicas es importante (o de operaciones matemáticas) lo mejor es el C.
Si además sabes combinar C y assembly, estas de parabienes 
El basic.... dejalo, no se lo recomiendo A NADIE, es algo para niños.
-
Buenas. Voy a aportar mi granito de arena.
Yo antes era defensor del ASM, por todas las ventajas que se comentan arriba. Desde que he empezado a utilizar el C30, no lo cambio por nada. Te pongo un ejemplo:
a = b *c;
Con esta expresión a simple vista tan sencilla y suponiendo que sean números enteros de 8 bits sin signo, indudablemente en ASM se tarda muchisisisimo más, porque en C es tan simple como eso.
Que pasaría si después de hacer nuestro código decidimos trabajar con números de 16 bits, porque los 8 se nos quedan cortos(me ha pasado en asm). Pues en C no cambia prácticamente nada y en ASM es código nuevecito.
Otra ventaja muy importante es que los micros nuevos 18F, dsPIC, etc, tienem un juego de instrucciones que son bastante complejas y difíciles de aprender. Con C no cambia nada. Puedes portar fácilemtne programas de un micro a otro. además con los 144KBytes de memoria de programa que tiene un dsPIC, ni haciendo el programa más complicado que querais le haceis cosquillas.
En resumen no cambio ya el C ni para hacer parpadear unos LEDs. 
Eso sí, cada uno que use el que más le guste
-
bueno amigo.... yo enmi caso he pasado por un poco de todo para aprender.... y en definitiva a mi gusto por lo menos me quedare definitivamente con el c... las razones son bastantes y como dice antoniof la portabilidad y compatibilidad entre micros es genial.... en realidad casi no tienes que preocuparte de elegir el micro a usar mientra estas desarrollando, por que yo en mi caso veo lo que necesito hacer, hago el programa y despues elijo el micro deacuerdo de como haya quedado el programa..... la verdad muchas veces me paso que estaba con ASM y derrepente me quedaba sin capacidad de memoria y tenia que transformar gran parte del soft para poder adaptarlo, en cambio en C un par de retoque y ya esta......
en conclucion si es por recomendarte algo, sin duda quedate con el C, es lo mas practico amigo....
-==XooTRAooX==-
-
Escrito originalmente por xootraoox
bueno amigo.... yo enmi caso he pasado por un poco de todo para aprender.... y en definitiva a mi gusto por lo menos me quedare definitivamente con el c... las razones son bastantes y como dice antoniof la portabilidad y compatibilidad entre micros es genial.... en realidad casi no tienes que preocuparte de elegir el micro a usar mientra estas desarrollando, por que yo en mi caso veo lo que necesito hacer, hago el programa y despues elijo el micro deacuerdo de como haya quedado el programa..... la verdad muchas veces me paso que estaba con ASM y derrepente me quedaba sin capacidad de memoria y tenia que transformar gran parte del soft para poder adaptarlo, en cambio en C un par de retoque y ya esta......
en conclucion si es por recomendarte algo, sin duda quedate con el C, es lo mas practico amigo....
-==XooTRAooX==-
Quisiera aclarar a nuestro amigo que preguntó sobre el lenguaje, que la parte portatil del C es la relativa a la lógica. La relativa a puertos y hardware no es tan "transparente". Hay que tener en cuenta varias cosas.
También aconsejo el C pero como dije antes, no es la panacea! No hay soluciones mágicas cuando se trabaja en diseños "embebidos"... , hay que lidiar directamente con el hardware y es ahí donde cada microcontrolador cambia por eso no es tannn obvio programar en pics o los microcontroladores que sean.
De todas formas siempre C es la opcion más facil de portar a cualquier sistema.
Saludos
-
Antonio, bienvenido al C, me alegro que hayas abandonado el lado oscuro de la fuerza.
-
Escrito originalmente por nocturno66
Antonio, bienvenido al C, me alegro que hayas abandonado el lado oscuro de la fuerza.
Creo que en los microcontroladores el Assembly no se abandona más, si uno va a usar mucho acceso a puertos.
A lo que voy es que por ejemplo en los pic16 yo ya tengo tantos macros creados que no me es cómodo usar ningún compilador de C y no me he visto forzado a utilizar matemática de coma flotante asi que he venido de para bienes.
En cuanto al C, lo uso bastante en los PIC18 pero a veces necesito un par de líneas en assembly... es bueno usar el C pero usar assembly no es "malo"... es depende de como uno codifique.
La forma "normal" o "mas comun" en que la gente codifica en assembly hace imposible migrar el código entre microcontroladores o entre diferentes software! Pero eso depenede más del programador (la persona sentada frente a la computadora) que de la potencia del lenguaje en sí.
Por ejemplo, casi nadie usa código reubicable en assembly... de los que lo utilizan unos pocos menos saben como trabajar con el linker... y de ahí en mas pocos saben realmente reutilizar el código fuente.
De todas formas, en el caso del ejemplo del tipo A = B * C queda a claras la potencia del C cuando se quiere dar una solución en forma rápida. Así y todo si uno tiene las rutinas para multiplicar en 8 bits o en 16 bits y las tiene armadas como un macro, solo hace falta cambiar el nombre del macro y LISTO! pero como dije antes pocos o casi nadie programa de esa forma.
Saludos
-
Jejeje Nocturno he pasado con tu ayuda de Dark Vader a Anakin Skywalker en menos de un mes
. Ni George Lucas lo hizo tan rápido.
Amigo maunix, creo que la gente que desarrolla los compiladores de C para pic sí trabaja a ese nivel con ASM. Gracias a ellos, podemos disfrutar de las comodidades del C y de todos los lenguajes de alto nivel.
-
Escrito originalmente por antoniof
Amigo maunix, creo que la gente que desarrolla los compiladores de C para pic sí trabaja a ese nivel con ASM. Gracias a ellos, podemos disfrutar de las comodidades del C y de todos los lenguajes de alto nivel.
Por supuesto que esto es así, el punto al que yo iba era otro.
Vamos a ver si se me entiende:
En sistemas embedded donde uno se acerca mucho al hardware el C no es la panacea!
Traten de cambiarse de un pic 18F4580 a un 18F458 , con ese simple cambio y tendrán que lidiar con muchas configuraciones de clock "a medida" . Me explico?
Estas cuestiones en las PC las resuelve el sistema operativo, y es ahí donde las ventajas de la portabilidad del código son mas evidentes! Son los "drivers" los que lidian con las diferencias de hardware dandole al programador siempre la misma interfaz de programacion.
Por otra parte, si uno programa en assembly con subrutinas con código reubicable, con macros que realicen ciertas funciones importantes luego el código puede ser realmente muy portable y muy similar a lo que es un C.
De hecho compiladores de C como el CCS realmente parecen un lenguaje de macros y no un compilador Ansi C!
Repito:
. Uso el C cuando puedo sobre todo en los PIC18.
. Uso el assembly en los PIC16 principalmente porque tengo infinidad de módulos y subrutinasy macros ya armados y funcionando a la perfeccion hechos en assembly, yo le paso un par de parámetros y la rutina me resuelve todo.
. Aconsejo simpre a utilizar el C pero tambien a "conocer algo del assembly" o al menos de los módulos ya que si algo no funciona es ahí donde debemos recurrir.
Espero haberme puesto más en clar.
-
Coincido con el cordobés, pero en definitiva son necesidades específicas las que te van a obligar a usar assembler, en ocaciones es necesario sacrificar la comodidad de un lenguaje de más alto nivel para obtener vlocidad o hacer un código más compacto.
Creo que el proyecto es el que define el lenguaje a usar.
Saludos.-