Autor Tema: TUTORIAL: ATtiny 84 con avr-gcc.  (Leído 15386 veces)

0 Usuarios y 2 Visitantes están viendo este tema.

Manuel

  • Colaborador
  • *
  • Mensajes: 23
TUTORIAL: ATtiny 84 con avr-gcc.
« en: 27/May/2015, 16:22:05 pm »
Vamos a ver cómo programar un ATtiny84 de forma fácil y autónoma, usando avr-gcc, en varios episodios que iré indexando.


miniFAQ:

¿Por qué ATtiny84?
Es un chip barato (menos de 1,50 euros en formato DIP14), el más alto de su clase con 8K de flash y 512 bits de SRAM y EEPROM. Está disponible en formato DIP (hobbyist-friendly). Puede funcionar hasta a 20Mhz de frecuencia. Tiene un ADC de 7 canales, con 10 bits de resolución. Ponerlo a funcionar en una protoboard requiere una cantidad mínima de componentes. A ese precio, puede sustituir a varios chips lógicos, y salir más barato y ser más versátil. Además, es fácil portar estas ideas a muchos otros chips ATtiny.

¿Por qué avr-gcc?
Es gratis, rápido y fácil. Dispone de gran cantidad de herramientas auxiliares para desensamblar y analizar programas. Si quieres ensamblar, puedes hacerlo inline con gran facilidad.

¿Vas a usar algún firmware?
Ninguno. La idea es emplear código que se sostenga por si mismo, para tener acceso completo al aparato con un mínimo de derroche en espacio.
« Última modificación: 06/Nov/2022, 10:47:15 am por Administración del foro »

Manuel

  • Colaborador
  • *
  • Mensajes: 23
Crash-course: blink con ATtiny84.
« Respuesta #1 en: 27/May/2015, 17:23:29 pm »
Para resumir todas las ideas, veamos cómo hacer un blink mínimo en un ATtiny84 funcionando a 20Mhz.

Lo primero, monta el chip en una protoboard, llevando el pin1 a 5V, el pin14 a tierra, los pin2 y pin3 a tierra con sendos condensadores de 22pF, y conectados entre si con un cristal a 20Mhz (o la frecuencia que quieras, por encima de 3Mhz). Para hacer el blink, conecta un LED al pin8, y llévalo a tierra con una resistencia razonable (200 Ohm o así.) Una imagen aquí.

Ahora, programa los fuses del microcontrolador para que funcione bien a esta frecuencia de reloj. Esto se logra con avrdude, usando el comando:

Código: [Seleccionar]
avrdude -c arduinoISP -p t84 -U lfuse:w:0xff:m -U hfuse:w:0xdc:m -U efuse:w:0xff:m
Es posible que tengas que cambiar el tipo de programador, por ejemplo, -c usbasp si usas el usbasp, etc. Esta elección de fuses prepara el micro para funcionar con el cristal, y activa del brown-out detector a un nivel razonable.

Ahora vamos a por el programa del blink en si mismo:

Código: (C) [Seleccionar]
#include <inttypes.h>
#include <avr/io.h>
#include <util/delay.h>
#include <avr/eeprom.h>
#include <avr/pgmspace.h>
#include <avr/interrupt.h>
#include <string.h>
 
int main ()
{
DDRA |= (1 << 5);      // Pin 5 como salida.
    for (;;)
    {
        PORTA |= (1 << 5);      // Enciende pin 8.
         _delay_ms(250);
PORTA &= ~(1 << 5);   // Apaga pin 8.
         _delay_ms(250);
    }
}

La parte de main() en este código es bastante clara, si uno se lee la documentación de ATtiny84: se está configurando el bit 5 del puerto A, que corresponde al pin 8 del chip. Se usan los registros DDRA (Data Direction puerto A) para configurarlo como salida, y el registro PORTA para encender y apagar el LED. La macro _delay_ms está definida en el fichero de cabecera util/delay.h y es precisa y fácil de usar.

Una cosa que llama mucho la atención al pasar del ensamblador al C es que en este programa no se hace mención de los vectores de interrupción. ¡Y al menos necesitamos el vector de reset! ¿Cómo resuelve avr-gcc este problema? Parece que tenemos dos problemas:

  • Queremos que nuestro código main() y demás subrutinas no sobreescriban los vectores de interrupción, sino que empiecen más adelante que ellos.
  • Queremos almacenar en los dos primeros bytes de la flash un salto relativo a main().

