RP6Control M32: Projekt I2C-Slave

[Dirk]

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:

// 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

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.
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:

#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

Die REGs 0,1 sind die Interrupt- und Status-Register wie beim Base-Slave.
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?

[RolfD]

Hallo Dirk,
zu den Soures allgemein, ich hab inzwischen oft festgestellt, das in den RP6 Quellen mal versucht wurde Ideen unter zu bringen die dann aber zum Teil mit ner heißen Nadel zuende gestrickt wurden. D.H. man findet da zuweilen Strukturen und Ansätze (Reste?), die im Prinzip nicht ausgearbeitet sind. manche Stellen sind sogar mit "TODO" markiert. Es gibt aber auch Zusammenhänge, die komplex sind... z.B. alles mit Motoren und Timer.
Slyd hat aber auch immer gesagt das die RP6 Lib ein "Vorschlag" zur Arbeitsgrundlage ist und kein absoluter Weg zur Glücklichkeit - weshalb mich auch wundert das recht wenig an den Libs bisher verbessert wurde im Gegensatz zu anderen Bots mit AVR. Die RP6 Gemeinde ist scheinbar recht genügsam in den Anforderungen... Allerdings hindert wohl die besagte Komplexität auch ein wenig denn es gibt viele Stellschrauben und wenn man nur an einer dreht funktioniert oft nix mehr...

Das ist mir alles ziemlich unklar.

Nicht nur Dir... ich sehs beim überfliegen aber wie du...1 und 4 dürften unnütz sein, 2 und 3 sind "Krücken" um irgendwas abzufangen.. schlimmstenfall weil irgendwo was verbummelt wird. 3 Sek timeout.. tststs is ja schlimmer wie XP *gg

Punkt 10 dürfte problematisch sein auch wenn ich es für erstrebenswert halte.

Bei der SPI-ROM Geschichte... muss man da nicht ganze Pages beschreiben? Macht es Sinn, Daten dann byteweise zu übergeben? Wenn ich vom Master aus 64 Byte ins ROM schreiben will, schreibt man dann da 64*64 Pages? Ich mein... das sind 4096 Page-Schreibvorgänge... das kostet Zeit und der Rom Baustein ist im Nu ausgeleiert... genau so das Micro... macht es Sinn die ADC-Werte des Mikro oder des ADC-Keypad an den Master zu übergeben? Welche Taste gedrückt ist...oder ein Händeklatsch-Event.. oder Frequenterkennung ok.. aber die Auswertung sollte der Slave vorher machen und die Daten fürs I2C Register aufbereiten oder? In der anderen Richtung eben so.. wie beschreibt man dann das LCD4x16? in dem ich da 64 Zeichen plus Steuerzeichen an den Slave morse? Mit zwischendrin Register setzen?
Ein Salve darf ja ruhig dumm sein...aber bissel was sollte der schon vorbereiten den alle paar sec nen adc Wert vom Micro ist für nen Master witzlos. Der Ganze Ansatz mit dem Slaveregister ist eigentlich witzlos... da müsste ein anständiges serielles Protokoll her... sowas z.b. http://de.wikipedia.org/wiki/Modbus ... zu dem Thema hab ich mich aber schon mehrfach ausgelassen.
Punkt 2 dürfte also schwierig werden. Das betrifft übrigends auch alle anderen Slaves die es so für den RP6 gibt. Das möchte ich als "Bedenken" mal anmelden.
Ansonsten denk ich, wenn so "Kinderkrankheiten" ausgemerzt sind, könnte das was werden... da ich mein eigenes Projekt hab, bin ich aber bussy. Ich guck aber gern mal mit bei Dir rein.
LG Rolf

Nachtrag: Die Rechnung mit dem SPI-Rom stimmt so nich.. sind keine 4096 Pages.. nur 4096 Bytes und 64 Page writes... mein Fehler.

[Dirk]

Hallo Rolf,

... SPI-ROM Geschichte... muss man da nicht ganze Pages beschreiben?

