Checkliste: Ausrüstung für ATiny Programmierung

[Thilo (Gast)]

Hi,

ich möchte ein bischen mit einem Mikrocontroller herumspielen. Für's 
erste will ich was ganz kleines, um einfach mal die Software-Toolchain 
aufzusetzen und ein paar kleine Spaßprogramme zu programmieren.

Ich habe mir dafür den ATiny 13A ausgesucht, da er billig ist (65Ct/St 
bei 
https://guloshop.de/shop/Mikrocontroller/ATtiny13-A::15.html?XTCsid=nmn1ls7mu2gf7nmh100c7n0ev5) 
und zum Programmieren würde ich mir das hier holen 
https://guloshop.de/shop/Mikrocontroller-Programmierung/guloboard-P-mit-Programmer::4.html?XTCsid=nmn1ls7mu2gf7nmh100c7n0ev5

Laut Angaben passt das Programmiergerät ja zum ATiny 13A. Kann ich das 
Programmiergerät mit avrdude verwenden? Ich habe auf der avrdude-Seite 
(http://www.mikrocontroller.net/articles/AVRDUDE) ganz unten gelesen, 
dass der ATiny 13 nicht direkt verwendet werden kann mit der Version 
5.10. Gilt das auch noch für die Version 5.11 (ein Changelog konnte ich 
auf der offiziellen Seite nicht finden)? Und wie sieht es mit dem 13A 
aus? Funktioniert die Konfiguration von der Wiki-Seite auch für diesen?

Falls avrdude und 13A nicht sicher miteinander funktionieren könnte ich 
noch alternativ auf den ATiny 85 umschwenken, aber der kostet halt 
gleich das doppelte.

Ach so eine Sache noch, kann man den 13A überhaupt in C programmieren? 
Man hat ja nicht gerade viel Platz (1k), aber C wäre für mich schon ein 
muss. Wie viele Bytes hat denn so ein Basisprogramm, wie

int main()
{
  return 0;
}

das für den ATiny kompiliert wurde (ohne Debugging-Informationen 
versteht sich)?




Vielen Dank und Grüße

Thilo

P.S. Bitte keine anderen Mikrocontroller vorschlagen. Ich will einen 
kleinen 8-Pin Baustein der quasi nichts kostet und nicht viel kann ;-)

[Oliver J. (skriptkiddy)]

Thilo schrieb:
> Falls avrdude und 13A nicht sicher miteinander funktionieren könnte ich
> noch alternativ auf den ATiny 85 umschwenken, aber der kostet halt
> gleich das doppelte.
Den tiny13 kann man über ISP flashen. Das geht über den mitgelierten 
usbasp und avrdude.

> P.S. Bitte keine anderen Mikrocontroller vorschlagen. Ich will einen
> kleinen 8-Pin Baustein der quasi nichts kostet und nicht viel kann ;-)
Ich würde dir trotzdem fürs Rumspielen einen größeren AVR empfehlen. Da 
hat man in der Regel keine Speicherplatzprobleme und hat mehr Peripherie 
drinne. Zum Kennenlernen der AVR ist der tiny13 nicht die beste Wahl. Am 
besten du nimmst dir nen ATMega8 der passt AFAIK zum 
AVR-GCC-Tutorial.

Gruß Oliver

[Markus W. (Firma: guloshop.de) (m-w)]

Oliver J. schrieb:
> Den tiny13 kann man über ISP flashen. Das geht über den mitgelierten
> usbasp und avrdude.

Korrekt, hab ich wahrscheinlich schon 1000-mal gemacht.
Mit avrdude 5.10 hatte ich da aber noch nie Probleme. Auch die Fuse-Bits 
habe ich damit schon angepasst (Oszillatorfrequenz).

>> P.S. Bitte keine anderen Mikrocontroller vorschlagen. Ich will einen
>> kleinen 8-Pin Baustein der quasi nichts kostet und nicht viel kann ;-)
> Ich würde dir trotzdem fürs Rumspielen einen größeren AVR empfehlen. Da
> hat man in der Regel keine Speicherplatzprobleme und hat mehr Peripherie
> drinne. Zum Kennenlernen der AVR ist der tiny13 nicht die beste Wahl. Am
> besten du nimmst dir nen ATMega8 der passt AFAIK zum
> AVR-GCC-Tutorial.

