IR-bake

[Dirk]

Hi,

Würde für mein verstzändnis der stopwatches bedeuten, dass man diese an einer beliebigen stelle im vorderen bereich des programmes startet (einmal) und dann im ersten durchlauf der while(true) schleife auf null stellt und dann im zweiten durchlauf den Ir-empfang prüft...

Ja... Das startStopwatchX(); brauchst du nur EINMAL am Programmanfang, d.h. später normalerweise nicht wieder.

Die Benutzung geht dann so:
if(getStopwatchX() > 100) // mach was alle 100ms
{
// Was alles zu tun ist ...
setStopwatchX(0); // Stopwatch auf Null stellen
}

Die software reagiert sehr eigenartig auf das drücken der buttons: mal garnicht, mal mit kurzem start mit sofort erfolgtem break, mal richtig. Wie könnte ich da was verbessern? Verzögerungen in der tastenabfrage z.b.?

Ich würde 2 Sachen ändern:
1. In der SWITCH-CASE-Struktur sieh dir die while(true) Schleifen an: Alle Pausen (mSleep) dort und im Bereich "anzeige gedrückter buttons" müssen raus,- d.h.: Die Haupt-while(true)-Schleife muss ohne Unterbrechungen/Pausen ablaufen. Wenn man Texte länger lesen soll, müßte man das auch mit einer weiteren Stopwatch machen.
2. Die Zeile uint8_t key_1 = getMultiIOPressedButtonNumber(); brauchst du nicht. Es reicht: uint8_t key_1; (Grund: Weiter unten wird die Taste ja wieder eingelesen: key_1 = getMultiIOPressedButtonNumber(); )

[inka]

Hi Dirk,

Die Benutzung geht dann so:
if(getStopwatchX() > 100) // mach was alle 100ms
{
// Was alles zu tun ist ...
setStopwatchX(0); // Stopwatch auf Null stellen
}

macht das programm wirklich ALLE 100ms etwas oder immer dann wenns mal größer als 100ms ist? Also 101/102/105 - wanns gerade abgefragt wird? Ich glaube, wenn die funktionen im ablauf länger/komplizierter werden klappt es mit der abfrage nicht mehr so genau?

ich habe nun den zweiten abschnitt meines

case 2:
    setLEDs(0b0010);
    writeString_P("\n\n messung feldvariable\n\n");
    writeChar('\n');
    initRP6Control();
    initLCD();

    startStopwatch2();//neu

    while(true)
    {
    uint8_t i = 0;
    for(i = 0; i < 199; i++)
        {
        temp_IR[i] = read_IR_value();
        feld_IR[i] = temp_IR[i];
        if(getStopwatch2() > 50)//neu
        {
        writeIntegerLength(temp_IR[i],DEC,4);
        if(i % 12 == 0)
            {
            writeChar('\n');
            setStopwatch2(0);//neu
            }
        else
            {
            writeString_P(" | ");
            setStopwatch2(0);//neu
            }

//        mSleep(50);//entfallen
        }

        }

        /**************************/
        uint8_t key_1;
        key_1 = getMultiIOPressedButtonNumber();
        if(key_1 != 0) break;

        /**************************/
    }

    break;

durch die stopwatches ergänzt, es läuft im prinzip, aber eben nur im prinzip. Mit dem mSleep(50) war die ausgabe so:

0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004

mit stopwatches ist sie so:

0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004
0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004 | 0004

der code raegiert nun williger auf den druck auf die buttons, kann ich die ausgabe regelmäßiger machen?

[RoboHolIC]

macht das programm wirklich ALLE 100ms etwas oder immer dann wenns mal größer als 100ms ist? Also 101/102/105 - wanns gerade abgefragt wird? Ich glaube, wenn die funktionen im ablauf länger/komplizierter werden klappt es mit der abfrage nicht mehr so genau?

Genau SO ist es, so steht es ja auch im Code, nämlich >100. Versuche ruhig mal "=100", dann wird es noch schlimmer werden!
Was in einem harten Zeitraster abgearbeitet bzw. getestet werden soll, muss
- entweder schnell pollend, also häufiger als die Zeitzähleinheit angegangen werden
- oder besser noch: als (hochpriorer) Interrupt implementiert werden.

[Dirk]

Hi inka,

macht das programm wirklich ALLE 100ms etwas oder immer dann wenns mal größer als 100ms ist? Also 101/102/105 - wanns gerade abgefragt wird?

