Que lenguaje de programación me recomiendan para aprender microcontroladores

[antiworldx]

No recoomiendo usar basic o pascal o cualquier otro pseudolenguaje. Cierto que es facil, pero lo malo es que he visto, que quienes inician con esas cosas, jamas aprenden C y mucho menos Assembler y acaban metidos en cada embrollo...
No recomiendo simplemente, por que si vas a programar un micro, es por que necesitas tener conocimiento del mismo.

 

[juanes79]

Gracias a todos popr las sugerencias y recomendaciones acerca de lenguaje que debo utilizar. Por todo lo que analice de sus aportes , pienso que voy a empezar por el lenguaje c. En mi trabajo basicamente lo que se hace con los microcontroladores, es programarlos para controles o secuanciadores de varias salidas ( 1,2,4,6,10,13 salidas). se programan para que estos controles manejen mangueras luminosas y hagan varas secuencias dependiendo la programación. Tambien se utilizan los micro para realizar dimerizado ( atenuacvión de la luz de forma lenta).
Los microcontroladores que se utilizan son los siguientes: pic 16f84-16f873A-16c54-12f675-
16F883.

Si conocen información que me puede servir para programar en c de manera detallada y clara o si tienen algunos diagramas o programas les pido el favor que me den a conocer estos para poder tener buen material de estudio. Los escvucho con paginas recomendadas y si conocen de algun curdso en videotutorial sobre el tema desde lo mas basico.

Saludos y mil gracias.

 

[antiworldx]

Eso si, haymucha informacion en el foro... solo es cosa que pongas en el buscador algo parecido a "controlar luces en pic" o algo similar. Creo que vi por ahi tambien un tutorial de pics y otro de C.

 

[electroconico]

Si vas a trabajar con la serie 16F ó menores te recomiendo CCS C compiler(pic c).
Si vas con familia 18F 24f , etc... C18 C30 de microchip.

Saludos!

 

[antiworldx]

apoyo la idea ...

 

[unmonje]

Yo, en primer lugar, al que no sabe nada, pero nada de nada sobre que es programar, le recomendaria que se iniciara en Pascal, si, ya se que en pascal no se pueden hacer muchas cosas (o ninguna quiza), pero recordemos que fue desarrollado especificamente como un lenguaje de aprendizaje, las declaraciones que se utilizan son muy sencillas, en realidad es muy sencillo el lenguaje en si.
Luego de aprender un poco de Pascal, y por consiguiente, programacion en general, creo que lo mas adecuado es proseguir con "C", no aconsejo assenmbler porque la verdad que lo desconozco, he visto algun codigo y me parecio engorroso, mas que nada para el que se inicia.
Bueno, ese es mi punto de vista, saludos.

Bueno, afortunadamente los PIBES que diseñan los micro ,se dieron cuenta que los programadores -mandan- y aceptaron que debian hacer micros con pocas instrucciones.
INTEL (los copiones ,lo siguieron) ,se engolocinò y tubo que pagar el precio con sus larguisimos paquetes de instrucciones.
Los programadores en tanto usaban siempre las primitivas,dejando oscioso, gran parte de la electrònica !! jajaja
De ahi salieron las PIC y otras,retornando a la vieja estructura Harvard.(banco de DATOS/banco de comandos) me encantò !!

 

[HADES]

Miren mucha yo en lo personal uso Basic y Jamas me ha dado mucho merengue a la hora de hacer progris para lecturas, stepper, o cualquier otra fumada que se me antoje sencillamente lo considero un tanto mas amigable y pues de peso tampoco en fin Yo el basic.

saludos y se cuidan ( XD )

 

[macraig]

Por corregir varias imprecisiones:

1. Con C SI TIENES EL CONTROL COMPLETO DEL MICRO. Puedes incluso incluir subloques de codigo directamente en assembler en medio de tu codigo C. Es decir puedes escribir un programa en C con determinadas partes en assembler.

2. C es mejor, por que es mas facil mantener una estructura coherente. Lo que hace a tus programas escritos en C mas faciles de mantener que los escritos en assembler. C te ayuda a consentrarte mejor en la idea que en los detalles de la implementacion, lo que se traduce en menores tiempos de desarrollo. C es portable, lo que significa que transladar programas de un micro a otro no es tan complicado como hacerlo en assembler.

