Hallo Leute,
hier mache ich mal einen Thread auf, in dem wir einen I2C-Slave für die M32-Platine entwickeln können.
Erst mal die Planung:
1. Der I2C-Slave für die M32 soll genauso arbeiten, wie der RP6Base I2C-Slave (RP6Base_I2CSlave.c) in den Demos.
2. Er soll möglichst (fast) alle Funktionen/Ressourcen der M32 über I2C "fernsteuerbar" bzw. abfragbar machen.
3. Er soll als I2C-Master eine andere M32, die CCPRO M128 oder die M256 WiFi akzeptieren.
4. Er soll die I2C-Adresse 12 bekommen.
5. Er soll über XBUS INT2 mit dem Master verbunden sein.
6. Er soll wie der Base-Slave auch eine Timeout-Funktion haben.
7. Er soll folgende Befehle (commands) über I2C verstehen:
Dabei setzt Befehl 0 die 8 freien I/O-Pins der M32 als Ein- oder Ausgänge, Befehl 2 schaltet die einzelnen I/O-Portpins.Code:// Commands: #define CMD_CONFIGIOS 0 #define CMD_SETIOS 1 //#define CMD_CONFIG 2 #define CMD_SETLEDS 3 #define CMD_DISCHARGEPEAKDETECTOR 4 #define CMD_GETMICROPHONEPEAK 5 #define CMD_SETMEM_CS2 6 #define CMD_WRITESPI 7 #define CMD_WRITEWORDSPI 8 #define CMD_READSPI 9 #define CMD_READWORDSPI 10 #define CMD_SET_WDT 11 #define CMD_SET_WDT_RQ 12 #define CMD_SPI_EEPROM_WRITEBYTE 13 #define CMD_SPI_EEPROM_ENABLEWRITE 14 #define CMD_SPI_EEPROM_DISABLEWRITE 15 #define CMD_SPI_EEPROM_READBYTE 16 #define CMD_SPI_EEPROM_GETSTATUS 17 #define CMD_INITLCD 18 #define CMD_CLEARLCD 19 #define CMD_WRITECHARLCD 20 #define CMD_WRITEINTEGERLCD 21 #define CMD_SETCURSORPOSLCD 22 #define CMD_BEEP 23 #define CMD_SETBEEPERPITCH 24 #define CMD_SOUND 25
Befehl 3 schaltet die LEDs. Befehle 4, 5 gehen mit dem Mikro um.
Befehle 6-10 sind die SPI-Befehle.
Befehle 11,12 gehören zum Watchdog-Timer (wie bei der Base!).
Befehle 13-17 lesen und schreiben von/aus dem SPI-EEPROM auf der M32.
Befehle 18-22 steuern das LCD auf der M32 an.
Befehle 23-25 steuern den Sound mit dem Beeper.
8. Er soll folgende Register zum Lesen durch den Master vorhalten:
Die REGs 0,1 sind die Interrupt- und Status-Register wie beim Base-Slave.Code:#define I2C_REG_STATUS1 0 #define I2C_REG_STATUS2 1 #define I2C_REG_IO_STATUS 2 #define I2C_REG_MEM_CS2 3 #define I2C_REG_SPIBYTE 4 #define I2C_REG_SPIWORD_L 5 #define I2C_REG_SPIWORD_H 6 #define I2C_REG_SPIEEPROMSTATUS 7 #define I2C_REG_SPIEEPROMBYTE 8 #define I2C_REG_SPIEEPROMWORD_L 9 #define I2C_REG_SPIEEPROMWORD_H 10 #define I2C_REG_ADC_4_L 11 #define I2C_REG_ADC_4_H 12 #define I2C_REG_ADC_3_L 13 #define I2C_REG_ADC_3_H 14 #define I2C_REG_ADC_2_L 15 #define I2C_REG_ADC_2_H 16 #define I2C_REG_ADC_6_L 17 #define I2C_REG_ADC_6_H 18 #define I2C_REG_ADC_5_L 19 #define I2C_REG_ADC_5_H 20 #define I2C_REG_ADC_7_L 21 #define I2C_REG_ADC_7_H 22 #define I2C_REG_ADC_MIC_L 23 #define I2C_REG_ADC_MIC_H 24 #define I2C_REG_ADC_KEYPAD_L 25 #define I2C_REG_ADC_KEYPAD_H 26 #define I2C_REG_RELEASEDKEYNUMBER 27 #define I2C_REG_PRESSEDKEYNUMBER 28 #define I2C_REG_LEDS 29
IO-Status (REG 2) sind die 8 freien I/O-Ports (sofern auf Eingänge geschaltet).
REGs 3-10 sind Leseregister der SPI- und SPI-EEPROM-Funktionen.
REGs 11-23 sind die freien ADC-Kanäle der M32.
REGs 23,24 sind der ADC-Wert des Mikro.
REGs 25,26 sind der ADC-Keypad-Wert.
REGs 27,28 sind die Nummern der zuletzt losgelassenen bzw. gedrückten Taste.
Mit REG 29 läßt sich der aktuelle Stand der 4 LEDs auslesen (an/aus).
9. Er soll auf die RP6Control Library https://www.roboternetz.de/community...ersion-1.3beta aufsetzen. Grund: Die aktuelle Lib V1.32beta ist voll kompatibel zur neuesten Version 1.3 und stellt mit eigenen Tasks schon regelmäßig die ADC-Werte und Werte der I/O-Ports zur Verfügung.
10. Bei Timeout soll die M32 funktionsfähig bleiben (Base-Slave bleibt dann in einer Endlosschleife stehen und muss resettet werden!).
Wenn ihr Ergänzungen möchtet: Hier posten!
Dann mache ich mich demnächst an eine erste Version.
Ist das sonst in der Planung so ok? Vorschläge? Änderungen?
Ich habe auch noch Verständnis-Fragen zum RP6Base-Slave:
... und zwar zu den Stopwatches in der Base-Slave-Demo (RP6Base_I2CSlave.c):
Es werden Stopwatches 1..4 benutzt/gestartet.
- Stopwatch1 wird nur gestartet, aber nicht benutzt: Lasse ich weg.
- Stopwatch2 ist der Timeout-Zähler, der in signalInterrupt gestartet wird und in clearInterrupt gestoppt/resettet wird. Über 3000 gibt es ein Timeout. Soweit verstehe ich das. In task_update wird Stopwatch2 aber resettet, und zwar im if(getStopwatch4() > 250) - Teil. Das passt eigentlich nicht in die Logik, weil man meinen sollte, dass Stopwatch2 alle 250ms resettet wird. Das macht aber keinen Sinn und findet so auch gar nicht statt, weil Stopwatch4 nie resettet wird.
- Stopwatch3 steuert die Watchdog-Anfrage. Verstehe ich.
- Stopwatch4 wird gestartet, nie resettet und resettet anfangs einmalig Stopwatch2 nach 250ms. Warum? Da Stopwatch4 immer weiter durchläuft, wird nach Überlaufen wieder Stopwatch2 einmalig resettet. Das ist mir alles ziemlich unklar.
Wer kann mir da weiterhelfen und den Sinn erklären?
Zitieren
Lesezeichen