Licht mit Tiny13

1. Timer aufsetzen und darin das Tastensignal einlesen und entprellen.
2. Zustandsautomat aufsetzen.
3. Entprellte Tastensignale als Ereignisse innerhalb des 
Zustandsautomaten auswerten.
4. Ebenso Timerereignisse auswerten.

Welche Sprache ?

Timm schrieb:
> Hier ist der Code
da gehört er aber nicht hin, sondern in den Anhang deines Posts.

>   PORTB = ((1<<PB0)|(1<<PB1)|(0<<PB2));
>

>   while(1)
>   {
>     if(!(PINB &(1<<PB2)))
>     {
...
>     }
>
>     if(!(PINB &(1<<PB2)))
>     {
....
>     }

Kanst du das mal erklären. Über das bescheuerte "Nullgeschiebe" lohnt es 
sich schon gar nicht mehr aufzuregen, aber wo ist der Pullup für PB2?
Und wo ist deine Entprellung? Auch dein Programm wird ohne nicht 
funktionieren.

mfg.

Timm schrieb:
> habe vorhin eine Zeile vergessen
>       DDRB  =(0<<DDB0);
>       PORTB=(0<<PB0);

Vergiss diesen Mist. Ich glaube, du weisst überhaupt nicht, was das 
macht.

http://www.mikrocontroller.net/articles/Bitmanipulation

mfg.

Timm schrieb:
> Wir dürfen im Internet recherchieren, lesen und unterstützung holen.
> Wichtig ist, dass ich es dann auch verstanden habe und erklären kann.
>
> wo finde ich die Entprellroutine von PeDa??

In der Artikelsammlung unter "Entprellung". Aber vergiss es. Die 
Funktion wirst du nicht erklären können.

Entprellung geht im einfachsten Fall so:
-Feststellen, daß Taste gedrückt
-Warten(~20-50ms)
-Testen, ob Taste immer noch gedrückt

Damit hast du das Prellen eliminiert.

Das reicht aber noch nicht. Du musst die Zustandsänderung der Taste 
erfassen.
Also:
-Feststellen, ob Taste, die vorher nicht gedrückt war, jetzt in diesem
 Moment gedrückt wurde
-Warten
-Testen, ob immer noch gedrückt
-Sich merken, daß Taste jetzt gedrückt ist.
...
-Feststellen, ob Taste gehalten wird oder die gerade gedrückte Taste
 jetzt in diesem Moment losgelassen wurde.
-Warten
-Testen ob losgelassen
-Sich merken, daß Taste nicht mehr gedrückt ist.

Solange die Taste gehalten wird, lässt du einen Zähler laufen, der dir 
ab einem bestimmten Zählerstand "lang" liefert. Wenn "lang" erkannt 
wurde, veränderst du die Helligkeit.
"kurz" kannst du erst nach dem Loslassen der Taste erkennen. Nämlich aus 
der Tatsache, daß die Taste gerade losgelassen wurde und während sie 
gedrückt war, nicht "lang" erkannt wurde. Du kannst "kurz" nicht an der 
gedrückten Taste erkennen. Woher soll der Controller wissen, wie lange 
der Benutzer die Taste jetzt drücken wird? Wenn er das wüsste, könnte er 
auch die Lottozahlen vorhersagen.

-"kurz": Taste losgelassen und Zähler < Langwert
-"lang": Taste gehalten und Zähler >= Langwert
-"nichts tun": Taste losgelassen und Zähler > Langwert

Der Langwertzähler muß nach den Loslassen grundsätzlich auf 0 gesetzt 
werden.

mfg.

100n parallel zum Schaltkontakt wirken oft Wunder. Wenn man das weiss, 
wird der Thread kürzer. ;-)