Man muss nicht. Ich denke, dass man da eher auch nur einzelne Bytes schreiben/lesen sollte (vielleicht Einstellungen..?). bzw. der Slave speichert dort Messwerte und der Master fragt sie in kleineren Portionen ab. Im Grunde kann man diese EEPROM-Funktionen auch nur zur Verfügung stellen: Der Programmierer des Masters muss damit adäquat umgehen: Z.B. Page-Grenzen beachten und Adressen verwalten. Die Sinnfrage ist ohnehin immer relativ.

...wie beschreibt man dann das LCD4x16?

Das geht sicher nicht sehr effektiv, aber es geht, zumindest mit Übertragung von Einzelzeichen. Ich könnte auch Strings übertragen, aber das wäre dann doch etwas "übers Ziel hinaus".

macht es Sinn die ADC-Werte des Mikro oder des ADC-Keypad an den Master zu übergeben?

Nicht wirklich, aber Mic und Keypad könnte man theoretisch hardwaremäßig von den ADCs abtrennen für andere Aufgaben. Die Tasten werden ja immerhin ausgewertet (pressed/releasedkeyNumber) ... Aber du hast Recht: Es geht besser.

Kurz noch zu den Stopwatches:
Wenn ich im Base-Slave in der task_update den Anfang so ändere:

 if(getStopwatch4() > 250)
 {
  uBat_measure += adcBat;
  uBat_measure /= 2;
  uBat_count++;
  setStopwatch4(0);
 }

... funktioniert tatsächlich auch die Timeout-Funktion des Slaves. Warum ist mir das nicht vorher aufgefallen? Naja, immerhin klappte es ja mit dem Base-Slave.
Jetzt verstehe ich das mit den Stopwatches besser: War wohl ein Bug ...

[Filou89]

Hallo Zusammen,

Ich könnte auch Strings übertragen, aber das wäre dann doch etwas "übers Ziel hinaus".

Ich würde es für sinnvoll halten, wenn man dem Slave einige "Standard-Strings" beibringen würde die im Programm hinterlegt werden und dann zur ausgabe auf dem LCD nur noch aufgerufen werden müssen.
Im Sinne von:

#define CMD_WRITESTRINGNRLCD   2X

Macht das Sinn?

[EDIT]
Punkt 10: Wie stellst du dir das "Weiterleben" vor? Sollen einfach keine neuen Befehle mehr ausgegeben werden, soll eine vordefinierte "Sicherheitsstellung" eingenommen werden, auf dem LCd eine Warnung ausgegeben werden und auf neue I2C Befehle gewartet werden... Als Slave soll er ja nur das tun, was der Master befiehlt.
Mir scheint die "Sicherheitsstellung" sinnvoll. Der Slave würde dann eine Notfallprozedur abarbeiten. Das wäre aber sicher auch anwenderspezifisch; Man könnte jedoch hier eine gute Schnittstelle vorsehen.

Ist für die Ansteuerung der Servos auch etwas vorgesehen?
[/EDIT]
Grüsse

[Filou89]

Hi Dirk,
Ich habe mal die Remotrol-Version und Base Version als Vorlage genommen und mal einen Anfang gemacht.
Noch konnte ich nicht alle CMD's schreiben. Manche lesen eigentlich mehr aus als schreiben, andere schreiben und lesen. Das muss noch überarbeitet werden.
Hoffentlich kannst du dies weiterverwenden.
Grüsse
Filou

[RolfD]

@Filou89
Die Idee mit den Strings per ID aufrufen ist erst mal bestechend gut - schauen wir uns aber mal die Praxis an:
+ Man könnte die Strings im EEPROM oder SPI Rom hinterlegen so das sie nicht im knappen Speicher rumliegen.
- Das ist aber letztlich nur für fixe Strings ohne Variablen sinnvoll.

Möchte ich - was wohl öfter statt findet - z.b. einen String wie "Bat:7,2V LDR_L: 500 LDR_R: 270" ausgeben,
wird schnell klar das es nicht lohnt davon irgendwas vor zu definieren oder man müsste Funktionen basteln die Werte in Platzhalter abgelegter Strings frickeln... erinnert mich irgendwie an printf oder?

Also geht es - für was auch immer - nur um Fixe Strings, ist die Idee gut. Für zusammengesetzte Strings bleibt nur "morsen".