Das mit dem AVR-Tutorial hier im Wiki ist richtig - leider. Der ATmega8 
ist veraltet, wenn dann sollte man den ATmega88 oder bei ein bisschen 
mehr Speicherplatzbedarf den pinkompatiblen ATmega328 verwenden.

Ich hab vor Jahren meinen Einstieg in die AVR-Programmierung mit dem 
ATtiny13 bzw. dessen 8-pinnigen Vorgänger gefunden und es nicht bereut. 
Meiner Ansicht nach eignet sich der ATtiny13 (oder 13A) viel besser für 
den Einstieg als ein größerer Mikrocontroller. Und wenn man AVRs 
wirklich kennen lernen will, dann fängt man mit Assembler an.

Je mehr Funktionen ein solcher AVR besitzt, desto unübersichtlicher wird 
es für einen Einsteiger.

Aber ok, das ist meine Meinung und meine persönliche Erfahrung. :-)

Thilo schrieb:
> Ach so eine Sache noch, kann man den 13A überhaupt in C programmieren?
> Man hat ja nicht gerade viel Platz (1k), aber C wäre für mich schon ein
> muss. Wie viele Bytes hat denn so ein Basisprogramm, wie
>

> int main()
> {
>   return 0;
> }
>

> das für den ATiny kompiliert wurde (ohne Debugging-Informationen
> versteht sich)?

Ehrlich: keine Ahnung. Ich programmier so kleine Bausteine lieber in 
Assembler, weil ich dadurch mehr Leistung raushole und viel genauer 
weiß, was das Programm tut.

Wenn du eine Aufgabe in C löst, brauchst du meistens deutlich mehr Platz 
als in Assembler - zudem läuft das Programm dann nicht selten langsamer. 
Wenn C für dich wirklich wichtig ist, würde ich vielleicht ein paar 
Versuche mit dem ATtiny13 machen, letztlich aber dann doch mindestens 
beim ATtiny85 bleiben, der hat immerhin 8 KB Flash und 512 Bytes SRAM, 
das sollte für C reichen.

[spess53 (Gast)]

Hi

ATTiny13 halte ich für relativ sinnfrei. Man kann die benötigten 
ISP-Pins (ich weiß, kann man auch doppelt belegen) abzieht, bleiben noch 
3 nutzbare Pins übrig.

