Hallo PicNick,

ja, das mit den IDs für die Funktionen des Slave verstehe ich.
Aber wie ist das auf der Slave-Ebene mit den einzelnen Funktionen, die ein,- sagen wir genormtes-, Programm haben könnte.
Beispiel:
Dein RNSI2C kann ja nicht nur die 10 Servos ansteuern, sondern auch noch per I2C-Befehl seine Adresse geändert bekommen.
Bei meinem RNIRI2C gibt es 3 Funktionen: IR-Empfangspuffer lesen, ein Kommando+Adresse senden und I2C-Adresse ändern. Wie kann oder sollte man das "normieren"? Es macht ja Sinn, die zusätzlichen Funktionen transparent zu machen!

Mein aktuelles Projekt ist z.B. ein DCF77-Decoder mit I2C-Ausgabe für den 2313,- das klappt schon ganz gut und ist in der Testphase.

Ich würde also in eurem Projekt zur Zeit folgende IDs beantragen:

ID IR-RC5: Empfangspuffer lesen
ID IR-RC5: Adresse+Kommando senden
ID DCF77: Zeit einlesen
ID DCF77: Uhrzeit Softclock stellen

Was bleibt als Frage:
Wer "weiss" auf den höheren Ebenen eigentlich, welche Funktionen es auf Ebene des 2313-Slaves gibt und wie sie ausgeführt werden?
Bei deinem RNSI2C ist das z.B. CMD (1) | srvNr | srvpos, bei meinem IR-Slave ist das CMD (0) | RC5-Adr | RC5-Cmd für das Senden, dazu kommt noch das Empfangen, da auch evtl. mit unterschiedlicher Größe des Empfangspuffers.
Ähnlich wird es auch beim DCF77-Slave aussehen. Da wird dann noch dazu kommen, dass man auch die "Betriebsart" des DCF77-Decoders per I2C-Befehl ändern kann. Dafür würde ich dann sozusagen noch eine weitere ...
ID DCF77: Betriebsart (Parameter) einstellen
... brauchen.
Für fast jeden Slave bräuchte man auch eine ID fürs Ändern der eigenen Adresse:
ID IR-RC5: I2C-Adresse ändern
ID DCF77: I2C-Adresse ändern

Ich weiss nicht, ob ich klar gemacht habe, was ich meine.
Macht es Sinn, da eine Art Standard zu beschreiben? Z.B. könnte man bestimmte Funktionen des Slave immer auf dieselbe Weise durchführen:
-> Hauptsendefunktion: START | 0 | n Bytes_to_send | STOP
-> Parameter ändern: START | 1 | n Parameter | STOP
-> I2C-Adresse ändern: START | 2 | neue Adresse | STOP

Gruß Dirk