Forum: Mikrocontroller und Digitale Elektronik FRAM von Ramtron mit einem LPC2131 treiben


von campus (Gast)


Lesenswert?

Hi,

ich moechte ein FRAM von Ramtron mit einem LPC2131 treiben, also Daten
hineinschreiben und  herauslesen. Nun will ich erfahren, wie die
Testroutine aussieht. Wenn irgendwas schiefgehen wuerde, wie erkennt
man, ob das Problem am Schreiben oder am Lesen liegen wuerde?

MfG
Campus

von Vikinger (Gast)


Lesenswert?

Ich fürchte ein gutes Oszi ist dafür das einzigst geeignete Mittel.

Vikinger

von Peter D. (peda)


Lesenswert?

"Wenn irgendwas schiefgehen wuerde, wie erkennt
man, ob das Problem am Schreiben oder am Lesen liegen wuerde?"


Du liest mehrmals. Wenn es dabei Unterschiede gibt, ist es ein
Lesefehler.

Du liest nach jedem Schreiben zurück. Wenn das Gelesene ungleich ist,
ist es ein Schreibfehler.


Viel häufiger sind aber Ein- und Ausschaltfehler (CPU oder FRAM spinnt
bei Unterspannung). Diese lassen sich nur durch eine CRC über einen
Datenblock oder ähnliches erkennen.
Ein Supervisor-IC oder Brown-Out ist eigentlich bei jeder Art nicht
flüchtiger Speicher Pflicht.


Peter

von campus (Gast)


Lesenswert?

muss das ein Digitaloszi sein, um die Daten zu speichern?

MfG

von Vikinger (Gast)


Lesenswert?

Hallo,

> muss das ein Digitaloszi sein, um die Daten zu speichern?

könnte sich als Vorteilhaft erweisen.

Welche Schnittstelle möchtest Du den eigentlich verwenden?

Grüße
Erik

von campus (Gast)


Lesenswert?

SPI

Ciao

von Vikinger (Gast)


Lesenswert?

Hallo campus,

ich möchte selber einen FM25L256 am LPC2106 betreiben (Muster sind
schon da so das ich nach Weinachten damit anfangen werde). Leider hat
der LPC2106 noch ne alte SPI Schnittstelle so das Du warscheinlich
nichts mit meinen Sourcen anfangen könntest. Der LPC2131 hat, glaube
ich zumindest, schon das neuere SSP-Device welches der LPC2106 erst,
laut Robert Teufel, Q2/2006 bekommen soll.

Für den Anfang werde ich erst mal das Status-Register vom FRAM
beschreiben und zurück lesen. Das sind nur 2 Bytes und sollte auch noch
auf ein normales Oszi draufpassen (ohne das man Speicher zum scrollen
braucht). Ich versuche dann die beiden Bits BP1 und BP0 in allen
Varianten zu setzen und zurückzulesen, wenn das klappt ist IMHO die
erste Hälfte erledigt. Danach werde ich mich dann dem Lesen und
Schreiben von Daten widmen.

Wenn mein "Treiber" fertig ist soll er in Blöcken mit Prüfsummen
arbeiten und immer ein Read-Back nach jedem Schreibvorgang
durchführen. Ansonsten kann ich nur peter dannegger zustimmen und
verwende in der fertigen Schaltung einen externen
Under-Voltage-Detektor (der LPC2106 hat leider keinen).


> Du liest mehrmals. Wenn es dabei Unterschiede gibt,
> ist es ein Lesefehler.

Dieser Aussage kann ich nicht ganz zustimmen, es könnte auch immer der
selbe (Programmier-)Fehler sein.


Grüße
Erik the Vikinger

von Manfred Glahe (Gast)


Lesenswert?

Ich benutze FRAM's von Ramtron seit vielen Jahren und kann dir
versichern, daß sie völlig unproblematisch sind. Bei mir ist jedenfalls
noch nie eines aufgetreten, obwohl ich die SetupDaten darin speichere
und die Ubdates über Rs232 vom PC hole.

Manfred Glahe

von Vikinger (Gast)


Lesenswert?

@Manfed
> Ich benutze FRAM's von Ramtron seit vielen Jahren und
> kann dir versichern, daß sie völlig unproblematisch sind.

Das glaube ich Dir gerne, ich gehe auch nicht davon aus das die FRAMs
sich nicht an die Spezifikation halten. Ich denke eher das es nicht
ganz ohne Probleme (bzw. nicht beim ersten Versuch) klappen wird auch
den LPC21xx dazu überreden mit dem FRAM zusammen zu arbeiten.

> Bei mir ist jedenfalls noch nie eines aufgetreten, ...

Was "eines" ?? Ein Problem? Wie gesagt, ich glaube nicht das der FRAM
Probleme verursachen wird.