/* Belehrungsmodus  *Marke oberg'scheit!*

Ich habe oft  - bestimmt fälschlicherweise - den sehr schlimmen 
Verdacht, dass sich die meisten von Euch zwar hinsichtlich 
Programmierung perfekt auskennen, aber, dass es sehr oft an 
Grundkenntnissen von elektronischen Schaltungen mangelt.  Ich sage 
immer, dass das Display-Rubbeln und die Black-Box-Grundeinstellung, 
Marke "Scheissegal-was dahinter-steckt-Hauptsache-die Kiste-rennt" , 
einfach zu wenig ist. Und eben deshalb sollte man niemals mit 
Scheuklappen (beidseitig 'ne Klappe) hier im Forum herumrennen!
Dazu ist das Forum einfach zu schade!
Holt Euch Elektronik-Grundkenntnisse, dann seid Ihr allen anderen 
voraus!
Viele von Euch wissen nicht einmal, wie man den Vorwiderstand für eine 
LED berechnet, wie man die Formel U=R*I umstellen kann, wenn man zum 
Bleistift die Stromaufnahme bräuchte! Das ist grundlegend!
Und Linux kann weit mehr,Leute, als Eure Buntklick- IDE's! Wenn Ihr da 
reinschnüffelt, wisst Ihr erst , was wirklich läuft!

Und von elektronischen GRUND-Kenntnissen sollte man ausgehen, BEVOR man 
versucht, zu programmieren und keineswegs umgekehrt! Amen!

Obergescheitmodus aus */

Timm schrieb:
> Danke für die Erklärung. Ich habe jetzt den Code für Kurz geschrieben,
> kann es so stimmen?
>
>
>   while(1)
>   {
>     if(!(PINB &(0<<PB2))

Was erwartest du da als Ergebnis?

(0<<PB2).
Ich weiss nicht, wer sich das ausgedacht hat und welche Vollpfosten das 
immer wieder als sinnvoll verteidigen. Aber tu dir selbst den Gefallen 
und vergiss, daß du das jemals gesehen hast.
Das ist eine völlig unbrauchbare Konstruktion. Eine 0 kannst du 
versuchen, sonstwo hinzuschieben. Das ist und bleibt immer 0. Und wenn 
du 0 mit irgendwas UND-verknüpfst ist auch das Ergebnis immer 0. Also 
kann man damit etwas abfragen, wenn das Ergebnis immer 0 ist?

Guck dir an, wie man das richtig macht:
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Zugriff_auf_IO-Ports

Der Bitmaniplationslink oben ist nicht ganz so prickelnd.

mfg.

Thomas Eckmann schrieb:
> Eine 0 kannst du versuchen, sonstwo hinzuschieben. Das ist und bleibt immer 0.

Ähem, das trifft leider nicht immer zu. Gemäß C-Spezifikation ist das 
Schieben um mehr als die Datentypbreite undefiniert. Folglich kann jeder 
beliebige Wert herauskommen, also auch ungleich Null. Es gibt 
irgendeinen kommerziellen Compiler, der bei höheren Optimierungsstufen 
tatsächlich mit solchen üblen Tricks arbeitet, um bei irgendwelchen 
fingierten Benchmarks besonders gut abzuschneiden.

Andreas Schweigstill schrieb:
> Thomas Eckmann schrieb:
>> Eine 0 kannst du versuchen, sonstwo hinzuschieben. Das ist und bleibt immer 0.
>
> Ähem, das trifft leider nicht immer zu. Gemäß C-Spezifikation ist das
> Schieben um mehr als die Datentypbreite undefiniert. Folglich kann jeder
> beliebige Wert herauskommen, also auch ungleich Null. Es gibt
> irgendeinen kommerziellen Compiler, der bei höheren Optimierungsstufen
> tatsächlich mit solchen üblen Tricks arbeitet, um bei irgendwelchen
> fingierten Benchmarks besonders gut abzuschneiden.

Unsinn.
Hier wird gar nichts geschoben, sondern vom Compiler eine Konstante 
eingesetzt. Und wenn der sieht, "0 schieb 10^36 mal nach links", dann 
setzt er da 0 rein. Weil er bei "0 schieb..." gar nicht mehr weiter 
macht. Schliesslich lassen sich die Compilerbauer nicht jeden Blödsinn 
unterjubeln. Um das Schieben zur Laufzeit geht es dabei überhaupt nicht. 
Aber schön, daß du drüber geschrieben hast.

Vielleicht solltest du deinen Nachnamen manchmal zum Omen machen.

mfg.

Timm schrieb:
>       btnpress++;
>       if(btnpress<20)

Das macht doch auch keinen Sinn, daß das darauf Folgende 20 mal 
ausgeführt wird.
Ist das wieder ein Tipfehler?

Hör auf, Programmfetzen (fehlerhaft) abzutippen. Sondern stell deinen 
ganzen Programmtext als Anhang ein. Dann kann man das auch mal laufen 
lassen.

mfg.