[AVR] Verschillen tussen ATtiny & ATmega?

Tiny: <21 pinnetjes, de mega's zijn die met meerdere pinnekes. De opbouw van beide is vrij gelijkend, maar er zijn wel eens verschillen in functies (ADC kanalen, aantal timers, communicatie mogelijkheden, ...)

Tegen de tijd dat jij het 2K geheugen van een Tiny vol hebt zitten heb je héél veel firmware geschreven of echt énorm slechte firmware geschreven.

Zoek voor de grap eens een datasheet op van een attiny2313 en een atmega32, het is een hoop leeswerk maar je zult vanzelf zien wat de werkelijk grote verschillen zijn. Ik kan je hier wel een lijst geven maar ik denk niet dat je daar wijs uit gaat worden.

Mzzls

Persoonlijk vind ik de ATmega88 (168, 328) een goede AVR om mee te starten. Is niet al te prijzig, en biedt redelijk veel mogelijkheden.

Tegen de tijd dat jij het 2K geheugen van een Tiny vol hebt zitten heb je héél veel firmware geschreven of echt énorm slechte firmware geschreven.

Die hoeft niet noodzakelijk slecht¹ geschreven te zijn. Iets als dit krijg je al niet meer in een ATtiny13 gepompt:

#include <avr/io.h>
#include <util/delay.h>

int main(void)
{
    double ms;

    DDRB = _BV(PB1);

    while (1) {
	for (ms = 1.0; ms < 100.0; ms++) {
	    PORTB |= _BV(PB1);
	    _delay_ms(ms);
	    PORTB &= ~(_BV(PB1));
	    _delay_ms(ms);
	}
    }
}

¹) Ik zou het geen slechte broncode durven noemen. Beetje onverstandig wel, natuurlijk...

Ik zou dan meteen voor een arduino/freeduino bordje gaan. Makkelijk te progammeren (rechtstreeks aan je USB poort) en veel functionaliteit is beschikbaar in libraries.

Op 18 november 2009 20:18:09 schreef pros:

#include <avr/io.h>
#include <util/delay.h>

int main(void)
{
    double ms;

    DDRB = _BV(PB1);

    while (1) {
	for (ms = 1.0; ms < 100.0; ms++) {
	    PORTB |= _BV(PB1);
	    _delay_ms(ms);
	    PORTB &= ~(_BV(PB1));
	    _delay_ms(ms);
	}
    }
}

Als je er dan ook bij zet dat die "double" de zaak hier compleet verziekt dan heb je een statement, die trekt meteen de hele floating point libraries naar binnen.
Floats en doubles in embedded controllers is dodelijk voor je code footprint.

Als je van die 'ms' een 'int' maakt is de code nog maar 50 - 100 bytes (ex c-startup) schat ik zo.

Er zit een flinke adder onder het gras: als ms een int is, wordt het nog erger!
_delay_ms() verwacht immers een float, waardoor de fp-libs sowieso nodig zijn.
Maar omdat ms een int is, komt er extra-code aan te pas om die naar een float te vertalen.

Het vorige voorbeeld resulteert in 3114 bytes machinecode.

Dit levert 3412 bytes op:

int main(void)
{
    int ms = 1;

    DDRB = _BV(PB1);

    while (1) {
	for (ms = 1; ms < 100; ms++) {
	    PORTB |= _BV(PB1);
	    _delay_ms(ms);
	    PORTB &= ~(_BV(PB1));
	    _delay_ms(ms);
	}
    }
}

Ik heb in het verleden verschillende soorten controllers besteld. Als ik nu zie wat ik echt gebruik zijn het vooral de Atmega168 en nu recent bijna uitsluitend de Atmega328P. Voor het kleine prijsverschil kunt je zo je voorraadsoorten wat beperken. Ik koop ze minstens per 10 stuks.
Als inbouwruimte een probleem is moet ik soms nog de kleintje gebruiken. Dan is het de Attiny45.
Een tussenligger is ook nog de ATtiny26. Heeft vrij veel mogelijkheden en lage prijs.

Maar de topper blijft de ATmega168/328. Ik heb hier ook een 10tal arduino printjes in stock. Dit voor het geval ik snel iets moet hebben. Maar praktisch gebruik ik toch het meest mijn gaatjesprinten. Dit resulteerd toch nog altijd in een compacte oplossing voor inbouw.

Die 328 had ik vooral nodig voor zijn 2K SRAM en niet voor het programma gedeelte. Ik werk altijd in assembler en om daar meer dan 2K byte aan geheugen nodig te hebben mag je al een heel grote toepassing hebben. Zelfs mijn Master wireless remote flash toepassing met keyboard en display en RFM12B zender heeft maar 1800 bytes aan code nodig. Zelfs de Vbat komt op de display.

badankt voor de info,

