| Re: Komplexer Parameter bei Funktionsaufruf Kategorie: Programmierung (von Guido - 11.09.2006 17:24) | ||
| Als Antwort auf Re: Komplexer Parameter bei Funktionsaufruf von Thomas - 2.09.2006 21:06 | ||
| ||
|
Hallo Thomas, ich hatte im Zusammenhang mit komplexen Datentypen ein Problem mit Vergleichen von byte values, was dazu führte, dass mein Program sehr unstabil und teilweise gar nicht funktioniert hatte. Ich hatte ähnlich wie Du für meine Haussteuerung verschiedene, auch verschachtelte Datentypen angelegt zur Beschreibung von Schaltern, Dimmern, Rollos, usw. Dabei hatte ich auch die meisten nummerischen Werte als byte angelegt. if vergleiche auf diese Werte lieferten aber nicht immer das gewünschte Ergebnis. Insbesondere Verleiche auf "0" schlugen öffters fehl. Ich vermute, dass bei if-Vergleichen immer mit Integer Werten gearbeitet wird. Es könnte nun sein, dass der MSB-Byte des Integer Wertes nicht richtig initialisiert bzw. gesetzt ist. Nachdem ich alle meine Datentypdefinitionen von byte auf int geändert hatte lief das Program fehlerfrei. Ich wei�, dass das evtl. gar nicht dein Problem ist, aber es ist mir bei Deinen Datentypen aufgefallen und nur eine Erfahrung die ich selbst gemacht habe. Gru� Guido > > Hallo Thomas, > > > > Wie sieht genau die Definition des eigenen Datentyps aus, und > > wie gro� ist das Array definiert ? > > > type typSwitch > { > // dies ist die Beschreibung der einzelnen Input! Schalter > byte bInputPort; // PortNummer für den Input > byte bCountOfOutputs; // wieviele Outputports wollen wir schalten? > typSwitchAddress arSwitchAddress[dcl.COUNT_SWITCH_PER_INPUT]; // Liste der Adressen > string strDescription; // Beschreibung des Ports > byte bolSpecial; > } > > type typSwitchModule > { > // dies ist die Datenstruktur für die I/O Module > byte bInputAdr; // Input Adresse > byte bOutputAdr; // Output Adresse > byte bOutputValue; // Wie sieht der Startwert für den Output aus? > byte bInputValue; // Aktueller Input > /* Nun kommt die Taster Maske, da einige Ports auch von Schaltern > belegt werden, wollen wir diese ausblenden. Jeder Port welcher ein Taster > ist, wird mit einer 1 in der Maske repräsentiert */ > byte bValueButtonAndMask; > byte bAktiv; // Ist das Modul aktiv? > string strLocation; // Lokation des Moduls > typSwitch arSwitch[dcl.COUNT_PORTS]; // Liste der Schalter > } > > Das Array arSwitch ist 8 Elemente gro�. > Das Array arSwitchModule ist 4 Elemente gro�. > > > > Es gibt zwar ein kleines Problem mit der Parameterübergabe > > von Strings aus zusammengesetzten Datentypen, aber ich denke, das hat > > hiermit nichts zu tun. > > > > Auch ein Stackproblem kann ich ausschlie�en, da in einem solchen Fall > > das Programm bei einem Overflow oder Underflow abbrechen würde > > und eine entsprechende Meldung an der Host-LED ausgegeben wird. > > > > Aber noch ein paar Fragen: > > Wird aus anderen Threads auf den PCF8574 zugegriffen ? > Ja aber ohne ein eigene Capture. Es ist doch in pcf drin? > > Kannst Du genau sagen, da� das Hängenbleiben beim Aufruf von pcf.in() passiert? > > (ggf. temporär Debuggingausgaben in der Funktion pcf.in() am Anfang und vor dem Return einfügen.) > Ich denke ja, werde ich aber auch in pcf.in direkt einmal loggen. > > Da Du eine eigene Platine verwendest, benutzt Du die Ports P1H.0-.3 ? > > Wenn nicht, hast Du Pull-Up-Widerstände angebracht ? > Ja sollten drin sein (Modul ist nicht von mir gebaut) > > Ansonsten kann es durch Störungen zu einer Programmverlangsamung kommen. > > (Es reicht oft eine Leuchtstoffröhre, oder auch Funkenbildung bei Schaltern.) > Das könnte es natürlich sein. Eigentlich ist der I2C Bus soweit es geht von solchen Quellen entfernt > und mit CAT5 Kabel gebaut (ca. 20m). Hhmm vieleicht die Module und das Schalten der Relais in > den Modulen. Eventuell ist ja hier was nicht korrekt... > > Hast Du irgendwelche rekursiven Aufrufe in Deinem Programm ? > > (Funktionen, die sich selbst aufrufen) > Nein. > > > > > > Noch ein kleiner Tip für Deine Funktion: > > Statt > > bInput1 = (not pcf.in (data.arSwitchModule[bIndex].bInputAdr)) > > and (not data.arSwitchModule[bIndex].bValueButtonAndMask); > > kannst Du einfach auch > > bInput1 = pcf.in (data.arSwitchModule[bIndex].bInputAdr) > > nor data.arSwitchModule[bIndex].bValueButtonAndMask; > > schreiben. > Stimmt, Danke für den Tip. > > > > > Meine Frage ist nun: Macht es Sinn den Aufruf pcf.in (data.arSwitchModule[bIndex].bInputAdr) > > > besser so zu formulieren: > > > bHilf = data.arSwitchModule[bIndex].bInputAdr; > > > pcf.in(bHilf); > > > > Prinzipiell darf es hier kein Unterschied geben. > > > > > Denn ein ähnliches Problem trat beim Setzen des Ports mit pcf.set auf und hier hat dies geholfen. > > > > Kannst Du das kurz schildern? > > Folgendes funktioniert, d.h. der Port wechselt. > > if (data.arRaum[i].bControl==1) > { > bModul = data.arRaum[i].bSwitchModule; > bAdress = data.arRaum[i].bOutputPort; > if (data.arRaum[i].bAction==1) > { > /* Ok, wir sollen den Raum heizen. Also holen wir uns die Adresse > des Heizungsaktor, den aktuellen Wert. Wenn dieser gerade aus > ist (255) dann toggeln wir den Port */ > b = pcf.get(bModul,bAdress); > if ((b==255)) > if (pcf.toggle(bModul,bAdress)==0) > com.Log("HZ_Control err Toggle",bAdress); > } > } > > > Wobei folgendes nicht funktioniert. Der Rückgabewert von pcf.toggle ist ungleich null und nichts passiert. > > if (data.arRaum[i].bControl==1) > { > if (data.arRaum[i].bAction==1) > { > /* Ok, wir sollen den Raum heizen. Also holen wir uns die Adresse > des Heizungsaktor, den aktuellen Wert. Wenn dieser gerade aus > ist (255) dann toggeln wir den Port */ > b = pcf.get(data.arRaum[i].bSwitchModule,data.arRaum[i].bOutputPort); > if ((b==255)) > if (pcf.toggle(data.arRaum[i].bSwitchModule,data.arRaum[i].bOutputPort)==0) > com.Log("heizung.HZ_Control #ERROR# Problem to toggle Port",data.arRaum[i].bOutputPort); > } > } > > Hinweis: Bei der letzten hatte ich auch noch den Fehler, dass der String länger als 30 Zeichen war. Hatte aber > beim Fehler keine �nderung gemacht. > > > > > MfG André H. > > > > Viele Grü�e Thomas | ||
Antwort schreiben Antworten: | ||