beim startup gibt es also 3 phasen mit insgesamt 5 kommunikations frames.
1. phase: initialisierung des avr
der avr bekommt 2x daten vom msp, die jeweils vom msp initiiert werden.
frame1 (config-8bit): vermutlich infos über die msp konfiguration, zb die anzahl der überwachten schalter.
frame2 (position-8bit): aktueller zustand der schalter
2. phase: initialisierung der timer des msp, beide initiiert durch den avr.
frame3 (cycle-18/8bit): initialisierung der cycletime plus antwort (cycleAck) des msp
frame4 (delay-10bit): initialisierung der delaytime
hier sind sogar 2 spikes zu sehen. die initialisierung erfolgt also in einem rutsch.
3. phase: schlafenlegen
frame5 (cycle-18/8bit): zum abschluss des startup wird der cycletimer noch mal neu gestartet.
Dabei kann ich nun keine veränderte Antwort-Sequenz mehr finden.
das ist nicht ganz richtig. es sind sogar 2 neue antworten erfolgt.
bei beiden versuchen mit aktiviertem cycle ist das cycleAck bei frame3 und frame5 immer unterschiedlich.
in frame3 bei beiden versuchen mit aktiviertem cycle "1001 0011", dezimal 147.
in frame5 bei beiden versuchen mit aktiviertem cycle "1000 0111", dezimal 135.
Code: Alles auswählen
00000000- 0 => no cycle
10010011-147 => init cycle on
10000111-135 => goto sleep with cycle after init
bisher:
10001011-139 => ?
10011111-159 => goto sleep with cycle after config delay, but no cycle change
eventuell ist auch der aktuelle status der taster im cycleAck enthalten.
2 neue variationen zum setzen der cycletime
ich bin guter hoffnung, dass mindestens eine der folgenden varianten den rhs dazu bringt, doch eine antwort zu senden.
bisher haben wir zuerst ein low auf die Data leitung geschrieben und anschliessend auf INPUT umgeschaltet.
das erzeugt einen tristate input, soweit ich das verstehe.
die 2 varianten erzeugen nun zuznächst einen input mit pullup vor der 18. fallenden flanke von Mout.
variante1 schaltet direkt nach der 18. fallenden flanke auf tristate und variante2 erst nach dem letzten bit der antwort (nach der for schleife).
zumindestens variante2 zeigt bei mir eine seltsame reaktion des msp:
anstatt (3x 64s + 5s wachzeit) abstand zwischen den zyklischen messages, erfolgen hiermit die msgs im abstand von genau (4x 64s +5s wachzeit).
Code: Alles auswählen
//variante1
for (uint8_t i=0; i < 26; i++) {
PORTC |= _BV(PC1); //SET OUT H (Aout)
while (!(PINC & (1 << PC2))); //WAIT WHILE L (Mout)
PORTC &= ~_BV(PC1); //SET OUT L (Aout)
if (i == 17) {
_delay_us(100);
// PORTC &= ~_BV(PC3); //SET OUT L (Data)
DDRC=B00000010; //SET INPUT (Data)
}
while (PINC & (1 << PC2)); //WAIT WHILE H (Mout)
if (i == 15) PORTC |= _BV(PC3); //SET OUT H (Data)
if (i == 17) {
PORTC &= ~_BV(PC3); //SET OUT L (Data)
}
if (i < 25) _delay_us(700);
}
PORTC &= ~_BV(PC3); //SET OUT L (Data)
DDRC=B00000010; //SET INPUT (Data)
//variante2
for (uint8_t i=0; i < 26; i++) {
PORTC |= _BV(PC1); //SET OUT H (Aout)
while (!(PINC & (1 << PC2))); //WAIT WHILE L (Mout)
PORTC &= ~_BV(PC1); //SET OUT L (Aout)
if (i == 17) {
_delay_us(100);
// PORTC &= ~_BV(PC3); //SET OUT L (Data)
DDRC=B00000010; //SET INPUT (Data)
}
while (PINC & (1 << PC2)); //WAIT WHILE H (Mout)
if (i == 15) PORTC |= _BV(PC3); //SET OUT H (Data)
if (i < 25) _delay_us(700);
}
PORTC &= ~_BV(PC3); //SET OUT L (Data)
DDRC=B00000010; //SET INPUT (Data)
wenn das vorgehen funktioniert, könnte ein entsprechendes vorgehen beim ausschalten der zyklischen msg, eventuell sogar dort andere antworten erzeugen als nur "null" und würde weitere erkenntnisse zum dekodieren ergeben.
aber grundsätzlich benötigen wir die antwort eigentlich nicht, oder?
frohe ostern