Schön wäre letztlich nur eine Lösung wie es ähnlich mit der RS232 gäbe, in dem man einfach per printf/scanf o.ä. ein Datenstrom auf der I2C verarbeitet und der Slave dies direkt zum Display bringt.
Da sagte aber Dirk leider schon: "übers Ziel hinaus"

Mehrarbeit an einer Stelle führt meist zu weniger Arbeit an vielen anderen Stellen. Leider wird bei den Interfaces gepart, auf vorhandene Lösungen gesetzt und auf Lowlevel programmiert.. nur muss man sich dann nicht über Lowlevelfunktionalität als Ergebnis wundern...

So lässt sich jedenfalls kein vielseitiges, modulares Interface bauen auch wenn es für diese eine Anwendung vielleicht halbwechs funktioniert.

EEPROM bzw. SPI ROM Speicher eignet sich hervorragend um z.B. crc, SIN, COS und ATAN2 Tabellen abzulegen... und vielleicht auch den ein oder anderen String ... aber das ist kein Ersatz für standartisiertes Stringhandling auf seriellen Interfaces jeglicher Bauform. Und genau das Fehlen solcher Konzepte auf dem RP6 erzwingt leider Lowlevel-I2C-Registergefummel-Lösungen.
Natürlich kosten Alternativen auch Speicher aber man spart anderso wo auch - mit etwas Geschick sogar mehrfach. Der Witz ist... solche Lösungen gibts sogar schon - werden aber nicht verwendet.
Stellt euch doch bitte nur mal vor... was man anstellen müsste wenn man 2 RP6 hat.. beide mit RFM12 und M32, wo nun die M32 der RP6_1 Daten auf die Base oder Display vom RP6_2 schreiben/lesen will.... Ok weil die M256 grade "in" ist nehmen wir halt die, statt der RFM12... macht es auch nicht einfacher. Mal abgesehen das 2 RFM12 10 Euro und bissel Hirnschmalz kosten, 2 M256 das 24fache!!!

Ich bin mir aber sicher das Dirk und/oder Du da was funktionierendes zusammen bekommen. Ach wenn es nur eine Lösungs-Replikation der Base_Slave und keine Invention für Serielle Schnittstellen ist - was ja zugegebener Weise auch nicht eure erklärte Aufgabenstellung ist.

Gruß Rolf

[Dirk]

Ich hab mal hier: http://www.rn-wissen.de/index.php/RP...M32:_I2C-Slave
... einen RN-Wissen Artikel zum M32 I2C-Slave aufgemacht.

Mitschreiben, wer möchte ...

[Dirk]

Hier: http://www.rn-wissen.de/index.php/RP...lave#I2C-Slave
... gibt es jetzt eine V1.0 des M32 I2C-Slave.

Wenn man die in die M32 lädt, fangen alle 3 Skunden die 4 LEDs an, für 3 Sekunden zu blinken. Das ist die Timeout-Anzeige, die nach 3 Sek. auslöst, dann nach weiteren 3 Sek. Blinken einen "Soft-Reset" auslöst.

Dazu blinkt die Heartbeat-Anzeige (* in der rechten LCD-Ecke).

Würdet ihr das mal testen?
Den M32-Master (am einfachsten RP6Control_07_I2CMaster.c) müßtet ihr für die M256 etwas anpassen.
Die Zeile: if(!block && (PIND & EINT1))
wird in: if(!block && (PINJ & INT2_PI15)) // XBUS INT2 -> PJ6 (PCINT15)
... geändert, weil XBUS INT2 als Interrupt verwendet wird.

[Filou89]

Also wenn immer die äusseren und die inneren blinken, dann funktioniert das bei mir!
Nur für die als Kosmetik habe ich noch das LCD gelöscht, jedoch nicht über den I2C Bus.
Grüsse

[fabqu]

Hab mal ne Frage zur Befehlsstruktur unter Punkt 8:
Wollt ihr für #define CMD_SETIOS jeden I/O einzeln setzen?
Oder analog zu SETLEDs auch mehrere auf einmal?
Und wie ists, wenn manche als Input, andere als Output behandelt werden sollten?

Die Idee ist wirklich klasse!
Und der Einschub mit den abgespeicherten Strings finde ich ebenfalls sinnvoll. Man kann ja auf gewisse Ereignisse vordefinierte Strings z.B. ins LCD schreiben lassen etc.

Grüße