Forum: Mikrocontroller und Digitale Elektronik Code wozu dient er?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Peterle (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
In einem Programm von Stefan Frings wird dieser Code verwendet:
1
USISR = (1<<USISIF) | (1<<USIOIF) | (1<<USIPF) | (1<<USIDC);
2
    USICR = (1<<USIWM1) | (1<<USICS1);
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

von M. K. (sylaina)


Bewertung
0 lesenswert
nicht lesenswert
Welchen Fehler bekommst du denn angezeigt?

von J. Zimmermann (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wie lautet der Fehlertext?
mfg
Achim

von Wolfgang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Peterle schrieb:
> Kann aber leider nicht rausbekommen was damit gemacht.

Vielleicht guckst du im Datenblatt vom falschen Prozessor nach.

von 122 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Rolf M. (rmagnus)


Bewertung
1 lesenswert
nicht lesenswert
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?

von W.S. (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von W.S. (Gast)


Bewertung
-10 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
1 lesenswert
nicht lesenswert
W.S. schrieb:
> USISR = (1 << 7) |  // Interruptflag setzen
>         (0 << 5) |  // Outputflag NICHT einschalten
>         (1 << 1) |  // Parität gerade
>         (1 << 0);   // Takt einschalten

warum so?

entweder ich setze vorher alles auf 0
USISR = 0;

und schalte dann die benötigten Bits ein

USISR = (1 << 7) |  // Interruptflag setzen
        (1 << 1) |  // Parität gerade
        (1 << 0);   // Takt einschalten

oder ich lösche die gewünschten Bits danach

USISR &= ~(1 << 5)  // Outputflag ausschalten

ein | (0 << 5) // Outputflag NICHT einschalten schaltet kein Bit aus 
welches default ein war.

1 | 0 bleibt 1

: Bearbeitet durch User
von STK500-Besitzer (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Hugo E. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> ein | (0 << 5) // Outputflag NICHT einschalten schaltet kein Bit aus
> welches default ein war.

Muß es ja auch nicht...

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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!!

von Ralph S. (jjflash)


Bewertung
1 lesenswert
nicht lesenswert
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!

von Hugo E. (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Rolf M. (rmagnus)


Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Wolfgang (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von STK500-Besitzer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Es gibt viele
> Flags in der HW, wo es nicht nur um ein/aus geht, sondern andere
> bedeutungen dahinter stehen.

z.B.?

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Leute, ihr driftet zu sehr vom Thema ab. Helft dem TO!

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Peter D. (peda)


Bewertung
6 lesenswert
nicht lesenswert
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.

von Jim M. (turboj)


Bewertung
4 lesenswert
nicht lesenswert
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?

von Dieter F. (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Für welchen Mikrocontroller ist der Code geschrieben und welchen 
Mikrocontroller verwendest Du?

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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!

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
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.

von W.S. (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
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.

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Viele Wege führen nach Rom. Es gibt mehr als einen richtigen.

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
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.

von Leichtleser (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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!

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Peterle (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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:
1
USISR = (1<<USISIF) | (1<<USIOIF) | (1<<USIPF) | (1<<USIDC);
2
USICR = (1<<USIWM1) | (1<<USICS1);
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

von Wolfgang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Wolfgang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Peterle (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Dieter
ist für einen Atty 2313 geschrieben und verwende diesen auch. Die 
Belegung der Pins ist genau identisch zum ori.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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:
1
// vom Hersteller
2
3
#define DMAMUX_CHCFG_SOURCE_MASK                 0x3Fu
4
#define DMAMUX_CHCFG_SOURCE_SHIFT                0
5
#define DMAMUX_CHCFG_SOURCE(x)                   (((uint8_t)(((uint8_t)(x))<<DMAMUX_CHCFG_SOURCE_SHIFT))&DMAMUX_CHCFG_SOURCE_MASK)
6
7
// und dann noch zusätzlich
8
9
#define DMAMUX_CHCFG_SOURCE_DISABLED    DMAMUX_CHCFG_SOURCE(0)
10
#define DMAMUX_CHCFG_SOURCE_UART0_RX    DMAMUX_CHCFG_SOURCE(2)
11
#define DMAMUX_CHCFG_SOURCE_UART0_TX    DMAMUX_CHCFG_SOURCE(3)
12
#define DMAMUX_CHCFG_SOURCE_SPI0_RX     DMAMUX_CHCFG_SOURCE(16)
13
#define DMAMUX_CHCFG_SOURCE_SPI0_TX     DMAMUX_CHCFG_SOURCE(17)
14
// undsoweiter

von Peterle (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Konstanten definiert
1
#define USISIF  
2
#define USISR   
3
#define USIOIF  
4
#define USIPF   
5
#define USIDC   
6
#define USICR   
7
#define USIWM1  
8
#define USICS1  
9
#define USIWM0  
10
#define USIDR

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Ralph S. (jjflash)


Bewertung
0 lesenswert
nicht lesenswert
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

von Ralph S. (jjflash)


Bewertung
0 lesenswert
nicht lesenswert
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 ?

von Theor (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@ 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.

von Peterle (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Der gesamte Code:
1
#include "stdio.h"
2
#include "stdint.h"
3
#include "avr/io.h"
4
#include <avr/interrupt.h>
5
#include <util/twi.h>
6
#include <stdbool.h>
7
#include <avr/pgmspace.h>
8
#include "util/delay.h"
9
#include "stdlib.h"
10
11
#define USISIF  
12
#define USISR   
13
#define USIOIF  
14
#define USIPF   
15
#define USIDC   
16
#define USICR   
17
#define USIWM1  
18
#define USICS1  
19
#define USIWM0  
20
#define USIDR
21
22
#define ADR_b4 0
23
#define ADR_b5 0
24
#define ADR_b6 0
25
26
// PWM Values for the servos
27
volatile uint8_t servo[10];
28
29
// Activity Led timeout with initial blink of 400ms
30
volatile uint8_t ledTimeout=100; // 100*4ms
31
32
// Timer 0 Compare A Interrupt
33
ISR(TIMER0_COMPA_vect) 
34
  {
35
  // Sets servo 0-4 pins to low
36
  PORTD &= ~1;
37
  PORTD &= ~2;
38
  PORTA &= ~2;
39
  PORTA &= ~1;
40
  PORTD &= ~4;
41
  }
42
43
// Timer 0 Compare B Interrupt
44
ISR(TIMER0_COMPB_vect) 
45
  {
46
  // Sets servo 5-9 pins to low
47
  PORTD &= ~8;
48
  PORTD &= ~16;
49
  PORTD &= ~32;
50
  PORTD &= ~64;
51
  PORTB &= ~1;
52
  }
53
54
// Timer 0 Overflow Interrupt
55
ISR(TIMER0_OVF_vect) 
56
  {
57
  static uint8_t loop;
58
59
  // Set servo pins to high, round-robin, two pins per interrupt
60
  if (servo[loop] != 0) 
61
    {
62
    switch (loop) 
63
      {
64
      case 0: PORTD |= 1; break;
65
      case 1: PORTD |= 2; break;
66
      case 2: PORTA |= 2; break;
67
      case 3: PORTA |= 1; break;
68
      case 4: PORTD |= 4; break;
69
      }
70
    }
71
  if (servo[loop+5] != 0) 
72
    {
73
    switch (loop) 
74
      {
75
      case 0: PORTD |= 8;  break;
76
      case 1: PORTD |= 16; break;
77
      case 2: PORTD |= 32; break;
78
      case 3: PORTD |= 64; break;
79
      case 4: PORTB |= 1;  break;
80
      }
81
    }
82
83
  // Set timer compare values for the next (not the current) loop
84
  if (++loop>4) 
85
    {
86
    loop=0;
87
    }
88
  OCR0A=servo[loop];
89
  OCR0B=servo[loop+5];
90
91
  // Switch activity led off when it's timeout has expired
92
  if (ledTimeout!=0) 
93
    {
94
    ledTimeout--;
95
    if (ledTimeout==0) 
96
      {
97
      PORTB |= 64;
98
      }
99
    }
100
  }
101
102
103
int main() 
104
  {
105
  // Configure pin direction and pull-ups
106
  DDRA  = 1|2;
107
  DDRB  = 1|64;
108
  PORTB = 2|4|8|16;
109
  DDRD  = 1|2|4|8|16|32|64;
110
111
  // Timer 0: fast PWM, prescaler 64, IRQ on overflow, compare match A and compare match B.
112
  TCCR0A = (1<<WGM01) | (1<<WGM00);
113
  TCCR0B = (1<<CS01)  | (1<<CS00);
114
  TIMSK0  = (1<<TOIE0) | (1<<OCIE0A) | (1<<OCIE0B);
115
116
  // Enable interrupts
117
  sei();
118
119
  // Receive data from I2C in the main loop
120
  while (1) 
121
    {
122
    // Enable driving SCL
123
    DDRB |= 128;
124
    PORTB |= 128;
125
    // SDA=input
126
    DDRB &= ~32;
127
128
    // Clear i2c status flags and wait for start condition
129
    USISR = (1<<USISIF) | (1<<USIOIF) | (1<<USIPF) | (1<<USIDC);
130
    USICR = (1<<USIWM1) | (1<<USICS1);
131
    while (!(USISR & (1<<USISIF)));
132
    
133
   
134
    
135
    // Wait until end of start condition or begin of stop condition
136
    while ((PINB & 128) && !(PINB & 32));
137
138
    // Break when a stop condition has been received while waiting
139
    if (PINB & 32) 
140
      {
141
      break;
142
      }
143
    
144
    // Clear i2c status flags and prepare to receive the device address
145
    USISR = (1<<USISIF) | (1<<USIOIF) | (1<<USIPF) | (1<<USIDC);
146
    USICR = (1<<USIWM1) | (1<<USIWM0) | (1<<USICS1);
147
148
    // Wait for byte received or stop condition
149
    while (!(USISR & ((1<<USIOIF) | (1<<USIPF))));
150
151
    // If byte received
152
    if ((USISR & (1<<USIOIF))) 
153
      {
154
      // If the address is 0 or matches the configured address
155
      // All bits are shifted 1 to the left as required by the i2c protocol.
156
      uint8_t myAddress=(ADR_b6<<7) | (ADR_b5<<6) | (ADR_b4<<5) | (PINB & 30);
157
      if (USIDR==0 || (USIDR==myAddress)) 
158
        {
159
        // Switch activity LED for 80ms on
160
        PORTB &= ~64;
161
        ledTimeout=20; // 20*4ms
162
163
        // Sende ACK Bit
164
        USIDR=0;
165
        DDRB |= 32;
166
        USISR = (1<<USIOIF) | (1<<USIPF) | (1<<USIDC) | 14;
167
        while (!(USISR & (1<<USIOIF)));
168
        DDRB &= ~32;
169
170
        // Receive up to 10 bytes
171
        for (uint8_t channel=0; channel<10; channel++) 
172
          {
173
          // Clear i2c status flags and prepare to receive next byte
174
          USISR = (1<<USIOIF) | (1<<USIPF) | (1<<USIDC);
175
          USICR = (1<<USIWM1) | (1<<USIWM0) | (1<<USICS1);
176
177
          // Wait for byte received or stop condition
178
          while (!(USISR & ((1<<USIOIF) | (1<<USIPF))));
179
180
          // If byte received
181
          if ((USISR & (1<<USIOIF))) 
182
            {
183
            // copy to the servo value array
184
            servo[channel]=USIDR;
185
186
            //Sende ACK Bit
187
            USIDR=0;
188
            DDRB |= 32;
189
            USISR = (1<<USIOIF) | (1<<USIPF) | (1<<USIDC) | 14;
190
            while (!(USISR & (1<<USIOIF)));
191
            DDRB &= ~32;
192
            }
193
194
          // else if stop condition received, break the for loop
195
          else 
196
            {
197
            break;
198
            }
199
        }
200
      }
201
    }
202
  }
203
}
Der gesamte Code stammt von Stefan. Versuche ihn auf meiner Hardware zum 
laufen zu bekommen. Sind wohl wieder "die kleinen Unterschiede.

LG Pt

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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?

von Rolf M. (rmagnus)


Bewertung
1 lesenswert
nicht lesenswert
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ß.

von Peterle (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
von Stefan Frings und soll ein Slave Programm für den ATty 2313 sein um 
10 Servos anzusteuern über den I2C Bus

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hat er dir das per Mail geschickt, oder ist das hier irgendwo im Forum 
veröffentlicht worden?

von 2⁵ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nun, die m.M. nach beste Variante wäre doch:
1
USISR = (1<<USISIF) | // Interruptflag setzen
2
        (0<<USIOIF) | // Outputflag NICHT einschalten
3
        (1<<USIPF)  | // Parität gerade
4
        (1<<USIDC);   // Takt einschalten

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 ;-)

von Peterle (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wie kann ich das besser machen?

von EloGuy (Gast)


Bewertung
0 lesenswert
nicht lesenswert
#include <avr/io.h>

anstatt

"avr/io.h"

So sucht der compiler nur im globalen include verzeichnis und nicht im 
Projektverzeichnis.

von Peterle (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Es steht auf seiner Seite

von EloGuy (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Du hilfst einem aber auch nicht, dir zu helfen.

Link? Oder sollen das andere für dich neu eintüten und du klickst nur 
auf make?

von STK500-Besitzer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von EloGuy (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Peterle (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Peterle (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
im ORI stehn die definies nicht drin, stimmt. Dann werden die ganzen 
USI.. als Fehler angezeigt

von EloGuy (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
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?

von STK500-Besitzer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Ralph S. (jjflash)


Bewertung
0 lesenswert
nicht lesenswert
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):
1
 #define USISIF    7
2
 #define USISR    _SFR_IO8(0x00e)
3
 #define USIOIF    6
4
 #define USIPF    5
5
 #define USIDC    4
6
 #define USICR    _SFR_IO8(0x00d)
7
 #define USIWM1    5
8
 #define USICS1    3
9
 #define USIWM0    4
10
 #define USIDR    _SFR_IO8(0x00f)

von 2⁵ (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Der Code compiliert ohne Änderungen. Testen kann ich hier das Image 
nicht.
1
user@HPi7:~/src/ServoController/src$ cd tiny2313/
2
user@HPi7:~/src/ServoController/src/tiny2313$ ls
3
Makefile  rm.bat  ServoController.c
4
user@HPi7:~/src/ServoController/src/tiny2313$ make
5
avr-gcc -std=c99 -Wall -Os -mmcu=attiny2313 -DF_CPU=4000000    -c -o ServoController.o ServoController.c
6
avr-gcc -std=c99 -Wall -Os -mmcu=attiny2313 -DF_CPU=4000000  -Wl,-Map,ServoController_tiny2313.map -o ServoController_tiny2313.elf ServoController.o 
7
avr-objcopy -j .text -j .data -O ihex ServoController_tiny2313.elf ServoController_tiny2313.hex

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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?

von Brummbär (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Ralph S. (jjflash)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Ralph S. (jjflash)


Bewertung
0 lesenswert
nicht lesenswert
... 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.

von EloGuy (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Peterle (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von EloGuy (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Wolfgang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Ralph S. (jjflash)


Bewertung
0 lesenswert
nicht lesenswert
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)

von Ralph S. (jjflash)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Peterle (Gast)


Bewertung
3 lesenswert
nicht lesenswert
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 !!!!!!!!

von Karl B. (gustav)


Bewertung
0 lesenswert
nicht lesenswert
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)....
3
;...
4
sbi USICR, USITC    ; SCL L->H (USI clock toggle mode)

ganz nebenbei.

ciao
gustav

: Bearbeitet durch User
von Dieter F. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Peterle schrieb:
> Habe den falschen Prozessor angegeben.

Sag ich doch :-)

von Ralph S. (jjflash)


Bewertung
0 lesenswert
nicht lesenswert
Dieter F. schrieb:
> Sag ich doch :-)

... haben alle gesagt !

von Dieter F. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ralph S. schrieb:
> ... haben alle gesagt !

Ach - hast Du Dir die Beiträge mal durchgelesen?

von EloGuy (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.