Las versiones modernas de avr-gcc se ocupan directamente de esto, como veremos en la parte siguiente, sobre desensamblado de nuestro programa. Por ahora, podemos confiar en que gcc se encargará adecuadamente del trabajo sucio.

Por tanto, vamos a compilar el código fuente y subirlo. Para compilar,

Código: [Seleccionar]
avr-gcc -c main.c -o main.o -Os -mmcu=attiny84 -D__AVR_ATtiny84__ -DF_CPU=20000000L
La mayor parte de esto no es muy misteriosa. Las dos definiciones podrían haberse incluido en el fichero fuente:

Código: (C) [Seleccionar]
#define __AVR_ATtiny84__              // Modelo de mcu.
#define F_CPU= 20000000L         // Velocidad del reloj.
Observa que si tu reloj va a otra frecuencia, debes cambiarlo aquí. Por ejemplo, a 8Mhz deberías usar F_CPU=8000000L.

La optimación -Os es fundamental para que algunos de los ficheros de cabecera funcionen, así que no es conveniente saltársela.

Una vez que tenemos el fichero main.o generado por el compilador, podemos generar un fichero .elf con el programa:

Código: [Seleccionar]
avr-gcc main.o -o main.elf -Os -mmcu=attiny84 -D__AVR_ATtiny84__ -DF_CPU=20000000L
Las flags del compilador son idénticas, pero esta vez sólo se hace el linkado.

Ahora extraemos el fichero .eep, que contiene la información a subir a la eeprom: en nuestro caso, no hay ninguna que subir:

Código: [Seleccionar]
avr-objcopy -j .eeprom --set-section-flags=.eeprom='alloc,load' --change-section-lma .eeprom=0 -O ihex main.elf main.eep
Y la parte a subir a la flash de nuestro programa, que en este caso es todo:

Código: [Seleccionar]
avr-objcopy -O ihex -R .eeprom main.elf main.hex
El fichero main.hex es el que subiremos usando avrdude. Antes de hacerlo, de todos modos, es buena idea saber cuánto estamos usando de memoria, por si nos hemos pasado. Para ello, ejecutamos:

Código: [Seleccionar]
avr-size --mcu=attiny84 -C --format=avr main.elf
La salida es el clásico mensaje al que estamos aconstumbrados en el software de Arduino:

Código: [Seleccionar]
AVR Memory Usage
----------------
Device: attiny84

Program:    96  bytes (1.2% Full)
(.text + .data + .bootloader)

Data:          0 bytes (0.0% Full)
(.data + .bss + .noinit)

Por supuesto, nuestro minimalista blink apenas ocupa memoria. Para subir el programa a la flash, invocamos a avrudude:

Código: [Seleccionar]
avrdude -c arduinoISP -p t84 -B 9500 -e -U flash:w:"main.hex"
La opción -B 9500 ralentiza el envío, porque en mi caso lo hago a través de cables largos, y a grandes velocidades hay errores de transmisión. Si tu programamdor va rápido, puedes ahorrarte esta línea.

Y con esto tu attiny está listo para correr el programa. El proceso puede parecer muy largo, pero creando una macro, o un makefile (más adelante publicaré el mío), todo el procedimiento es muy rápido y adaptable a otros proyectos.
« Última modificación: 30/May/2015, 22:05:30 pm por Manuel »

Carlos

  • Moderador Global
  • ****
  • Mensajes: 294
Re:TUTORIAL: ATtiny 84 con avr-gcc.
« Respuesta #2 en: 27/May/2015, 23:07:29 pm »
Te recomiendo estas instrucciones para hacer más legible el código:

Código: [Seleccionar]
#define SET_BIT(byte, bit)  byte |= (1<<(bit))
#define CLEAR_BIT(byte, bit)  byte &= ~(1<<(bit))

   SET_BIT(DDRA, 5);     // Pin 5 como salida.

Además a mí me gusta crear un archivo de cabecera en todas las placas que hago para traducir los pines.
Dejo aquí un pequeño ejemplo:

Código: [Seleccionar]

typedef struct {
   unsigned char b0:1;
   unsigned char b1:1;
   unsigned char b2:1;
   unsigned char b3:1;
   unsigned char b4:1;
   unsigned char b5:1;
   unsigned char b6:1;
   unsigned char b7:1;
} bits;