Ja, genau. Es kann ja immer nur etwas alle 100ms gemacht werden, wenn die Hauptschleife, in der die if(getStopwatchX() > 100 steht, nicht regelmäßig wieder bei der Abfrage ankommt. Hat also die Hauptschleife so viel zu tun, dass sie z.B. für einen kompletten Durchlauf 200ms braucht, dann kann die o.g. Stopwatch-Abfrage natürlich auch nur alle 200ms laufen.
Ist die Hauptschleife schnell (das sollte sie!), dann kommt das mit den 100ms ganz gut hin. Der Ablauf ist dann in der if(getStopwatchX() Schleife:
- Stopwatch > 100 ?
- Alles, was gemacht werden muss
- Stopwatch = 0
Das bedeutet auch, dass wenn "Alles, was gemacht werden muss" etwas länger dauert, diese Zeit zum Intervall noch addiert werden muss.
Wenn du wissen willst, mit welchem Stopwatchwert du in die Abfrage gehst, dann gib den Wert der Stopwatch doch am Anfang der if(getStopwatchX() Schleife aus. Dann kannst du sehen, wie die Intervalle aussehen: writeInteger(getStopwatchX(), DEC);

Was kann man machen:
- Hauptschleife optimieren (Sleeps raus, keine UART/WiFi/LCD-Ausgaben, kein Warten auf Bedingungen ...)
- Auch in den if(getStopwatchX() Schleifen keine Verzögerungen, wenn sie NUR ZUM MESSEN dienen. Daneben kann es natürlich auch noch solche Schleifen zur Textausgabe geben,- die braucht man aber meist selten (alle 0,5 oder 1 s).

der code raegiert nun williger auf den druck auf die buttons, kann ich die ausgabe regelmäßiger machen?

Die Ausgabe wird "unregelmäßig", weil du in der for(i = 0; i < 199; i++) Schleife die Ausgabe mit einer Stopwatch machst. Dann passiert es manchmal, dass die for-Schleife schneller ist als die 50ms der Stopwatch, dann ist die Stopwatch noch <= 50 und eine Ausgabe wird übersprungen.
Du must die ganze Ausgabe in die Stopwatch-Abfrage bringen und darin nicht eine for-Schleife nehmen, sondern eine Schleife mit einem globalen Zähler.

[inka]

hi Dirk,

im code werden die variablen t1, t2 und tg verwendet

wenn ich diese variablen t1, t2 und tg als uint8_t definiere (so wie sie im code nachher verwendet werden) passieren die seltsamsten dinge:

auch wenn diese variablen nur den abschnitt im case3 bertreffen, haben sie einfluss auf das verhalten im abschnitt case1 und case2 und zwar NUR die reine definition, auch wenn der code, wo sie verwendet werden auskommentiert wird!

im case1 wird z.b. die IR bake überhaupt nicht erkannt, auch wenn sie direkt vor dem IR-empfänger steht

im case2 werden im terminal statt 0000 (empfang) bzw. 0004 (kein empfang) die reinsten fantasiezahlen ausgegeben und die bake nicht erkannt

definiere ich statt "t1" z.b. "x" und statt "t2" z.b. "y" passiert das nicht, das programm läuft ganz normal ab. Der neue abschnitt case3 läuft noch nicht richtig, aber case1 und 2 laufen ganz normal...

ich konnte mir jetzt mit dem umdefinieren der variablen helfen, will Dich jetzt auch nicht mit dem ganzen code behelligen, gibt es aber dafür eine erklärung?

[Dirk]

Hi inka,
schau dir noch mal die Datentypen in GCC an!

Hier die Wichtigsten:
uint8_t -> 0..255
int8_t -> -128..+127
uint16_t -> 0..65535
int16_t -> -32768..+32767
uint32_t -> 0..4294967295
int32_t -> -2147483648..+2147483647
float -> -3.4E38..+3.4E38 (Fließkomma)

Wenn du negative Zahlen brauchst, must du schon einen intX_t Typ nehmen, bei nur positiven Werten reicht ein uintX_t.
Deine Werte liegen teils ja schon über/bis 520, also kommst du mit uint8_t nicht hin (Werte passen nicht in die Variablen und machen dann Mist).

[inka]

so, jetzt hats geklappt...

http://www.youtube.com/watch?v=HqvyW...ature=youtu.be

[fabqu]

Stark!!!
Und wie ich sehe mit Multi-IO im Einsatz

[inka]

manchmal geht es schneller als man erhofft hat:

ich habe das beispiel "RP6Control_10_Move2.c" in der mainschleife mit dieser funktion ergänzt (spannungsabfrage über die multiIO)

void accuzustand(void) //  accuspannung abfragen und signalisieren
{

LTC2990_measure();
if (vbat < 6)
{
buzzer(330);
mSleep(200);
buzzer(330);
mSleep(200);
bake_suche();
}

}

dort kann ich direkt über die Vbat abfrage den wert festlegen bei dem die funktion "bake_suche" aufgerufen werden soll. Und es funktioniert!!!


Ich muss jetzt noch prüfen nach welcher funktion jetzt die reaktion auf die bumper erfolgt, ob das auf diese "behaviour_escape" oder auf die direkte abfrage in der "bake_suche" ist. Ich vermute es ist die "behaviour_escape" funktion...


weiter geht es dann mit der liniensuche: ich muss ja in einer bestimmten richtung (eigentlich senkrecht auf die wand) auf die ladestation zufahren...

[TrainMen]

Gratulation zum Etappensieg,
ich bewundere Deine hartnäckigkeit bei diesem Projekt.