Hallo, habe folgendes Problem: ich benutze einen PIC 18F25k20 und den dazugehörigen C18 Compiler. Jetzt wollte ich versuchen das Carry Bit auszulesen und habe dazu das Datenblatt durchsucht. Da Stehen im Instruction Set auch einige nützliche Dinge diesbezüglich aber keiner der Befehle funktioniert bei mir! Als Fehler sagt er, dass das Befehlswort nicht definiert sei... Was muss ich denn einbinden um diese Befehle nutzen zu können? Ansonsten eben mein aktuelles Problem: Wie lese ich das Carry Bit aus.... Danke vorweg
> Wie lese ich das Carry Bit aus.... Welche Programmiersprache? > Als Fehler sagt er... Wer sagt das? Wenn du mit C programmierst, dann darf man deine Frage als Witz auffassen, oder? :-/ Denn wenn das ein C-Programm ist, kannst du das Carry-Flag z.B. mit
1 | if (a>b) { ... } |
auswerten. Dann wird a-b gerechnet, und wenn ein Unterlauf aufgetreten ist (also das Carry-Flag gesetzt wird), die Befehlsfolge {...} ausgeführt. Ergo: in C interessiert dich das Carry-Flag an sich gar nicht mehr, das macht alles der Compiler für dich.
erstmal danke für die schnelle Antwort Aber auch wenn es sich wirklich um C handelt ist die Frage kein Witz! Denn ich habe das Problem, dass ich eine char Variable bitweise durchlaufen muss um sie in 8 Bit lange Blöcke zerlegen zu können. Wollte das durch Schiften und anschließendes Auslesen des Carry bits realisieren. Habe etwas ähnliches schonmal bei einem Infinion c167 gemacht und da ist es auch in C kein Problem das Carry bit auszulesen....
Hat dein C-compiler einen Inlineassembler dann kannst du aus asm mnemonik zurückgreifen. Sonst musst du die Funktion in asm schreiben und vom c-compiler einbinden lassen.
@ Christian K. (mick-roc) >Denn ich habe das Problem, dass ich eine char Variable bitweise >durchlaufen muss um sie in 8 Bit lange Blöcke zerlegen zu können. Aha, Fuzzy Logik oder was? >Habe etwas ähnliches schonmal bei einem Infinion c167 gemacht und da ist >es auch in C kein Problem das Carry bit auszulesen.... Nicht so viel kiffen, das schlägt auf's Gemüt und den ohnehin nur knapp zweistelligen IQ . . . .
Irgend welche der Arithmetik-Flags aus dem Statusregister in C auszulesen ist zwar möglich, aber ziemlich sinnlos, denn schon mit geänderten Optimierungseinstellungen, oder der nächsten Compilerversion muß der Code nicht mehr funktionieren. Der Zustand der Flags gehört zum Innenleben der abstrakten C-Maschine und ist aus C-Sicht undefiniert. Für besondere Zwecke stellen viele C-Compiler einen Inline-Assembler zur Verfügung, mit dem man sozusagen alle Sauereien machen kann. Aber man sollte im eigenen Interesse damit äußerst sparsam umgehen, wenn man nicht im unpassenden Moment später böse Überraschungen erleben will...
Einzelne Bits eines Bytes/Worts fragt man in C z.B. so ab:
1 | if (byte&(1<<position)!=0) {...} |
Zum Verständnis wie der Compiler die Klammern von innen her aufdröseln:
1 | (1<<position) |
erzeugt eine Maske, bei der eine 00000001 um "position" Stellen nach links verschoben wird. Mit position==3 ergibt sich also 00001000. & ist der binäre UND-Operator. In
1 | byte&(1<<position) |
wird also byte mit der vorher erzeugten Maske UND-verknüpft. Und wenn dann ganz zum Schluss das Ganze ungleich Null ist
1 | (byte&(1<<position)!=0) |
dann wird die Klammer ausgeführt. Fertig, ganz ohne Carry. Aber mein Tipp: Kauf dir das Standardwerk von K&R "Programmieren in C" und lies dir das in Ruhe durch. C ist keine Sprache, in der überhaupt ein Carry-Flag definiert ist (weil das ja schon wieder recht Prozessorabhängig ist). Wozu also eines einsetzen? EDIT: > dass ich eine char Variable bitweise > durchlaufen muss um sie in 8 Bit lange Blöcke zerlegen zu können. char-Variablen sind beim PIC 8 Bit lang, wozu also noch zerlegen?
Ok, an lkmiller, uhu und winne ein Danke, ich denke es ist durgekommen, dass ich noch kein Profi bin.... aber solche Kommentare wie von falk verbitte ich mir! Kann ja wohl nicht wahr sein, dass man hier als Neuling gleich als dumm bezeichnet wird nur weil man IN EINEM FORUM eine Frage stellt, egal wie unqualifiziert sie sein mag!!! Das Buch werd ich mir vermutlich mal anschaun, scheine wirklich Lücken zu haben.... Damit kann geschlossen werden.
Christian K. wrote: > Das Buch werd ich mir vermutlich mal anschaun, scheine wirklich Lücken > zu haben.... Es ist das Standardwerk über C - das sollte jeder C-Programmierer gründlich durcharbeiten. Über Falk mußt du dich nicht aufregen; es reicht, von ihm zu lernen - der ist ein echter Elektronik-Experte und kein Diplomat.
> Fertig, ganz ohne Carry. Dürfte aber zu deutlich größerem und länger dauerndem Code führen. > C ist keine Sprache, in der überhaupt ein Carry-Flag > definiert ist (weil das ja schon wieder recht Prozessorabhängig ist). Naja, ich wüßte keinen, der keins hat. > Wozu also eines einsetzen? Weil man mit dem Rotieren durch's Carry-Flag deutlich effizienteren Code produzieren kann. Wenn man das braucht, muß man's aber eben in Assembler machen.
>> Fertig, ganz ohne Carry. > Dürfte aber zu deutlich größerem und länger dauerndem Code führen. Ja, wahrscheinlich. Aber C ist keine Sprache, die maximale Effizienz für sich beansprucht (dafür gibts ja Assembler). Sondern mit einem generisch geschriebenen C-Programm erreiche ich bestmögliche Portierbarkeit des Codes auf unterschiedliche Zielarchitekturen. > Wenn man das braucht, muß man's aber eben in Assembler machen. Wobei es heute in der Industrie billiger ist, einen schnelleren Controller zu nehmen, als einen schmächtigen von Hand so lange hinzutrimmen, dass er es gerade noch so packt. Nur, um dann mit der Markteinführung 6 Monate hinter der Konkurrenz zu sein :-(
Naja, für die drei Zeilen Assembler bracht man keine 6 Monate. Und bei sehr hohen Stückzahlen wird jeder halbe Cent, den man pro hergestelltem Gerät sparen kann, auch gespart.
> Naja, für die drei Zeilen Assembler bracht man keine 6 Monate. Auch richtig. Aber für solche Anwendungen sind recht gute Compilerkentnisse nötig, damit z.B. durch einen Interrupt nicht alles zerhagelt wird. Das sind dann die Programme, die eigentlich immer laufen, aber einmal am Tag Probleme machen :-o Ich habe die Erfahrung gemacht, dass, wenn solche Tricks nötig sind, irgendwoanders im Systemdesign der Hund begraben ist. Und der wacht garantiert früher oder später als Zombie wieder auf :-/ > Und bei sehr hohen Stückzahlen wird jeder halbe Cent, den man pro > hergestelltem Gerät sparen kann, auch gespart. Ich lass das Sparen dann den Einkauf machen ;-)
müsst ihr eigentlich bei jedem thema was halbwegs in die richtung geht aufs neue mit der "C vs Asm" Diskussion anfangen? Ganz egal was richtig ist, entweder man hat mittlerweile so viele kommentare dazu das man weiß wann man was benutzt oder man wird es nie verstehen. Aber alle 3 Tage der gleiche Kram ist doch irgendwie überflüssig. Danke, Gute Nacht
Bitte 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.