Grüße
Erik

von Manfred Glahe (Gast)


Lesenswert?

Autor: Vikinger
Datum: 03.12.2005 10:57

Ich fürchte ein gutes Oszi ist dafür das einzigst geeignete Mittel.

Vikinger
___________________-

Nicht unbedingt, eine Programmschleife ist gut geeignet, die gesendeten
Daten der SPI auch mit einem analogen _Scope testen zu können.

MfG Manfred Glahe

von Vikinger (Gast)


Lesenswert?

@Manfred

Ich muss ehrlich zugeben nur ganz kurz mit einem analogem Oszi
gearbeitet zu haben. Ich wollte I2C debuggen. Als mein damaliger Chef,
der mit diesem Oszi mehr Erfahrung hatte, mir helfen wollte kam recht
schnell die Entscheidung "ein neuer Ossi muss her". Es kam dann eins
mit 4 Kanälen und 1GSample/s von Tektronix. Ich will hier keine Werbung
betreiben aber mit dem Oszi hab ich ein gutes Jahr gearbeitet und wurde
nie enttäuscht. Okay das Teil hat damals, Ende 2002, ca. 2500 Euros
gekostet.
Bei meinem derzeitigem Arbeitgeber steht ein HP 16500B, mit
2x1GSample/s (16532A) und 4*16*500MHz-Logic-Analyzer (16555A) drin, auf
meinem Tisch. Da muss ich mich aber erst richtig einarbeiten. Was es
gekostet hat weis ich nicht aber es klebt eine Inventarnummer von
Grundig drauf, mein derzeitiger Chef hat in diesem Frühjahr etwas
"Leichenflederei" betrieben. Als das Teil neu war hat es mehr als ein
kleiner Golf gekostet.

Fazit: ich bin in diesem Zusammenhang etwas verwöhnt. Muss aber auch
dazu sagen das gutes Werkzeug durch fast nichts zu ersetzen ist.

Für mich privat überlege ich schon seit Jahren wie ich zu etwas
"Ordentlichem" kommen könnte, allzu teuer darf es jedenfalls nicht
werden schließlich will ich mir keinen Elektronikpark im Werte eines
Mittelklasse-BMW zulegen.

Grüße
Erik the Vikinger

von Peter Dannegger (Gast)


Lesenswert?

Wozu dafür überhaupt einen Oszi bemühen.

Man liest sich einfach das Datenblatt des FRAM durch, auf welcher
Flanke was eingelesen wird und welche Kommandos abzuschicken sind und
dann das Datenblatt des LPC, wie man dessen SPI einstellt und fertig.



Peter

von Vikinger (Gast)


Lesenswert?

> Man liest sich einfach das Datenblatt ...

Ach nee, und wenns trotzdem nicht funktioniert? Wie bekomme ich dann
raus wo die Ursache liegt? Wenn ich den externen Datenstrom, zwischen
Protz und FRAM, analysieren kann (egal mit was) hab ich eine gute
Chance zu erkennen was falsch läuft. Ohne dem wirds schwierig.

Wenn Du andere Methoden kennst dann teile uns die doch bitte mit.

Grüße
Erik

von Peter Dannegger (Gast)


Lesenswert?

@Erik,

ich gehe erstmal nicht davon aus, daß es schief laufen kann.

Und wenn ich einen neuen MC nehme, dann mache ich das SPI erstmal zu
Fuß, also Bit setzen, löschen, testen, Byte schieben als Schleife in
Software.

SPI hat ja kein unteres Limit, man kann es also in Ruhe mit ner Taste
durchsteppen und mit LEDs angucken, was passiert.

Und wenn das läuft, probiert man das Hardware-SPI. Bzw. oft ist der
Tempogewinn so minimal, daß ich es gleich bei der Software-SPI
belasse.


Ich habe mit SPI noch nie Probleme gehabt. Eigentlich muß man doch nur
aufpassen, daß man die richtigen Flanken auswählt.


Peter

von Peter Dannegger (Gast)


Lesenswert?

P.S.:

Man sollte nicht immer gleich alles so verbissen sehen.

Wer grundsätzliche Probleme hat, die Wirkungsweise des SPI zu
verstehen, der nehme erstmal einen 74LS595 mit 8 LEDs und bringe die
zum Leuchten.
Und vielleicht noch einen 74LS165, um das Einlesen zu üben.

Danach sollten auch komplexere SPI-Devices beherrschbar sein.

Denn ohne zu wissen, wonach man sucht, nützt auch das beste Oszi
nichts.


Peter

von campus (Gast)


Lesenswert?

