ATTiny in C programmierbar?

[Werner (Gast)]

Hallo zusammen!

Ich habe eine simple Frage: Ist es nun möglich, ALLE AVRs (also somit 
auch ALLE ATTinys) im AVR Studio in der Programmiersprache C zu 
programmieren?
Aus einem alten AVR Studio kenne ich, dass die "ganz kleinen" ATTinys 
damals nur per Assembler programmierbar waren.

Wie lautet eigentlich der kleinste ATTiny? Attiny4?


Danke und Gruß

[asd (Gast)]

ATTiny 44 und 45 gehen auf jeden Fall in C.
C braucht aber genügend RAM Speicher für den Stack. Irgendwann macht es 
bei zu wenig Speicher einfach keinen Sinn mehr eine Hochsprache zu 
benutzen.

[Johann L. (gjlayde)]

Prinzipiell ja, aber mit folgender Einschränkung: Nicht alle 
Support-Funktionen der Standard-Libs sind implementiert.  Z.B. gibt

$ avr-gcc foo.c -mmcu=attiny4 -Os

mit folgendem "Programm"

float inc (float a)
{
    return a + 1;
}

int main (){}

den Linkerfehler

/local/gnu/install/avr-gcc-7.1.1/bin/../lib/gcc/avr/7.1.1/../../../../avr/lib/avrtiny/libm.a(addsf3.o): In function `__addsf3':
(.text.avr-libc.fplib+0x6): undefined reference to `__addsf3x'
(.text.avr-libc.fplib+0x8): undefined reference to `__fp_round'
collect2.exe: error: ld returned 1 exit status

[Patrick J. (ho-bit-hun-ter)]

Hi

Und woran sehe ich, als ungeübter C-Neuling, daß es sich hier um das 
Fehlen von float-Zahlen handelt?
Aus der Fehlermeldung kann ich bestenfalls Buchstabenweise auf den Code 
kommen, da nicht viel mehr als 'ein Buchstabe am Stück' so in dem Code 
vorkommt.
(zumindest interpretiere ich Das so)

[Oliver S. (oliverso)]

Man wächst mit seinen Fehlermeldungen. Sachdienliche Hinweise liefert 
dann google.

Oliver

[Johann L. (gjlayde)]

Patrick J. schrieb:
> Und woran sehe ich, als ungeübter C-Neuling, daß es sich hier um das
> Fehlen von float-Zahlen handelt?

Garnicht. Auch nicht als C-Experte.

Es handelt sich dabei um Interna der Tools wie Naming-Conventions von 
Support-Funktionen.

Falls du auf ATtiny4 float brauchst, hast du den falschen µC oder den 
falschen Algorithmus gewählt — oder beides.

Welche Funktionen sonst noch fehlen kann ich dir nicht sagen, da 
müsstest du in die Implementierung der Libs schauen, also avr-libc und 
libgcc.  Prinzipiell kannst du die Implementierung auch selbst 
hinzufügen, z.B. indem du in deinem Projekt eine __addsf3 implementierst 
falls float-add benötigt wird oder strtok falls du strtok brauchst.

Neben der Vollständigkeit der Implementation ist auch zu bedenken, dass 
gcc für avrtiny merklich schlechter optimiert, insbesondere wegen der 
verkrüppelten Adressierungsarten die nur indirekt, post-increment und 
pre-decrement zulassen, nicht aber indirekt+offset.  Wenn der Code also 
z.B. einen Frame braucht, gibt's erheblichen Bloat.  Dito wenn indirekt 
auf eine Struktur zugegriffen wird.

Dass der reduzierte Registersatz mit nur 16 Registern die Codegüte 
weiter drückt, öfter Parameter über den Stack übergeben werden müssen 
und eher die Register ausgehen, was ein Frame bedingt, sollte auch klar 
sein.

Zudem würde ich als C-Neuling nicht mit einem ATtiny4 anfangen, sondern 
ersma auf dem PC Gehversuche machen und dann mit einem komfortableren µC 
beginnen wie ATmega168 oder so.

[Peter D. (peda)]

Problemlos mit dem AVR-GCC programmieren lassen sich alle AVRs mit 
vollem Registersatz (32 Register) und echtem Stack im SRAM. Der kleinste 
damit ist der ATtiny13.

[Markus (Gast)]

Die Attiny13 habe ich oft in C programmiert.
Ich war erstaunt, wie viel man trotz der geringen Speichergröße damit 
machen kann.

[Rolf M. (rmagnus)]

Johann L. schrieb:
> Dass der reduzierte Registersatz mit nur 16 Registern die Codegüte
> weiter drückt, öfter Parameter über den Stack übergeben werden müssen
> und eher die Register ausgehen, was ein Frame bedingt, sollte auch klar
> sein.

Ich dachte, der GCC nutzt sowieso nur 16 Register.

Übrigens: Wie viele Register  Speicher  sonstige Features der Tiny4 
hat, das weiß anscheinend nicht mal Microchip so genau:
http://www.microchip.com/wwwproducts/en/ATtiny4

[Dennis K. (scarfaceno1)]

Rolf M. schrieb:

> Übrigens: Wie viele Register  Speicher  sonstige Features der Tiny4
> hat, das weiß anscheinend nicht mal Microchip so genau:
> http://www.microchip.com/wwwproducts/en/ATtiny4

Ja...
Die müssen das erst noch von Atmel erzählt bekommen...
:-P

[Ein flüchtiger Gast (Gast)]

Genaugenommen kann man C so programmieren, das der gleiche Assemblercode 
am Ende rausfällt, als würde man direkt in Assembler programmieren.
Das geht natürlich nur in gewissen Grenzen.
Natürlich muss man dabei auch auf Float, höhere Rechenoperationen, etc 
verzichten.

Selbst Takte zählen funktioniert in c. Da muss man aber Sprache und 
Compiler beherrschen. "Wir" haben das mal exemplarisch in einer 
Vorlesung gemacht, beherrschen tue ich das aber nicht. ;-)

Ob ich in C eine Funktion aufrufe und der Compiler sich um den Stack 
kümmert, oder ich in Assembler eine Unterroutine aufrufe und selbst 
meine Register auf den Stack packe sollte keinen großen Unterschied 
machen.

[Walter T. (nicolas)]

Werner schrieb:
> t es nun möglich, ALLE AVRs (also somit
> auch ALLE ATTinys) im AVR Studio in der Programmiersprache C zu
> programmieren?

Die ATtinys mit Hardware-Stack (ATtiny 11 und 12) lassen sich mit dem 
AVR-GCC nicht programmieren. Also ist die Frage mit "Nein" zu 
beantworten.

Warum man diese alten µC noch einsetzen sollte, ist eine andere Frage.

[Johann L. (gjlayde)]

Rolf M. schrieb:
> Ich dachte, der GCC nutzt sowieso nur 16 Register.

Auf AVRs mit 32 Registern verwendet GCC bis zu 32 Register sowie das 
T-Flas in SREG.  Warum sollte er auf Regs welche verzichten?

[Rolf M. (rmagnus)]

Johann L. schrieb:
> Rolf M. schrieb:
>> Ich dachte, der GCC nutzt sowieso nur 16 Register.
>
> Auf AVRs mit 32 Registern verwendet GCC bis zu 32 Register sowie das
> T-Flas in SREG.  Warum sollte er auf Regs welche verzichten?

Hmm, ich meine, es sei zumindest früher mal so gewesen. Warum, weiß ich 
nicht.

[M. K. (sylaina)]

Rolf M. schrieb:
> Hmm, ich meine, es sei zumindest früher mal so gewesen. Warum, weiß ich
> nicht.

Ich tippe mal, dass das früher so war weil die mit dem damaligen GCC 
programmierbaren AVRs eh nur 16 Register hatten.

[m.n. (Gast)]

M. K. schrieb:
> Ich tippe mal, dass das früher so war weil die mit dem damaligen GCC
> programmierbaren AVRs eh nur 16 Register hatten.

Wenn ich nicht irre, war der AT90S1200 der erste AVR. Der hat 
selbstverständlich 32 Register, sonst wäre es kein AVR.
Nebenbei gibt es auch noch andere C-Compiler als GCC ;-)

[Peter D. (peda)]

M. K. schrieb:
> Ich tippe mal, dass das früher so war weil die mit dem damaligen GCC
> programmierbaren AVRs eh nur 16 Register hatten.

Die ersten AVRS (AT90Sxxxx) hatten alle 32 Register (1997).
Erst ab ATtiny4 wurden sie halbiert (2009). Deshalb sind die auch nicht 
mit dem AVR-GCC programmierbar.

Nicht supportet sind auch die alten AVRs ohne SRAM (AT90S1200, 
ATtiny11,12,15,28). Einen Compiler ohne PUSH/POP zu bauen ist nämlich 
recht aufwendig. Unmöglich ist es nicht, siehe PIC.

Die Bezeichnung ATtiny10 wurde übrigens doppelt vergeben, siehe Bild.

[Johann L. (gjlayde)]

Peter D. schrieb:
> Die ersten AVRS (AT90Sxxxx) hatten alle 32 Register (1997).
> Erst ab ATtiny4 wurden sie halbiert (2009). Deshalb sind die auch nicht
> mit dem AVR-GCC programmierbar.

Doch ATtiny4 et al. sind ebenfalls programmierbar mit avr-gcc, und es 
wird der reduzierte Registersatz verwendet.  Am anfang jeder s-datei 
wird z.B. definiert

__tmp_reg__ = 16
__zero_reg__ = 17

im Gegensatz zu normalen AVRs mit tmp=R0 und zero=R1.

Außerdem wird ein anderes ABI verwendet, z.B. sind R18, R19 call-saved 
und nicht call-clobbered, und in R16/17 werden natürlich keine Parameter 
übergeben.  Und anstatt für

char fun (char *s)
{
    return s[1];
}

einfach

fun:
  movw r30,r24
  ldd r24,Z+1
  ret

muss man umständlich

fun:
  mov r31,r25
  mov r30,r24
  subi r30,lo8(-(1))
  sbci r31,hi8(-(1))
  ld r24,Z
  ret

weil Z+1 keine gültige Adressierungsart ist.

[M. K. (sylaina)]

Johann L. schrieb:
> Doch ATtiny4 et al. sind ebenfalls programmierbar mit avr-gcc, und es
> wird der reduzierte Registersatz verwendet.

Das hat auch keiner bezweifelt aber oben wurde ja schon ein Beispiel 
genannt:

Versuche mal folgende Funktion auf einem Attiny4 zu implentieren:

float myFloatDouble(float a){
  return a*2.0;
}
int main(void){
  float myFloat = 0.0;
  for(;;){
    myFloat=myFloatDouble(25.4);
  }
}

Als MCU=attiny4 führt obiger Code zu einem Linker-Fehler, mit z.B. 
MCU=attiny45 wird der Code problemlos übersetzt.

Man kann den Attiny4 durchaus mit Hilfe von C leben einhauchen, es gibt 
aber auch durchaus, ich sag mal, Funktionen, die man dem Attiny4 nicht 
mit C beibringen kann, z.B. mit float-Variablen rechnen.

[Peter D. (peda)]

M. K. schrieb:
> die man dem Attiny4 nicht
> mit C beibringen kann, z.B. mit float-Variablen rechnen.

Die float-Lib belegt ~1kB, d.h. ab ATtiny25 (2kB) kann man daran denken.

Probier mal, obs für den ATtiny40 klappt, das ist auch so eine 
reduzierte Chimäre, aber mit 4kB Flash.
Ich benutze immer noch den WINAVR 2010, kann das also nicht testen.

[Rolf M. (rmagnus)]

Peter D. schrieb:
> Probier mal, obs für den ATtiny40 klappt, das ist auch so eine
> reduzierte Chimäre, aber mit 4kB Flash.

Was bringt denn eigentlich die Reduktion auf 16 Register? Macht das die 
Herstellung wirklich signifikant billiger, oder ist das nur so eine 
kranke Ausgeburt irgendwelcher Marketing-Leute?

[Axel R. (Gast)]

Ein kurze Zwischenfrage sei erlaubt:
TPI Programmiermode(für Tiny10 zB) geht mit welchem Tool? Kann das 
mittlerweile mein AVRISP MKII? Bislang brauchte man wohl ein STK600 
inklusive allem drum und drann...

StromTuner

[Ingo L. (corrtexx)]

Peter D. schrieb:
> Ich benutze immer noch den WINAVR 2010, kann das also nicht testen.
Mich interessiert brennend warum. Du bist ja soweit Profi das du dafür 
mehr Gründe als "zu faul für was Neues" haben dürftest.

Axel R. schrieb:
> Kann das mittlerweile mein AVRISP MKII?
Ja kann er

[Yalu X. (yalu) (Moderator)]

Peter D. schrieb:
> Probier mal, obs für den ATtiny40 klappt, das ist auch so eine
> reduzierte Chimäre, aber mit 4kB Flash.

Das geht auch nicht, da für alle reduzierten Tinies die gleichen
(reduzierten)  Bibliotheken verwendet werden. Der Grund für das Fehlen
vieler FP-Routinen liegt aber nicht im Speicherverbrauch, sondern daran,
dass sie in Assembler geschrieben sind und deswegen erst umgeschrieben
werden müssten.

[Axel S. (a-za-z0-9)]

Rolf M. schrieb:
> Was bringt denn eigentlich die Reduktion auf 16 Register? Macht das die
> Herstellung wirklich signifikant billiger, oder ist das nur so eine
> kranke Ausgeburt irgendwelcher Marketing-Leute?

Das kann eigentlich nur Marketing sein, um den Verkauf der größeren 
Chips anzukurbeln. Fällt mir auch bei "kastrierter" Peripherie immer 
wieder negativ auf. Z.B. haben die beliebten (weil kleinen) 
ATTiny25/45/85 zwar 3 Timer, aber keiner von denen ist 16-bittig. Was 
soll das? Als ob die paar Flipflops mehr ein Problem dargestellt hätten.

[Johann L. (gjlayde)]

Axel S. schrieb:
> Rolf M. schrieb:
>> Was bringt denn eigentlich die Reduktion auf 16 Register? Macht das die
>> Herstellung wirklich signifikant billiger, oder ist das nur so eine
>> kranke Ausgeburt irgendwelcher Marketing-Leute?
>
> Das kann eigentlich nur Marketing sein, um den Verkauf der größeren
> Chips anzukurbeln.

War der Grund nicht der, dass diese Tinys einen besonders kleinen 
Footprint hatten, der zur Zeit der Markteinführung von keinem normalen 
AVR erreicht wurde?

[Peter D. (peda)]

Ingo L. schrieb:
> Peter D. schrieb:
>> Ich benutze immer noch den WINAVR 2010, kann das also nicht testen.
> Mich interessiert brennend warum. Du bist ja soweit Profi das du dafür
> mehr Gründe als "zu faul für was Neues" haben dürftest.

Warum sollte ich etwas einwandfrei funktionierendes deinstallieren, 
kostet doch nur unnütz Zeit.
Den Support für die reduzierten ATtiny brauche ich nicht, da ich die 
nicht verwende. Im Alter lötet man nicht so gerne winzige Bauteile.

[Ingo L. (corrtexx)]

Peter D. schrieb:
> Warum sollte ich etwas einwandfrei funktionierendes deinstallieren,
> kostet doch nur unnütz Zeit.
Weil der Compiler sich ja auch weiter entwickelt und Fehler behoben 
werden z.B.!?

[Peter D. (peda)]

Ingo L. schrieb:
> Weil der Compiler sich ja auch weiter entwickelt und Fehler behoben
> werden z.B.!?

Aber auch neue Fehler hinzu kommen können. Ich mag bekannte Fehler 
lieber als neue unbekannte.
In der Praxis habe ich bisher keinen fehlerhaften Code beim WINAVR 
bemerkt.

[M. K. (sylaina)]

Ingo L. schrieb:
> Weil der Compiler sich ja auch weiter entwickelt und Fehler behoben
> werden z.B.!?

Wenn man aber von den Fehler nicht tangiert wird hat man davon auch 
keinen Vorteil. Und warum sollte man Aufwand für etwas treiben, dass man 
später eh nicht nutzt?