Primeros pasos con microcontroladores

[Hellmut1956]

Hay placas Arduino que tienen casi que el tamaño del avr utilizado. En si una placa Arduino no es mas que el controlador sacando sus pines a aquellos de la placa. Antes yo hacía mis propias placas usando el mega8, hoy con esas placas de provinencia China el esfuerzo no se justifica para mi.
Si te entiendo bien, el controlador puede ser grabado con programas de algún compilador siempre y cuando no se necesita usar funciones periféricas del controlador. Para un novato familiarizarse en los detalles de como ejecutar el compilador ya puede ser reto. Por dar un ejemplo propio, hasta el día de hoy no se configurar un entorno Eclipse. Por eso me limito a utilizar tales herramientas que en su instalación ya configuran el "Eclipse"!
La otra cosa que me llevo a comprar herramientas de la empresa Jetbrain es usar esta herramiento en el entorno de mi PC y definir como compilador o interpretador por ejemplo en un Raspi. La programación en Python fue lo que me llevo a decidirme por las herramientas de ese proveedor.

 

[TRILO-BYTE]

Bueno yo me refería a pasos con microcontroladores.
No estoy diciendo que afueras entres con Arduino.
A mí experiencia me ha tocado reparar algunos aparatos con pic de la familia 12
Es cierto que son muy limitados en RAM es cierto que Arduino ofrece las perlas de la virgen y un montón de chinaderas , pero hay aparatos que existen y tienen un pic de la familia 12 y con una reprogramación quedan como nuevos o hay que cambiar el pic y hacer un programa nuevo y queda reparado.

Yo no me meto tanto en detalles de ASM me gusta usar lenguaje C y pues a sacarle jugó al C que si tiene versatilidad.

Ojo ya no defiendan a Arduino solo digo que hay que ser flexibles.

 

[pandacba]

Trilo lo que tu propones no es que este mal, pero si te escucharas, todo lo que hablas es de quien ya sabe programar, para quien desea empezar es chino básico.......
Arduino fue echo para las personas que jamas en su vida programaron absolutamente nada, es decir para quienes nunca han utilizado un lenguaje de programación de ningún tipo.

Que es bueno conocer assembler claro que sí!!!!, pero no para iniciarse.
Arduino fue pensado para aquellos que jamás programaron nada en su vida, y que con muy pero muy poco, obtienen resultados, pueden ver en forma inmediata lo que hacen.
Nosotros hemos echos algunos experimentos, a quienes jamás hicieron nada que hicieran algunas tanto en assembler, como C y en Arduino.
Los que tenían que utilizar el Assembler y C terminaban abandonando.
Pero lo que utilizaron Arduino, se prendieron más a hacer cosas y a tener ganas de informarse para ir más lejos.

Arduino no es C presisamente pero se basa en el, por lo que los utilizan sin darse cuenta lo están empezando a aprender y la necesidad de ir más lejos hace que tengan la disponibilidad de ponerse a estudiar.

Eso quiere decir que quienes concibieron Arduino estaban en lo cierto.
La plataforma Arduino no puede ser analizada desde el ángulo de quienes manejan varios lenguajes de programación.
Que tiene sus limitaciones? Obvio porque es para aprender y esa es la parte buena, luego que empiezan a dominarlo viene el paso siguiente y es lo bueno de Arduino, que podes programar el micro directamente utilizando las mismas placas, sin cambiar nada y esa es la mejor parte.
Nosotros utilizamos el mundo Arduino para maquetado de ideas por lo rápido de su implementación una vez que la idea esta madurada decidimos bajo que plataforma lo haremos y que lenguaje utilizaremos.
Desde la misma forma que en mécanica se ha utilizado y aún se hace con los Meccano y Lego.
Hemos llegado a unir ambos mundos, para luego hacer el desarrollo final

 

[M@rcuS]

Muy buenas a todos... y pues de la misma forma que todos, estoy entrando de lleno con el mundo de los microcontroladores y mi pregunta va por lo siguiente.

Al momento de gestionar puertos... ya sea de accesando a la memoria RAM o bien accesando con las sentencias predefinidas del compilador... cual es la importancia de ambos y cuando tendría que utilizar bien el uno o el otro.

Agradecería su colaboración...