Soll ein Interrupt des SPI hier beim Lesen und Schreiben eingesetzt
werden? Was heisst die alte SPI-Schnittstelle? Bei LPC2131 gibt es SPI-
und SSP-Schnittstellen. Ich nutze jedoch die SPI-Schnittstelle, ist es
in Ordnung?

MfG
Campus

von Vikinger (Gast)


Lesenswert?

> Man sollte nicht immer gleich alles so verbissen sehen.
Ja Du hast recht.
"Wenn nur einen Hammer hat der sieht überall nur Nägel."

> Bei LPC2131 gibt es SPI- und SSP-Schnittstellen.
Das wuste ich nicht, ich hab nicht ins UM gesehen.
Laut Aussage von Robert Teufel ist die SSP deutlich besser als die
SPI-Schnittstelle. Ich hab das im UM vom neuen LPC2103 mit dem UM vom
alten LPC2106 verglichen und kann Robert nur zustimmen.
Wenn Dir eine hohe FRAM-Performance (und auch eine geringe
CPU-Belastung) wichtig ist dann benutze lieber die SSP-Schnittstelle.
Die hat nen richtigen FIFO in beide Richtungen so das Du einen
kompletten Lesebefehl, natürlich nur mit wenigen zu lesenden Bytes, auf
ein mal in die SSP-Unit geben kannst und dann einfach Interruptgesteuert
die Antwort abholst. Schreiben wird auch nicht schwieriger werden. Bei
der SPI-Schnittstelle (zumindest der in den LPC210x) brauchst Du für
jedes Byte einen Interrupt und kannst die Leitungsgeschwindigkeit nicht
richtig ausnutzen. Da könnte es fast sinnvoll sein ganz auf Interrupts
zu verzichten, sind ja schließlich knapp 2 MBytes/s bei 15MBit/s
Leitungsgeschwindigkeit.

Grüße
Erik

von Manfred Glahe (Gast)


Lesenswert?

> Man sollte nicht immer gleich alles so verbissen sehen.
Ja Du hast recht.
"Wenn nur einen Hammer hat der sieht überall nur Nägel."
_____________________________

Ganz so einfach ist das nun auch wieder nicht. Handelt es sich z.B. um
die erste Musterschaltung, dann können noch Probleme mit anderen
Leiterbahnen oder IC's, welche zusätzlich an einem SpiAusgang hängen,
auftreten und unter Umständen sogar NUR bei höheren Arbeitsfrequenzen
auftreten. Hier hilft ein langsames Durchsteppen überhaupt nicht mehr,
weil z.B. kapazitive Fehllasten nur mit einem Oszi aufzuspüren sind.

Ein gutes Oszi ist z.B. das MixedSignal HP54645D, welches ich benutze.
Damit dokumentiere ich gleichzeitig Kurvenformen GUT/SCHLECHT und
bringe sie zur Deckung. So kann ich auch über hohe Schreibdichten eine
Abweichung vom Sollzustand schell feststellen.

www.elektronik-kompendium.de/public/glahe/pictreg1.jpghe/pictreg1.jpg

MfG Manfred Glahe

von Manfred Glahe (Gast)


Lesenswert?


von Vikinger (Gast)


Lesenswert?

Hallo,

Der Spruch sollte natürlich heißen:
"Wer nur einen Hammer hat der sieht überall nur Nägel."

@Manfred
Prinzipiel hast Du recht, knifflige Probleme kann man oft nur mit gutem
Werkzeug lösen. Ich glaube was Peter sagen wollte ist das man nicht
immer gleich großes Gerät auffahren muss, vieles läst sich nach etwas
denken auch ganz simpel analysieren.

Ich hab mal ein PCI-Device in einem FPGA entwickelt und alles was ich
hatte waren 2 7Segement-Anzeigen auf dem FPGA-PCI-Development-Board,
meine SW unter purem DOS und meine Finger. Mit letzteren habe ich
geprüft ob der FPGA und der PCI-Kontroller vom Mainboard gegeneinander
trieben, die haben sich dann beide merklich erwärmt. Mit nem richtigen
Logic-Analyzer hätte ich es warscheinlich einfacher gehabt (wenn man
mal von der Einarbeitung in den Analyzer absieht), aber am meisten hat
mir damals eine richtig gute PCI-Docu mit allen Buszyklen (nicht nur
Standart Lesen + Schreiben) gefehlt. FPGA und Mainboard arbeiten bis
heute problemlos zusammen.

Zum SPI-FRAM denke ich auch das es mit hoher Wahrscheinlichkeit auf
Anhieb (oder zumindest mit wenig Try&Error) klappt. Wenn doch Probleme
kommen werde ich mir das Oszi schnappen und nachsehen ob 'Ist' mit
'Soll' übereinstimmen, schließlich sind in der FRAM-Docu alle
relevanten Diagramme drin.

Grüße
Erik

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.