hallo jerome,
beeindruckende und informative ergebnisse, die du gepostet hast.
Auffällig ist nach dem 17. Takt (?) ein Low-Spike.
Meine Annahme ist, dass an der Stelle die Übertragung vom 328P zum MSP430 endet und am 328P nun von OUTPUT auf INPUT gewechselt wird, um die Antwort vom MSP430 zu lesen.
perfekt erkannt, würde ich meinen. faszienierendes werkzeug, dieser kleine analyzer.
einfaches an- und ausschalten würde allerdings einfacher funktionieren.
bis zu 17 bit werden an den msp gesendet und bis zu 8 bit gibt es als antwort darauf.
wenn ich alle möglichen 17 bits nutze, ergibt "10111100101000000" dezimal 96576.
das wäre schon nah an 86400 sekunden für 24 stunden.
da diese kommunikation auch bei jedem zustandswechsel erfolgt, würde der timer dadurch immer zurückgesetzt, also neu gestartet werden. und mit "00000000000000000" wird der timer nicht gestartet.
andererseits stelle ich mir dann die frage: warum ständig so eine "grosse und fixe" zahl übertragen?
oder: was passiert dann bei konfiguriertem EVENT_DELAYTIME (0-7620)? wacht er dann bei statuswechsel erst auf, legt sich wieder hin, und wacht nach EVENT_DELAYTIME nochmal auf?
und bei MSG_FOR_POS_A,B,C kann man "NO_MSG" konfigurieren, sodass er dann gar nicht aufwachen müsste. oder wird nur die funkmessage verhindert?
fragen über fragen. da bräuchte es noch viele tests mit unterschiedlichen konfigurationen, um die genaue logik zu ermitteln.
ein mitschnitt beim originalen rhs wird sicherlich ähnlich komplex sein.
kleiner unterschied
bei der erzeugung des signals "D0" beim rhs nimmst du gegenüber eq3 offensichtlich einen etwas anderen weg.
beim sci ist die pausendauer scheinbar immer konstant. du verkürzt die pausendauer bei jeder änderung vom signal "D2".
absicht?
ich werde demnächst mal den neuen sketch testen.
gruss frank