Du hast wahrscheinlich recht. Das das Programmieren können nicht im Verhältnis steht zum Aufwand und Ärger den der I²C gerade macht. Das mit dem Netzteil ist ja auch irgendwann gelaufen. Noch ein bisschen drauf rum denken. Noch Ärgert es mich einfach das es Andere hin bekommen aber ich nicht. Ist halt die erste Zeit viel umstecken bis es läuft. Oder muss die Arduino IDE auf den Pi machen. Könnte sein das das geht. damit das aber geht muss ich noch einen Wartungs Modus für das Netzteil machen sonst fährt mir das den PI Hard runter (watchdock).
Eigentlich will ich auf dem PI nicht arbeiten Code auf 7 Zoll ist nicht so prickelt aber wahrscheinlich alles Luxus Probleme.
(20.12.2019, 08:18)Der kleine Punky schrieb: [ -> ]...
Die RTC kann ich nicht Öffnen weil es die Teil ID schon gibt eine Idee wie man das Lösen kann ?
war dir fritzing abgestürtzt?
ich glaub unter ."../Fritzing/parts/user" findest das teil mit der ID. dieses dann löschen-.
Kurze zwischen Info:
I2C geht zu mindestens konnte ich gerade MCP und Nano via I2C ansprechen. Habe jetzt noch mal einen Anderen LevelShifter gekauft der scheint das Problem gelößt zu haben.
Keine weiteren Wiederstände nichts zusätliches. Ok die neuen habe jetzt nur 4 Kanäle und 2 sind für I2C weg aber das sollte ja passen.
Jetzt muss ich nur noch mal das Thema INT Testen also am Nano ein Pin High machen und gucken ob das und wie das bei PI ankommt.
Wenn ich es messen könnte würde ich glatt mal probieren ob der Pegewandler das PWM schafft dann wäre alles Perfekt. Aber das Display zu opfern glaube ich so mutig bin ich nicht.
Hat einer von Euch schon selbst ein I²C Protokoll entwickelt ?
Das wird jetzt echt Spannend noch habe ich da keine Richtige Idee.
i2c ist doch bereits das Protokoll, oder was meinst du?
wilkst du eigene low/high mit timings dazu entwickeln?
Nein, wahrscheinlich habe ich einfach noch nicht genug gelesen.
Die Linux befehle I2C Set und Get legen nahe was man eigentlich nicht mehr als ein WORD also 2 Byte übertragen kann. Ist das so ?
Bei RS232 muss man sich auch was ein fallen lassen mit zum Beispiel STX und ETX da mit man weiß wo eine Übertragung an fängt und wo sie auf hört.
Das Wort Protokoll ist vielleicht zu hoch gegriffen mir fällt aber kein besser ein.
Beispiel Netzteil:
<stx><TypeByte><Wert><etx>
Das mein Netzteil Protokoll das Type Byte ist so Definiert:
Code:
//Protokoll Defs
#define STX 0x02
#define ETX 0x03
#define ACK 0x06
#define IDKL15 0x10
#define PIALIVECOUNT 0x11
#define SYSTEMSTATE 0x12
#define COMMANDRESULT 0x13
#define EXTERNVOLTAGE 0x14
#define NACK 0x15
Ist also die Zündung Aktiv kommt:
0x02 0x10 0x01 0x03 über die Leitung
ein Command wird mit:
0x02 0x13 0x06 0x03 Quitiitiert
Und so was muss ich mir ja noch für die Kommuniktion Überlegen habe ja jetzt keine Vorgaben durch einen Hersteller. Muss ja nur verstehen auf beiden Seiten Natürlich darf ich den Bus nicht kaputt machen.
Gerade für den Rücktranport von Infos wird das interessant da ich ja nicht einfach senden kann wie bei RS232.
Ergo muss es Irgend wie so aussehen:
PI -> Nano Gibt mal Sensor Licht
Nano <- PI wert
Und da fängt mein Verständnis gerade an. Noch dazu weil es ja im Arduino Wire.onRequest ein void ist das verstehe ich so gar nicht.
Wire.requestFrom (SLAVE_ADDRESS, responseSize); Habe ich auf dem PI so noch nicht gefunden warten auf Size Bytes von der Remote Adresse.
0x02 + 0x03 ist immer anfang und ende.
und das zweite byte vermutlich der befehl
das dritte byte bis (wie lang auch immer) kannst dann beliebige daten rein schreiben, solang kein 02+03 dabei ist.
oder schau dir mal von bmw das ibus protokoll an. wobei das etwas komplexer wäre.
Ich habe es gestern gelöst für mich.
https://bitbucket.org/numberfive/sdl2gui...nd_IO_I2C/
Ich habe mich am MCP Orientiert das hat den Vorteil das man mit den Commandline Tools für I²C Testen kann.
Code:
i2cget -y 1 0x21 0x00 w -> AD0 abfragen
i2cget -y 1 0x21 0x01 w -> AD1 abfragen
i2cget -y 1 0x21 0x02 w -> AD2 abfragen
i2cget -y 1 0x21 0x03 w -> AD3 abfragen
i2cget -y 1 0x21 0x04 w -> AD4 abfragen
i2cget -y 1 0x21 0x05 w -> AD5 abfragen
i2cget -y 1 0x21 0x06 w -> PWM 1 Abfragen
i2cget -y 1 0x21 0x07 w -> PWM 2 Abfragen
i2cget -y 1 0x21 0x08 w -> DIGI Pins abfragen
i2cset -y 1 0x21 0x10 0x10 -> Interval einstellen Value * 100 Ms
i2cset -y 1 0x21 0x11 0x10 -> PWM 1 einstellen
i2cset -y 1 0x21 0x12 0x10 -> PWM 2 einstellen
i2cset -y 1 0x21 0x13 0x03 -> AD's enable / disable 0x03 => 0 und 1 Enabled
i2cset -y 1 0x21 0x14 0x03 -> DIGI's enable / disable 0x03 => 0 und 1 Enabled
i2cset -y 1 0x21 0x15 0x00 -> DIGI Pins auf Input umschalten 0x00 alle da wo ne 1 ist Input
i2cset -y 1 0x21 0xF0 -> Konfiguration im EEPROM speichern
Eine INT Pin / Leitung habe ich auch Programmiert. Das muss ich aber noch Testen. Das heiß Sollte sich ein AD Wert ändern (Interval) wird der PIN High oder ein Digi PIN sich ändern.
Die digiPins werden im Loop Abgefragt die AD's nur im Intervall. Ok den kann man auf 0 Stellen aber dann sollte man keine Debug ausgaben mehr machen wollen (Serial) und I²C hängt da auch genauen Grund weiß ich nicht aber ich glaube das ist eh nicht wirklich Interessant. So nahe dran zu sein.
Was ich jetzt noch überlege ist ob ich noch eine Funktion einbaue das die AD's nur Melden wenn ein wert Änderung um X stand findet und nicht jeden den zum Beispiel der Licht Sensor wacklt doch sehr.
Mal sehen
(13.01.2020, 07:57)Der kleine Punky schrieb: [ -> ]Was ich jetzt noch überlege ist ob ich noch eine Funktion einbaue das die AD's nur Melden wenn ein wert Änderung um X stand findet und nicht jeden den zum Beispiel der Licht Sensor wacklt doch sehr.
Mal sehen
Sollte recht einfach machbar sein. Musst nur den (letzten) Messwert mal in einer Variable speichern und dann mit dem aktuellen Messwert vergleichen. Wenn der größer/kleiner X ist, dann melden. Zum Schluss den letzten Messwert wieder in die Variable speichern. Und wenn du dann noch den Mittelwert einer Messreihe als Referenzwert nimmst, sollte das die Schwankungen des Sensors ausgleichen.
Das mache ich ja so aber der sensor wackelt ergo habe ich alle Interval zeit einen INT High.
Jetzt ist es so, zu mindestens beim Lichtsensor, das eine Wert Änderung um 1 für den Mensch keine wahrnehmbare Veränderung ist.
Das zum Beispiel auch so Scheint die Sonne ins Zimmer ist die werte Änderung nicht so stark wie wenn man eine Lampe auf den Sensor hält.
So ist es zur Zeit
Code:
bool readAd(byte adress) {
bool valueChanged = false;
if(bitRead(configuration.enableAD, adress) == 1) {
word adValue = 0x00;
//AD4 und AD5 Belegt durch I²C
switch(adress) {
case 0x00:
adValue = analogRead(A0);
break;
case 0x01:
adValue = analogRead(A1);
break;
case 0x02:
adValue = analogRead(A2);
break;
case 0x03:
adValue = analogRead(A3);
break;
case 0x04:
adValue = analogRead(A6);
break;
case 0x05:
adValue = analogRead(A7);
break;
}
if(adValue != lastAD[adress]) {
lastAD[adress] = adValue;
valueChanged = true;
DebugPrinter.print(F("AD"));
DebugPrinter.print(adress, HEX);
DebugPrinter.print(F(" has Value: "));
DebugPrinter.print(lastAD[adress], HEX);
DebugPrinter.println();
}
}
}
Jetzt könnte ich auch:
if(ABS(adValue - lastAD[adress]) > mininmal Change )
schreiben dann würde ich das nur mit bekomme wenn der AD sich um X (Minimal Change Ändert)
Oder könnte man auch versuchen:
word roundValue = (adValue + lastAD[adress]) / 2;
if(roundValue != lastAD[adress])
Oder sagen wir mal 5 letzte Messwerte Speichern daraus den Mittelwert bilden und den dann mit dem Letzten mittelwert vergleich und dann Melden.
Das aber ganz schön Komplexe zu lesen später im code. Auch kommen dann so sachen hin zu das erst die 5 Messung saubere werte liefert.
Das dann doof wenn man ad dynamsch ein und aus schaltet.
Mal noch ein bisschen drauf rum denken.