Si además quieres enviarnos un Artículo para el Blog y redes sociales, pulsa el siguiente botón:
Hola a todos, tras trastear bastante me ha surgido una duda bastante curiosa: teniendo arduino, pinguino y similares... ¿Para que nos sirven los PICs? Segun los veo son bastante mas complicados de programar en comparacion. Cierto que se me ocurren bastantes ventajas, pero en el tema de robotica se me hace mejor un arduino que un PIC. Tampoco se mucho del tema, pero asi a ojo solo se me ocurre lo siguiente:
A favor de PIC:
Mas barato.
Puedes hacer un integrado con el y ahorrar espacio.
En contra:
Mas dificil de programar.
Menos intuitivo.
Requiere de un programador.
Se que seguramente sea una pregunta tonta, pero mi intencion es mas saber que usos tienen los PICs que entrar en una discuison sobre que es mejor de los dos.
De hecho, para empezar se podría hacer todo con una Papilio One, que seguro que gustaría en estos momentos a Maese Ranganok.
Pero como muy bien dice Furri, depende muy mucho de lo que quieras hacer. Para un aficionado o alguien que sólo pretenda testear o desarrollar algo muy sencillo muy rápido, pues una Arduino o Pinguino van estupendamente (dentro de unos límites). Pero cuano se trata de tiradas más o menos grandes, prestaciones, cosas complejas, o donde hay temas importantes de temporización/precisión/etc, generalmente acaba uno haciendo electrónica a la medida, que es donde entran los micros a 'bajo nivel'.
En lo que discrepo es en el ensamblador: para cosas más o menos de cierta envergadura, lo más rápido y eficiente es usar C (claro, con un micro 'C friendly' 😈 ). Y para cosas más complejas e ir escalando, sistema operativo tipo RTOS, FPGA, ARM's grandes, IGEP/BeagleBoard, MareNostrum, ENIAC, etc.
Ningún compilador optimiza al 100% ni en rendimiento ni en espacio. Hoy mismo me he enterado de que DigitalWrite de Arduino gasta 50 ciclos de reloj pero si intercalas el cambio de estado en ensamblador lo puedes hacer en solo 2 ciclos... no se donde lo leí pero me quedé de piedra...
El caso es que hay empresas como en una que trabajé hace poco donde van mejorando el software pero tienen que compatibilizar con los terminales antiguos (algunos fabricados hace 10 años)... el programa en ensamblador casi llena la memoria de programa, el hecho en C excede la memoria del micro.... que yo sepa probado con el compilador de C de Microchip y con CCS.
Ningún compilador optimiza al 100% ni en rendimiento ni en espacio. Hoy mismo me he enterado de que DigitalWrite de Arduino gasta 50 ciclos de reloj pero si intercalas el cambio de estado en ensamblador lo puedes hacer en solo 2 ciclos... no se donde lo leí pero me quedé de piedra...
Bueno, en realidad en lo primero estás confundiendo un par de cosas. Es cierto que digitalWrite da asco en cuanto al código que genera, pero ni muchísimo menos es culpa del compilador, sino de la librería de Arduino que define esa función de una forma muy poco óptima y redundante. Por ejemplo, se asegura que el pin es de salida comprobándolo y cambiándolo en caso de que no lo sea en ese momento, etc. También podría usarse una instrucción en C de la forma "PORTB = 0xFF;" y eso es C que el compilador compilará y optimizará si es posible (en este caso lo que he puesto debería producir una sola instrucción de ensamblador).
Yo pienso que para proyectos de cierta magnitud, el uso de ensamblador queda totalmente descartado simplemente porque no es viable. Para proyectos pequeños creo que se puede utilizar si los recuros son extremádamente limitados y/o se necesitan cumplir unos requisitos de tiempos muy estrictos, sino usaría un lenguaje de más alto nivel, ya que acelera muchísimo el proceso.
...Yo pienso que para proyectos de cierta magnitud, el uso de ensamblador queda totalmente descartado...
una cosa es lo que uno piensa (como has dicho) y otra la realidad empresarial, si el proyecto es de cierta magnitud el programa tiene que ser grande y complejo lo que puedes solucionar poniendo un pic con mas prestaciones... u optimizar todo lo posible para ahorrarte 1 euro en cada pic.
Lo mio no es una opinión, lo digo por experiencia en primera persona, he visto sacar un lector de huella dactilar con gestión de usuarios y minutias gestionado con un pic y totalmente desarrollado en ensamblador por un ingeniero superior que sabe C de sobra, el motivo... grandes tiradas.
furri.
Ahí es donde entra también la arquitectura del micro. Yo he escrito muchos programas en C para el AVR, y con el IAR difícilmente he podido mejorar algo de lo que el compilador ha hecho. Sin embargo, cuando programaba en ensamblador mi primer y único PIC (16f84, 2000-2001), el resultado del compilador no sólo dejaba mucho que desear, si no que la arquitectura ponía bastante difícil hacer las cosas.
Los cambios de banco, movimientos contínuos a/desde RAM, y el cuello de botella de un único acumulador, por no comentar la lacra del stack en HW limitadísimo, ponían las cosas difíciles a cualquier programador experimentado, así como al ensamblador.
El compilador tambien hace mucho, como pude comprobar con el IAR, GCC y el Imagecraft, pero aún así, el código quedaba muy compacto y fácil de seguir en ensamblador una vez compilado. Las posibles mejoras requieren un trabajo largo por parte de un ingeniero de SW que bien pueden costar mucho más que lo que se ahorra con un micro algo más pequeño.
No en vano, para tiradas modestas, se tiende a usar micros exageradamente grandes, ya que el tiempo de desarrollo y optimización puede ser mayor que el coste de estos micros. Máxime si hablamos de ARM's que cuestan incluso menos que el equivalente en 8 bits (como un AT91SAM7S64 comparado con un ATmega64, por ejemplo).
Un mes de un ingeniero de SW significa muchos euros, y si repartimos entre la tirada, el impacto puede ser grande: pongamos 3000€ (recordemos que lo que cuesta un trabajador no es lo que cobra a fin de més, gracias al IRPF, SS) al mes. Si la tirada de de 3000 equipos, ya tenemos un euro de más de coste por equipo. Si la tirada es de 300.000, sólo hablamos de un céntimo. Y eso sin contar el coste de mantenimiento y seguimiento de los programas, más el coste de homologación de los mismos.
