Sonderbare Effekte beim ARM-RM-Modul

[bodefeld]

Ich habe einige funktionstüchtige LPC-RM-Module im Einsatz und habe mich jetzt mal an die ARM-Variante gewagt. Prinzipiell funktioniert auch einiges, aber eben leider nicht alles
PA programmieren funktioniert, Testalarme funktionieren, Rauchkammerwerte und Temperaturen auslesen funktioniert. Was aber zum Beispiel nicht funktioniert ist das Auslesen der Seriennummer oder der Temperaturoffset, der funktioniert nämlich nur in einem relativ kleinen Bereich. Sobald ich mich da zweistelligen Werten nähere, schlagen die Endergebnisse ganz grob nach oben aus.
Auffällig ist auch, daß jedesmal die komplette Applikation neu programmiert werden muss weil angeblich die Versionsnummern nicht passen. Das ist auch soweit erstmal richtig, die ARM Variante zeigt mir in der ETS nämlich Versionsnummer 1.8 (statt der 2.4 die die LPC-Aufbauten zurück geben). Auch steht in der Geräteinfo unter "Programm" nicht etwa "Rauchmelder" sondern "76 03F2 18".

Nach allen möglichen Verrenkungen ist mir jetzt durch Zufall aufgefallen, daß die Versionsnummer in der ETS sich nach 1.9 ändert wenn ich in der app_main.cpp den bcu.begin Aufruf von "bcu.begin(0x004c,0x03fs,24);" auf "bcu.begin(0x004c,0x03fs,25);" ändere. Interessant daran ist, dass 24 dezimal 0x18 Hex und 25 dezimal 0x19 Hex ist, ich glaube das hängt irgendwie zusammen

Programmiert wurden die Module per Flashmagic sowohl mit dem OM13054 als auch mit dem seriellen LPC-Programmer, beides funktioniert einwandfrei, führt aber auch zu den selben Ergebnissen. Es sind insgesamt 6 ARM-Module die allesamt dasselbe Verhalten zeigen, LPC-Module im selben Rauchmelder funktionieren einwandfrei, ich habe aber (natürlich) auch schon mehrere Rauchmelder getestet.

Hat das Phänomen schonmal jemand gesehen? Und kann mir vielleicht jemand eine aktuelle HEX-Datei zur Verfügung stellen mit der ich das mal testen könnte? Ich vermute den Fehler irgendwo in meiner Entwicklungsumgebung (ich benutze die VM unter Virtualbox/OSX), weiß mir aber mittlerweile nicht mehr zu helfen.

Vielen Dank!

[klayman]

Hi, nachdem ich das flashen jetzt endlich geschafft habe, stehe ich vor dem selben Problem, bzw. einer ganzen Reihe von Problemen:

- Partielles programmieren (geht wenn man bcu.begin(0x004c,0x03fs,36) schreibt, entspricht 24 in hex)
- Werte auslesen geht garnicht (ist im Code teilweise auskommentiert wegen neuer Lib)
- Temp. Offset liegt bei negativen Werten voll daneben (evtl. Vorzeichenproblem?)
- Alarm zurücksetzen geht nicht
- Seriennummer wird nicht gesendet

Ich kann leider nicht wirklich programmieren (die zwei Kurse in der Uni sind schon 15 Jahre her ) und muss daher viel rumprobieren. Ich fürchte da brauchen wir die Hilfe der ursprünglichen Entwickler...

Viele Grüße,
Klayman

[bodefeld]

Das ist merkwürdig, Werte lesen funktioniert bei mir ohne Probleme (abgesehen davon, daß als Seriennummer halt immer eine 0 zurückkommt).

[klayman]

Hi, mein Fehler, auslesen funktioniert jetzt auch. Möglicherweise dauert es etwas bis die Werte verfügbar sind, es scheint als würde der Auslesebefehl keine Abfrage des RM triggern, sondern die zuletzt erhaltenen Werte im Speicher zu verwenden. Für die Seriennummer konnte ich keine Routine in der rm_app.cpp finden.
Lass mal über den Temperatur Offset grübeln: In Zeile 487 wird zu dem bis dahin korrekt empfangene und berechnete Wert (weil bei Offset >=0 alles ok) der Korrekturwert addiert, das Ergebnis in char umgewandelt und das ganze dann mit 10 multipliziert. Ich vermute bei der Umwandlung läuft was mit den Vorzeichen schief.
Bei einem Offset von 0 bekomme ich gerade eine Temperatur von 23,74°C angezeigt. Bei einem Offset von -1 werden daraus 49,24°C. eine Differenz von 25,5 - eine in der Informatik verdächtige Zahl Allerdings hat sich der Code von LPC zu ARM an diesen Stellen und auch in der Umrechnungsroutine auf DPT 9.001 nicht verändert...

[bodefeld]