// Define input and output pins
#define PORT_A (* (volatile bits *) &PORTA)
#define PIN_A  (* (volatile bits *) &PINA)
#define DDR_A  (* (volatile bits *) &DDRA)

#define PORT_B (* (volatile bits *) &PORTB)
#define PIN_B  (* (volatile bits *) &PINB)
#define DDR_B  (* (volatile bits *) &DDRB)

#define PORT_C (* (volatile bits *) &PORTC)
#define PIN_C  (* (volatile bits *) &PINC)
#define DDR_C  (* (volatile bits *) &DDRC)

#define PORT_D (* (volatile bits *) &PORTD)
#define PIN_D  (* (volatile bits *) &PIND)
#define DDR_D  (* (volatile bits *) &DDRD)

// Define standar Input/Output values
#define DDR_OUTPUT  1
#define DDR_INPUT   0

#define PORT_HIGH   1
#define PORT_LOW    0

#define PIN_HIGH    1
#define PIN_LOW     0

// Output leds
#define DDR_D1    DDR_C.b7
#define DDR_D2    DDR_C.b0
#define DDR_D3    DDR_D.b6
#define DDR_D4    DDR_B.b0
#define DDR_D5    DDR_A.b0
#define DDR_D6    DDR_A.b1
#define DDR_D7    DDR_D.b5
#define DDR_D8    DDR_D.b7

#define PORT_D1   PORT_C.b7
#define PORT_D2   PORT_C.b0
#define PORT_D3   PORT_D.b6
#define PORT_D4   PORT_B.b0
#define PORT_D5   PORT_A.b0
#define PORT_D6   PORT_A.b1
#define PORT_D7   PORT_D.b5
#define PORT_D8   PORT_D.b7

Un saludo.
« Última modificación: 27/May/2015, 23:09:27 pm por Carlos »

Carlos

  • Moderador Global
  • ****
  • Mensajes: 294
Re:TUTORIAL: ATtiny 84 con avr-gcc.
« Respuesta #3 en: 28/May/2015, 17:26:05 pm »
Manuel, ¿sabes cómo se puede ver la lista de instrucciones en ensamblador después de compilar el programa c?

Manuel

  • Colaborador
  • *
  • Mensajes: 23
Desensamblado de nuestro blink.
« Respuesta #4 en: 28/May/2015, 18:46:04 pm »
Vamos a desensamblar el programa compilado en el capítulo anterior, para hacernos una idea de cómo trata el compilador nuestros programas. La manera de lograrlo es:

Código: [Seleccionar]
avr-objdump build/main.elf --architecture=avr:25 -S
Conviene usar el fichero .elf generado anteriormente, para tener una versión definitiva de lo que se va a subir: la información proveniente del fichero objeto puede ser menos reveladora. El ATtiny84 tiene arquitectura avr25, y el modificador -S pide desensamblarlo todo. El resultado es:

Código: [Seleccionar]
build/main.elf:     file format elf32-avr


Disassembly of section .text:

00000000 <__vectors>:
   0: 10 c0        rjmp .+32      ; 0x22 <__ctors_end>
   2: 17 c0        rjmp .+46      ; 0x32 <__bad_interrupt>
   4: 16 c0        rjmp .+44      ; 0x32 <__bad_interrupt>
   6: 15 c0        rjmp .+42      ; 0x32 <__bad_interrupt>
   8: 14 c0        rjmp .+40      ; 0x32 <__bad_interrupt>
   a: 13 c0        rjmp .+38      ; 0x32 <__bad_interrupt>
   c: 12 c0        rjmp .+36      ; 0x32 <__bad_interrupt>
   e: 11 c0        rjmp .+34      ; 0x32 <__bad_interrupt>
  10: 10 c0        rjmp .+32      ; 0x32 <__bad_interrupt>
  12: 0f c0        rjmp .+30      ; 0x32 <__bad_interrupt>
  14: 0e c0        rjmp .+28      ; 0x32 <__bad_interrupt>
  16: 0d c0        rjmp .+26      ; 0x32 <__bad_interrupt>
  18: 0c c0        rjmp .+24      ; 0x32 <__bad_interrupt>
  1a: 0b c0        rjmp .+22      ; 0x32 <__bad_interrupt>
  1c: 0a c0        rjmp .+20      ; 0x32 <__bad_interrupt>
  1e: 09 c0        rjmp .+18      ; 0x32 <__bad_interrupt>
  20: 08 c0        rjmp .+16      ; 0x32 <__bad_interrupt>

