Ausgabe an UART bringt Müll

[Hue \. (hue)]

Hallo,

ich habe ein seltsames Problem: Wenn ich die globale Variable 
"__release" in der Funktion "decode" auskommentiere, kommt Zeichenmüll 
auf dem Terminal an.

Das "main.c" File in der momentan Fassung funktioniert. Die Daten werden 
von einer
PS/2 Tastatur gelesen. Sobald ich aber testen will, ob die Taste 
losgelassen wird, sie sendet dann nämlich "0xF0", dann will ich dies mir 
merken und die nachfolgenden Zeichen ignoriern. Aber das Auskommentieren 
der "__release" Variable bringt mein Programm durcheinander. Wo klemmt 
hier die Säge?

MfG

HUE \a

[Oliver J. (skriptkiddy)]

void decode ( uint8_t sc )
{
  if ( sc != 0xF0 )
  {
    uart_putc(sc);
//    __release=0;      
  } else {
//    __release=1;
  }
  return;
}

Seit wann hat eine void Funktion ein return?

[Peter II (Gast)]

Oliver J. schrieb:
> Seit wann hat eine void Funktion ein return?

wie willst du sonst eine funktion mal in der mitte abbrechen?

[Oliver J. (skriptkiddy)]

Peter II schrieb:
> Oliver J. schrieb:
>> Seit wann hat eine void Funktion ein return?
>
> wie willst du sonst eine funktion mal in der mitte abbrechen?

Du hast recht.

[Hue \. (hue)]

Hallo,

das "return" kann durchaus entfernt werden, es ändert aber das 
beschriebene Problem nicht. Sobald ich versuche einen Zwischenstand 
mittels globaler Variable oder localer Variable "static uint8_t release" 
zu speichern, kommt auf dem Terminal nur noch Quatsch an.

Hat noch jemand dazu einen Tipp?

HUE \a

[Justus (Gast)]

Peter II schrieb:
> Oliver J. schrieb:
>
>> Seit wann hat eine void Funktion ein return?

Meiner Kenntnis nach muss ein Return immer einen Wert zurückliefern, so 
kann der Programmteiln icht funktionieren. Es muss lauten

return (0); oder irgendetwas anderes - aber schlicht return; geht nicht.

[Peter II (Gast)]

Justus schrieb:
> Es muss lauten
> return (0); oder irgendetwas anderes - aber schlicht return; geht nicht.

nein denn return ist keine funktion damit muss auch keine klammer hin. 
Klar darf man es auch ohne parameter verwenden.

Sollte aber in jeden Buch auch so drin stehen.

[Oliver J. (skriptkiddy)]

Ich hatte sowas von unrecht.
Hier ist eine Referenz zum return-statement.

http://home.htw-berlin.de/~junghans/cref/SYNTAX/return.html

[Justus (Gast)]

Oliver J. schrieb:
> http://home.htw-berlin.de/~junghans/cref/SYNTAX/return.html

sorry, der Link funktioniert nicht.

[Peter II (Gast)]

Justus schrieb:
> sorry, der Link funktioniert nicht.
klar geht doch

[Edi R. (edi_r)]

Justus schrieb:
> sorry, der Link funktioniert nicht.

Bei mir schon.

[Matthias (Gast)]

Die Variablen sollten so definiert werden:
Außerdem sollte die Variable Data auch mal wieder auf 0x00
gesetzt werden, da Du ja "nur" Bits setzt und nicht aktiv löschst!

volatile uint8_t __edge, __bitcount;
volatile uint8_t __release;

ISR(INT0_vect)
{
    static uint8_t data;                      // Holds the received scan code

    if (!__edge)                                // Routine entered at falling edge
    {
        if(__bitcount < 11 && __bitcount > 2)    // Bit 3 to 10 is data. Parity bit,
        {                                    // start and stop bits are ignored.
            data = (data >> 1);
            if(PINA & 4)
                data = data | 0x80;            // Store a '1'
        }

        MCUCR = 3;                            // Set interrupt on rising edge
        __edge = 1;
        
    } else {                                // Routine entered at rising edge

        MCUCR = 2;                            // Set interrupt on falling edge
        __edge = 0;

        if(--__bitcount == 0)                    // All bits received
        {
      decode(data);
      data = 0x00; // DAS HIER SOLLTE VIELLEICHT AUCH REIN!
            __bitcount = 11;
        }
    }
}

[Hue \. (hue)]

Hallo,

die Anweisungen "volatile" und das Rücksetzen von "data" haben nicht den 
gewünschten Effekt gebracht. Es kommt immer noch Müll auf dem Terminal 
an.

HUE \a

[Justus (Gast)]

Edi R. schrieb:
> Justus schrieb:
>
>> sorry, der Link funktioniert nicht.
>
>
>
> Bei mir schon.