3. Tu puedes saber exactamente cuantos ciclos de reloj necesita cada instruccion en C. Muchos sistemas en tiempo real se escriben en C.

Salu2.

 

[Moyano Jonathan]

Para la poderosa familia de micros AVR recomiendo ampliamente usar GCC en conjunto con rutinas en ASM.

Algo que quiero destacar es que en AVR - GCC, en caso de querer realizar las funciones en ASM no hace falta hacerlo con ASM - EMBEBIDO....algo bastante complejo en GCC....sino que escribis todas las funciones en ASM puro para AVR y luego con un archivo include declaramos todas las funciones como extern functions... entonces podés compilar directamente tus proyectos usando GCC y ASM.

 

[electroconico]

Para la poderosa familia de micros AVR recomiendo ampliamente usar GCC en conjunto con rutinas en ASM.

Algo que quiero destacar es que en AVR - GCC, en caso de querer realizar las funciones en ASM no hace falta hacerlo con ASM - EMBEBIDO....algo bastante complejo en GCC....sino que escribis todas las funciones en ASM puro para AVR y luego con un archivo include declaramos todas las funciones como extern functions... entonces podés compilar directamente tus proyectos usando GCC y ASM.

Interesante lo del ASM con el GCC, no lo he probado ni habia leído esto que comentas.

ME gusta bastantito el GCC y el atmega8

 

[juanes79]

Hola amigos, les pregunto si antes de realizar un proyecto real con pic conviene primero realizar una simulación con el programa proteus y que tan confiable o buena puede ser esta.
Espero recibir sus comentarios.

Saludos y mil gracias.

 

[antiworldx]

Hola amigos, les pregunto si antes de realizar un proyecto real con pic conviene primero realizar una simulación con el programa proteus y que tan confiable o buena puede ser esta.
Espero recibir sus comentarios.

Saludos y mil gracias.

Nooooooooooooooooooooo! Proteuss es "SCRAP"!!!!

Usa depurador... Yo ni si quiera apoyo la revision de codigos simulados en proteuss.

P.D. ATmega y dsPIC son mis dos pulgares de batalla.

 

[electroconico]

Proteus para cosas relativamente sencillas,te puede romper la cabeza con sus fallos , me ha pasado que en proteus no sirve mi aplicación y al desesperarme lo montaba en físico y uhh andaba joya y también al revés

Saludos!

 

[antiworldx]

"El mundo feliz de proteuss"... Todo funciona en proteuss, pero a la hora de la verdad... Sorpresa!!! Me he encontrado errores en los programas revisados, como el hecho de que el codigo quiere acceder zonas de memorias inexistentes en el microcontrolador, y proteuss simplemente, lo ejecuta, creando zonas de memoria DE LA NADA!!!. Ese es uno de los mas comunes, entre otros que me hizo pensar que proteuss es solo un hobbie de dummys.

 

[Dr. Zoidberg]

Ese es uno de los mas comunes, entre otros que me hizo pensar que proteuss es solo un hobbie de dummys.

Muy parecido a eso!!!!!

El problema real es que Proteus solo es una herramienta, pero la mente del diseñador debe estar detrás de ella para saber usarla correctamente. En las escuelas y universidades, muchos docentes han tomado la estúpida decisión de usar una herramienta de simulación como un banco de pruebas real...y mas allá de los errores de Proteus, no se enseña como simular correctamente...y mucho menos se enseña como realizar pruebas reales en un circuito digital armado....Total, en Proteus ponen el osciloscopio y ya está...sale el dibujito, pero si hacés lo mismo en el circuito real, la ondas dejan de ser "cuadradas", se alteran las frecuencias de los osciladores, intentan usar el osciloscopio como un analizador lógico (y si lo logran, son MAGOS!)...en fin...toda una sarta de tonterías y problemas que con las herramientas de simulación no existen...Ohhh...que COOOOOOOL!!!!

 

[ByAxel]

El problema real es que Proteus solo es una herramienta, pero la mente del diseñador debe estar detrás de ella para saber usarla correctamente.

Coincido.