00000022 <__ctors_end>:
  22: 11 24        eor r1, r1
  24: 1f be        out 0x3f, r1 ; 63
  26: cf e5        ldi r28, 0x5F ; 95
  28: d2 e0        ldi r29, 0x02 ; 2
  2a: de bf        out 0x3e, r29 ; 62
  2c: cd bf        out 0x3d, r28 ; 61
  2e: 02 d0        rcall .+4      ; 0x34 <main>
  30: 15 c0        rjmp .+42      ; 0x5c <_exit>

00000032 <__bad_interrupt>:
  32: e6 cf        rjmp .-52      ; 0x0 <__vectors>

00000034 <main>:
  34: d5 9a        sbi 0x1a, 5 ; 26
  36: 24 ef        ldi r18, 0xF4 ; 244
  38: 31 e0        ldi r19, 0x01 ; 1
  3a: dd 9a        sbi 0x1b, 5 ; 27
  3c: 84 ec        ldi r24, 0xC4 ; 196
  3e: 99 e0        ldi r25, 0x09 ; 9
  40: f9 01        movw r30, r18
  42: 31 97        sbiw r30, 0x01 ; 1
  44: f1 f7        brne .-4      ; 0x42 <__SREG__+0x3>
  46: 01 97        sbiw r24, 0x01 ; 1
  48: d9 f7        brne .-10      ; 0x40 <__SREG__+0x1>
  4a: dd 98        cbi 0x1b, 5 ; 27
  4c: 84 ec        ldi r24, 0xC4 ; 196
  4e: 99 e0        ldi r25, 0x09 ; 9
  50: f9 01        movw r30, r18
  52: 31 97        sbiw r30, 0x01 ; 1
  54: f1 f7        brne .-4      ; 0x52 <__SREG__+0x13>
  56: 01 97        sbiw r24, 0x01 ; 1
  58: d9 f7        brne .-10      ; 0x50 <__SREG__+0x11>
  5a: ef cf        rjmp .-34      ; 0x3a <main+0x6>

0000005c <_exit>:
  5c: f8 94        cli

0000005e <__stop_program>:
  5e: ff cf        rjmp .-2      ; 0x5e <__stop_program>

Lo más importante es comprobar que, en efecto, avr-gcc se ocupa de gestionar automáticamente los vectores de interrupción, y hacer que el vector 0 apunte  a main(). Los demás vectores apuntan a <__bad_interrupt> (0x32), que directamente lleva a un reset. En otro episodio veremos cómo usar la macro ISR() del fichero avr/interrupt.h para alterar otros vectores, y cómo esto se refleja de manera clara en el ensamblador.

Veamos algunos detalles interesantes del desensamblado:

Después del reset, se salta a <__ctors_end> (0x22), claramente abreviatura de "vectors end". Allí se pone a cero el registro r1 (en C ese registro siempre está a cero),  y a continuación se anula el registro de estado (out 0x3f, r1). A continuación se inicializan los registros de pila (0x3e y 0x3d) en el valor 0x25f = 607. Este valor parece misterioso hasta que se consulta el mapa de la memoria RAM del ATtiny (hoja de datos, Sec. 5.1.1, pág. 16): la memoria comienza con 0x60 registros de entrada-salida, y luego los 512 bytes (0x200) de SRAM  lo que, empezando en cero, da el top de la RAM en 0x260 - 1 = 0x25f. La pila es inicializada en el top de la RAM y, naturalmente, crece hacia abajo.

Inicializada la pila, es seguro hacer un call a main() y comenzar las rutinas en C.

La función main() no tiene gran interés. Es un enorme bucle con los retardos _delay_ms() preprogramados en forma de bucles internos. Todo está bastante bien y resulta adecuadamente compacto.

Observa que, en caso de que main() no fuera un bucle infinito, finalmente retornaría a <__ctor_end>, el cual llamaría a <exit> y entraría en un bucle infinito. Todo es seguro y está bien pensado.

Así pues, esta es la anatomía de nuestro programa blink. Es bastante tranquilizador ver lo bien que hace su trabajo el compilador.
« Última modificación: 28/May/2015, 19:12:41 pm por Manuel »