>Ich habe mir dafür den ATiny 13A ausgesucht, da er billig ist (65Ct/St
>bei ...

Wenn das ein entscheidendes Argument ist, dann fang besser gar nicht 
erst an. Die Folgekosten werden dich ruinieren.

MfG Spess

[Oliver J. (skriptkiddy)]

Markus W. schrieb:
> Wenn du eine Aufgabe in C löst, brauchst du meistens deutlich mehr Platz
> als in Assembler - zudem läuft das Programm dann nicht selten langsamer.
> Wenn C für dich wirklich wichtig ist, würde ich vielleicht ein paar
> Versuche mit dem ATtiny13 machen, letztlich aber dann doch mindestens
> beim ATtiny85 bleiben, der hat immerhin 8 KB Flash und 512 Bytes SRAM,
> das sollte für C reichen.
Nen Kumpel hat sich mal ne Taschenlampe Dimm- und Blinkfunktion gebaut. 
Darin werkelt auch ein ATtiny13. Wurde in C programmiert.


> Ehrlich: keine Ahnung. Ich programmier so kleine Bausteine lieber in
> Assembler, weil ich dadurch mehr Leistung raushole und viel genauer
> weiß, was das Programm tut.
Hab grad mal das Minimalbeispiel durchlaufen lassen:
44 bytes mit -Os
56 bytes mit -O0
(avr-gcc (GCC) 4.3.5 und avr-libc 1.6.8)

Gruß Oliver

[nate (Gast)]

spess53 schrieb:
> die benötigten
> ISP-Pins (ich weiß, kann man auch doppelt belegen) abzieht, bleiben noch
> 3 nutzbare Pins übrig.

öhm, häh? die ISP pins brauch ich aber doch nur in dem moment, in dem 
ich den tiny programmiere. danach kann ich sie für alles mögliche 
verwenden.

Thilo schrieb:
> Laut Angaben passt das Programmiergerät ja zum ATiny 13A. Kann ich das
> Programmiergerät mit avrdude verwenden? Ich habe auf der avrdude-Seite
> (http://www.mikrocontroller.net/articles/AVRDUDE) ganz unten gelesen,
> dass der ATiny 13 nicht direkt verwendet werden kann mit der Version
> 5.10. Gilt das auch noch für die Version 5.11 (ein Changelog konnte ich
> auf der offiziellen Seite nicht finden)? Und wie sieht es mit dem 13A
> aus? Funktioniert die Konfiguration von der Wiki-Seite auch für diesen?

das bezieht sich aber doch nur auf mysmartusb und nicht auf den usbasp, 
der beim guloboard dabei ist. mit dem und avrdude dürfte es da keine 
schwierigkeiten geben!

[Thilo (Gast)]

Super danke für eure Beiträge, dann wird es der ATiny 13A für's erste 
:-)

Oliver J. schrieb:
>> Ehrlich: keine Ahnung. Ich programmier so kleine Bausteine lieber in
>> Assembler, weil ich dadurch mehr Leistung raushole und viel genauer
>> weiß, was das Programm tut.
> Hab grad mal das Minimalbeispiel durchlaufen lassen:
> 44 bytes mit -Os
> 56 bytes mit -O0
> (avr-gcc (GCC) 4.3.5 und avr-libc 1.6.8)
>
Seltsam, ich habe es gerade auch ausprobiert und komme mit avr-gcc -O3 
test.c -o test -nostdlib -Xlinker -s und avr-gcc -Os test.c -o test 
-nostdlib -Xlinker -s auf jeweils 228 Bytes.

...vielleicht sollte ich kein ELF erstellen?

[Oliver J. (skriptkiddy)]

Thilo schrieb:
> Seltsam, ich habe es gerade auch ausprobiert und komme mit avr-gcc -O3
> test.c -o test -nostdlib -Xlinker -s und avr-gcc -Os test.c -o test
> -nostdlib -Xlinker -s auf jeweils 228 Bytes.

Mach mal avr-size auf die elf-datei da siehst du die wirkliche Größe.

Gruß Oliver

[Markus W. (Firma: guloshop.de) (m-w)]

Oliver J. schrieb:
> Thilo schrieb:
>> Seltsam, ich habe es gerade auch ausprobiert und komme mit avr-gcc -O3
>> test.c -o test -nostdlib -Xlinker -s und avr-gcc -Os test.c -o test
>> -nostdlib -Xlinker -s auf jeweils 228 Bytes.
>
> Mach mal avr-size auf die elf-datei da siehst du die wirkliche Größe.
>
> Gruß Oliver

Ich kann euch grad nicht ganz folgen. Wenn der Compiler gut ist, 
übersetzt er

main() { return 0; }

so:

rjmp PC

und braucht dafür genau ein Befehlswort, also 2 Bytes.

[Tokyo D. (tokyodrift)]

Markus W. schrieb:
> Ich kann euch grad nicht ganz folgen. Wenn der Compiler gut ist,
> übersetzt er
> main() { return 0; } so:
> rjmp PCund braucht dafür genau ein Befehlswort, also 2 Bytes.

Wenn der Entwickler gut ist lässt er für main(){ return 0; } den 
Mikrocontroller ganz weg. Das hilft aber nicht weiter. Ein Programm das 
nichts tut braucht kein Schwein, deswegen ist es auch nicht sinnvoll da 
das letzte rauszuoptimieren. Der GCC macht halt einen Startup-Code oder 
sowas, der braucht immer einen bestimmten Platz, und sobald du mehr als 
return 0; machst brauchst du den auch.
Anders gesagt, main(){ return 0; } ist das kleinstmögliche Programm, 
jede Instruktion mehr braucht halt dann ein (oder entsprechend viele) 
Befehlsworte mehr.

[Oliver J. (skriptkiddy)]

Markus W. schrieb:
> Ich kann euch grad nicht ganz folgen. Wenn der Compiler gut ist,
> übersetzt er
> main() { return 0; } so:
> rjmp PCund braucht dafür genau ein Befehlswort, also 2 Bytes.
Welcher Compiler tut das?

[Thilo (Gast)]

Oliver J. schrieb:
> Thilo schrieb:
>> Seltsam, ich habe es gerade auch ausprobiert und komme mit avr-gcc -O3
>> test.c -o test -nostdlib -Xlinker -s und avr-gcc -Os test.c -o test
>> -nostdlib -Xlinker -s auf jeweils 228 Bytes.
>
> Mach mal avr-size auf die elf-datei da siehst du die wirkliche Größe.
>
Tatsächlich, da kommt schon etwas kleineres raus.

00000000 <.text>:
   0:   80 e0           ldi     r24, 0x00       ; 0
   2:   90 e0           ldi     r25, 0x00       ; 0
   4:   08 95           ret

Sieht so aus als wäre int 16Bit groß.

[Thilo (Gast)]

Thilo schrieb:
> ...vielleicht sollte ich kein ELF erstellen?
>
Ich habe festgestellt, dass viele Leute scheinbar die Daten aus dem ELF 
per objcopy entpacken, aber man kann auch direkt z.B. eine Intel Hex 
Datei erzeugen indem man ld mit --oformat das gewünschte Ausgabeformat 
mitteilt, z.B. avr-gcc -Os -o test.hex -nostdlib -Wl,-s,--oformat=ihex 
test.c

[Markus W. (Firma: guloshop.de) (m-w)]

Thilo schrieb:
>

> 00000000 <.text>:
>    0:   80 e0           ldi     r24, 0x00       ; 0
>    2:   90 e0           ldi     r25, 0x00       ; 0
>    4:   08 95           ret
>

>
> Sieht so aus als wäre int 16Bit groß.

Returnwert macht bei main() im Mikrocontroller eh nicht viel Sinn. 
"Echte" Funktionen kann man ja mit int8_t deklarieren.

Wie übersetzt der Compiler wirklichen Code, z.B. das hier?

if((PINB|(1<<PORTB2))==0)  // wenn B2 auf low
  PORTB|= (1<<PORTB3);  // setze B3 auf high

[Thilo (Gast)]

Markus W. schrieb:
> Wie übersetzt der Compiler wirklichen Code, z.B. das 
hier?if((PINB|(1<<PORTB2))==0)  // wenn B2 auf low
>   PORTB|= (1<<PORTB3);  // setze B3 auf high
>
Mir ist die Ausgabe nicht ganz schlüssig. Da fehlt das Setzen. Ist dein 
Code korrekt?

  avr-objdump -dS test-pin

test-pin:     file format elf32-avr


Disassembly of section .text:

00000000 <main>:
#include <avr/io.h>
int main()
{   
    if((PINB|(1<<PORTB2))==0)  // wenn B2 auf low
   0:   86 b3           in      r24, 0x16       ; 22
          PORTB|= (1<<PORTB3);  // setze B3 auf high
    return 0;
}  
   2:   80 e0           ldi     r24, 0x00       ; 0
   4:   90 e0           ldi     r25, 0x00       ; 0
   6:   08 95           ret

Kompiliert habe ich mit avr-gcc -mmcu=attiny13 -Os -nostdlib -o test-pin 
-g test-pin.c

[Markus W. (Firma: guloshop.de) (m-w)]

Thilo schrieb:
> Mir ist die Ausgabe nicht ganz schlüssig. Da fehlt das Setzen. Ist dein
> Code korrekt?

Soweit ich mich an den C-Syntax erinnere, müsste
    PORTB|= (1<<PORTB3);
gleichbedeutend sein mit
    PORTB= PORTB | (1<<PORTB3);
Folglich wird Bit 3 im Register PORTB gesetzt.

Aber, wie schon geschrieben, ich programmiere AVRs normalerweise nicht 
mit C. Kann also gut sein, dass ich mich irre.

[Christian F. (cmf)]

Markus W. schrieb:
> Soweit ich mich an den C-Syntax erinnere, müsste
>     PORTB|= (1<<PORTB3);
> gleichbedeutend sein mit
>     PORTB= PORTB | (1<<PORTB3);
> Folglich wird Bit 3 im Register PORTB gesetzt.

ja richtig

[Markus W. (Firma: guloshop.de) (m-w)]

Markus W. schrieb:
> Wie übersetzt der Compiler wirklichen Code, z.B. das hier?
>

> if((PINB|(1<<PORTB2))==0)  // wenn B2 auf low
>   PORTB|= (1<<PORTB3);  // setze B3 auf high

Sorry, war mein Fehler: die IF-Abfrage ist falsch!
Statt | muss dort & stehen, sonst wird die Bedingung nie wahr. Der 
Compiler hat das offensichtlich erkannt und den Then-Teil, also das 
Setzen des Bits, einfach wegoptimiert. Schlauer Compiler. :-)