En las escuelas y universidades, muchos docentes han tomado la estúpida decisión de usar una herramienta de simulación como un banco de pruebas real...y mas allá de los errores de Proteus, no se enseña como simular correctamente...

Gran problema.

Total, en Proteus ponen el osciloscopio y ya está...sale el dibujito, pero si hacés lo mismo en el circuito real, la ondas dejan de ser "cuadradas", se alteran las frecuencias de los osciladores

Te respondo con:

Proteus solo es una herramienta, pero la mente del diseñador debe estar detrás de ella para saber usarla correctamente.

1ro Mi experiencia; en mis 4 añitos con los microcontroladores solo he tenido tropiezos los primeros 6 meses, luego me salido todo bien (simular y llevar el circuito a lo real) ¿Por que? no se... será que gracias a todo lo que aprendí con la eléctrónica y la experiencia de probar y probar con todo!! tal vez.

2do:

pero si hacés lo mismo en el circuito real, la ondas dejan de ser "cuadradas", se alteran las frecuencias de los osciladores, intentan usar el osciloscopio como un analizador lógico (y si lo logran, son MAGOS!)...en fin...toda una sarta de tonterías y problemas que con las herramientas de simulación no existen...Ohhh...que COOOOOOOL!!!!

Para empezar yo no le veo punto de inicio para criticar al "simulador" (no lo defiendo) ya que en un circuito real hay muchas más variables a tomar en cuenta que por lo general son evitadas... digo ¿Un transistor del mismo tipo es exactamente igual a otro del mismo tipo? NOOO... el simulador precisamente el Proteus simula eventos "Ideales", muy pocos reales y si pudiera seria el señor simulador que solo pudiera correr en una PC de última generación que solo las universidades más prestigiosas lo pudieran obtener!!! exagero? Si pero es la verdad...
Más nada, todo eso solo es tu punto de vista y personalmente uso ambas cosas (Simulo y prueba real) no dicen que ¡la práctica hace al maestro! pero admito que últimamente no necesito simular nada o hacer una prueba real ya que estoy seguro de que va a funcionar ¿Por que?... al parecer he aprendido de una forma distinta a adelantarme a los sucesos de algún circuito que haga; yo creo que esa pueda ser la iniciativa de los docentes -no se- pero ¿quién dice que el método para aprender siempre va a ser el mismo para todos?...

En fin, todo esto solo respecto a este simulador, no pretendo englobar todo...
salu2

 

[unmonje]

"El mundo feliz de proteuss"... Todo funciona en proteuss, pero a la hora de la verdad... Sorpresa!!! Me he encontrado errores en los programas revisados, como el hecho de que el codigo quiere acceder zonas de memorias inexistentes en el microcontrolador, y proteuss simplemente, lo ejecuta, creando zonas de memoria DE LA NADA!!!. Ese es uno de los mas comunes, entre otros que me hizo pensar que proteuss es solo un hobbie de dummys.

jajajja...para simplificar....me quedo con ASM...siempre se que funciona...!!
(solo confio en lo que yo programo)

Por corregir varias imprecisiones:

1. Con C SI TIENES EL CONTROL COMPLETO DEL MICRO. Puedes incluso incluir subloques de codigo directamente en assembler en medio de tu codigo C. Es decir puedes escribir un programa en C con determinadas partes en assembler.

2. C es mejor, por que es mas facil mantener una estructura coherente. Lo que hace a tus programas escritos en C mas faciles de mantener que los escritos en assembler. C te ayuda a consentrarte mejor en la idea que en los detalles de la implementacion, lo que se traduce en menores tiempos de desarrollo. C es portable, lo que significa que transladar programas de un micro a otro no es tan complicado como hacerlo en assembler.

3. Tu puedes saber exactamente cuantos ciclos de reloj necesita cada instruccion en C. Muchos sistemas en tiempo real se escriben en C.

Salu2.

Comparto en general...pero al final,con todas las ventajas,personalmente me quedo con ASM!!
Respecto a -portable- que es un exelente argumento para grandes sistemas ,no se me da en PICs !!! Hice mucho en C...pero me aburre esperar a escribir todo el còdigo. jajaja

 

[Dr. Zoidberg]