Manuel

  • Colaborador
  • *
  • Mensajes: 23
Re:TUTORIAL: ATtiny 84 con avr-gcc.
« Respuesta #5 en: 28/May/2015, 19:04:01 pm »
Carlos, sobre la idea de usar macros para limpiar el código: he programado mi propia versión de estas herramientas, y los propios ficheros de cabecera estándar  tienen sus abreviaturas, como sabes: _BV(x) para (1 << x), etc. Pero creo que no encajan en una versión minimalista: demasiadas explicaciones. Estoy creando una pequeña librería de funciones útiles, pero al introducir llamadas a funciones tipo digitalRead, el código ensamblado se complica y el espacio necesario para el programa crece de 96 bytes a más de 200 bytes, por eso de los prólogos y epílogos de las llamadas a funciones. Puede forzarse a avr-gcc a hacer un inlining agresivo pero, ¿realmente vale la pena?

La idea de trabajar con el oscilador interno de 8 Mhz es muy adecuada desde un punto de vista minimalista. Intentaré introducirla en el tutorial, porque así se simplifican al máximo los requerimientos. Realmente me da repelús usar un oscilador RC para nada que no sea audio, pero eso es claramente un prejuicio personal. También pesa el que soy un speed freak, y no me conformo con menos que todos los 20 Mhz  ::) . Muchas gracias por la sugerencia  :) .
« Última modificación: 28/May/2015, 19:14:26 pm por Manuel »

Carlos

  • Moderador Global
  • ****
  • Mensajes: 294
Re:TUTORIAL: ATtiny 84 con avr-gcc.
« Respuesta #6 en: 28/May/2015, 22:23:04 pm »
Gracias por el código para sacar el ensamblador. Intentaré adaptarlo al Attiny88

En cuanto al archivo de cabecera, no tiene por qué ocupar más. Simplemente renombro:
  DDRA |= (1<<5);

por:
  DDR_A.b5 = 1;

Mediante la definición de una estructura
No ocupa más y es más sencillo de entender. Microchip lo implementa así en sus compiladores.

Luego,  con un #define lo renombro otra vez a:

   PIN5 = 1;

Al final ocupa lo mismo y se compila con la misma instrucción en assembler que pone un bit a uno.

Un saludo.

Manuel

  • Colaborador
  • *
  • Mensajes: 23
Visualizador LCD con ATtiny84.
« Respuesta #7 en: 29/May/2015, 21:05:57 pm »
Estoy un poco desbordado con cómo contar todo esto de manera instructiva, porque equivale a varios capítulos, pero allí va en modo preview cómo conectar un LCD a un ATtiny84. El proceso deja todavía tres pines libres, que voy a usar para un proyecto de medición de radiofrecuencia.

[youtube]gJQHkvQLJ4s[/youtube]

El código fuente es reconocible por su semejanza a Arduino:

Código: (Arduino) [Seleccionar]
#include <inttypes.h>
#include <avr/io.h>
#include <util/delay.h>
#include <avr/eeprom.h>
#include <avr/pgmspace.h>
#include <avr/interrupt.h>
#include <string.h>

#include "util.h"
#include "LiquidCrystal.h"

const uint8_t barra[] = "> ";
                     
int main ()
{
    int i = 0;
   
    LiquidCrystal lcd(7, 6, 5, 4, 3, 2);
    lcd.begin(16, 2);
    lcd.write((uint8_t*) "Hello, sailor!", 14);
    lcd.setCursor(0, 1);

    while(1)
    {
        lcd.setCursor(i,2);
lcd.write(barra, 1);
delay(200);
lcd.write(&barra[1], 1);
i++;
if (i == 16) i = 0;
delay(200);
    }
}

La librería util.h contiene algunas definiciones para hacer el código más bonito, y LiquidCrystal.h es una adaptación a ATtiny de la librería de Arduino, eliminando la superclase Print y simplificando el código. Ha sido realmente fácil de portar. Aún queda trabajo por hacer, para que sea más agradable de usar, pero funciona perfectamente en estos momentos.

Próximamente subo en un archivo comprimido mi makefile y todos los ficheros fuente, e intentaré ir detallando poco a poco cómo generar un entorno de trabajo.

A propósito, el tamaño del archivo es:

Código: [Seleccionar]
AVR Memory Usage
----------------
Device: attiny84