[Oliver J. (skriptkiddy)]

Thilo schrieb:
> if((PINB|(1<<PORTB2))==0)
PINB|(1<<PORTB2) ist immer ungleich null. Folglich wird auch niemals
PORTB|= (1<<PORTB3);
ausgeührt.

Das der Compiler trotzdem PINB einliest, könnte daran liegen, dass PINB 
volatile ist.

Gruß Oliver

[Peter D. (peda)]

Thilo schrieb:
> Sieht so aus als wäre int 16Bit groß.

Ja, int muß mindestens 16Bit sein.
Steht aber auch in jedem C-Buch.


Peter

[Thilo (Gast)]

Oliver J. schrieb:
>> if((PINB|(1<<PORTB2))==0)
> PINB|(1<<PORTB2) ist immer ungleich null. Folglich wird auch niemals
> PORTB|= (1<<PORTB3);
> ausgeührt.
>
> Das der Compiler trotzdem PINB einliest, könnte daran liegen, dass PINB
> volatile ist.
>
Ob es volatile ist kann ich dir nicht sagen (wahrscheinlich schon), aber 
es ist wird vor allem mit einem Makro namens _SFR_IO8 definiert. Mit AVR 
GCC habe ich bis heute noch nie gearbeitet, aber beim Keil C Compiler 
gibt es spezielle Schlüsselwörter um Pins/Ports zu markieren: sfb und 
sfr.

