Erneut Hallo an die Community, ich möchte das OCR1AH und OCR1AL beschreiben. Dabei habe ich im Datenblatt herausgelesen, dass ich das High-Byte zuerst beschreiben soll. Im gleichen Zusammenhang soll ich dafür das TEMP Register verwenden. Mir ist nicht ganz klar wie das in C gehen soll? Zudem habe ich im Register Summary auch kein Register TEMP gefunden. Wie soll die Zuweisung des Vergleichswertes genau geschehen. Ich hätte mir jetzt vorgestellt, dass das ungefähr folgendermaßen aussehen müsste ( 111110100000 soll im Dezimalsystem 4000 sein) TEMP = 1111 ; OCR1AH = TEMP; OCR1AL = 10100000; Ich bin mir aber alles andere als sicher. So wie ich das versehe, kann ich die ganze Zahl 4000 einfach nicht einfach ins OCR1A Register schreiben, weil der Controller 8-bit instruction set simulator hat bzw. ist. Alles auf einen Punkt gebracht: Wie soll die Zuweisung des Vergleichswertes in C genau geschehen. Wenn die Frage sehr schräg sein sollte, bitte ich um Nachsicht. Ich befasse mich erst seit kurzem mit der uC Programmierung. kind regards fragenkinsey
Julian Kinsey schrieb: > Mir ist nicht ganz klar wie das in C gehen soll? > ... > So wie ich das versehe, kann ich die ganze Zahl 4000 einfach nicht > einfach ins OCR1A Register schreiben Doch. Der Compiler kümmert sich darum.
Julian Kinsey schrieb: > Erneut Hallo an die Community, > > ich möchte das OCR1AH und OCR1AL beschreiben. Dabei habe ich im > Datenblatt herausgelesen, dass ich das High-Byte zuerst beschreiben > soll. Im gleichen Zusammenhang soll ich dafür das TEMP Register > verwenden. Mir ist nicht ganz klar wie das in C gehen soll? Das wird automatisch verwendet. Deshalb mußt du ja das High-Byte zuerst schreiben. Indem du das tust, wird der Wert im Temp-Register zwischengespeichert, und beim Schreiben des Low-Bytes wird der Wert aus dem Temp-Register zusammen mit dem des Low-Bytes übernommen. > So wie ich das versehe, kann ich die ganze Zahl 4000 einfach nicht > einfach ins OCR1A Register schreiben, weil der Controller 8-bit > instruction set simulator hat bzw. ist. Doch kannst du. Der Compiler kümmert sich dann automatisch drum, das richtig zu machen.
OCR1A will einen 16bit wert. 8bit in OCR1AH und 8bit in OCR1AL. 4000 als 16bit Wert entspricht binär ausgedrückt 0000111110100000. Das teilst Du in der Mitte, es bleiben 2 8bit Werte: 00001111 und 10100000. Der erste Wert (der höhere, also 00001111) kommt ins H-Register, der andere ins L-Register. Wenn Du Zahlen Binär rechnest, fängst Du mit der niedrigsten, also 1 rechts an. Das ist das LSB. Dann nach links 2 4 8 16... usw. Die letzte Stelle links ist dann das MSB, bei 8bit 128, bei 16bit 32768.
Habe ich euch richtig verstanden, dass ich einfach OCR1A = 4000; schreiben soll, selbst, wenn mein uC 8-bit instruction set simulator besitz? Folgendes trifft nämlich auf meinen uC zu. •AT90CAN*/ATmega*C*, AT90USB*/ATmega*U*, AT90PWM*, and ATtiny87/167 devices will never be supported by simulator models, for these devices the 8-bit instruction set simulator will have to be used. Ich dachte, dass zwingt mich dazu, dass OCR1A in OCR1AH und OCR1L aufzuspalten. Ist das etwa egal? Danke für die letzten Beiträge. kind regards fragenkinsey
Also zähle ich wie folgt: High Byte Bitstelle: 15 14 13 12 11 10 9 8 Binärfolge: 1 0 1 0 0 0 0 0 Low Byte Bitstelle: 7 6 5 4 3 2 1 0 Binärfolge: 0 0 0 0 1 1 1 1 Ist das so richtig?
Julian Kinsey schrieb: > Habe ich euch richtig verstanden, dass ich einfach > > OCR1A = 4000; > > schreiben soll, Ja. Ist dir das zu einfach? > selbst, wenn mein uC 8-bit > instruction set simulator besitz? Der Simulator hat damit nicht das geringste zu tun.
:
Bearbeitet durch User
> Ich dachte, dass zwingt mich dazu, dass OCR1A in OCR1AH und OCR1L aufzuspalten.
Nochmal:
Es gibt kein OCR1A.
Das du trotzdem
OCR1A = 4000;
schreiben kannst, ist ein Service des Compilers, der für dich die
Aufteilung in High-Byte und Low-Byte bzw. das Aufteilen nach OCR1AH und
OCR1AL macht.
Wozu hat man denn einen C-Compiler, wenn man sich dann erst recht wieder
um solche Kinkerlitzchen selbst kümmern muss, die ein Compiler
genausogut erledigen kann?
:
Bearbeitet durch User
Julian Kinsey schrieb: > Habe ich euch richtig verstanden, dass ich einfach > > OCR1A = 4000; > > schreiben soll, selbst, wenn mein uC 8-bit > instruction set simulator besitz? Ich weiß nicht, was du hier mit "simulator" meinst. Und es hat auch weniger damit zu tun, als mit dem Compiler. Falls du avr-gcc einsetzt, weiß der selber, daß er diesen Zugriff in zwei Hälften teilen muß. Ob andere Compiler das auch können, weiß ich nicht. > Folgendes trifft nämlich auf meinen uC zu. > > •AT90CAN*/ATmega*C*, AT90USB*/ATmega*U*, AT90PWM*, and ATtiny87/167 > devices will never be supported by simulator models, for these devices > the 8-bit instruction set simulator will have to be used. Wo steht das? Und wieso denkst du, daß der Simulator was damit zu tun hat?
Rolf Magnus schrieb: > Wo steht das? Und wieso denkst du, daß der Simulator was damit zu tun > hat? Help -> View Help -> Simulator -> Known issues in Simulator -> General issues Hier steht das. for these devices the 8-bit instruction set simulator will have to be used. Woanders habe ich singemäß die Bedeutung von 8-Bit instruction set gelesen. Das wird anhand des ADCW erklärt. Man soll den ADCW in ADCWH und ADCWL aufteilen. Deshalb dachte ich, dass ich das auch bei OCR1A machen sollte, da es sich hierbei bekanntlich um ein 16 Bit Register handelt. Ich sehe noch nach, ob ich die Quelle der letzten Aussage finde. Aber vermutlich und anscheinend habe ich da Sachen miteinadner verwechselt, weil ich kaum Ahnung habe.
:
Bearbeitet durch User
> Also zähle ich wie folgt: > > > High Byte > > Bitstelle: 15 14 13 12 11 10 9 8 > Binärfolge: 1 0 1 0 0 0 0 0 > > > Low Byte > > Bitstelle: 7 6 5 4 3 2 1 0 > Binärfolge: 0 0 0 0 1 1 1 1 > > Ist das so richtig? Nein, schau mal: Bitstelle 15 14 13 12 11 10 9 8 Weret 32768 16384 8192 4096 2048 1024 512 256 Bitstelle 7 6 5 4 3 2 1 0 Wert 128 64 32 16 8 4 2 1 Für 4000 also 2048+1024+512+256+128+32. Da überall eine 1 der Rest 0.
Ahhh...kapiert. Also so. Julian Kinsey schrieb: > High Byte > > Bitstelle: 15 14 13 12 11 10 9 8 > Binärfolge: 0 0 0 0 1 1 1 1 > > Low Byte > > Bitstelle: 7 6 5 4 3 2 1 0 > Binärfolge: 1 0 1 0 0 0 0 0 Besten Danke an Alle.
Julian Kinsey schrieb: > Ahhh...kapiert. > > Also so. > > Julian Kinsey schrieb: >> High Byte >> >> Bitstelle: 15 14 13 12 11 10 9 8 >> Binärfolge: 0 0 0 0 1 1 1 1 >> >> Low Byte >> >> Bitstelle: 7 6 5 4 3 2 1 0 >> Binärfolge: 1 0 1 0 0 0 0 0 > > > Besten Danke an Alle. Ja. Aber selbst dann, wenn du die zerlegung selbst machen willst, schreibst du das nicht binär. Sondern so
1 | OCR1AH = 4000 / 256; |
2 | OCR1AL = 4000 % 256; |
oder
1 | OCR1AH = 4000 >> 8; |
2 | OCR1AL = 4000; |
oder etwas ausführlicher
1 | OCR1AH = ( 4000 >> 8 ) & 0xFF; |
2 | OCR1AL = 4000 & 0xFF; |
aber auf keinen Fall schreibst du es in Form von Binärdarstellung. Erstens bringt es dir nichts. Zweitens liest es sich verdammt schlecht. Drittens ist es extrem fehleranfällig, derartig lange Würschte von 0-en und 1-en zu handhaben. Und viertens ist sowas ein Albtraum, wenn sich die Zahl mal ändern muss. Es gibt ein paar (wenige) Fälle, in denen Binärdarstellung sinnvoll ist. Aber meistens ist Binärschreibweise so ziemlich die ungeeignetste Schreibweise, die man sich vorstellen kann. Muss man ja auch nicht. Wenn du 4000 meinst, dann schreib auch 4000. Enweder indem du sie selber zerlegst, wie oben, oder indem du das den Compiler machen lässt
1 | OCR1A = 4000; |
und gut ists.
Julian Kinsey schrieb: > Rolf Magnus schrieb: >> Wo steht das? Und wieso denkst du, daß der Simulator was damit zu tun >> hat? > > Help -> View Help -> Simulator -> Known issues in Simulator -> General > issues > > Hier steht das. > > for these devices the 8-bit instruction set simulator will have to be > used. Da geht es darum, was der Simulator kann. Das hat überhaupt nichts damit zu tun, wie du die Register des Prozessors beschreiben mußt. > Woanders habe ich singemäß die Bedeutung von 8-Bit instruction set > gelesen. Da geht es dann um den echten Prozessor. > Das wird anhand des ADCW erklärt. Man soll den ADCW in ADCWH > und ADCWL aufteilen. Deshalb dachte ich, dass ich das auch bei OCR1A > machen sollte, da es sich hierbei bekanntlich um ein 16 Bit Register > handelt. Das ist prinzipell ja auch richtig. Für ADC und Timer hat der Prozesser 16-Bit-I/O-Register. Da AVR aber nur eine 8-Bit-Architektur ist, kann der Prozessor diese nicht am Stück schreiben oder lesen. Deshalb ist der Zugriff über zwei 8-Bit-Registerhälften gelöst. Der Compiler kann sich aber darum kümmern. Du schreibst in C einfach ADCW oder OCR1A hin, und der Compiler baut das um in die zwei Zugriffe auf die Registerhälften, die der Prozessor braucht.
Rolf Magnus schrieb: > Da geht es darum, was der Simulator kann. Das hat überhaupt nichts damit > zu tun, wie du die Register des Prozessors beschreiben mußt. > >> Woanders habe ich singemäß die Bedeutung von 8-Bit instruction set >> gelesen. > > Da geht es dann um den echten Prozessor. Das war mir bis jetzt nicht klar. Danke für deine Erklärung zum Thema. Danke für deine ausführliche Schreibweisen der drei Varianten. Karl Heinz schrieb: > OCR1A = 4000; > und gut ists. In diesem Sinnde beende ich den Thread. Einfach nur super wie ihr mir geholfen habt. Danke
Doch noch eine Frage hierzu: Rolf Magnus schrieb: > Der Compiler kann sich aber darum kümmern. Du schreibst in C einfach > ADCW oder OCR1A hin, und der Compiler baut das um in die zwei Zugriffe > auf die Registerhälften, die der Prozessor braucht. Gilt das für das Schreiben gleichermaßen wie fürs Schreiben?
Julian Kinsey schrieb: > Gilt das für das Schreiben gleichermaßen wie fürs Schreiben? Das auf alle Fälle. Es gilt aber auch für's Lesen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.