SoloCodigo

Saludos a todos! En vista de algunas diferencias que existen entre la conveniencia de programar micros en C ó asembler, me tomo la libertad de abrir ésta nueva discusión.
La idea es ir sacando cosas en claro, y exponer aquí nuestras experiencias. En primer lugar, para no confundir y desanimar a los que comienzan  Segundo, para ampliar nuestros conocimientos.
Bien, en lo posible seamos imparciales y objetivos...

Comienzo: recién comparé dos rutinas relacionadas con el manejo de un display LCD, una de inicialización del display y la otra para escribir un dato en el display. Las rutinas fueron escritas en asembler y en C (compiladas con el CCS C), están probadas, y realizan exactamente la misma función.
Resultados:
En C, las rutinas me ocupan 106 y 78 bytes para la inicialización y la escritura, respectivamente; en asembler, 66 y 68 bytes. Tengo 40 bytes menos (en asm) para la inicialización, y 10 menos (en asm) para la otra rutina.
Conclusión (mía):
*En asm necesito menos ROM.
*En C fué mucho más rápida y simple la escritura del código.

Bien, compartan sus opiniones, y entre todos encontremos las pautas para definir cuál es la herramienta más conveniente para cada proyecto que iniciemos.

Saludos

Conclusión (mía):
*En asm necesito menos ROM.
*En C fué mucho más rápida y simple la escritura del código.

Es obvio. Asm es lenguaje de máquina, es más tardado hacerlo en Asm que en C.

Ya lo sacaste tu solo:
Asm es mejor pero más tardado, C es más rápido pero se necesita más ROM.

{una cosa más aprendida en este día }
 

Esta ves no hare comparacion entre C y ASM como suguiere Tirol les hablare de mi experiencia en C.
Yo he usado tres tipos de compilador C para el desarrollo de proyectos profecionales.

1.- CCS para Pics.         calificacion "Regular"  precio us$ 1000 aprox.
2.- ICC para Atmel Avr  calificacion "Optima"   precio us$ 700 aprox.
3.- IAR para ARM core   calificacion "Una Maravilla" precio us$ 2000 a us$ 5000 aprox.

CCS:
Lo Malo:
No es standar ANSI la columna verterbrar de un progama escrito con este compilador no es portable a micros de otras marcas,requiere de manuales del fabricante ya que todo el manejo del hardware viene soportado con funciones tipo CUSTOM, no trae optimisador de codigo para ahorrar memoria.
Lo Bueno:
La ultima version maneja toda la familia Pics,las librerias Custom configuran con eficiencia casi todos los modulos de hardware para luego solo interactuar con ellos.

ICC:
Lo Malo:
La documentacion de fabricante es deficiente.
Lo Bueno:
Full ANSI, todo lo leido en los libros standar de C (ej: El lenguaje de programacion  C autor Dennis M Ritchie ) corre en este compilador,con pequeños cambios he portado funciones hacia otros micros, tiene optimisador de codigo con un algorismo  bastante eficiente para ahorrar memoria.

IAR:
Lo Malo:
Aun no lo encuentro.
Lo Bueno:
Este compilador es un caso especial sumando las caracteristicas de ICC y varias otras mas, nos permite progamar en C,C++,POO.Para los que dominan programacion POO se daran cuenta la potencialidad de este compilador para realizar proyectos de altas prestaciones.

Saludos.

Tengo rato sin programar un PIC (y nunca lo he hecho en C), pero la mayoría sabemos que el código en C resultará en algo más de espacio.

Mi idea es, hay que aprender ASM para entender "cómo" trabaja el microcontrolador en cuestión.

Para proyectos grandes, quizá sea mejor trabajarlos en C y posteriormente optimizar partes del código usando ASM (porque supongo que los compiladores que existen deben permitir embeber código ASM).

Por cierto, la razón por la que hace tiempo no programé con C (no tenía necesidad de programas complejos y con ASM me la podía pasar) es por el enorme costo de las herramientas que encontré, ¿me podrían pasar enlaces a las herramientas que conocen (ojalá cuenten con alguna versión demo)?

También, hace tiempo leí algo por allí de un compilador llamado AnyC, pero nunca encontré nada que se pudiera usar (descargar).

Saludos,
José Jorge (Geo).

OTRA COSAA..

LA COMPATIBILIDAD DEL CODIGO EN C HACEN DE C ALGO INTERESANTE, EMIGRAR DE UN MICRO A OTRO ES MUY FACIL Y NO REQUIEREN MUCHOS CAMBIOS, EN ENSAMBLADOR SI QUISIERAMOS EMIGRAR EL CODIGO TMB NO ES COMPLICADO PERO NOS HACE OJEAR EL DATASHEET UN PAR DE VECES PARA SABER COMO ESTA MAPEADA LA RAM PARA REDIRECCIONAR ALGUNOS REGISTROS. EN C A VECES NI ES NECESARIO VER EL DATASHEET EN MUCHOS DE LOS CODIGOS.