Program:    1384 bytes (16.9% Full)
(.text + .data + .bootloader)

Data:         24 bytes (4.7% Full)
(.data + .bss + .noinit)

Mucho major de lo que me atrevía a esperar.
« Última modificación: 29/May/2015, 21:07:39 pm por Manuel »

Carlos

  • Moderador Global
  • ****
  • Mensajes: 294
Re:TUTORIAL: ATtiny 84 con avr-gcc.
« Respuesta #8 en: 30/May/2015, 00:02:42 am »
Está muy bien el ejemplo.
Echo de menos algún circuito para entender cómo lo has conectado.
Yo suelo utilizar KiCad. Es opensource y muy profesional.

Tu proyecto casi ocupa todos los pines del Attiny.
Con los módulos I2C - LDC se reducen los pines a 2. El problema está en que la programación se complica bastante.

Un saludo.

Manuel

  • Colaborador
  • *
  • Mensajes: 23
Montaje básico.
« Respuesta #9 en: 30/May/2015, 16:03:58 pm »
Para experimentar de manera básica con ATtiny84 vamos a usar el siguiente montaje (pincha para aumentar):


DETALLES:

El cristal de cuarzo (20 Mhz) con los dos condensadores cerámicos (22 pF) producen un reloj de precisión para el microcontrolador. Si no tienes un cristal de 20 Mhz, cualquier otro cristal de más de 3 Mhz es válido, simplemente cambiando la opción -DF_CPU a la hora de compilar. Por ejemplo, para un cristal de 16 Mhz, debería usarse: -DF_CPU=16000000L.

¿Por qué no usar el resonador RC interno a 8 Mhz, y ahorrar así dos pines y tres componentes? En primer lugar, porque un oscilador RC tiene una estabilidad pobre y un elevado ruido de fase. Son osciladores sucios. Los osciladores RC, incluso los cerámicos, pueden ser insuficientes para varios fines prácticos. En segundo lugar, porque a mayor frecuencia extraemos mejores prestaciones del microcontrolador.

Si deseas usar el oscilador RC interno, los fuses se programan de la siguiente manera (para 8Mhz de funcionamiento sin divisor del reloj):

Código: [Seleccionar]
avrdude -U lfuse:w:0xe2:m -U hfuse:w:0xdc:m -U efuse:w:0xff:m
esto vale para la opción -DF_CPU=8000000L.

Hemos incluido en la perfboard un regulador de voltaje LM7805, conectado a un paquete de baterías. Idealmente, debería usarse una batería de 9V para estos fines, en vez de baterías AA, puesto que el 7805 necesita un mínimo de 7V para funcionar correctamente.

La línea amarilla lleva al pin de RESET, y está conectada vía 10K al voltaje positivo.

La línea verde está conectada al PINA5 del ATTiny, y lleva a un led verde protegido por 220 Ohm, para hacer ensayos con el programa blink.

« Última modificación: 06/Nov/2022, 10:48:11 am por Administración del foro »

Manuel

  • Colaborador
  • *
  • Mensajes: 23
LCD con ATtiny84: montaje.
« Respuesta #10 en: 30/May/2015, 16:13:39 pm »
Vamos a dar salida de texto a nuestro ATtiny84. Esto nos va a llevar a infinidad de posibilidades a la hora de comprobar y depurar nuestros programas. Para ello, solo necesitamos un clásico módulo LCD1602 como los que se emplean en Arduino. Las conexiones necesarias están en este diagrama (pincha para aumentar):

Circulan por ahí, como ha comentado Carlos, versiones del LCD con interfaz I2C, que ocupan muchos menos pines. Nos ocuparemos del bus I2C más adelante, al implementar una pequeña librería basada en USI para los modo master y slave. Por ahora, tendremos que conformarnos con que nos queden 3 pines libres que, como veremos, son suficientes para algunos proyectos intersantes.
« Última modificación: 06/Nov/2022, 10:48:21 am por Administración del foro »

Manuel

  • Colaborador
  • *
  • Mensajes: 23
Re:TUTORIAL: ATtiny 84 con avr-gcc.
« Respuesta #11 en: 30/May/2015, 16:18:21 pm »
Está muy bien el ejemplo.
Echo de menos algún circuito para entender cómo lo has conectado.
Yo suelo utilizar KiCad. Es opensource y muy profesional.