Agradezco sus aportes, pero mi consulta iba más apuntado a lo siguiente...

   #include <16F628a.h>

   #fuses MCLR, NOWDT, XT

   #use delay (clock=4Mhz)


   VOID main (){

                                                                                                                        

      set_tris_a (0xFF) ;

      set_tris_b (0x00) ;

      output_b (0) ;

                                                                                                                        

   WHILE (true)

   {

      IF (input (PIN_A0) == 0)

      {

         WHILE (!input (PIN_A0)) delay_ms (100);

         output_toggle (PIN_B0) ;

      }

    }

 

 

#include <16f628a.h>

#fuses   NOWDT,XT,PUT,MCLR

#use delay(clock=4Mhz)


#byte PORTA= 5

#byte PORTB= 6


void main(){

   set_tris_a(0b11111111);
   set_tris_b(0b11111110);

 
   while(true){
            if (BIT_TEST(PORTA,0))
           {
               BIT_SET(PORTB,0);
            }
          }

Como pueden ver, ambas estructuras cumplen la misma función que es encender un led con un botón, pero el dilema mío es, ¿qué tan importante es tener acceso a la gestión de puertos por medio de la memoria RAM?
Ya que como se nota en el primer ejemplo, no es necesario declarar la dirección de memoria y la declaración de las mismas se hace con una directiva específica, con lo que se obtiene el mismo resultado.

Pero de todas formas vuelvo agradecer las opiniones vertidas.

 

[pandacba]

Lo que haces en la primera parte es definir la función que tendra cada pin del puerto, todo depende de que es lo que quieres hacer con ellos y como los utilizaras, si vas a manejar un display LCD, tienes que definir en el modo que has de acceder al display, es decir cuantos pines utilizaras defiir el rol de cada pin.
En otros casos te servirán para tomar datos del exterior y deberas asociarlos a una variable y definir el tipo de la misma.
Cuando vas a poner un led a parapadear no tiene mucho sentido definir nada.
Pero ten en cuenta que un puerto se puede utilizar como E/S.
Toda esta información esta en los lenguajes para cada micro, así como los tipos de variables y sus alcances, eso es algo básico, que para entenderlo hay que leer los manuales del lenguaje adoptado, para ver todos los formatos que soporta, y familiarizarse con Bit, Byte, Word, Float, que es básicamente igual para todos los lenguajes, y practicar los ejemplos que traen al respecto para entenderlos en toda su magnitud

 

[Saint_]

¿qué tan importante es tener acceso a la gestión de puertos por medio de la memoria RAM?

Hola M@rcuS. El dilema que tienes yo lo reduciría simplemente a cuestión de gusto y sabor del programador. en mi caso siempre prefiero el como de trabajo tal como en tu primer ejemplo, el segundo modo lo usaría en un caso muy, demasiado extraordinario.
solo un detalle:

output_toggle (PIN_B0) ;

sirve para cambiar de estado 0->1 o 1->0 Mientras que:

BIT_SET(PORTB,0);

pone es estado alto al bit correspondiente.

 

[TRILO-BYTE]

Ya sé cuál es tu duda.
En cualquier libro de programación en C
Especifica el uso del preprosesador que es una directiva más o menos así:
#define
#pragma
#bit
#include
#.. etc.

Estás declaraciones las vaz a encontrar según el compilador que uses unas son válidas otras no en diferentes compiladores es decir
#use_rs232
No va a funcionar en un compilador que no sea CCS
Por que esa directiva es propia de ese compilador.

En cambio
#pragma
Es más estándar en cualquier compilador.

No es RAM es más una directiva que el compilador entenderá y la traducirá a código.

Otro ejemplo:

#define valor 33

Es como si yo hubiera hecho esto:

Const Char valor =33;

 

[M@rcuS]

Hola M@rcuS. El dilema que tienes yo lo reduciría simplemente a cuestión de gusto y sabor del programador. en mi caso siempre prefiero el como de trabajo tal como en tu primer ejemplo, el segundo modo lo usaría en un caso muy, demasiado extraordinario.
solo un detalle:

sirve para cambiar de estado 0->1 o 1->0 Mientras que:

pone es estado alto al bit correspondiente.

Agradesco tu aporte amigo Saint_ y pues respecto al tema de los estados lo tengo reclarisimo... pero mi duda estaba mas en la MEMORIA RAM...
por lo demas muchas gracias.

 

[TRILO-BYTE]

Es que como dije no es RAM estás confundiendo mucho RAM que son las variables y el preprosesador del compilador.
El preprosesador hace muchas cosas como desde el simple y conocido
#include
Hasta funciones como

#if define
#endif

Que permite hacer una pregunta al compilador como la versión del compilador.

Ojo eso NO es RAM.

RAM es una variable o un conjunto de ellas
Una simple variable:
Char variable;
Una cadena de variables:
Char variable [4]={1,2,3,4};

Una matriz de variables:
Char variable [2][2]={ {1,2}, {7,8} };

O un apuntador.
Char *variable;

Todo eso sí es RAM

 

[Scooter]

Aparte de que creo que los dos ejemplos hacen cosas distintas ya que uno conmuta el estado del pin y el otro solo lo activa y nunca lo desactiva, además no veo la RAM por ningún sitio.

Como ya te han comentado, si usas
#define varible 15
eso le da el valor 15 a variable pero ocupa en el PC donde esté el compilador, no en el micro
Si haces
const int variable =15;
entonces si que ocupará espacio en la ram del micro.

 

[TRILO-BYTE]

Con solo poner el operador CONST es definir la variable en modo ROM bueno en el caso de los microcontroladores flash sería en FLASH

 

[Scooter]

Eso debería de hacer const, no gastar RAM en algo que no se puede modificar, he dicho RAM porque algunos compiladores no lo hacen así. Por ejemplo Arduino y supongo que por ende el avr studio.
Para que lo meta en la flash hay que añadir algo delante que ahora mismo no recuerdo.
Edito, he hecho memoria:
Arduino Reference
Es progmem

 

[TRILO-BYTE]

Supongo que es por qué en Arduino recide un programa que hace que funcione como lo conocemos .

 

[Scooter]

Hasta donde sé Arduino es un bootloader en el micro más una capa encima del compilador de C que añade las cuatro chorradas que diferencian al wiring del C.
De hecho prácticamente puedes meter el código C que quieras enmedio del wiring.
Por ejemplo #define es C, no existe #define en wiring y se usa sin más.
La definición de variables y constantes es idéntica al C y eso es lo que me hace suponer que el compilador lo hace así.

Normalmente no lo hago, pero en su día me dediqué a desensamblar el código que generaba el SDCC para el 8051 y era curioso verlo. Con AVR no lo he hecho porque no conozco su CM, pero sí que he hecho bastantes pruebas de velocidad y algunas han sido muy sorprendentes. Las publicaré cuando tenga un rato, acabamos de salir de un proyectillo de 26ud 'para ayer' y hemos ido de cráneo, creí que no llegaba!!

 

[TRILO-BYTE]

Que interesante ¿Como haces una prueba de velocidad?
Me gustaría saber .
Yo lo que hice no sé si es correcto.
Es hacer un toggle en medio del código y con el oscilpscopio medir la frecuencia.

Algo así:

Main()
{
Código...

Pin^=1;
}

En pic las velocidades dejan mucho que desear.

 

[Scooter]

Eso es lo que hacía

La última ha sido la velocidad del toogle en si mismo y ha sido la mas sorprendente.

 

[Dr. Zoidberg]

La unica diferencia entre programar en C y en wiring es que los archivos C deben tener extension .cpp y losde wiring no se por que lo maneja el IDE.
En archivos .cpp yo he metido codigo C puro con muchas directivas de preprocesador y todo lo que es C del AVR-GCC compila como piña.

Asi que no se den mas rosca con el tema, Arduino se programa en C y el bootloader ni sabe que es lo que carga.

PD: tambien he metido C++ en archivos .cpp y tambien va como piña, y eso que he usado singleton con constructores privados y toda la bola, mucho mejor que la forma en que construyen las bibliotecas...

 

[TRILO-BYTE]

Bueno C es .c
No soporta clases
C++ es .cpp
Soporta clases
Eso lo veía con los Freescale.
Nunca me he metido con los AVR por qué me parecen caros acá en mi ciudad y el compilador AVR studio es muy pesado para mí laptop.

No digo que sean mejores los PIC la verdad no los defiendo pero me acordé con ellos.

Y a lo que voy es que un microcontrolador será bueno para quien se acomode con el o por el proyecto que se esté realizando.
Esto lo digo para un novato que diga .
¿Cual es el bueno?
Respuesta todos son buenos depende el proyecto o la disponibilidad.

 

[Dr. Zoidberg]

Bueno C es .c
No soporta clases
C++ es .cpp
Soporta clases

En el IDE de Arduino no hay archivos .c, solo se usan .cpp por que el compilador es invocado con las opciones para compilar C++. Como C++ "incluye" al C (pero no a la inversa) entonces es posible unificar ambas compilaciones en un solo tipo de archivo.
En un archivo .CPP podes incluir solo codigo C puro o codigo C++ puro o ambos tipos de codigo.

 

[Gasparv]

Buenas ..
yo recomiendo aprender ensamblador y experimentar con pequeñas rutinas. En mi caso me he conformado con PIC16F84, MPLAB, Real PIC simulator y el programador K150. El Arduino chino está ahí, esperando algún proyecto más complejo. Ciertamente, es más barato, pero un PIC es mucho más simple para pequeños prototipos.
En otros tiempos llegué a programar una interfaz RS232 con la que comunicaba un PC con el PIC con un protocolo simple basado en caracteres.

G.