Sehr gut beobachtet! Das scheint wirklich irgendein Fehler bei der Typisierung der Variablen zu sein, ich kann hier exakt dasselbe beobachten. -1 führt zu einem positiven Offset von 25.5, -50 zu einem positiven Offset von 20.5, da stimmt vermutlich irgendwas mit signed/unsigned nicht.
Aber auch komisch, daß die Versionsnummer die im Code Dezimal angegeben wird dann später im Melder als Hex-Wert erscheint, das ist ja bei der LPC-Version auch nicht der Fall.
Letzteres hat mich ja vermuten lassen, daß irgendetwas mit meinem Compiler nicht stimmt. Wenn der Code identisch ist, dann muß es ja entweder am Compiler oder an der Plattform selber liegen. Aber ob sowas jetzt durch Little/Big Endian oder ähnliches zu Stande kommen kann? Das übersteigt meine Kompetenz

[klayman]

uuuh, ich glaub ich hab's gefunden: Der Compiler für ARM scheint char by default als unsigned zu betrachten, es sei denn man gibt dem compiler --signed_chars als Option mit. Da ich nicht genau weiß wie man das in der Entwicklungsumgebung der VM macht, habe ich in Zeile 487 den cast des userEeprom von "char" in "signed char" angepasst, also so:

Code: Alles auswählen

lval += (signed char)userEeprom[CONF_TEMP_OFFSET] *10;

Und siehe da: Negative Offsets funktionieren Bleibt die Frage an welchen anderen Stellen das noch ein Problem ist. Im Rauchmelder konnte ich nur noch eine weitere Stelle in der rm_com.cpp in Zeile 126 finden. Ein signed char macht dort aber keinen Unterschied und macht irgendwie auch keinen Sinn, da ja nix berechnet wird... Zur sblib selbst müssten die Experten hier nochmal was sagen.

Geht bei Dir denn das Zurücksetzen eines Alarms über den Bus und wenn ja, was genau sendest Du auf welches Kommunikationsobjekt?

Viele Grüße,
Klayman

[klayman]

Aber auch komisch, daß die Versionsnummer die im Code Dezimal angegeben wird dann später im Melder als Hex-Wert erscheint, das ist ja bei der LPC-Version auch nicht der Fall.

Kann mir vorstellen, dass das auch irgendwo in char gecastet wird und dort das selbe Problem auftritt. Das lässt sich aber erstmal mit dem passenden Dezimalwert umgehen. Man müsste mal rausfinden wo man dem Compiler die Option --signed_chars mitgeben kann und dann den originalen code von GitHub nochmal übersetzen.

[bodefeld]

Das mit dem Alarm kann ich erst morgen ausprobieren, sonst flieg ich hier raus
Was genau soll ich denn probieren? Einen Testalarm via Bus auslösen und dann wieder zurücksetzen?

Zu den Einstellungen in der IDE kann ich leider auch nichts beisteuern, da blicke ich garnicht durch. Ich hab mir schon eine Flasche Sekt gekauft als ich das erste Mal überhaupt irgendwas kompiliert bekommen habe

Aber offenbar betrifft das Problem dann ja nicht nur den Rauchmelder und auch nicht nur die Temperatur-Offsets. Vermutlich kommt auch der Effekt mit der Applikations-Version irgendwo aus dieser Richtung. Vor allem aber müßten dann ja alle ARM-Projekte auf die eine oder andere Art davon betroffen sein oder sehe ich das falsch?

[klayman]

naja, vielleicht haben die Entwickler der anderen Applikationen das schon irgendwo berücksichtigt. Man kann ja explizit signed und unsigned schreiben und dann gehts... Lass morgen mal nen neuen Fred dazu aufmachen

Das mit dem Alarm hat sich geklärt. Man muss eine 0 senden um Alarme zu resetten. Keine 1 wie fälschlicherweise angenommen und wie von einem HomeServer QC Template vorgesehen. Muss dem HS jetzt beibringen eine 0 statt einer 1 zu senden...

Funktioniert sonst alles bei Dir? Wie gesagt, für die Seriennummer scheint es keine Methode in der rm_app zu geben. Auf die kann ich aber verzichten.

Danke,
Klayman

[bodefeld]

Ja, soweit ich das überschauen kann funktioniert beinahe alles: halt bis auf die Dinge, die ich im ersten Posting erwähnt hatte.
Das was Du vorgeschlagen hast mag ja funktionieren aber mir kommt es so vor als würde man das Symptom und nicht die Ursache beheben. Es scheint ja doch irgendwie prinzipielle Probleme beim ARM-Modul zu geben - was den Funktionsumfang angeht ist das halt noch weit vom LPC-Modul entfernt, denn da geht halt einfach alles so wie erwartet.
Ein Hotfix der sich nicht dem eigentlichen Problem widmet mag ja für irgendeine Übergangsphase eine Lösung darstellen aber ich würde trotzdem mal gern hören was die Entwickler dazu sagen, die eigentliche Ursache scheint ja doch etwas tiefer vergraben zu liegen.

Ich hoffe, daß sich hier noch jemand meldet. Bis dahin lasse ich mal besser die Finger von irgendwelchen ARM-Aufbauten