Einlesen von Tastern mit Entprellheader

[Daniel U. (Firma: zuhause) (uhli)]

Hallo!

Habe die Entprellfunktion mittels Flankenerkennung von µC.net genutzt.
Leider reagiert der µC (ATm8) nicht darauf.
Woran kann das liegen?
Wäre nett wenn mal jemand einen Blick auf das angehängte
Programm wirft.
Es soll folgende Funktion haben:
1. Tastendruck: LED aus
2. Tastendruck: LED blinkt
3. Tastendruck: LED an

Viele Grüße

[Karl H. (kbuchegg)]

#define TASTERPORT PORTC
#define TASTERBIT PINC5

von einem Port liest man über das PINx Register ein und nicht über das 
PORTx Register.

Code nicht einfach gedankenlos übernehmen. Die Zeile hier

   if(zustand = 0 & !(TASTERPORT & (1<TASTERBIT))

muss dir bereits den entscheidenden Hinweis bringen, ob bei TASTERPORT 
das Port Register oder das Pin Register anzugeben ist.

PS: diese Form der Flankenerkennung ist auf eine funktionierende 
Entprellung angewiesen. Die funktioniert aber nur dann, wenn beim 
AUfrufer

  while( 1 ) {

    taster();

    ....

    _delay_ms( 10 );
  }

es auf jeden Fall eine Form eines Delays gibt. Ohne Delay wird da nichts 
enptrellt. Dazu ist der µC viel zu schnell wieder in der Funktion, so 
dass Preller gnadenlos durschchlagen. Das hättest du dann auch einfacher 
haben können. So wie du überhaupt die ganze Funktionalität bei 
vorhandenem Delay einfacher haben kannst.

[holger (Gast)]

>Code nicht einfach gedankenlos übernehmen. Die Zeile hier
>
>   if(zustand = 0 & !(TASTERPORT & (1<TASTERBIT))
>
>muss dir bereits den entscheidenden Hinweis bringen,

das da ein Tippfehler ist.

(1<TASTERBIT)

So wird ein Schuh draus:

(1<<TASTERBIT)


Und wie zum Teufel kommt man auf die Idee eine einfache
Textdatei als PDF zu posten?

[Karl H. (kbuchegg)]

holger schrieb:
>>Code nicht einfach gedankenlos übernehmen. Die Zeile hier
>>
>>   if(zustand = 0 & !(TASTERPORT & (1<TASTERBIT))
>>
>>muss dir bereits den entscheidenden Hinweis bringen,
>
> das da ein Tippfehler ist.
>
> (1<TASTERBIT)
>
> So wird ein Schuh draus:
>
> (1<<TASTERBIT)

Danke.
Noch ein Fehler. Nach dem Erkennen des PORTC - PINC Fehlers hab ich 
nicht mehr weiter gelesen. Mir hat schon der Teil "alles gelbe ist 
auskommentiert" gereicht.

[Daniel U. (Firma: zuhause) (uhli)]

Ja danke für die Tipps!

Warum keine einfache Textdatei als pdf posten?, habe nur open office
und kein word

[Karl H. (kbuchegg)]

Daniel Duesentrieb schrieb:
> Ja danke für die Tipps!
>
> Warum keine einfache Textdatei als pdf posten?, habe nur open office
> und kein word

du sollst weder das eine noch das andere benutzen!

Häng dein C File einfach an, so wie es ist. Nicht mehr und nicht 
weniger.
Wozu verpacken? Ein C File ist erst mal ein Text File wie jedes andere 
auch. Nur mit dem Unterschied, dass das Forum schon weiß, wie es mit 
derartigen Files umgehen soll und entsprechendes Syntax Highlighting 
benutzt. Nur mit dem Unterschied, dass man dann mit einfachem Copy&Paste 
Teile aus deinem Code ausschneiden und in der Antwort wieder verwenden 
kann, ohne erst mal einen externen Viewer benutzen zu müssen.

Ganz im Gegenteil. Da ein C File einfach nur ein einfaches 
ASCII-Textfile ist, kann es auch keine Viren oder sonstige Schadlast 
beinhalten. Ein gepostetes C-File mach ich unbedenklich auf. Bei einem 
Word-File überleg ich mir das 3 mal.

[holger (Gast)]

>Warum keine einfache Textdatei als pdf posten?, habe nur open office
>und kein word

Ich kenne keinen Compiler der OpenOffice, PDF oder Worddokumente
verarbeitet. Welchen Compiler benutzt du?

[Peter D. (peda)]

holger schrieb:
> Und wie zum Teufel kommt man auf die Idee eine einfache
> Textdatei als PDF zu posten?

Damit keiner sie einfach mal durch den Compiler jagen kann, ob Warnungen 
oder Errors gemeldet werden. Oder sie vielleicht sogar simuliert.

Wenn man direkt die *.c Datei postet, könnte ja leicht jemand auf solche 
verrückten Ideen kommen und sofort die Fehler finden.

[Conny G. (conny_g)]

holger schrieb:
> Und wie zum Teufel kommt man auf die Idee eine einfache
> Textdatei als PDF zu posten?

Schutz des Urheberrechts. Sonst zieht noch einer mit der wertvollen 
Software davon!

[saydexcfgtvhujk (Gast)]

Wenn die Software wirklich so wertvoll wäre, dann würde das PDF keine 
ernstzunehmende Hürde...

[saydexcfgtvhujk (Gast)]

Nachtrag: darstellen...

[Stefan F. (Gast)]

Abgesehen von der außerordentlich hässlichen Formatierung des 
Quelltextes und der sträflichen Verwendung von #include mit absoluten 
Pfaden sehe ich folgende vermutlich fehlerhafte Zeilen:

if(rw==1) // Tastendruckzaehler=0
{
  PORTC|=(1<<PC5); 
  Tastendruckzaehler++;
} // neg. Logik -> + schaltet, LED aus

if((rw==1)&&(Tastendruckzaehler==1)) // blink blink blink
{
  Ledblinken(); 
  Tastendruckzaehler++;
}

if((rw==1)&&(Tastendruckzaehler==2)) // leucht leucht leucht
{
  PORTC&=~(1<<PC5); 
  Tastendruckzaehler=0;
} // neg. Logik -> - schaltet, LED ein

Wenn der Tastendruckzaehler=0 ist, werden alle drei bedingte Codeblöcke 
nacheinander ausgeführt. Das hast Du sicher nicht gewollt, oder doch? 
Wenn ja, wozu dienen dann die vielen if Ausdrücke?

PS: Hier siehst Du, wie einfach es ist, Text auf dem PDF heraus zu 
kopieren. Das geht einfach so, genau wie bei einer Textdatei.

[Peter D. (peda)]

Stefan us schrieb:
> PS: Hier siehst Du, wie einfach es ist, Text auf dem PDF heraus zu
> kopieren. Das geht einfach so, genau wie bei einer Textdatei.

Aber je mehr unnötige Hürden man aufstellt, umso weniger beschäftigen 
sich mit dem Problem.

Atmel hatte mal ne Zeitlang Copy&Paste in seinen PDF-Datenblättern 
gesperrt.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

holger schrieb:
> Ich kenne keinen Compiler der OpenOffice, PDF oder Worddokumente
> verarbeitet. Welchen Compiler benutzt du?

Solch einen Compiler kenne ich auch nicht, aber früher(tm) hatte ich 
zwei Kollegen, die ihre C-Quelltexte mit Word und Wordpad schrieben und 
sich dann über die komischen Fehlermeldungen des Compilers wunderten. 
Als ich sie auf die Ursache des Problems hinwies, wollten sie mir 
zunächst nicht glauben. Erst nach etlichen Tagen (des 
Nichtkompilierens...) mussten sie mir dann rechtgeben. Angeblich hatten 
sie auch während des Studiums ihre Quelltexte immer mit Word geschrieben 
und es hätte da niemals Probleme gegeben.

Naja, gegen das Schreiben mit Word ist ja nichts einzuwenden, solange 
man nicht kompilieren will...

Oder besitzen die Microsoft-Compiler etwa heimlich einen 
Word-Importfilter? Denkbar wäre das schon.

[Uhli (Gast)]

Ja
Asche auf mein Haupt, ihr habt natürlich recht, es ist quautsch als pdf 
zu posten.
Habe nur einem anderen Anfänger die Problemstellung per mail geschickt 
und
das ganze in ein pdf gehauen, da er auch andere Programmieroberfläche 
nutzt etc.
Deshalb habe ich ihm auch den auskommentierten Teil markiert.

...


Dann hab ich nur eben noch zwei Fragen zu dem was Stefan_us schrieb:
"...sträflichen Verwendung von #include mit absoluten
Pfaden..."

-Was ist günstiger als die Verwendung absoluter Pfade?
 Oder was sin d die genauen Nachteile?
 Im Moment Fällt mir da nur ein das man die Pfadangabe immer Ändern
 muss wenn man die include in eine ander Datei haut.

-Sorry das versteh ich gerade nicht: "Wenn der Tastendruckzaehler=0 ist, 
werden alle drei bedingte Codeblöcke nacheinander ausgeführt."
Warum werden dann die 3 Codeblöcke nacheinander aufgeführt?

MfG Uhli

[Karl H. (kbuchegg)]

Uhli schrieb:
> Ja
> Asche auf mein Haupt, ihr habt natürlich recht, es ist quautsch als pdf
> zu posten.
> Habe nur einem anderen Anfänger die Problemstellung per mail geschickt
> und
> das ganze in ein pdf gehauen, da er auch andere Programmieroberfläche
> nutzt etc.
> Deshalb habe ich ihm auch den auskommentierten Teil markiert.

Damit hat der dann dieselben Probleme.

QUelltext, mit dem ein anderer etwas anfangen können soll, den 
verschickst du ganz einfach als genau die Textdatei, die du schreibst. 
Niemand muss dazu irgendwas auspacken oder einpacken oder umformatieren 
oder sonst irgendwas damit tun.
Ein Programmtext ist einfach nur eine Textdatei. Die gibt es seit 60 
Jahren und in einer reinen Textdatei gibt es auch keine Möglichkeit, 
irgendwelche Viren oder Trojaner oder sonstigen QUatsch unterzubringen. 
Das ist einfach nur Text, eine Abfolge von Buchstabebn, definiert durch 
(meistens) ASCII Code.
Das Leben könnte so viel einfacher sein, wenn Micorsoft nicht in ihrer 
unnachahmlichen Weitsicht beschlossen hätte, dass EMails auch HTML 
können müssen. Vorher waren EMails genauso einfach nur Text, der von 
einem Postfach zum anderen geschickt wurde. Sicher, Bilder konnte man 
nicht im Text einbetten, aber das brauchte auch niemand wirklich. Dafür 
waren die Mails klein und der einzige Virus den man damit ohne Ahnhabng 
verschicken konnte war die EMail
"Um mal etwas tolles zu sehen, gehen sie auf die Commandline und tippen 
sie "FORMAT C:" ein.

> Dann hab ich nur eben noch zwei Fragen zu dem was Stefan_us schrieb:
> "...sträflichen Verwendung von #include mit absoluten
> Pfaden..."
>
> -Was ist günstiger als die Verwendung absoluter Pfade?

keine absolute Pfade.
Wenn du dein Projekt von einem Ordner auf einen anderen Ordner 
verschiebst, dann ändert sich ja deiser absolute Pfad.

Besser ist es zb. Utility Verzeichnisse in der IDE einzutragen. Dann 
übergibt die IDE dem Compiler beim AUfruf diese Pfade, auf das der 
COmpiler sie alle durchsucht, wenn er ein Header File suchen muss.

>  Oder was sin d die genauen Nachteile?
>  Im Moment Fällt mir da nur ein das man die Pfadangabe immer Ändern
>  muss wenn man die include in eine ander Datei haut.

Genau das. Und zwar in allen C Dateien, die zum Projekt gehören. Das 
werden bei dir noch nicht so viele sein, es soll aber schon Projekte 
gegeben haben, die aus ein paar Hundert C-Files bestanden haben.

> -Sorry das versteh ich gerade nicht: "Wenn der Tastendruckzaehler=0 ist,
> werden alle drei bedingte Codeblöcke nacheinander ausgeführt."
> Warum werden dann die 3 Codeblöcke nacheinander aufgeführt?

WEil du in jedem if den Tastendruckzaehler erhöhst. Dadurch ist dann 
immer gleich die Bedingung für den nächsten if gegegben.

  i = 0;

  if( i == 0 )
    i++;      // i ist danach 1

  if( i == 1 )   // super: i ist ja bereits 1. Im vorhergehenden then
                 // Zweig wurde es ja von 0 auf 1 erhöht.
    i++;         // und jetzt wird i von 1 auf 2 erhöht

  if( i == 2 )   // daher trifft dann auch jetzt diese Bedingung zu.
    i++;

Wenn du deinen ganze Code mal ein bischen einfacher schreiben würdest, 
würde man das leichter sehen. Denn die Teilbedingung, dass rw gleich 1 
sein muss, ist ja in allen if's gefordert

  Tastendruckzaehler = 0;

...

  if( rw == 1 )
  {
    PORTC |= (1<<PC5); 
    Tastendruckzaehler++;

    if( Tastendruckzaehler == 1 ) // blink blink blink
    {
      Ledblinken(); 
      Tastendruckzaehler++;
    }

    if( Tastendruckzaehler == 2 ) // leucht leucht leucht
    {
      PORTC &= ~(1<<PC5); 
      Tastendruckzaehler = 0;
    }
  }

jetzt sieht man ganz deutlich, dass am Anfang der Tastendruckzähler am 
Anfang bei 0 losstartet. Beim tastendruck wird er duch das ++ erhöht, 
wodurch die Bedingung für das erste if zutgrifft. In Abarbeitung dessen 
then-Teil wird der Zähler wieder erhöht, wodurch die Bedingung für das 
nächste if zutrifft. etc. etc.