FRAM

Eigene Bibliotheken oder ports
Thomas Barth
Administrator
Beiträge: 90
Registriert: So 5. Apr 2015, 21:46
Wohnort: Frankfurt/M
Kontaktdaten:

FRAM

Beitrag von Thomas Barth » Mi 23. Sep 2015, 19:32

Hallo liebe PSoC Freunde.

Habe angefangen für den FRAM des PSoC4 BLE Pioneer Kit einen kleinen Treiber zu schreiben:
https://github.com/ThomasBarth/PSoC_I2C ... master/src

Wenn ihr mitmachen wollt, Kritik üben wollt, Vorschläge habt oder mir Tipps zu Doxygen geben könnt würde ich mich freuen.

Code: Alles auswählen

P_M_DERIVE(T_ALG.E_BH) := UC_16S_EN_16NS (TDB.T_ENTIER_16S
                                   ((1.0/C_M_LSB_BH) *
                                   G_M_INFO_DERIVE(T_ALG.E_BH)))

Reiner W.
Beiträge: 112
Registriert: Di 7. Apr 2015, 11:43

Re: FRAM

Beitrag von Reiner W. » Di 3. Nov 2015, 10:57

Hallo Thomas,

mal ne frage zu den FRAMs. Leider habe ich bisher noch nicht damit gearbeitet, deshalb will ich für ein Projekt einiges abklären.
Ich möchte gern für eine Fräse die Absolutkoordinaten über Optical Encoder an den Schrittmotoren permanent erfassen.
Verfahrensweise:
- Erstmalige NULL Setzung mit Referanzschalter oder manuell von Hand
- Danach soll die XYZ Position permanent im FRam mitgespeichert werden und zwar per Schritt. Der Zähler müßte dann ja im FRAM liegen und mit jedem Schritt inc/dec werden. Die Schrittfrequenz liegt im unteren kHz Bereich.

Meinst du, dass das sowohl von den read/write-cycles als auch von der Transfergeschwindigkeit klappt. Sollte eigentlich I2C reichen? Sollte mit einem PSoC4 oder 4M laufen.

Klar kann ichs probieren;-) Ich versuche aber vorab zu klären, ob der Weg gangbar sein könnte.
Reiner W.

RA1981
Beiträge: 38
Registriert: Do 23. Apr 2015, 07:54

Re: FRAM

Beitrag von RA1981 » Mi 4. Nov 2015, 00:06

Hi Reiner,

ich bin zwar nicht Thomas, aber ich antworte frech mal trotzdem =)

Zu meinem Verständnis: Die Koordinaten wären alle relativ, ist das richtig? Das heisst also, ein relativer Nullpunkt wird durch das Nullen gesetzt, die nachfolgenden Koordinaten beziehen sich auf diesen Nullpunkt. Ein Verschieben des (relativen) Nullpunkts verschiebt also das "Fräsprogramm" bzw die abzufahrenden Wege, aber nicht die Position der einzelnen Punkte zueinander. Und die Berechnung der Punkte dazwischen erfolgt live, also da muss nix zwischengespeichert werden?