Markus W. schrieb:
> Thilo schrieb:
>> Mir ist die Ausgabe nicht ganz schlüssig. Da fehlt das Setzen. Ist dein
>> Code korrekt?
>
> Soweit ich mich an den C-Syntax erinnere, müsste
>     PORTB|= (1<<PORTB3);
> gleichbedeutend sein mit
>     PORTB= PORTB | (1<<PORTB3);
> Folglich wird Bit 3 im Register PORTB gesetzt.
>
Meine Aussage bezog sich eher auf die Ausgabe des Compilers nicht auf 
den C-Code. Dass die if-Bedingung falsch ist, ist mir aber auch nicht 
aufgefallen, dabei ist es im Nachhinein offensichtlich...

So ich haue mal ab in die Feiertage. Ich wünsche euch frohe Ostern.


Thilo

[Peter D. (peda)]

Thilo schrieb:
> Ach so eine Sache noch, kann man den 13A überhaupt in C programmieren?

Ja.
Das ist überhaupt nicht mit PC-Programmierung vergleichbar, wo unter 1MB 
garnichts geht.
Für kleine Ablaufsteuerungen ist der gut geeignet.

Aufwendige Sachen, wie Filesystem, Webserver, GUI usw. gehen natürlich 
nicht.
Float (AVR-GCC) geht ab etwa 2kB Flash (ATtiny25).

Du könntest Dir ja trotzdem einen ATtiny85 gönnen, der ist 
pinkompatibel. Dann kann man erstmal das Programm zum Laufen bringen und 
danach auf Größe optimieren.


Peter