main.c:1:0: error: MCU ‘attiny11’ supported for assembler only
11
In file included from /usr/lib/gcc/avr/4.5.3/../../../avr/include/avr/io.h:423:0,
12
from main.c:1:
13
/usr/lib/gcc/avr/4.5.3/../../../avr/include/avr/iotn11.h:51:4: warning: #warning "MCU not supported by the C compiler"
14
main.c:3:2: warning: #warning "F_CPU war noch nicht definiert, wird nun mit 1000000 definiert"
15
make: *** [main.o] Fehler 1
Bedeutet dies dass AVR-GCC nicht für den ATTINY11 geeignet ist, oder
benötige ich noch irgendeine Include-Datei oder Lib?
Für den ATMEGA8515 konnte ich bereits erfolgreich ein Programm schreiben
und testen.
Betriebssystem: Ubuntu 12.04
Installiert: AVR-GCC, AVR-LIBC, AVRDUDE
Programmer: STK500
Hoffen das sind alle notwendigen Informationen. Wenn nicht, einfach
bescheid geben.
Achja noch ne kurze Frage: was ist der Unterschied zwischen F_OSC und
F_CPU? Beim ATMEGA8515 reicht die Angabe von F_OSC im Makefile, beim
ATTINY11 nicht. Dieser benötigt die Angabe von F_CPU im C-Code.
Gruß
Michael
Ältere Versionen (so etwa GCC 3.3 ?) sollen die kleine Tinys unterstützt
haben, aber auch nur mit einigen Einschränkungen.
Wenn es nicht gerade um sehr große Stückzahlen geht - wäre ein etwas
größerer Chip mit RAM die einfache Alternative.
Schade,
dann muss wohl ein neuer, größerer Controller her. Gibt es irgendwo eine
Liste welche Controller geeignet sind oder muss ich Datenblätter wälzen?
Gibt es sonst noch Dinge die ich beachten muss? (Hab mit AVR noch so gut
wie keine Erfahrungen)
Die Stückzahlen bleiben überschaubar. Vom Preis her kanns also auch ein
größerer Controller sein. Da gehts mir eher noch um die Abmessungen.
40-pin PDIP ist manchmal einfach zu groß.
Gibt es eine andere (einfache) Möglichkeit ATTINY's nativ unter Linux zu
programmieren.
Gruß
Michael
Ulrich schrieb:> Ältere Versionen (so etwa GCC 3.3 ?) sollen die kleine Tinys unterstützt> haben, aber auch nur mit einigen Einschränkungen.
Nein, wurden nie unterstützt.
Es gibt irgendwo im Netz einen Hack, mit dem man so einigermaßen
arbeiten kann, wenn's unbedingt sein muss.
Michael L. schrieb:> dann muss wohl ein neuer, größerer Controller her.
Naja, das eine Kilobyte Flash und die paar Register eines ATtiny11
bekommst du auch mit Assembler gefüllt. ;-)
Allerdings sind die Dinger in jeglicher Hinsicht steinzeitlich.
Nicht nur die CPU-Architektur, auch der Rest. Außerdem ist er
nur HV-programmierbar.
> Gibt es irgendwo eine> Liste welche Controller geeignet sind oder muss ich Datenblätter wälzen?
Dafür müsstest du uns deine Anforderungen nennen.
Wenn aber ein ATtiny11 bereits für dich geeignet wäre, dann geht
wohl fast jeder AVR. :)
> Die Stückzahlen bleiben überschaubar.
Dann würde ich keinen ATtiny11 nehmen. Der einzige Grund für das
Ding wäre wirklich nur der Preis.
> Da gehts mir eher noch um die Abmessungen.> 40-pin PDIP ist manchmal einfach zu groß.
8pinnige AVRs gibt's wie Sand am Meer, vom schon am Beginn des
Rentenalter stehenden ATtiny13 angefangen.
> Gibt es eine andere (einfache) Möglichkeit ATTINY's nativ unter Linux zu> programmieren.
Anders als was?
> Naja, das eine Kilobyte Flash und die paar Register eines ATtiny11> bekommst du auch mit Assembler gefüllt. ;-)
Wenn Assembler würd ich aber gerne auf dem gleichen Controller auch mit
C programmieren können, um nicht gleich komplett zweigleisig anzufangen.
Also gleich mit unterschiedlichen Controllern und unterschiedlicher
Programmiersprache.
>> Gibt es irgendwo eine Liste welche Controller geeignet sind oder muss>> ich Datenblätter wälzen?> Dafür müsstest du uns deine Anforderungen nennen.
Das "geeignet" bezog sich auf AVR-GCC.
Ansonsten habe noch keine konkreten Anforderungen da ich mich ersteinmal
in die Materie einarbeiten muss. Aber für ein mögliches Projekt das ich
schon im Hinterkopf habe muss ich 2 PWM Signale mit einer Periodendauer
von 20ms einlesen und 4 PWM Signale (aber nur 2 zur selben Zeit) mit
einer Frequenz von mehreren kHz ausgeben.
(Vorwärts-Rückwärts-Drehzahlsteller für 2 DC-Motoren)
> 8pinnige AVRs gibt's wie Sand am Meer, vom schon am Beginn des> Rentenalter stehenden ATtiny13 angefangen.
Dann gibts nur noch das Problem mit dem Compiler...
>> Gibt es eine andere (einfache) Möglichkeit ATTINY's nativ unter Linux zu>> programmieren.> Anders als was?
Äh, ich mein keine andere sondern überhaupt eine Möglichkeit in C.
AVR-GCC ist ja so wie es aussieht keine Möglichkeit.
Michael L. schrieb:> Dann gibts nur noch das Problem mit dem Compiler...>>>>> Gibt es eine andere (einfache) Möglichkeit ATTINY's nativ unter Linux zu>>> programmieren.>> Anders als was?> Äh, ich mein keine andere sondern überhaupt eine Möglichkeit in C.> AVR-GCC ist ja so wie es aussieht keine Möglichkeit.
Nur der Attiny11 wird nicht unterstützt. Andere 8-pinner werden aber
unterstützt:
13
15
25
45
85
Ok, dann hab ichs falsch verstanden.
> Der ATTiny hat kein RAM, nur Register.
Dachte das wäre auf alle Attiny's bezogen.
Werd wohl erstmal die Datenblätter der genannten Attiny's durchsuchen um
beim nächsten Kauf etwas passenderes zu bekommen ;)
Michael L. schrieb:> Ok, dann hab ichs falsch verstanden.>>> Der ATTiny hat kein RAM, nur Register.> Dachte das wäre auf alle Attiny's bezogen.>> Werd wohl erstmal die Datenblätter der genannten Attiny's durchsuchen um> beim nächsten Kauf etwas passenderes zu bekommen ;)
Atmel hat auf seiner Webseite eine Liste aller AVRs mit den wichtigsten
Parametern und zwar schön tabellarisch angeordnet. Fang doch erstmal da
an.
Michael L. schrieb:> Aber für ein mögliches Projekt das ich> schon im Hinterkopf habe muss ich 2 PWM Signale mit einer Periodendauer> von 20ms einlesen und 4 PWM Signale (aber nur 2 zur selben Zeit) mit> einer Frequenz von mehreren kHz ausgeben.
Dann solltest du dir vor allem die Timerhardware ansehen. PWM
einlesen klingt nach input capture interrupt, dann musst du noch
klären, ob du den gleichen Timer auch parallel für PWM mit benutzen
kannst. Das ist im wesentlichen eine Frage der Taktrate und der
Zählweite des Timers.
Wenn beide PWM-Eingägne voneinander unabhängig sind, kann es sich
auch lohnen, über einen Controller pro Kanal nachuzudenken. Die
Software selbst hat bei alldem ohnehin nicht viel zu tun, also 2 x
ATtiny25 würde es wahrscheinlich schon tun. (ATtiny13 ist sehr
viel einfacher gestrickt als die neueren ATtiny25...85, den würde
ich mir nur antun, wenn es entweder auch damit alles noch ganz
einfach realisierbar ist oder aber Kostendruck dahinter steckt.)
werden u.a. zwei Listen von unterstützten MCUs ausgegeben, eine für den
C-Compiler und eine für den von diesem verwendeten Assembler. Letztere
ist üblicherweise auch für den Linker gültig.
Bis GCC Versionen bis 4.4 wird nur die Liste für den Assembler/Linker
ausgegeben. Um zu sehen, was der C-Compiler unterstützt, versuchst du,
ein Programm für eine garantiert nicht existierenden MCU zu compilieren:
1
avr-gcc -mmcu=x dummy.c
Die Fehlermeldung enthält die gewünschte Liste.
Dann schaust du noch nach, welche MCUs deine AVR-Libc unterstützt: Im
Include-Verzeichnis gibt es für jeden Typ eine Datei namens io*.h. Der *
steht für den abgekürzten MCU-Namen, also bspw. "tn13" für ATtiny13.
Jetzt musst du nur noch die Schnittmenge der drei Listen (C-Compiler,
Assembler/Linker und AVR-Libc) bilden, dann weißt du, was alles geht.
Wenn du schon eine bestimmte MCU ins Auge gefasst hast, kannst du
natürlich auch einfach prüfen, ob du ein Testprogramm für diese MCU
fehlerfrei bauen kannst.
Yalu X. schrieb:> Die Fehlermeldung enthält die gewünschte Liste.
Das ist zwar korrekt, aber es geht auch einfacher "über den Daumen".
Außer den "prähistorischen" AVRs (AT90S1200, ATtiny11, ATtiny12)
unterstützt der Compiler nahezu alle AVRs, die es gibt. Für die
ganz neuen "tiny tinys" (ATtiny4, 5, 9, 10, 20, 40) mit dem
reduzierten CPU-Kern gibt's Patches bislang nur von Atmel, die sich
aber in freier Wildbahn als nicht gerade sehr stabil erwiesen haben,
insofern sollte man wohl von der Benutzung des C-Compilers für diese
Controller vorerst abraten.
Alle anderen 8-bit-AVRs werden unterstützt, bei einigen mit dem Suffix
"A" muss man diesen für das Compilieren ggf. weglassen (aus Sicht des
Programmierers sollten sich A- und nicht-A-AVRs nicht unterscheiden).
bekomme ich nur mögliche Parameter für Assembler und Linker und eine
Liste bekannter MCU's. In der Liste ist auch der ATtiny11 enthalten.
Also hilft das leider nichts.
1
avr-gcc -mmcu=x dummy.c
verweist lediglich auf den Befehl
1
avr-gcc --target-help
> Wenn du schon eine bestimmte MCU ins Auge gefasst hast, kannst du> natürlich auch einfach prüfen, ob du ein Testprogramm für diese MCU> fehlerfrei bauen kannst.
Ich werd wohl erstmal anhand der Tabellen eine grobe Vorauswahl treffen,
dann damit testen ob er unterstützt wird und danach nochmal genauer ins
Datenblatt schauen.
Danke für die Tipps.
Michael L. schrieb:> Mit> avr-gcc --target-help> bekomme ich nur mögliche Parameter für Assembler und Linker> und eine Liste bekannter MCU's.> In der Liste ist auch der ATtiny11 enthalten.
Ja, weil der Compiler den ATtiny11 kennt — allerdings nur, um zu bei
Verwendung zu meckern, daß der lediglich per Assembler unterstützt wird
:-)
Einen Überblick über die ca 200 unterstützen Derivate gibt die GCC-Doku,
hier für 4.7.1:
http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc/AVR-Options.html
Diese Liste ist komplett und vollständig da aus den Compilerquellen
automatisch erzeugt.
Ältere Dokumentationen bis für 4.6 sind leider nicht so akribisch...
Michael L. schrieb:> Mit>> avr-gcc --target-help>> bekomme ich nur mögliche Parameter für Assembler und Linker und eine> Liste bekannter MCU's. In der Liste ist auch der ATtiny11 enthalten.> Also hilft das leider nichts.
Mist, das habe ich nicht überprüft. Ich habe nur gesehen, dass die Liste
für Assembler mehr Namen enthält als die für den C-Compiler. Faulerweise
habe ich aber nicht nachgeschaut, welche Namen in der C-Liste fehlen.
Ein wenig blöd finde ich das aber schon, dass die Listen die bekannten
und nicht die wirklich unterstützten MCUs enthalten. Was nützt es zu
wissen, welche MCU-Namen in irgendeinem internen Array des Compilers
stehen, wenn sie sich bei näherem Hinsehen als Dummy-Einträge entpuppen?
Immerhin weiß der Compiler ja, dass er mit MCUs wie dem ATtiny11 nichts
anfangen kann, warum gibt er dieses Wissen bei --target-help nicht
einfach preis?
Michael L. schrieb:> Schade,> dann muss wohl ein neuer, größerer Controller her.
Es reicht völlig, wenn man einen AVR nimmt, der auch beschaffbar ist.
Die ATtiny11, 12, 15 werden ja schon lange nicht mehr hergestellt. Sie
waren auch nur sehr kurz verfügbar, sodaß einfach kein Bedarf bestand,
sie zu implementieren.
Die Nachfolger ATtiny13, 25, 45, 85 kann der AVR-GCC in C.
Peter
Thread beobachten
Seitenaufteilung abschalten