Falls ja, dann geht es ja wirklich nur drum, Koordinatensätze, also ein Fräsprogramm abzuspeichern. Und das geht mit dem FRAM sicher, und mit einem "normalen" EEPROM auch (ich vermute das FRAM willst du nehmen, weil's eh schon auf dem Kit ist). Warum ich das für sicher halte ist, weil du bereits bei einem normalen EEPROM die Daten ja nur abspeichern und lesen musst - Speichern nur einmal, lesen mehrmals, aber es kommt hier nach meinem Verständis nicht auf die Geschwindigkeit an - das sind je nachdem (EEPROM/FRAM) Werte im Millisekundenbereich für's schreiben und für's Lesen noch viel weniger - das soll dich nun nicht davon abhalten einen Blick ins Datenblatt zu werfen und die Zeitwerte rauszufieseln. Aber es tut nicht weh, wenn der Fräskopf ein paar ms über einem Punkt verharrt, um abzuspeichern, und während er sich zum nächsten Punkt bewegt kann man ggf schon das folgende Koordinatenpaar auslesen.

Stell die Gegenfrage anhand der zu erwartenden Datenmengen: Welche Zeiten sind wo (Bewegung/Verharren bzw Lesen/Speichern) gefordert bzw vertretbar und stelle sie gegeneinander. M.E. tun ein paar ms beim Verharren und Speichern nicht weh (weil du länger als ein paar ms brauchst, um die Taste zu drücken, die an diesem Punkt speichert).

Wenn es nicht so ist, dass die zwischen zwei Punkten liegenden Koordinaten live berechnet werden, sondern ebenfalls gespeichert werden müssen, dann hast du zwar erhöhten Datenverbrauch und damit ist auch mehr Zeit nötig, um auszulesen und zu speichern - es hindert dich aber niemand daran, die Daten aus dem FRAM in einen Buffer im Controller zu holen und erst dann zu verarbeiten.

Wie angedeutet sind mir die Anforderungen noch nicht ganz klar, deswegen kann ich's auch nur grob umreissen, aber ich bin generell der Meinung, dass schon ein EEPROM genug Speed hätte - beim FRAM hast du die ms für's Schreiben nicht mal nötig (weil eben FRAM und kein EEPROM).

Hoffe das war nun nicht zu verwirrend :D

Gruß Ralf

Reiner W.
Beiträge: 112
Registriert: Di 7. Apr 2015, 11:43

Re: FRAM

Beitrag von Reiner W. » Mi 4. Nov 2015, 01:26

Hi Ralf,
Zu meinem Verständnis: Die Koordinaten wären alle relativ, ist das richtig? Das heisst also, ein relativer Nullpunkt wird durch das Nullen gesetzt, die nachfolgenden Koordinaten beziehen sich auf diesen Nullpunkt. Ein Verschieben des (relativen) Nullpunkts verschiebt also das "Fräsprogramm" bzw die abzufahrenden Wege, aber nicht die Position der einzelnen Punkte zueinander. Und die Berechnung der Punkte dazwischen erfolgt live, also da muss nix zwischengespeichert werden?
Nicht ganz;-) Vielmehr ist der Encoder mit der Achse starr gekoppelt. Ich brauche pro Achse nur einen Zählerwert. Die Achse wird erstmalig auf den Maschinennullpunkt gefahren (Referenzfahrt) dann wird die Achse genullt(Zähler im FRam auf Null). Von jetzt an zählt der Zähler absolute Maschinenkoordinaten, weil der Enkoder ja mechanisch mit der Achse gekoppelt ist.
Vorausgesetzt natürlich, die Enkoderauswertung arbeitet auch dann weiter, wenn die Maschine abgeschaltet ist, deswegen soll da ein kleiner Akku rein.
Wenn dafür gesorgt wird, dass die Motoren im ausgeschalten Zustand nicht bewegt werden können, brauche man vlt. auch keinen Akkubetrieb.
Es wird also kein Fräsprogramm mitgespeichert, sondern ich brauche lediglich pro Achse einen 32bit Int Zähler.
weil du bereits bei einem normalen EEPROM die Daten ja nur abspeichern und lesen musst
Der EEProm wäre wahrscheinlich wegen der Menge an Schreib-/Lesezyklen schnell am Ende, da die Zähler ja im kHz Bereich geschrieben werden müssen.

Die Anforderung ist also:
- 3*32bit RAM
- nichtflüchtig
- max. Schreibgeschwindigkeit ca. 8kHz (je nach Encoderauflösung)
- max. read/write cycles sagen wir:
400imp/mm * 1000mm/min * 60 * 5 * 365 (also mal so 5h pro Tag ein Jahr lang - so als worst case)
Das sind dann max. 43.800.000.000 write cyclen. Also eigentlich kein Problem für die FRam mit ca. 100 trillion cycle endurance (beim Flash - EEPROM sind es 10K erase/write cycles)

Eigentlich sollte das mit den FRam kein Problem sein, oder übersehe ich was?

Warum das Ganze? Wenn man absolute Koordinaten hat, spart man sich beim Einschalten der Fräse jeweils die Referenzfahrt und kann dennoch auf fixe Maschinenkoordinaten für Werkzeugwechsel etc. zugreifen.
Man könnte auch Glasmessstäbe mit absoluten Koordinaten einsetzen, aber die sind bei der geforderten Länge von ca. 1m sauteuer.
Und da als Steppermotore Hybrid - Servos eingesetzt werden sollen, fällt der Encoder schon mal mit ab;-) Gibt übrigens auch Servos, die die absoluten Koordinaten schon von Haus aus in der Elektronik verwalten, aber da sind wir wieder beim Preis;-)
Reiner W.

RA1981
Beiträge: 38
Registriert: Do 23. Apr 2015, 07:54

Re: FRAM

Beitrag von RA1981 » Mi 4. Nov 2015, 02:21

Ah, okay. Jetzt klingelt es schon lauter :D

In dem Fall kannst es wie folgt berechnen:

Max. Schreib-/Leserate in Bytes/s ist ja bekannt, sowohl die nötige (von der Maschine) als auch die mögliche (vom FRAM). Die max. Geschwindigkeit der Schnittstelle auch (PSoC und FRAM). Du ermittelst damit wie lange du pro Byte oder Byteblock brauchst. Wenn das nötige locker in das mögliche passt, sollte es kein Problem geben, speziell dann nicht wenn mit (sauberen) Interrupts gearbeitet wird.