Bei mir nicht, vielleicht stimmt was mit Eurem Internet nicht?

[Marc H. (Gast)]

Justus schrieb:
>> Bei mir schon.
>
>
>
> Bei mir nicht, vielleicht stimmt was mit Eurem Internet nicht?

Vielleicht ist Dein Rechner kaputt? Nimm doch mal etwas Speisefett und 
öle die CPU etwas, damit sie besser läuft und Du was empfangen kannst.

[Hue \. (hue)]

Also nach weiteren Tests hat es nur mit dem Setzen der Variable 
"_release" zu tun.
Fraglich warum nur das Setzen schon den Müll auf dem Display verursacht. 
Ich habe doch noch nichts verbrochen, was die Ausgabe an das Terminal 
angeht, oder?

HUE \a

[Marc H. (Gast)]

Hue \a schrieb:
> Also nach weiteren Tests hat es nur mit dem Setzen der Variable
> "_release" zu tun.
>
> Fraglich warum nur das Setzen schon den Müll auf dem Display verursacht.
> Ich habe doch noch nichts verbrochen, was die Ausgabe an das Terminal
> angeht, oder?
>
> HUE \a

Ich denke nicht, dass es mit der Variablen _release zu tun hat, viel 
mehr scheint die Return-Rückgabewertproblematik Ursache für das 
Nichtfunktionieren Deines Programmentwurfes zu sein. Alternativ könntest 
Du die Verwendung einer cerebralen Logik verwenden, die z.B. in 
Wirbeltieren vorkommend aufzufinden sind.

[Justus (Gast)]

Ode an die Logik

Eines morgens trafen sich eine Logik und ein Gatter. Nachdem die Logik 
klassisch nachdachte, fand sie das Gatter schön und tat sich mit dem 
Gatter zusammen. Vereint kommen sie noch heute als Logikgatter in 
digitalen Schaltkreisen vor - vereint bis zum letzten PC.

[Hue \. (hue)]

Hier ist die Routine "decode"

void decode ( uint8_t sc )
{
    if ( sc != 0xF0 )
    {
         uart_putc(sc);
//      __release=0;            
    } else {
//      __release=1;
    }
}

So gehts!

void decode ( uint8_t sc )
{
    if ( sc != 0xF0 )
    {   
        uart_putc(sc);
      __release=0;            
    } else {
      __release=1;
    }   
}

So nicht!

HUE \a

[Stefan E. (sternst)]

Es könnte auch schlicht ein Timing-Problem sein. Der PS/2-Clock ist mit 
10-16.7 kHz ja auch nicht gerade langsam. Es könnte sein, dass es ohne 
die Zuweisungen an __release noch so gerade eben passt, mit ihnen aber 
nicht mehr.

PS: Was soll der Unsinn mit den beiden führenden Unterstrichen? Solche 
Namen sind für den Compiler reserviert.

[Justus (Gast)]

Stefan Ernst schrieb:
> Was soll der Unsinn mit den beiden führenden Unterstrichen? Solche
>
> Namen sind für den Compiler reserviert.

Das sehe ich auch ao. Es liegt einfach an dem Return, dass ist 
fehlerhaft und die Unterstriche sind nicht nur für Compiler, sondern 
auch für Eisdielen.

[Hue \. (hue)]

Wo ist denn in der Funktion "decode" das RETURN"?

Hier mein funktionierender Code mit der lokalen Definition von 
"release".

void decode ( uint8_t sc )
{
    uint8_t release;

    if ( sc != 0xF0 )
    {
        uart_putc(sc);
        release=0;
    } else {
        release=1;
    }
}

Es kann ja nicht ein Timingproblem sein, wenn das schreiben der Variable 
"release" im lokalen Modus funktioniert, und als "static" Variable oder 
als "globale" Variable nicht.

Der Code ist an die AppNote von Atmel zur Abfrage der Tastatur 
angelehnt.

HUE \a

[Stefan E. (sternst)]

Hue \a schrieb:
> Wo ist denn in der Funktion "decode" das RETURN"?

Ignoriere den Troll doch einfach.

Hue \a schrieb:
> Es kann ja nicht ein Timingproblem sein, wenn das schreiben der Variable
> "release" im lokalen Modus funktioniert, und als "static" Variable oder
> als "globale" Variable nicht.

Doch, kann es, denn als lokale Variable wird sie (und die Zuweisungen an 
sie) komplett wegoptimiert. Packe doch mal ein paar NOPs in die 
funktionierende Version, und schaue was passiert.

[Hue \. (hue)]

Hallo,

vielen Dank für Eure konstruktiven Hinweise. Ich habe mich nun der 
Meinung angeschlossen, dass ich ein Timing Problem habe. Ich werde mich 
nun bemühen, dies zu beheben.

Ein schönes Wochenende...

HUE \a