Tu proyecto casi ocupa todos los pines del Attiny.
Con los módulos I2C - LDC se reducen los pines a 2. El problema está en que la programación se complica bastante.

Un saludo.
Muchas gracias, Carlos. Estoy intentando incorporar todas tus sugerencias para hacer el tutorial lo más accesible y perfecto que se pueda: está siendo un montón de trabajo a la hora de documentar las cosas con cierto nivel de detalle. Estoy intentando hacer gráficos accesibles a golpe de Fritzing, que genera hermosos gráficos de protoboards.

Aunque parezca mentira, para el proyecto final que quiero desarrollar, un medidor de frecuencias / medidor de potencias para osciladores de radio, aún me va a sobrar un pin, que intentaré conectar a un bótón para hacer una interfaz minima. A ver cómo marcha la cosa.
« Última modificación: 30/May/2015, 16:19:57 pm por Manuel »

Manuel

  • Colaborador
  • *
  • Mensajes: 23
Instalando el entorno de programación.
« Respuesta #12 en: 30/May/2015, 20:59:24 pm »
Para compilar todos los ejemplos de este tutorial sin problemas, es aconsejable instalar el entorno de programación Cygwin. Se trata de un entorno tipo UNIX corriendo bajo Windows, con una terminal infinitamente más avanzada que command.com. Dispone de la suite de compilación gcc, y de gran cantidad de librerías y utilidades adicionales.

1. Instalando Cygwin.

Dirígete a la página oficial, entra en la sección de descargas y baja el instalador de 64 bits (a menos que tengas un sistema Windows anticuado).

La instalación es sencilla, pero lleva un rato, porque hay que descargar interactivamente las diversas herramientas que componen el entorno.

La instalación por defecto es perfecta, salvo porque no incluye el paquete make, que nos hará falta para compilar y subir cómodamente nuestros programas. Así que, en este primer paso, simplemente instala con las opciones por defecto. En tu escritorio aparecerá un icono verde y negro que te llevará directamente a la consola.

2. Instalando make.

Vuelve a ejecutar el instalador de Cygwin. Ahora, tu instalación será reconocida, y se te permitirá instalar paquetes adicionales. De entre la lista, busca "make" en la sección "devel", con la descripción "make: the GNU version of the 'make' utility." Márcala para instalar, acepta las dependencias que se indican, y continúa con el proceso de instalación para terminar.

Si ahora vas a la consola e invocas 'make', el programa responderá:

Código: [Seleccionar]
make: *** No targets specified and no makefile found.  Stop.
Eso quiere decir que has instalado make correctamente.

3. Instalando WinAVR.

Para finalizar, tienes que instalar la suite de compilación para AVR. Nada puede ser más fácil. En primer lugar, dirígete a la página oficial del proyecto y, una vez allí, salta a la sección de descargas. Nosotros vamos a trabajar con la versión 20100110 (pulsa aquí para descargar).

Instala normalmente el programa, y tendrás en tu consola disponibles todas las herramientas de porgramación para AVR.

De todos modos, para completar del todo el proceso, y tener acceso desde nuestro entorno UNIX a las herramientas de programación, y poder modificarlas, es conveniente hacer una copia de toda la suite al directorio /usr/share de nuestro UNIX. Esto se logra de la manera siguiente:

Si has instalado WinAVR en C:\Program Files (x86)\WinAVR20100110, ve a ese directorio, y cópialo. Ahora, si has instalado Cygwin en C:\cygwin64, ve a C:\cygwin64\usr\share y pega en esa localización la carpeta.

Con estos pasos estás listo para hacer todos los ejemplos del tutorial, sin ningún problema. También dispones de una excelente shell, una suite de compilación para x86 y para AVR, y una multitud de herramientas de trabajo.

4. Opcional: crea un acceso directo a tu directorio de trabajo.

Para poder descomprimir archivos, usar editores de código avanzados (como notepad++) y acceder rápidamente a tus programas, es buena idea crear un acceso directo en tu escritorio al área de trabajo.

Si tu usuario de Windows se llama "pepe", Cygwin habrá creado en C:\cygwin64\home\pepe tu carpeta de trabajo. Envía esa carpeta al escritorio como acceso directo, y podrás entrar en ella a toda velocidad.
« Última modificación: 30/May/2015, 21:06:13 pm por Manuel »