Wie kommst du auf 8kHz?

1000mm/min = ~37mm/s -> * 400imp/mm = ~14800imp/s * 3Achsen -> 44400 imp/s (worst case)
Oder verstehe ich die Angaben noch falsch? Falls nicht, dann scheinen mir die 8kHz zu wenig, und es kommt noch hinzu dass du pro Puls je einen Lese-/Schreibzyklus hast, also ~90k Zyklen (außer du liest nur einmal und führst den Wert mit und schreibst ihn dann nur immer). Das heißt dass du vermutlich mit mindestens (4Byte Daten + 4Byte geschätzter Overhead) * 90k = ~720kByte/s feuern musst.

Falls ich nun Uhrzeitbedingt n Blackout hab - sorry :D ich schau es mir dann morgen nochmal an...

Ralf

Reiner W.
Beiträge: 112
Registriert: Di 7. Apr 2015, 11:43

Re: FRAM

Beitrag von Reiner W. » Mi 4. Nov 2015, 02:50

1000mm/min = ~37mm/s -> * 400imp/mm = ~14800imp/s * 3Achsen -> 44400 imp/s (worst case)
Hast recht. Muss da mal ein genaues Konzept machen. Da die FRam seriell 3,4MHz (I2C) können bekomme ich das vlt. hin.
Reiner W.

RA1981
Beiträge: 38
Registriert: Do 23. Apr 2015, 07:54

Re: FRAM

Beitrag von RA1981 » Mi 4. Nov 2015, 09:44

Okay, dann hab ich zumindest das richtig verstanden :D

Bei 3,4 MHz wären das dann etwa 400kByte pro Sekunde, und da wird's dann schon knapp, wenn meine andere Berechnung stimmt, weil das ja dann nicht die reine Schreibrate wäre, sondern auch der Overhead mit drin ist.

Ralf

Reiner W.
Beiträge: 112
Registriert: Di 7. Apr 2015, 11:43

Re: FRAM

Beitrag von Reiner W. » Mi 4. Nov 2015, 10:51

Bei 3,4 MHz wären das dann etwa 400kByte pro Sekunde, und da wird's dann schon knapp,
Ja, die Dinger gibt es ja auch als SPI oder parallel. Da sind dann weit höhere Übertragungsraten drin.
Aber ich bin da noch ganz am Anfang. Sozusagen in der Konzeptphase und da stellen sich noch andere Überlegungen:
- eigener FRAM pro Achse
- kumulieren der Impulse auf Byte/Blockgröße und erst dann schreiben (schreibe wenn block voll oder x-ms nichts mehr gekommen ist)
- Batteriepufferung oder nicht
usw.
Und dann braucht es noch eine Schnittstelle um die Koordinaten in die Steuer-Software beim Start zu übernehmen.
Da meine Servos wohl dieses Jahr nicht mehr kommen, kann ich das Ganze etwas vertagen. Da habe ich also Zeit, mich mal etwas mit den FRAMs zu befassen.
Reiner W.

RA1981
Beiträge: 38
Registriert: Do 23. Apr 2015, 07:54

Re: FRAM

Beitrag von RA1981 » Mi 4. Nov 2015, 12:16

Da hast du recht, wenn noch ein bisschen Zeit bleibt ist die sinnvoll investiert, wenn man sich dann vorher alles nochmal genau anschaut.

Ralf

Thomas Barth
Administrator
Beiträge: 90
Registriert: So 5. Apr 2015, 21:46
Wohnort: Frankfurt/M
Kontaktdaten:

Re: FRAM

Beitrag von Thomas Barth » Do 12. Nov 2015, 19:37

Zur Geschwindigkeit:
FRAM arbeitet Taktsynchron zum Bus. Die maximale Bitrate z.B. am I²C definiert damit auch die schreib/lese-Geschwindigkeit.
Die Teile haben intern einen Adresszähler der automatisch mitläuft, du kannst also theoretisch den ganzen Speicher in einem Zug füllen und als Ringbuffer benutzen. Probleme bekommst du nur wenn das Gerät unerwartet ausgeschaltet wird. Soweit ich es verstanden habe ist der Zustand des Adresszählers flüchtig (kann man ja auch mal ausprobieren).
Wenn du immer die selben 2x32Bit schreiben möchtetst (also 2x4x8Bit z.B. immer ab adr: 0x0) dann musst du noch 2x8Bit Overhead für das Setzen des Adresszähler dazurechnen.

Code: Alles auswählen

P_M_DERIVE(T_ALG.E_BH) := UC_16S_EN_16NS (TDB.T_ENTIER_16S
                                   ((1.0/C_M_LSB_BH) *
                                   G_M_INFO_DERIVE(T_ALG.E_BH)))

Antworten