Hi,
hab hier ne Routine auf nem ATMega 1284P die nen Drehgeber abfragt.
Funktioniert gut. Nu möchte ich aber den Wert au 0..100 eingrenzen,
dabei fiel mir auf, daß eins und eins nicht immer zwei ist...
Liegt's an den Compiler-Einstellungen?
int8_t encode_read2( void ) // read two step encoders
{
int8_t val;
cli();
val = enc_delta;
enc_delta = val & 1;
sei();
return val >> 1; // funktioniert
// stattdessen einzelne Befehle:
val >> 1; // bewirkt permanentes
return val; // erhöhen des Zählers val
}
1. Was ist die Ursache?
2. Wie kann ich den Code umschreiben damit es funktioniert?
Joachim ... schrieb: > val >> 1; // bewirkt permanentes Das sollte aber ne Warung geben (nutzloser Code). Peter
Gast
#2727588
Ach Peter, das ist ja eine der vielen Krücken in C, auf die so manche C-Programmierer so unglaublich stolz sind. Beispiele wie if(result=MyFunc()) oder noch schlimmer if(result=MyFuncPtr) gibt's zuhauf - und mich wundert es nicht, daß der Compiler da den Mund hält. Immerhin ist dieser Murks formal was Erlaubtes. Tja, das haben die Leute nun von der großen Freiheit, die sie mit C schon immer haben wollten: Die Freiheit, beliebigen Murks zu verzapfen und sich dann totzusuchen. Der Debugger ist nach wie vor das wichtigste Tool des C-Programmierers, weil er einem zeigt, was für eine S.. tatsächlich - frei nach Kohl - hinten raus gekommen ist... W.S.
Gast
#2727589
Joachim ... schrieb: > 1. Was ist die Ursache? Das ist so ungefähr, wie
1 | |
2 | |
3 | |
Vielleicht fällt der Groschen so eher :-)
Gast
#2727592
W.S. schrieb: > was für eine S.. tatsächlich - frei nach Kohl - > hinten raus gekommen ist... Ja, und es entlarvt Leute. Denn zum Beispiel sieht man jetzt, welche S. -- frei nach Kohl -- in deinem Beitrag herausgekommen ist. Er enthält nämlich effektiv keine sachdienliche Information zum Thema, sondern nur Getrolle. Der Compiler meckert im Übrigen sehr wohl. Vorausgesetzt, man sagt ihm, dass er meckern soll. Wurde aber schon etliche Male erklärt. Denkbare Optionen wären etwa -Wall und -Wextra.
W.S. schrieb: > Der Debugger ist nach wie vor das wichtigste Tool des C-Programmierers, Nö. Es reicht völlig, die Warnungen einzuschalten und zu lesen. Ich habe übrigends beim AVR noch nie den Debugger benutzt. Peter
Wobei im Forum schon öfter Leute aufgeschlagen sind, die irgendwann einräumten, allerlei Warnungen des Compilers ignoriert zu haben. Ein Allheilmittel ist das also nicht. Da muss man dann schon mit -Werror ran.
W.S. schrieb: > Ach Peter, das ist ja eine der vielen Krücken in C, auf die so manche > C-Programmierer so unglaublich stolz sind. Konkret ist dieser 'Murks' keine Krücke. Er ist eine logische Konsequenz aus dem Sprachaufbau, aber nichts worauf jemand stolz wäre. > Beispiele wie if(result=MyFunc()) oder noch schlimmer > if(result=MyFuncPtr) gibt's zuhauf eigentlich .... nicht. Klar macht jeder bei seinen ersten Schritten in einer Programmiersprache dumme Fehler. Aber die macht er in jeder anderen Programmiersprache auch. Dieses konkrete Fehlerbild macht man 3 oder 4 mal in seinen Lehrjahren aber dann nie wieder. Ich kann mich gar nicht mehr erinnern, wann ich diesen Fehler das letzte mal gemacht habe, und ich schreibe pro Jahr sicherlich mehr als ein paar Tausend Lines of Code. Dieser Fehler ist mir mit Sicherheit in den letzten 20 Jahren kein einziges mal passiert. > Der Debugger ist nach wie vor das wichtigste Tool des C-Programmierers, Das wichtigste Tool eines C-Programmierers, was die Sprachdefinition angeht, ist meiner Meinung nach immer noch ordentliche Literatur, die dann aber auch gelesen und durchgearbeitet werden muss. Nur so lernt man den Sprachaufbau kennen und versteht, wie die Einzelteile der Sprache ineinandergreifen und warum bestimmte Dinge so sind, wie sie sind. Verfügt man nur über Halbwissen, passen die Puzzleteile natürlich nie ineinander und das SPrachkonzept 'C' erschliesst sich einem nicht.
Peter Dannegger schrieb: > Ich habe übrigends beim AVR noch nie den Debugger benutzt. Da kann ich nu beipflichten. Ich bin schon viele Jahre dabei und habe auch schon mal einen einfachen TCP/IP Stack geschrieben, der zeitlich quasi nur aus debuggen bestand ;-). Aber den eingebauten Debugger habe ich noch nie benutzt. Bei PC-Programmen geht das, weil keine (oder nicht viele) Signale in Echtzeit aktualisiert oder ausgelesen werden müssen (z.B. LED-Matrix). Bei AVRs ist man mit "selsbtgebauten" Debug-Schnittstellen ala RS232 besser dran.
Simon K. schrieb: > Bei AVRs ist man mit "selsbtgebauten" Debug-Schnittstellen ala RS232 > besser dran. Wenn man das ganze dann noch mit einem schönen Makro macht ist das später auch recht schnell wieder 'entsorgt', schön zu sehen bei Ulrich Radigs Webserver.
Sven P. schrieb: > Der Compiler meckert im Übrigen sehr wohl. Vorausgesetzt, man sagt ihm, > dass er meckern soll. Ich musste schon in Projekten mit Entwicklern zusammen arbeiten, die auf den Hinweis, sie sollten all die Warnungen beseitigen, die Compiler-Einstellungen im Makefile anpassten. Kaum ertappt, verlagerten sie die Unterdrückung der Warnungen in #pragma-Anweisungen. Eine Idi..., ähh früherer Kollege meinte, dass der Code korrekt kompiliere, wenn man die Produktion zweimal starte. Er war leider zu dumm, um zu verstehen, dass das Make-System so schlau ist, (auch mit Warnungen) kompilierte Quelltexte nicht erneut zu verarbeiten. Besonders übel war daran, dass beim Kompilieren des gesamten Projektes stets mehr als tausend Warnungen auftraten, von denen mehr als 990 aus seinen Dateien stammten. Dadurch hat man dummerweise sehr schnell wirklich wichtige Warnungen übersehen. Wir versuchten, entsprechenden Druck auf ihn auszuüben, besseren Code zu schreiben. Leider ging das nach hinten los. Wenn er eine Warnung bekam wegen eines fehlenden Prototypen oder fehlerhafter Parameter, schrieb er eben an Ort und Stelle einen für seinen Zweck passenden Prototyp hin. Und als das Unternehmen Stellen abbauen musste, konnte er überhaupt nicht verstehen, warum ihm als allerersten gekündigt wurde. Hmmm, warum wohl?
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.