@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
Zitieren
Lesezeichen