wat ik ga maaken is een special effecten controller zo als ik al heb gescheefen.
de funkties die hij moet uitvoeren is het simuleeren van kappote lantarenpaalen.
daarvoor wil ik firmware schijfen dat de lamp laat knipperen als of het een kappute TL buis is en ik wil meerede lantarens aan sluiten,
en om het allemaal nog iets echte te maaken
wil ik een soort van dobelsteen script gebruiken die op true of false komt (bool variable)
als die op true staat is dat de kappote straat lamp zo is het elke keer als je hem aanzet een andere lamp en soms meerede en soms geen lamp verder nog een dag/nacht regeling en looplicht.

en ik denk dat dat best grote scripts worden nu weet ik aleen nog niet wat ik ga doen een grote mega of merede tiny controllers

Ik denk dat als je maar weg blijft van functies als _delay_ms() dat je wel een eind kunt komen met een tiny.

Voor zoiets als een delay tussen het knipperen van een ledje gebruik je dan _delay_loop_2(0) bijvoorbeeld.

_delay_ms is voor wanneer je precies n milliseconden wilt wachten, wil je voor special effects toch bijna nooit. Die functies staan hier ook wel beschreven: http://www.nongnu.org/avr-libc/user-manual/

Kom kom, zo erg is de _delay_ms nou ook weer niet, zolang je maar constante waarden meegeeft ipv variabelen. Bovenstaande voorbeeld met twee maal _delay_ms(100L) is slechts 435 bytes.

Hier staat een bruikbaar voorbeeld, dat zowel met grote waarden als met variabelen overweg kan zonder floating-point gedoe.

Als je er 1 vermenigvuldiging in zet ben je ook de klos (attiny2313) deze (en misschien meerdere tiny's) heeft geen hardware multiplier, de compiler gaat dan die hele vermenigvuldiging in code voor elkaar zien te krijgen, je stijgt dan al heel erg snel boven je beschikbare geheugen uit..

Op 18 november 2009 20:18:09 schreef pros:
[...]
Die hoeft niet noodzakelijk slecht¹ geschreven te zijn. Iets als dit krijg je al niet meer in een ATtiny13 gepompt:

knip

¹) Ik zou het geen slechte broncode durven noemen. Beetje onverstandig wel, natuurlijk...

Dit is razig, vies, 666, 21 dec 2012,...

REGEL 1: Ziet dat je altijd een vaste cyclus tijd hebt in uw hoofdlus. Ga NIET spelen met VARIABLE delay's. Waarom anders heeft ATMEL timer interrupts geschapen.

REGEL 1.1: Gebruik liever in uw main lus geen delays. Zie REGEL 4

REGEL 2: Werkt nooit of te nimmer met floating points in AVR/PIC of meer in het algemeen in MCU zonder FPU. Kost enorm veel RAM en FLASH en power. Probeer alles met integers op te lossen.

REGEL 3: Ken UW hardware. Ik merk dan de meeste niet eens hun datasheet bij het programmeren naast hun hebben liggen/openstaan.

REGEL 4: Gebruik een tickcounter. Dit is een variable die bv om de 1 ms met 1 word verhoogt. Bv

#include <avr/io.h>
#include <util/delay.h>
 
volatile unsigned int tick_cnt = 0;

int main(void)
{
    unsigned int ms;
 
    DDRB = _BV(PB1);
 
    init_timer();
    ms = 1;
    while (1) {
      if(tick_cnt > ms){
        PINB = _BV(PB1); //Zie datasheet wat ik hier mee bedoel (regel 3)
        tick_cnt = 0;
        ms++;
      }

    }
}

ISR(TIMER_INT){
   
  tick_cnt++;

}

Het gebruik van timer-interrupts is handig en nauwkeurig - als je nog een timer ter beschikking hebt, natuurlijk. De ATtiny13 bv. heeft er maar eentje, en die wordt al snel in beslag genomen voor andere taken.
En dan is een software-delay meer dan handig - zolang je maar wegblijft van floats...

Je kunt altijd als een timer op PWM modus staat de timer ovf interrupt gebruiken. Als je dan lineair interpolatie kent kunt je dan nog altijd met ticks werken maar dan is 1 niet 1 ms maar iets anders.

De attiny reeks is meestal voor low cost toepassingen en missen tegenover de AVR mega en Xmega wat functionaliteit.

Ze missen altijd:

* 2 kloktik vermenigvuldiging
* Bootloader functionaliteit
* IPV specifieke I2C of SPI hebben ze een USI. De USI kan als I2C of SPI gebruikt worden maar daar is extra software voor nodig (De attiny88 heeft dat dus wel).
* Geen asynchrone timer 2.

Van de attiny reeks is de attiny2313 wel mijn favoriet. Klein, goedkoop en veel onboard functionaliteit, jammer dat er geen 4kb versie is.

Als ik begin met een toepassing pak ik meestal de grootste AVR die past in de toepassing. Meestal is dat dus de atmega168 (me favoriet). En als eenmaal de toepassing werkt, optimaliseer zover mogelijk en pak dan meestal een kleinere/goedkopere AVR. Vaak is dit de atmega48 of een attiny2313.