leider zeigt mein AVR Studio das als Fehler an. Kann aber leider nicht
rausbekommen was damit gemacht. Hat was mit dem i2C Flag zu tun und
clair.
Hat jemand eine Idee dazu?
LG Pt
Es werden vermutlich irgendwelche Bits in irgendwelchen Registern
gesetzt.
SR =Status Register CR=controlRegister?
Alle notwendigen includepfade in der Ide hinterlegt? Die die Register
und schiebewertedefinieren?
Peterle schrieb:> leider zeigt mein AVR Studio das als Fehler an.
Und es sagt nur "Fehler!", aber keine Information darüber, welcher
Fehler aufgetreten ist?
Syntaktisch sieht die Zeile korrekt aus, d.h. ich würde vermuten, dass
irgendwelche Definitionen fehlen, weil der falsche (unbekannte)
Prozessor eingestellt ist.
> Hat was mit dem i2C Flag zu tun und clair.
Wer oder was ist Clair?
Peterle schrieb:> Hat jemand eine Idee dazu?
Natürlich. Da schaust du zu allererst im Referenzmanual des µC nach, was
für ein Register denn USISR ist. Dann schaust du in den Tiefen des
zugrundeliegenden Projektes nach, ob und wo du die Namen USISIF, USIOIF,
USIPF usw. findest. Das müßte in solchen Zeilen
#define USISIF 5
oder so ähnlich zu erwarten sein. Dann guckst du wieder ins Manual, was
an den entsprechenden Bitpositionen im besagten Register steht und was
es zu bedeuten hat.
Dann hast du damit herausgefunden, was besagte Statements zu bedeuten
haben und auch, warum es bei deinem Chip nen Fehler gibt. Denn entweder
hast du die Datei nicht eingebunden, wo der Zusammenhang zwischen den
o.g. Namen und den tatsächlichen Bits deklariert ist, oder für deinen
Chip gibt es irgend eines dieser Bits gar nicht.
W.S.
Nachtrag:
Peterle schrieb:> In einem Programm von Stefan Frings wird dieser Code verwendet:> USISR = (1<<USISIF) | (1<<USIOIF) | (1<<USIPF) | (1<<USIDC);> USICR = (1<<USIWM1) | (1<<USICS1);
An solchen Stellen sieht man mal wieder, daß das benutzen von
irgendwelchen Namen anstelle der echten Bitpositionen immer wieder Anlaß
zum Suchen ist, bis man herausbekommt, was da nicht läuft.
Ich präferiere deshalb immer, sowas anders zu schreiben, etwa so:
(Bitpositionen und Kommentare sind hier mal nur symbolisch zu verstehen)
1
USISR=(1<<7)|// Interruptflag setzen
2
(0<<5)|// Outputflag NICHT einschalten
3
(1<<1)|// Parität gerade
4
(1<<0);// Takt einschalten
Bei solcher Darstellung sieht man sofort, WAS da gemacht werden soll und
man braucht auch nur im Referenzmanual nachzulesen, nicht jedoch sich
durch ggf. ellenlange sonstige Headerfiles durchwühlen zu müssen.
Aber OK, es sind ein paar Buchstaben mehr zu schreiben, was offenbar
für so manchen geradezu unerträglich ist.
W.S.
W.S. schrieb:> Ich präferiere deshalb immer, sowas anders zu schreiben, etwa so:> (Bitpositionen und Kommentare sind hier mal nur symbolisch zu> verstehen)USISR = (1 << 7) | // Interruptflag setzen> (0 << 5) | // Outputflag NICHT einschalten> (1 << 1) | // Parität gerade> (1 << 0); // Takt einschalten>> Bei solcher Darstellung sieht man sofort, WAS da gemacht werden soll und> man braucht auch nur im Referenzmanual nachzulesen, nicht jedoch sich> durch ggf. ellenlange sonstige Headerfiles durchwühlen zu müssen.>> Aber OK, es sind ein paar Buchstaben mehr zu schreiben, was offenbar> für so manchen geradezu unerträglich ist.
Bis auf die Kommentare ist das doch bäh!
Dann kann man auch gleich eine Binär- oder Hexadezimal-Zahl mit
Kommentaren hinschreiben (Dezimal wäre dann endgültig verwirrend).
Die Bit-Name entspricht doch i.d.R. der Bezeichnung im Datenblatt.
Sooo schwierig ist das Lesen der Header-Dateien auch nicht.
Hugo E. schrieb:> Muß es ja auch nicht...
ach wenn ich was nicht einschalten will brauche ich keine 0 shiften, das
ist so überflüssig wie ein Kropf, war es ein schaltet es definitiv nicht
aus!!
W.S. schrieb:> An solchen Stellen sieht man mal wieder, daß das benutzen von> irgendwelchen Namen anstelle der echten Bitpositionen immer wieder Anlaß> zum Suchen ist, bis man herausbekommt, was da nicht läuft.>> Ich präferiere deshalb immer, sowas anders zu schreiben, etwa so:> (Bitpositionen und Kommentare sind hier mal nur symbolisch zu> verstehen)USISR = (1 << 7) | // Interruptflag setzen> (0 << 5) | // Outputflag NICHT einschalten> (1 << 1) | // Parität gerade> (1 << 0); // Takt einschalten
... und warum verwendest du dann für USISR (was wohl das Statusregister
USI sein soll) nicht die Adresse für das Statusregister und verwendest
hierfür einen Namen???
Warum nur wurden in avrio Namen vergeben wenn man sie nicht verwenden
soll?
Woher weiß man auf Anhieb, dass das 7. Bit das Interruptflag ist, das 5.
das Outputflag usw. ?
Jeder hat so seine Präferenzen und manche würden z.Bsp. ein (1 << 0) für
Quatsch erachten und stattdessen einfach nur | 1 schreiben.
Andere würden vielleicht nur schreiben : USISR = 0xA3 (weil sie die Bits
im Kopf schnell nach Hex wandeln können).
Ich stelle mir gerade vor, bei einem Cortex die ungleich mehr
vorhandenen Register (und logischerweise deren Bits) alle einzeln über
deren Bitpositionen zu aktivieren / reaktivieren: Mein Tisch wäre
übersäät mit Datenblätter ... oder ich bräuchte 2 Monitore: einen fürs
Programmierfenster, einen für den Codeeditor (ich hab zu Hause keinen
Platz für 2 Monitore).
Prinzipiell hilft das dem TO wenig: wenn ich in meine Glaskugel schaue,
versucht er vielleicht ein Programm für einen ATtiny für einen ATmega zu
übersetzen der kein USI hat ???
Der vielzitierte Blick ins Datenblatt würde (wie fast immer) helfen!
Joachim B. schrieb:> war es ein schaltet es definitiv nicht aus!!
Durch die gesamte Zuweisung schon.
Wenn man nur das Konstrukt mit den veroderten Bits nehmen würde, wäre
das was anderes. So aber kann vor der Zuweisung das Register an dieser
Stelle keine "1" haben, die gelöscht werden müßte.
Es suggeriert aber, dass irgendwas ausgeschaltet wird. Wird aber nicht.
Stattdessen wird da gar nichts gemacht, also sollte da auch gar nichts
stehen.
Diese Zeile
1
|(0<<5)
sagt ja quasi, dass in Bit 5 bitte eine 0 nicht reingeschrieben werden
soll. Das kann man deutlich besser ausdrücken, indem man die Zeile auch
nicht hinschreibt.
Über die Verwendung von Namen für die Bits statt kryptischer Nummern
sollte man eigentlich nicht mehr diskutieren müssen.
Hugo E. schrieb:> Joachim B. schrieb:>> war es ein schaltet es definitiv nicht aus!!>> Durch die gesamte Zuweisung schon.
Zuweisung oder nicht: Die Zeile hat keinerlei Wirkung.
W.S. schrieb:> An solchen Stellen sieht man mal wieder, daß das benutzen von> irgendwelchen Namen anstelle der echten Bitpositionen immer wieder Anlaß> zum Suchen ist, bis man herausbekommt, was da nicht läuft.
Wenn du echte Bitpositionen verwendest, gibt es zumindest keine lästigen
Fehlermeldungen, falls irgendetwas bei der Deklaration schief läuft,
z.B. wenn der Prozessor gar nicht passt.
Und schon Wochen später musst du das Rad halb neu erfinden, wenn du
verstehen willst, was das ganze sollte.
Rolf M. schrieb:> Und es sagt nur "Fehler!"
Das ist sehr seltsam und nicht hilfreich. Mache mal bitte ein Foto von
deinem ganzen(!) Bildschirm (incl. der Fehlermeldung) und poste das
hier.
Joachim B. schrieb:> warum so?
Damit man explizit sieht, was man mit ner Null bedenkt. Es gibt viele
Flags in der HW, wo es nicht nur um ein/aus geht, sondern andere
bedeutungen dahinter stehen.
W.S.
Stefanus F. schrieb:> Helft dem TO!
Machen wir - sobald er dann mal mit den dafür nötigen Informationen
rausrückt. Basierend auf dem, was er geschrieben hat, ist alles gesagt
worden.
W.S. schrieb:> An solchen Stellen sieht man mal wieder, daß das benutzen von> irgendwelchen Namen anstelle der echten Bitpositionen immer wieder Anlaß> zum Suchen ist, bis man herausbekommt, was da nicht läuft.
Fehlermeldungen des Compilers auszutricksen, ist der mit Abstand
schlechteste Rat.
Denn damit suchst Du Dich dumm und dusslig, wenn Du mal den MC-Typ
wechselst und der andere Bits an anderen Stellen hat.
Daher immer die Namen aus dem Datenblatt verwenden und keine "magischen"
Zahlen. Dann brauchst Du den Fehler nicht zu suchen, sondern liest
einfach die Fehlermeldung des Compilers.
W.S. schrieb:> Ich präferiere deshalb immer, sowas anders zu schreiben, etwa so:> (Bitpositionen und Kommentare sind hier mal nur symbolisch zu> verstehen)USISR = (1 << 7) | // Interruptflag setzen> (0 << 5) | // Outputflag NICHT einschalten> (1 << 2) | // Parität gerade> (1 << 0); // Takt einschalten
Lauter magische Zahlen im Code - GANZ BLÖDE IDEE.
Denn so versteht man nach 2 Wochen seinen eigenen Code nicht mehr. Mit
den "sprechenden" Namen für die Bits hingegen schon.
Fehler im vom Hersteller gelieferten Header kommen eher selten vor.
Und die Namen haben auch die angenehme Eigenschaft, auf einem
unpassenden Prozessor einen Fehler zu werfen - denn dort muss man den
Code vermutlich anpassen, weil Bitpositionen und Registernamen sich
geändert haben.
Hausaufgabe: Wie lange braucht ihr, um im Vergleich mit dem Manual
rauszufinden dass da eine Zahl oben falsch ist?
Jim M. schrieb:>> USISR = (1 << 7) | // Interruptflag setzen>> (0 << 5) | // Outputflag NICHT einschalten>> (1 << 2) | // Parität gerade>> (1 << 0); // Takt einschalten> Denn so versteht man nach 2 Wochen seinen eigenen Code nicht mehr.
Zusammen mit den Kommentaren ist er für mich klar verständlich, obwohl
ich auch sprechende Namen bevorzuge.
Faustregel:
Wann immer Du bemerkst daß Du grad ne literale Konstante hingeschrieben
hast und kurze Zeit später nen Kommentar dazu der sie erklärt, wann
immer das geschieht weißt Du genau daß Du noch ein #define brauchst und
selbst wenn es in dem Moment an der Tür klopf rufst Du "eine Minute
noch!" und schreibst es noch hin bevor Du gehst!
Wolfgang schrieb:> Und schon Wochen später musst du das Rad halb neu erfinden, wenn du> verstehen willst, was das ganze sollte.
Nein, denn genau DAS steht ja direkt daneben. In solchem Falle brauch
ich nicht mal ins Manual zu schauen.
W.S.
W.S. schrieb:> Bei solcher Darstellung sieht man sofort, WAS da gemacht werden soll und> man braucht auch nur im Referenzmanual nachzulesen, nicht jedoch sich> durch ggf. ellenlange sonstige Headerfiles durchwühlen zu müssen.
Nö. Bei der von Dir abgelehnten Schreibweise, bei der die Bits mit ihren
Namen angegeben werden, muss man auch keine Headerfiles durchwühlen,
sondern man kann genau so im Referenzmanual nachlesen, denn da werden
schließlich die gleichen Namen verwendet.
Was für ein Referenzmanual sollte das sein, in dem nur steht "Setze Bit
7 in Register XY"? Da steht natürlich "Setze das Bit ABC in Register
XY".
Deine Versuche, anderen Leuten C bei- und auch näherzubringen, sind ja
im Prinzip durchaus sinnvoll, aber bitte: Schreib' nicht solchen
Quatsch.
Wenn Du diesen "Stil" für Dich gut findest, meinetwegen, aber versuch'
nicht, das anderen Leuten beizubringen.
Bernd K. schrieb:> weißt Du genau daß Du noch ein #define brauchst
Nö. Stattdessen erklärst du mir jetzt und auf der Stelle die Bedeutung
von FMC_TAGVDW1S0 - und zwar ohne in die Headerdateien zu schauen und
ohne zu wissen, um welchen Chip es sich gerade handelt.
Kannste nicht, das ist mir klar, ist ja auch provokativ von mir - aber
zu dem Zweck, daß du deine Ansichten etwas weniger verabsolutierst.
Nein, zusätzliche #define's sind an manchen Stellen gut, woanders nötig
und noch woanders überflüssig bis verwirrend.
Also in dem Falle weiß ich ganz genau, daß ich vielleicht ein #define
gebrauchen kann oder je nach Situation eben nicht. So etwa.
Und wer etwas weiter oben von "sprechenden" Namen schreibt, der möge
ebenfall mal auf der Stelle den Unterschied zwischen FMC_TAGVDW1S0 und
FMC_DATAW1S0U benennen. Dabei ist das noch einfach, denn es sind zwei
HW-Register und keine vom Hersteller einer Toolchain erfundenen Namen.
Von wegen SPRECHENDE Namen. Ich sage dazu Obfuscation. Um
herauszukriegen, was tatsächlich gemeint ist, muß man an mehreren
Stellen nachschauen. Und man kann sich nicht drauf verlassen, wenn man
mehr als nur eine Toolchain zu benutzen hat.
Den Präzedenzfall hatten wir ja schon mal diskutiert:
#define MeinPin 7
oder
#define MeinPin (1<<7)
Wer da das Eine gewöhnt ist und auf nen .h trifft, wo das Andere üblich
ist, fällt heftig auf die Nase - und das regelmäßig ohne die geringste
Warnung durch die Toolchain. Woher soll die auch wissen, ob da jemand 7
oder 128 haben will. Dies nur als Warnung vor angeblich "sprechenden"
Namen für Bits oder Bitgruppen.
W.S.
Rufus Τ. F. schrieb:> Nö. Bei der von Dir abgelehnten Schreibweise, bei der die Bits mit ihren> Namen angegeben werden, muss man auch keine Headerfiles durchwühlen,> sondern man kann genau so im Referenzmanual nachlesen, denn da werden> schließlich die gleichen Namen verwendet.
Lies einfach meinen obigen Beitrag und dann revidiere deine Aussage. Die
Sache mit MeinPin als 7 oder (1<<7) sollte dich dran erinnern.
W.S.
Rufus Τ. F. schrieb:> W.S. schrieb:>> Die Sache mit MeinPin als 7 oder (1<<7) sollte dich dran erinnern.>> Das ist eine komplett andere Baustelle. Lenk' nicht ab.
Das ist auch voll Sch....
Generell:
#define BIT0 0x01
...
#define BIT3 0x08
Und speziell
#define UC_ABC BIT3
So bleibt es leserlich!
Leichtleser schrieb:> Das ist auch voll Sch....
Das kann man so sehen, ich präferiere die Shift-Schreibweise auch nicht,
aber es gibt einen legitimen Grund dafür.
Das sind die Bitadressierungsarten des AVR-Assemblers, die mit
Bitnummern statt Bitwerten arbeiten. Und da die Register- und
Bitdefinitionen nicht doppelt vorliegen sollen, verwendet der
AVR-Assembler die gleichen Definitionsdateien wie der C-Compiler.
Damit wird im AVR-Umfeld mit Bitnummern statt mit Bitwerten gearbeitet,
und das wiederum hat die Shift-Schreibweise zur Folge.
Es stimmt genau, habt viel gesagt. Sehr viel für mich dabei. Danke erst
mal dafür. Habe eure Vorschläge soweit wie möglich gleich umgesetzt. Die
meisten Fehler konnte ich weg bekommen. Es gab allerdings keine grosse
Fehlermeldung, konnte deswegen auch nichts angeben. Bleibt im Grunde
noch ein Problem:
Das sind die beiden Fehler zu diesen Zeilen und das ca. 20 mal ???
expected expression before '=' token
expected expression before ')' token
Die Variablen werden erkannt und korrekt in rot dargestellt.
LG Pt
W.S. schrieb:> Nein, denn genau DAS steht ja direkt daneben. In solchem Falle brauch> ich nicht mal ins Manual zu schauen.
Meist funktioniert das genau bis zur ersten Änderung, bei der der
Kommentar nicht mitgezogen wird.
Peterle schrieb:> Das sind die beiden Fehler zu diesen Zeilen und das ca. 20 mal ???>> expected expression before '=' token> expected expression before ')' token
Und sind dein verwendeten Konstanten vernünftig, d.h. passend definiert
(und für den Compiler erreichbar)? Verschwindet die Fehlermeldung, wenn
du die beiden Zeilen auskommentierst? Sonst hast du ein anderes Problem.
Vergiss nicht, du programmierst in C und da versucht der Compiler, jedem
Mist noch irgendeinen Sinn abzugewinnen, bis er absolut nicht mehr
weiter kommt.
Rufus Τ. F. schrieb:> Das sind die Bitadressierungsarten des AVR-Assemblers, die mit> Bitnummern statt Bitwerten arbeiten. Und da die Register- und> Bitdefinitionen nicht doppelt vorliegen sollen,
Das ist aber wirklich geizige Begründung.
Bei Kinetis zum Beispiel sieht jedes einzelne Bit so aus:
1
#define UART_C2_TIE_MASK 0x80u
2
#define UART_C2_TIE_SHIFT 7
Das haben die durchgängig durchgezogen, die Header sind ja auch nicht
mühsam von Hand geschrieben sondern maschinell aus irgendwelchen
Tabellen erzeugt. Anhand der mit äußerster Konsequenz durchgezogenen
Namenskonvention kann man dann sofort erkennen OHNE in irgendwelchen
Headern nachzuschlagen daß es such um ein Bit namens TIE im Register C2
eines UART handelt welches unter dem exakt selben Namen in der Doku zu
finden ist.
Und alles was mehr als ein Bit breit ist bekommt sogar noch ein drittes
Makro mit dem man eine Zahl dorthin shiften und maskieren kann.
Und ich definiere mir dann manchmal sogar zusätzlich noch spezielle
Bitkombinationen mit besonderen Bedeutungen (zum Beispiel Namen von
Taktquellen oder Einträge in Muxtabellen) als benannte Konstanten.
z.B:
Bernd K. schrieb:> Das ist aber wirklich geizige Begründung.
Dafür kann ich nichts, das ist eine Entscheidung der Firma Atmel
gewesen.
Man hätte Dein Beispiel auch so formulieren können, um es noch einen
Hauch weniger fehlerträchtig zu bekomen:
1
#define UART_C2_TIE_SHIFT 7
2
#define UART_C2_TIE_MASK (1 << UART_C2_TIE_SHIFT)
Dann nämlich wird der relevante Wert nur einmal aufgeführt.
Aber, wie schon gesagt, das ist eines der Dinge, die man hinnehmen muss
und sollte, wenn man mit einer bestimmten µC-Architektur arbeitet.
Peterle schrieb:> expected expression before '=' token> expected expression before ')' token
... es scheint so, dass der "wirkliche" Fehler im Code davor sitzt und
du irgendwo eine Klammer oder einen Strichpunkt vergessen hast.
Poste mal den gesamten Code
Peterle schrieb:> #define USISIF> #define USISR> #define USIOIF> #define USIPF> #define USIDC> #define USICR> #define USIWM1> #define USICS1> #define USIWM0> #define USIDR
??????? was ist das ? Die Namen der Bits im Register brauchen schon die
Bitpositionen dahinter.
Woher soll der Compiler wissen, welches Bit bspw. USISIF einnimmt ?
@ Peterle
Ich rate Dir dringendst, erst einmal ein C-Buch zu lesen.
1. Du erkennst im Embedded-Bereich häufig angewendete Operatoren '|' und
"<<" nicht. Das gilt für den wohl häufigsten Operator '=' wohl auch.
2. Was Du für Variablen hältst, sind keine.
3. Was Du für Programmtext hältst ist in Wirklichkeit Textersatz.
4. Du schätzt die Bedeutung von Fehler- und Warnmeldungen falsch ein;
das allerdings lernt man aus Erfahrung und nicht aus einem Buch.
Peterle schrieb:> Sind wohl wieder "die kleinen Unterschiede.
Nein. Der Code ist so, wie er ist, schlichtweg unvollständig. Die
"leeren #defines" sind das Problem.
Hat dieser "Stefan" irgendwas zu dem Code geschrieben? Wo genau hast Du
den Code her?
Peterle schrieb:> #define USISIF> #define USISR> #define USIOIF> #define USIPF> #define USIDC> #define USICR> #define USIWM1> #define USICS1> #define USIWM0> #define USIDR
Das ergibt keinen Sinn. #define macht eine Textersetzung.
Das heißt, der Präprozessor macht aus dem da:
> // Clear i2c status flags and wait for start condition> USISR = (1<<USISIF) | (1<<USIOIF) | (1<<USIPF) | (1<<USIDC);
Das hier:
1
=(1<<)|(1<<)|(1<<)|(1<<);
Kein Wunder, dass der Compiler damit nichts anzufangen weiß.
Die Variante hat den Vorteil, im Klartext anzugeben, was gemacht wird
und gleichzeitig den Namen der Flags angibt, um z.B. im Ref Manual
die Erklärung schnell zu finden bzw. den Compiler dazu auffordert,
Fehlermeldungen zu schmeißen, wenn aus irgend einem Grund die #defines
weg sind.
Über den Sinn von "Outputflag NICHT einschalten" kann man natürlich
streiten.
Diskutieren könnte man jetzt noch, Kommentare auf Deutsch oder doch
besser auf Englisch ;-)
Peterle schrieb:> von Stefan Frings und soll ein Slave Programm für den ATty 2313 sein um> 10 Servos anzusteuern über den I2C Bus
Da hast du was zerändert. Die Defines sind im Original nicht drin.
STK500-Besitzer schrieb:> Die Defines sind im Original nicht drin.
Die sind ja auch quatsch so. So würden die nur zum testen was bringen.
Die Richtigen müssen in der jeweiligen IO.H stehen.
#define BLA
#ifndef BLA
#error BLA NOT DEFINED!
#endif
Im Code von Stefan Frings sind die includes nicht verunstaltet. Dort
sind sie, wie sie sein müssen mit < > und nicht mit " ".
Ich tippe darauf, dass es daran liegt.
Peterle schrieb:> im ORI stehn die definies nicht drin, stimmt. Dann werden die ganzen> USI.. als Fehler angezeigt
Argl! Und da hast du dir gedacht, schreiben wir mal irgendwas hin, und
nachdem es dann nicht ging, behauptest du, das sei der Code, den du
bekommen hast…
Was hast du denn noch alles geändert? Wie compilierst du es?
EloGuy schrieb:> Die sind ja auch quatsch so. So würden die nur zum testen was bringen.
DAs war keine allgemeine Feststellung, sondern ein Hinweis fürs Peterle.
Ich bin mir sehr sicher, dass die Bitpositionen und vor allem die
absolute Adressen der Register USISR, USICR und USIDR in avr/io.h
angegeben sind.
Irgendwo müßte von daher in der Compilerausgabe eine Warnung stehen,
dass du bestehende defines umdefinierst.
Versuche mal die von dir gezeigten defines aus dem Quelltext zu löschen,
ansonsten (lt. Datenblatt):
Peterle schrieb:> im ORI stehn die definies nicht drin, stimmt. Dann werden die ganzen> USI.. als Fehler angezeigt
Na, dann ist die "Idee", einfach leere #defines in den Code
reinzuknallen, jetzt nicht gerade die beste gewesen.
Das sind offensichtlich Namen von Registern und Bits eines bestimmten
µC.
Die werden wohl nicht definiert sein, weil Du beim Compileraufruf nicht
angibst, welchen µC Du verwendest. Der Code von Stefan ist für folgende
beide Varianten vorhanden: tiny2313 und tiny26.
Welchen davon Du verwendest, musst Du Deinem Compiler schon auch
mitteilen.
Im Codearchiv von Stefan sind auch makefiles enthalten -- in denen steht
das auch korrekt drin.
Könnte es vielleicht sein, daß Du diese makefiles nicht verwendet
hast?
Rolf M. schrieb:> sagt ja quasi, dass in Bit 5 bitte eine 0 nicht reingeschrieben werden> soll. Das kann man deutlich besser ausdrücken, indem man die Zeile auch> nicht hinschreibt.
Ein Code muss sich am besten selber dokumentieren. Wenn es Dir hilft,
darfst Du selbstverständlich auch 0 << 5 schreiben. Das stört den
Compiler nicht und auch das Programm wird dadurch nicht größer.
Peterle schrieb:> im ORI stehn die definies nicht drin, stimmt. Dann werden die ganzen> USI.. als Fehler angezeigt
natürlich stehen die nicht drin, weil die in io.h drin stehen. Wenn dein
Compiler die USI-Namen als nicht definiert anmeckert, dann
höchstwahrscheinlich deshalb, weil du versuchst den Code für einen
Controller OHNE USI Hardware zu übersetzen...
... um genau zu sein stehen sie in iotn2313.h drin, die Datei wird
inkludiert von io.h !
io.h wählt je nachdem, für welchen Controller das Programm übersetzt
werden soll, die entsprechende I/O Datei aus.
Ralph S. schrieb:> Irgendwo müßte von daher in der Compilerausgabe eine Warnung stehen,> dass du bestehende defines umdefinierst.
Nein, das bricht mit Fehler ab, wenn schon was definiert ist.
Keine Hacks mit Datenblatt-Raussuchen, sondern die includes so machen
wie im Original! Er hat da fleissig rumgepfuscht wie man oben sieht.
Brummbär schrieb:> Rolf M. schrieb:>> sagt ja quasi, dass in Bit 5 bitte eine 0 nicht reingeschrieben werden>> soll. Das kann man deutlich besser ausdrücken, indem man die Zeile auch>> nicht hinschreibt.>> Ein Code muss sich am besten selber dokumentieren. Wenn es Dir hilft,> darfst Du selbstverständlich auch 0 << 5 schreiben.
Ich finde nicht, dass es hilft. Ganz im Gegenteil, wie ich ja auch
geschrieben habe.
> Das stört den Compiler nicht und auch das Programm wird dadurch nicht> größer.
Richtig, wie ich ebenfalls geschrieben habe.
ich verwende den Attiny 2313 wie angegeben.
Ralph S. schrieb:> #define USISIF 7> #define USISR _SFR_IO8(0x00e)> #define USIOIF 6> #define USIPF 5> #define USIDC 4> #define USICR _SFR_IO8(0x00d)> #define USIWM1 5> #define USICS1 3> #define USIWM0 4> #define USIDR _SFR_IO8(0x00f)
damit bekomme ich keiner Fehlermeldung mehr.
Ist es sehr dumm zu fragen wie ich die makefile verwende, da ich bisher
ohne gearbeitet habe. Wenn die Angaben in der io stehen, wie finde ich
die?
Peterle schrieb:> damit bekomme ich keiner Fehlermeldung mehr.
Das ist definitiv falsch so. Du musst die includes richtig machen.
zu Makefile:
Einfach in der Konsole im Programmorder make eingeben. avr-toolchain
muss im systempfad sein.
EloGuy schrieb:> zu Makefile:> Einfach in der Konsole im Programmorder make eingeben. avr-toolchain> muss im systempfad sein.
Ja.
Hier ist das "originale" Projekt, das Peter verunstaltet hat:
http://stefanfrings.de/servocontroller/index.html
Der Code lässt sich einwandfrei compilieren.
Ich hatte darum gebeten, einen Screenshot vom ganzen Bildschirm und der
Fehlermeldung zu bekommen. Daran hätten wir erkennen können, welche
Software Peter verwendet. Wir hätten ihm auch helfen können, diese
Software korrekt zu konfigurieren.
Aber wer nicht will, der hat schon.
EloGuy schrieb:> Peterle schrieb:>> damit bekomme ich keiner Fehlermeldung mehr.>> Das ist definitiv falsch so. Du musst die includes richtig machen.
Die sind wahrscheinlich nicht mal der Auslöser, sondern die fehlende
Angabe des µCs, für den übersetzt werden soll. Das Makefile würde sich
drum kümmern, dass das korrekt angegeben ist.
Peterle schrieb:> Wenn die Angaben in der io stehen, wie finde ich die?
DU brauchst die nicht zu finden. Wenn deine Entwicklungsumgebung richtig
eingerichtet ist, findet der GCC die selbst.
Alles was in "< >" steht, sind Standard Header Dateien, um die du dich
nicht kümmern dürfen musst, also
1
#include <stdio.h>
2
#include <stdint.h>
3
#include <avr/io.h>
4
#include <avr/interrupt.h>
5
#include <util/twi.h>
Und wenn du die angucken willst, gibst du den Filenamen in die Suchmaske
deinem Dateimanager ein.
Ralph S. schrieb im Beitrag #5634014 diverse defines
Peterle schrieb:> damit bekomme ich keiner Fehlermeldung mehr.
Das ist keine Lösung, sondern ein hässlicher Balkon, der nur weitere
Folgefehler provoziert. Die Definitionen aller Register und Bits sind
bereits in der Toolchain enthalten. Wenn der C Compiler die zum Teil
nicht kennt, dann hast du den Compiler mit der falschen MCU Angabe
aufgerufen. Wenn du eine IDE verwendest, dann hast du es eben dort
falsch konfiguriert.
Mit anständigen Screenshots könnten wir weiter helfen. Diese
Geheimniskrämerei nervt mich. Ich habe auch schon 5 Emails nicht
hilfreich beantworten müssen, weil Peter nicht mit den nötigen Infos
rausrückt.
Stefanus F. schrieb:> Das ist keine Lösung, sondern ein hässlicher Balkon, der nur weitere> Folgefehler provoziert. Die Definitionen aller Register und Bits sind> bereits in der Toolchain enthalten. Wenn der C Compiler die zum Teil> nicht kennt, dann hast du den Compiler mit der falschen MCU Angabe> aufgerufen. Wenn du eine IDE verwendest, dann hast du es eben dort> falsch konfiguriert.>> Mit anständigen Screenshots könnten wir weiter helfen. Diese> Geheimniskrämerei nervt mich. Ich habe auch schon 5 Emails nicht> hilfreich beantworten müssen, weil Peter nicht mit den nötigen Infos> rausrückt.
Absolut alles richtig was ihr schreibt. Mit Sicherheit ist die Toolchain
nicht korrekt eingerichtet (und der MCU nicht angegeben). Es war von mir
an den TO nicht gedacht gewesen, dass er einen "Hack" vornimmt, denn er
weiß höchstwahrscheinlich nicht, was er tut (schließlich ist die io.h
genau für diesen Zweck da)
Stefanus F. schrieb:> Hier ist das "originale" Projekt, das Peter verunstaltet hat:> http://stefanfrings.de/servocontroller/index.html
Grübel, im originalen Projekt sind die Hexfiles doch auch enthalten!! An
den TO: warum flasht du nicht einfach das Hexfile und alles ist grün?
Du hast "erkennbare Mängel" im Umgang mit dem Compiler / der Toolchain
und auch Defizite im Umgang mit C. Von daher glaube ich nicht, dass du
in der Lage bist, das bestehende Projekt lauffähig zu modifizieren.
An alle...
Asche auf mein Haupt. Habe den falschen Prozessor angegeben.
Habe noch mal von vorn angefangen und es geht wie es soll
Bitte nicht gleich hauen, der Fehler lag bei meiner Dummheit oder
Blindheit
Bitte um Entschuldigung an alle die mir geholfen haben. Danke !!!!!!!!
Hi,
Peterle schrieb:> In einem Programm von Stefan Frings wird dieser Code verwendet:USISR => (1<<USISIF) | (1<<USIOIF) | (1<<USIPF) | (1<<USIDC);> USICR = (1<<USIWM1) | (1<<USICS1);
Das Datenblatt zum ATtiny2313/4313 finde ich auf die Schnelle hier:
http://www.mouser.com/ds/2/36/doc8246-71602.pdf
Ab Seite 160 etwa.
Ist aber Master nicht Slave!
Bei "Slave" würde das etwa so aussehen (mit Kommentar).
1
ldi temp, 0xF8 ; Im USI-Statusregister IR-Flags resetten, Counter auf 8
2
out USISR,temp ; (1<<USISIF)|(1<<USIOIF)|(1<<USIPF)|(1<<USIDC)|(1<<USICNT3)....
und nochmal kurz zu dem < > / " " Problem, welches mit den includes
entsteht.
Wenn du "io.h" angibst, dann sucht er zuerst im Projektverzeichnis. Wenn
dort eine io.h zu finden ist, dann bekommst du die vom compiler nicht,
die du ja wahrscheinlich erwartest.
Deshalb immer < > für die includes vom "system" und die
Anführungsstriche für eigene im Projektordner.
Thread beobachten
Seitenaufteilung abschalten