[gelöst] Fehler mit adc.classdef, Timingproblem wie beseitigen?

[franky08]

Müsste eigendlich auch ein ltc1257 set dabei sein, mmh. Sonst las ich das Ganze nochmal laufen, ist jetzt blos bischen blöd bei den Außentemperaturen di Heizung laufen zu lassen 

VG
Frank

[kpwg]

Nein, kein Stress. Ich schau mir das Logfile nochmals genauer an. Aber erst heute abend.

Viele Grüße, Ricardo

[franky08]

Danke dir. Schönen Sonntag.

VG
Frank

[franky08]

Hallo Ricardo, ich versuche jetzt einfach das "OK" auszufiltern. Mit if($value != "OK") in der adc.classdef müsste das doch zu machen sein, oder?

VG
Frank

[kpwg]

Hallo Frank,
Mir ist es gestern abend nicht gelungen, einen Fehler im Stream zu finden. War alles gut und nichts "durcheinander".  Wo könnten wir noch ansetzen?

Viele Grüße, Ricardo

[franky08]

Ich baue jetzt schon seit ein paar Stunden an der adc.classdef herum um den fehlerhaften Wert "OK" auszufiltern Ich habe langsam die Vermutung, dass ich beim compilieren von E6 die Fuse Bits vlt. falsch gesetzt habe und der Atmel damit zu "langsam" läuft. Habe einen Atmel 644P auf dem Board und beim make das auch so gesetzt aber mit den fuse Bits habe ich eine Einstellung aus dem Netz verwendet.

VG
Frank

[kpwg]

Ich hab meist low=FF high=D9 "ge-fust". Damit und einem 16Mhz Quarz habe ich keine Sorgen. Wenn jedoch das Timing nicht stimmt, sollte man doch gar nicht auf das System drauf kommen?

[franky08]

Fuse Bits hab ich genau wie du gesetzt, daran liegt es also nicht, war nur so ein Gedanke von mir. Langsam weis ich auch nicht mehr, wo ich noch suchen soll. Habe jetzt das get adc erst mal disabled und eine sub geschrieben, die das "Pferd" sozusagen von hinten aufzäumt. An Hand der DAC value setze ich die Leistung sozusagen hardcodiert. Über 3500 sind 100 Prozent usw. Dadurch habe ich Abstufungen von jeweils 25 Prozent als Angabe der Leistung. Ist zwar ein dämlicher Workaround aber besser als nichts.

P.S. Und ich versuche gerade dem MAC gcc "beizubringen" um nicht laufend zwischen 3 Rechnern switchen zu müssen (Linux zum compilieren, Windows mit AVR Studio zum flashen und der MAC ist eigendlich mein "Hauptrechner")
VG
Frank

[kpwg]

Ich habe ein altes Notebook, das ausschließlich mit Linux (Debian) läuft. Dort gibts für jedes E6 Projekt ein eigenes Verzeichnis, auch wenn das so nicht im Sinne des Erfinders ist. Hat aber den Vorteil, das ich für jedes E6 immer den speziellen Stand hab, mit dem ich zuletzt "dran" war. Geflasht wird dann auf Kommandozeile per avrdude mit dem Diamex All AVR- eine sehr zuverlässige Geschichte. Mit Usbasp und STK200 war es irgendwann zu nervig- man wusste nie so recht, warum das Flashen gelegentlich doch nicht klappte. 

[franky08]

Hallo, melde mich mal mit dem "altbekannten" Problem zurück
Nachdem die Logmeldung:

Code Auswählen Erweitern

AVRNETIO: unexpected answer "OK\nOK\n" received (wrote "adc get 0\n", expected .*)
2015.06.03 17:40:00 1: PERL WARNING: Illegal hexadecimal digit 'O' ignored at ./FHEM/99_myUtils.pm line 382.

nicht wegzubekommen war, habe ich kurzerhand ein zweites AVR-Net-IO mit E6 geflasht um mit diesem über ADC 0 die Spannung an MP1 bzw. MP2 zu messen. Die Schaltung ist von der Junkers Stetigregelung:
http://forum.fhem.de/index.php/topic,13653.msg85032.html#msg85032

Jetzt passiert etwas "seltsames"! Verbinde ich MP1 oder MP2 mit dem zweiten AVR-NET-IO Board, springt die Spannung am Steuersignal_Therme (vom ersten AVR_NET_IO Board also der DAC ) sofort auf ca.21V und die Heizung geht natürlich sofort in Betrieb. Jetzt stellt sich mir die Frage, wie das möglich ist?

VG
Frank

[franky08]

Nach Änderung der classdef´s sind die Logeinträge nun weg!

Code Auswählen Erweitern

get value cmd {"adc get %PortID\n"}
params PortID
get value expect ".*"
#get value postproc {\
# my $hexval = hex(trim("$_"));\
# my $hash  = $defs{%NAME};\
# readingsSingleUpdate($hash, "state", $hexval, 1);\
readingsSingleUpdate($hexval, 1);\
#}
Auswertung von get value in sub ausgelagert und:

Code Auswählen Erweitern

set setDAC params dacValue
set setDAC cmd {"ltc1257_set %dacValue\n"}
set setDAC expect "OK\n"
set init cmd {"ltc1257_init\n"}
set init expect "OK\n"

Warum das vorher nicht funktionierte, ist mir ein Rätsel.

VG
Frank