2do:
Para empezar yo no le veo punto de inicio para criticar al "simulador" (no lo defiendo) ya que en un circuito real hay muchas más variables a tomar en cuenta que por lo general son evitadas... digo ¿Un transistor del mismo tipo es exactamente igual a otro del mismo tipo? NOOO... el simulador precisamente el Proteus simula eventos "Ideales", muy pocos reales y si pudiera seria el señor simulador que solo pudiera correr en una PC de última generación que solo las universidades más prestigiosas lo pudieran obtener!!! exagero? Si pero es la verdad...

Yo no critico al simulador...y de hecho, a veces uso un simulador si pretendo diseñar algo que no es muy trivial. Lo que yo critico es el uso indiscriminado que se hace de una herramienta y la falta de entendimiento de quienes la usan, sobre todo para comprender sus limitaciones y aprender a modificar el comportamiento de los dispositivos que participan en el modelo simulado.

El otro problema es que simular "cosas digitales" es relativamente simple, por que hay poco para tocar, a menos que se trate de código programado o frecuencias de reloj o ciclos de trabajo. Pero en simulación analógica si se pueden representar las "diferencias" entre componentes y por ejemplo, hacer un barrido entre valores de hfe para ver como se comporta el circuito cuando cambio los componentes, o barrer en ft para pobar la estabilidad de un circuito...y esto es lo mas valioso de la simulación - al menos para mí - pero es lo que poca gente sabe explotar...y NO, no hace falta una PC de ultima generación ni mucho menos para usar este tipo de simuladores. Yo he usado - hace tiempo ya - una versión de PSPICE para probar un simulador de ondas de ECG...y lo corría bajo DOS en una PC 486DLC de 16Mhz. Pero claro, no tenía editor gráfico y había que definir a pedal y numerar a mano los nodos del circuito...pero tampoco era algo de otro planeta.

 

[Beamspot]

Generalmente, el simulador nunca me ha servido más que para encontrar respuestas frecuenciales en analógica.

Apoyo el C y el GCC, pero para entender de que va esto, es necesario un conocimiento de ensamblador. Escribir código largo es mucho más rápido y eficiente en C, más fácil de mantener, y más 'portable' (esto depende mucho de cómo lo escribas).

Por desgracia, el C es como una gruesa alfombra bajo la cual se esconden muchas veces las miserias y virtudes de los micros, pasando desapercibidas. El ensamblador desvela muchos misterios.

Personalmente, C, AVR, ARM Cortex M3, PCB directa (nada de protoboards, simulaciones ni historias), y muchas horas de echarle vueltas.

Por cierto, yo tampoco apoyo el autoruteo de PCB's. Estoy hasta las narices de tener que solucionar problemas porque alguien que de ingeniero no tiene más que un papel lo usa hasta las narices, y luego, al no funcionar nada, me toca a mí el solucionar los problemas 'extraños' que tiene. Especialmente porque todo le funciona correctamente en su simulación de proteus, y luego en la realidad, 'pierde los voltios por el camino'.

 

[ByAxel]

Apoyo el C y el GCC, pero para entender de que va esto, es necesario un conocimiento de ensamblador. Escribir código largo es mucho más rápido y eficiente en C, más fácil de mantener, y más 'portable' (esto depende mucho de cómo lo escribas).

Por desgracia, el C es como una gruesa alfombra bajo la cual se esconden muchas veces las miserias y virtudes de los micros, pasando desapercibidas. El ensamblador desvela muchos misterios.

Personalmente, C, AVR, ARM Cortex M3, PCB directa (nada de protoboards, simulaciones ni historias), y muchas horas de echarle vueltas.

Cierto.
Por lo menos ASM y C para evitar que algo funcione por MAGIA... y por cierto para los ARM ¿es cierto que no tiene caso programar en C? leí que se escribe menos código en asm que en C... eso del Thumb Instruction Set me gusto!!, me equivoco?

Por cierto, yo tampoco apoyo el autoruteo de PCB's. Estoy hasta las narices de tener que solucionar problemas porque alguien que de ingeniero no tiene más que un papel lo usa hasta las narices, y luego, al no funcionar nada, me toca a mí el solucionar los problemas 'extraños' que tiene. Especialmente porque todo le funciona correctamente en su simulación de proteus, y luego en la realidad, 'pierde los voltios por el camino'.

muy cierto.