Hallo, ich verzweifel gerade. Ich suche einen in C geschriebenen code, mit dem ich die dauer (bis 3s) eines Tastendrucks ermitteln kann ohne dabei den ganzen uC zu Blockieren. Gibt es da nicht irgendeinen Zähler wie z.B. einen Prozesscouter, anhand dessen ich feststellen kann wieviele Takte von Flanke zu Flanke vergehn? Eine while-Schleife blockt ja den ganzen uC und bei jedem Programmdurchlauf einen Zähler um 1 zu erhöhen funktioniert ja auch nicht zuverlässig, da die dauer eines Programmdurchlaufs nicht definiert ist. Wie wird denn sowas normalerweise gelöst?
Guck mal im AVR-GCC-Tutorial unter "Timer" - das sollte dein Problem lösen...
Hans Wurst wrote: > Ich suche einen in C geschriebenen code, mit dem ich die dauer (bis 3s) > eines Tastendrucks ermitteln kann ohne dabei den ganzen uC zu > Blockieren. > Wie wird denn sowas normalerweise gelöst? Garnicht. Die Länge eines Tastendruckes interessiert normaler Weise nicht. Will man aber nur kurz/lang unterscheiden, gehts am einfachsten so: Beitrag "Universelle Tastenabfrage" Peter
Danke da hilft beides schon Arg weiter... mit dem Tutorial da hätte ich
drauf kommen können sorry.
Aber zur 2. Antwort.
Da hat schonmal jemand nach der Zeile
>TCNT0 = (u8)(s16)-(XTAL / 1024 * 10e-3 + 0.5); // preload for 10ms
gefragt.
aber die antwort ist mir nicht ganz klar.
und zwar genauer (u8) schneidet das High-byte ab.
Grundsätzliche bedeutung ist klar, aber ist jetz High-byte = die ersten
8 oder die 2. 8 Byte von den 16 Bytes?
Und was hat das Minus-Zeichen direkt dahinter zu bedeuten?
Und nochmas: Wo gibts infos über (s16) (u8) (u16)?? (s8)??
Meine Suchresultate landen da immer bei Audi(s8) oder sowas ähnlichem.
Oder auf seiten die mehr Fragen als antworten bereit haben.
Ja und Danke, dass ihr einem so unwissendem Anfänger wie mir noch helft.
Danke.
Hans Wurst wrote:
> und zwar genauer (u8) schneidet das High-byte ab.
da muß man schauen, wie "u8" definiert ist und findet:1 | |
2 | |
D.h. es wird zu "unsigned char" und das ist in der Regel 8Bit. Es werden also nur die unteren 8Bit verwendet, was bei einer Zuweisung zu einem 8Bit-Timer zwar eh der Fall ist, aber damit werden dann Compilerwarnungen unterdrückt. > Und was hat das Minus-Zeichen direkt dahinter zu bedeuten? -2 ist besser lesbar als 254. Man will ja 2 Takte zählen bis zum Überlauf, also: -2 -> -1 -> 0 (Überlauf: auf -2 setzen) usw. > Und nochmas: Wo gibts infos über (s16) (u8) (u16)?? (s8)?? Meistens wird versucht die Beispiele compilierfähig zu posten, d.h. Ausdrücke, die nicht standard C sind werden entweder zu Anfang oder in einem includierten Headerfile definiert. Hier handelt es sich konkret um abgekürzte Typdefinitionen wegen Schreibfaulheit. > Ja und Danke, dass ihr einem so unwissendem Anfänger wie mir noch helft. Hauptsache, die Frage ist eindeutig und verständlich formuliert und die Antwort nicht offensichtlich zu ergooglen. Peter
Peter Dannegger wrote: > Hans Wurst wrote: >> und zwar genauer (u8) schneidet das High-byte ab. > > da muß man schauen, wie "u8" definiert ist und findet: >
1 | |
2 | |
3 | |
Ah so?!... ja das gibt natürlich Sinn. Danke >> Und was hat das Minus-Zeichen direkt dahinter zu bedeuten? > > -2 ist besser lesbar als 254. Man will ja 2 Takte zählen bis zum > Überlauf, also: -2 -> -1 -> 0 (Überlauf: auf -2 setzen) usw. minus 2 in einem unsigned char (u8)? da müsste doch der compiler wieder warnen oder fehler melden? oder nicht?
Hans Wurst wrote: > minus 2 in einem unsigned char (u8)? > da müsste doch der compiler wieder warnen oder fehler melden? > oder nicht? Nö. Du castest eine -2 zu unsigned char. D.h., dass schlicht und ergreifend das Bitmuster für "-2" (short, also 1111 1111 1111 1110) als unsigned interpretiert wird. Dabei wird (nach den im C-Standard festgelegten Regeln für Typkonversionen) einfach das Low-Byte übernommen, und das lautet nunmal 1111 1110. Eine Warnung würdest Du nur dann bekommen, wenn Du den Cast weglässt. Denn dann weiß der Compiler nicht, ob das Abschneiden des High-Bytes tatsächlich gewollt ist. Mit dem expliziten Cast nach u8 (also unsigned char) sagst Du lediglich dem Compiler "ich weiß was ich tu (zumindest glaube ich das)" und der Compiler macht es einfach. Explizite Typkonversionen zwischen eigentlich inkompatiblen Typen sind hauptsächlich dazu da, eben solche Warnmeldungen zu unterdrücken. Du könntest den Cast in dem Fall genauso gut weglassen. Dann bekämst Du eine Warnmeldung, von der Du annehmen würdest, dass Du sie ignorieren kannst, weil der "Informationsverlust" schließlich beabsichtigt ist. Das ist allerdings unschön, zumal es dazu verleitet, auch andere (berechtigte) Warnmeldungen zu ignorieren. Generell sollte Code so geschrieben sein, dass er keine Warnmeldungen generiert.
Vielan Dank.