UN DUDA DICEN QUE EN C LOS RETARDO NO SON TAN EXACTOS COMO LO SON EN ENSAMBLADOR?? A MI NO ME CONSTA REALMENTE NO SE SI ASI LO SEA OJALA ALGUIEN PUDIERA RESOLVERME ESTA DUDA, SERIA UN PUNTO A FAVOR DEL ENSAMBLADOR.....

NO ATACO EL ENSAMBLADOR AL CONTRARIO ME GUSTA PROGRAMAR EN ENSAMBLADOR, CREO QUE TIENES UN MAYOR CONTROL DE TODO EN ENSAMBLADOR ENTIENDES COMO TRABAJAN LOS PICS POR QUE TODO QUEDA EN EVIDENCIA Y ENTENDER LA ARQUITECTURA DE LOS PICS ES MUCHO MAS SENCILLO SI SE PROGRAMA DESDE ASSEMBLER......

SALUDOS

Hola!
No se si viene al caso, pero durante esta última semana he estado haciendo un curso en la central de B&R (Bernecker & Rainer, Eggelsberg, Austria; http://br-automation.co.at), empresa dedicada a la electrónica industrial. Y para sorpresa mia me encuentro con que los PLC de esta marca tienen la posibilidad de ser programados en C (ANSI C).
No soy un experto programador en C, pero esto me viene mejor que bien!! Puedo programar en el PLC funciones con, por ejemplo, complicados cálculos matemáticos sin tener que matarme en AWL (asembler para PLC). Es más, puedo crear mis propias librerias en C, y luego usar las funciones en KOP (ladder, lenguaje de contactos)
No estoy al tanto, pero según intercambios con otros compañeros de curso, Siemens aún no ofrece esta posibilidad. Aunque hay que reconocer que Siemens ofrece una biblioteca de librerías mucho más completa...
Bueno, se que entre un micro y un PLC hay algo de diferencia, en especial si miramos con suma atención el encapsulado(!); pero si a la hora de programar todos hablamos el mismo idioma, no hay gran diferencia.

Si bien esto no tiene nada que ver con los microcontroladores, quiero comentarlo para que sirva de incentivo a los que estan en la duda. En su momento estaba muy pegado al asembler, despues fui descubriendo las ventajas del C... Y ahora me pregunto por qué no le tome la mano un tiempo antes!

Bueno, tengo un par de proyectos atrasados ; pero creo que me gano algo de tiempo haciéndolo en C. Y mientras esté en este proyecto tengo dos PLC a disposición... Ya les comento las experiencias y conclusiones.

A meterle con el C, pero sin hecharle tierra al asembler (o al KOP )

Saludos

Saludos! He vuelto a este hilo, porque "donde dije digo, digo diego" es un dicho de mi pais, lo que viene a decir es que he cambiado mi opinion, desde que he empezado con C, asm es ese oscuro pasado en el que programar era tedioso y pesado.

He realizado aplicaciones en C y todas me han ido bien, sin falta de memoria ni de tiempo, aunque tampoco ha sido algo de muy alto nivel. Y tiene grandes ventajas, como la mayor facilidad para el desarrolo y el hecho de que es mas facil que cualquiera te eche una mano al ser mas legible.

Ademas al aprender C, el pasar no solo de una familia a otra, sino tambien cambiar de marca de micrcontrolador parece mas facil.

La serie 18F de microchip ya esta optimizada para C, y a partir de esta todas las posteriores: la 24F y los dspic, que son las mas modernas por ahora.

De todas formas la comparacion de Motorola y Microchip tiene como claro ganador a Motorola, aunque tambien hay que ver los sectores del mercado a los que se dirigen...

Saludos!

bueno, la verdad es que encuestion de microcontroladores no me parece que exista un ganador sobre otro... usar un potente microcontrolador Motorla para realizar una temporizacion simple para apagar un dispositivo me parece un total desperdicio de HW. Los Motorolas desde su concepcion son uCos muy buenos, pero cada diseñador debe escoger el mejor micro que se ajuste al circuito, asi como el mejor lenguaje de programación. Yo particularmente uso ambos, por todo lo expuesto en este post por los demas participantes... hacer un PWM o una adquisicion AD es mucho mas facil con C que con assembler (un par de instrucciones) , pero es muy recomendable saber programar en bajo nivel para poder corregir ciertas cosas que el C no permite, o que prefieres hacerlas de una forma mas eficiente... alguna aplicaciones de tiempo crítico requieren tener el código bien controlado y eso sólo lo consigues con asm... yo enseño cursos de Pics y yo siempre comienzo con assembler para despues pasar al C...

Bueno, despues de muchisimo tiempo sin postear por aqui me encuentro esta discusion, que personalmete creo que es algo que está mas que hablado y que todo el mundo tiene claro, pero veo que no.

En resumen, C sin dudarlo, y como explicare mas adelante no es cuestion de cual es mejor o peor, por que esos son terminos muy relativos. Mis cometarios estan basados en mi experiencia profesional.

Eficiencia del codigo: ¿Como?¿C mas eficiente que ASM?jajaja... Seguro que pensareis. Pues lo cierto es que en la muchos casos puedes conseguir código igual de eficiente en C que ASM por dos razones fundameltanmente:
1-Un buen compilador es capaz de optimizar el codigo MUCHO, incluso mas que una persona. Tened en cuenta que el codigo al final es un grafo de operaciones que puede ser optimizado mediante algoritmos, y los compiladores mejoran cada dia, así que sobre todo en codigos largos podemos optener optimizaciones muy buenas.
2- La librerias. ¿Eres un experto en metodos numericos?¿Estas seguro que tu algorimo es el mas eficiente?¿Seguro? Para muchas aplicaciones, sobre todo de cálculo, el uso de librerias especializadas nos aseguran que estamos utilizando los algoritmos mas eficientes para las operaciones que utilicemos. Es imposible e ineficiente, incluso para un ingeniero experto y con conocimietnos de metodos numericos, recordar o ponerse a buscar que metodos es el mas rapido para tal operación, o cual necesita menos memoria, etc...

Tiempo de desarrollo: El tiempo de desarrollo es fundamental para cualquier producto comercial, por varias razones. La primera es que obviamente a mas tiempo de desarrollo mas costoso sera el sistema. La segunda el el time-to-market, es decir, que mientras antes tengamos nuestro producto acabado, menos competencia tendremos. La tercera el la presión de los clientes: en el caso de que sea un sistema encargado, los clientes se ponen muy nerviosos conforme pasa el tiempo, les gusta tener resultados rápido. En muchos casos, sobre todo en empresas en las que se hacen series pequeñas (menos de 5000 unidades) el tiempo de desarrollo es clave, ya que los gastos de ingenieria suponen una parte muy importante de el coste final de producción: Ejemplo:

Mayor dificultad para integrar tu codigo con un sistema operativo: esto esta relacionado directamente con la eficiencia, ya que si no podemos utilizar un sistema operativo, muy buenos y listos tenemos que ser para que nuestro programa en ASM sea capaz de ejecutar eficientemente (sin esperas activas, con tiempos de respuesta controlados, aprovechando de forma dinámica los modos de bajo consumo....) varios procesos simultaneamente. Ademas la API de los SO siempre es en C.

Por que ninguna empresa te va a pedir que programes en ASM: quizás te pidan en la oferta de trabajo que sepas ASM, pero despues es muy raro programar algo en ASM, así, que para el caso, como la mayoria estais aprendiendo, deciros que lo mas problable es que si llegais a trabajar en desarrollo de sistemas embebidos nunca utilizareis ASM.

Por que la tendencia en sistemas embebidos son los sistemas con Linux embebido: es la tendencia, cada vez son mas baratos, en pocos años por el precio de PIC podrás comprar un micro capaz de mover Linux (hay ARM de 3€ y pico capaces), esto no es "usar Linux por que si", usar un SO tan avanzado permite implentar facilmente una series de funcionlidades en nuestros dispositivos que hace unos años no pensabamos que fuese posible.

Bueno, de todas formas tambien quiero dejar claro que existe la posiblidad de que una determinada aplicación se tenga que usar ASM. Despues de tanto rollo no he comentado una cosa que en realidad es la clave, la decisión de si se va utilizar ASM o C en un produto se toma siempre como resultado de un estudio economico del proyecto, así que en determinados casos puede resultar la opcion adecuada. Lo que pasa es actualmente siempre se quiere mucha funcionalidad en el sistema, y esto hace que ASM siempre pierda, por su mayor tiempo de desarrollo sobre todo.

Resumen:
mas funcionalidad = mas codigo
tiempo desarrollo ASM = 10*tiempo desarollo C
tiempo de desarrollo = coste, +competencia
C es reusable
ASM no es reusable
ASM mala integracion con SOs
escasa diferencia de precios entre micros mas y menos potentes


Saludos,
adc

Hola:

La mejor explicación clara y razonable que he visto sobre el C vs ASM. Sobre el sistema C# es bueno saberlo, también estoy aprendiendo ese lenguaje nuevo y es bueno saberlo. Si me permite, haré un copy & paste a otros foros sobre tu comentario cuando lo vuelvan a decir.

Bajo mi punto de vista, aprender ASM primero, luego al meterte con el C, entenderás más cosas y será más eficiente en aprendizaje. No todos los PIC cabe el código C, por falta memoria, RAM, etc. Trabajos pequeños ASM, grandes C.

Muy buen aporte, los que quieran aprender ASM que en las universidades utilizan es ASM, http://www.pic16f847a.com

Quiero hacer un SO en ASM como el Windows, pero en C me parece más fácil y en menos tiempo aunque no sea tan eficiente que el ASM.

Por algo será que se crea los lenguajes de alto nivel.

Un cordial saludos.