Woran könnte es liegen, dass die beiden folgenden Methoden (oder eine von ihnen) nicht korrekt funktionieren? Die I2C-Adresse des FRAM ist 0x50 (80 dezimal), ich schreibe testweise in die Speicherplätze 0-9 die Werte 10,11,12 ... 19, bekomme jedoch beim Lesen immer nur 255 zurück. "sw" ist eine Software-I2C, "softwire". Die funktioniert, das habe ich mit einem angepassten I2C-Scanner-Code getestet, der findet auch brav das FRAM auf 0x50.
Warum ich keine fertige Lib benutze? Keine von denen ist für SoftWire geeignet und soo viel Code ist es ja anscheinend auch nicht, wenn er denn funktionieren würde :-(
Wie heisst denn das FRAM?
Und an deiner Stelle würde ich mal etwas Fehlerabfrage machen, wie z.B. das ACK Bit. Bisher schreibst du da nur blind hin, ohne zu wissen, ob da überhaupt was im FRAM ankommt.
Bisher schreibst du da nur blind hin, ohne zu wissen, ob da
überhaupt was im FRAM ankommt.
Ja, das klingt sinnvoll, macht aber m.W. keine der Libs, die ich bisher untersucht habe. Viele arbeiten allerdings mit einem unübersichtlichen Wust an globalen Variablen, weshalb ich ziemlich lange gesucht habe
Wie heisst denn das FRAM?
Und an deiner Stelle würde ich mal etwas Fehlerabfrage machen, wie z.B.
das ACK Bit. Bisher schreibst du da nur blind hin, ohne zu wissen, ob da
überhaupt was im FRAM ankommt.
Hättest du ein Beispiel, wie ich das als Boolean-Rückgabewert in der Write-Methode verwenden könnte, statt "void"?
Hättest du ein Beispiel, wie ich das als Boolean-Rückgabewert in der
Write-Methode verwenden könnte, statt "void"?
Ich weiss ja nicht mal, mit was für einem MC du da rummachst. Wenns AVR wäre, verlasse ich mich da auf die bei mir sehr bewährte Library von PFleury.
Für STM32 habe ich hier was für die SPL, was auch Fehler meldet.
im Datenblatt steht aber 0xA0 für schreiben und 0xA1 für lesen (bei A2..A0 =0)
Dein Scanner gibt aber 7 Bit Adressen aus. Du must das R/W Bit selber dranpfriemeln.
also etwa so:
(0x50 << 1) | 0 beim schreiben
(0x50 << 1) | 1 beim lesen
Wenn ich mich richtig erinnere machst du den Fehler nicht zum ersten mal.
Deine Routinen haben im Lesebetrieb nichts mit der im DB geforderten Sequenz zu tun, und im Schreibbetrieb hast du halt die falsche Adresse. Würdest du auf ACK prüfen würdest du das sofort sehen.
Wenn ich mich richtig erinnere machst du den Fehler nicht zum ersten
mal.
Deine Routinen haben im Lesebetrieb nichts mit der im DB geforderten
Sequenz zu tun, und im Schreibbetrieb hast du halt die falsche Adresse.
Würdest du auf ACK prüfen würdest du das sofort sehen.
Wie ich schon schrieb, ich habe beide Methoden aus einer anderen, fertigen Lib entnommen, die sind genau so, wie eingangs beschrieben. Werde ich aber heute mal versuchen.
Wie ich schon schrieb, ich habe beide Methoden aus einer anderen,
fertigen Lib entnommen,
mach es einfach so wie es im DB beschrieben ist und es wird funktionieren.
Wie das wire Gedöns mit Ack und dem r/w Bit umgeht musst du dort nachschauen.
Übrigens EEprom Libs für 64k EEproms sollten auch funktionieren
Grund für den Einsatz FRAM ist die etwas zu langsame Ausgabe eines Bondruckers in einem Automaten-Prototypen (ca. 5s für ca. 12cm). Das hat leider genügt, dass mancher Kunde meinte, an dem Bon ziehen zu müssen, was das Druckmodul regelmäßig mit einer Fehlermeldung "Papierstau!" missinterpretiert und seinen Betrieb vorläufig einstellt.
Die schnelle Lösung für den im Einsatz befindlichen Prototyp: Die Druckdaten nicht pö-a-pö ausgeben, sondern erstmal (im FRAM) sammeln. Dann erfolgt am Ende die Bonausgabe "in einem Rutsch" schnell genug, so dass niemand mehr Zeit hat, an dem Bon zu zerren.
Aufgrund mechanischer Gegebenheiten wollte ich den FRAM zunächst nicht an die originalen Hardware-Pins für I2C des Arduino Mega anschließen, sondern SoftWire benutzen. Das wiederum klappt nicht auf die Schnelle mit den vorhandenen Libs (Adafruit u.a.), die sind alle auf Wire ausgelegt.
Nach 2 Tagen Zeitverschwendung habe ich nun doch eine kleine Adapterplatine gebaut, die sogar vom Kunden vor Ort einfach aufgesteckt werden kann. Die geänderte Firmware läuft nun mit der Adafruit-I2C-FRAM-Lib und FIFO-Druckerpuffer, die kann ich über Fernzugag einspielen.
Anbei mal eine kleine Lib für I2C-EEPROM, geht natürlich auch für FRAM.
Der Unterschied ist, beim EEPROM wird bis zu 10ms lang versucht, den Slave zu adressieren, beim FRAM klappt das immer sofort.
Eine eigene Frage?
Dieser Thread ist über 3 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
