www.mikrocontroller.net

Forum: Mikrocontroller und Elektronik EFSL Konfiguration LPC2148 ARM7

Autor: Gast (Gast)
Datum: 07.05.2008 15:51

Hallo!

Ich benutze die EFSL, um Daten auf einer SD-Karte zu speichern. Genauer
gesagt, es sollen kontinuierlich (1kHz) Daten geschrieben werden.
Ich verwende die "alte" Konfiguration (0.2.8) von Martin Thomas. Die
neueren funktionieren leider mit meiner SD-Karte nicht... Der
eingesetzte Mikrocontroller ist ein LPC2148. Als IDE setze ich das
Yagarto-Paket ein.

Es hat sich inzwischen folgendes Problem eingestellt: Ich schreibe brav
alle 1ms meine Daten. Leider passiert es ungefähr alle 26ms, dass dieser
Schreibvorgang etwas mehr als 3ms dauert und so ein doch recht enormer
Zeitverzug stattfindet. Ich gehe davon aus, dass es sich dabei um den
Zeitpunkt handelt, wenn der Puffer voll ist? Habe wie in der
ursprünglichen Konfiguration 3kB.
Um nun dennoch eine konstante Datenrate zu erreichen, habe ich versucht
den Puffer kleiner zu wählen, damit häufiger und kleinere Pakete
geschrieben werden. Leider klappt dies überhaupt nicht. Sobald ich die
Puffer-Größe ändere, werden keine Daten mehr geschrieben, bzw. nicht mal
mehr Dateien angelegt. Wenn ich die Größe auf 1 x 512 byte einstelle
wird sogar die SD-Karte nicht mehr erkannt.
Als alternative Notlösung habe ich versucht, wenigstens die Zeit
weiterlaufen zu lassen. Leider ist dies daran gescheitert, dass eine
Unterbrechung der Schreibroutine (nested interrupts) generell mit einem
Absturz belohnt wird.

Ich habe nun die folgende Fragen:
Wie kann ich die Größe des Puffers ändern und bringt dies überhaupt
etwas in meinem Fall?
Falls ich nicht richtig liege mit der "Puffer-ist-voll-Theorie", woran
liegt es dann?
Warum ist es nicht möglich verschachtelte Interrupts zu ermöglichen,
wenn EFSL-Funktionen genutzt werden?

Würde mich sehr freuen, wenn der Ein oder Andere ein paar Tipps,
Denkanstöße oder Ratschläge für mich übrig hat!

Grüße
Jansus
Autor: holger (Gast)
Datum: 07.05.2008 18:34

>Ich habe nun die folgende Fragen:
>Wie kann ich die Größe des Puffers ändern und bringt dies überhaupt
>etwas in meinem Fall?

Vermutlich bringt das nichts. Mach einfach Doublebuffering.
In einen Puffer sammelst du die Daten (per Int ?) und der
andere volle wird auf die Karte geschrieben (besser ohne Int).
Die Puffer müssen dann so groß sein das du mehr als 3ms überbrücken
kannst.

>Falls ich nicht richtig liege mit der "Puffer-ist-voll-Theorie", woran
>liegt es dann?

Da mussten wohl neue Clusternummern in der FAT eingetragen werden.
Wenn du Pech hast müssen dafür zusätzlich zum Datensektor noch
bis zu zwei FAT Sektoren gelesen und geschrieben werden.

>Warum ist es nicht möglich verschachtelte Interrupts zu ermöglichen,
>wenn EFSL-Funktionen genutzt werden?

Keine Ahnung :( FAT Routinen würde ich nicht in Interrupts legen.



PS: EFSL ist schnarchlangsam.

Versuchs vieleicht mal mit ELM-CHAN

http://elm-chan.org/fsw/ff/00index_e.html

Beispielcode für ARM liegt da aber noch nicht rum.

Oder mit meinen Routinen für LPC2136

http://www.holger-klabunde.de/arm/arm.htm

Kommt aber drauf an was du so an Funktionalität brauchst.
Es gibt da doch erhebliche Unterschiede zwischen den Programmen.

Alle drei habe ich bisher nur auf AVR vergleichen können
EFSL    lahm
ELM-CHAN  schnell
Meins    etwas schneller ;)


Auf ARM LPC2136
EFSL  geht so
Meins  Faktor 2

Ich werd die Tage mal versuchen ELM-CHAN auf dem LPC
zum laufen zu bringen.
Autor: Jansus (Gast)
Datum: 07.05.2008 22:00

Vielen Dank für Deine Antworten!

Hatte mich ursprünglich mal für die EFSL entschieden, da es mir damit am
einfachsten erschien schnelle Ergebnisse zu erzielen ohne mich übermäßig
mit der Theorie dahinter befassen zu müssen. Das hat sich wohl nun
gerächt...

Ein anderer meiner Ansätze war die SSP etwas flotter zu betreiben.
Leider ließ sich da nichts mit machen. 15MHz ging und bei mehr dann
leider nicht mehr (hatte drei verschiedene Karten getestet). Laut
Spezifikation (oder wo auch immer ich's gelesen habe) gehen manche
Karten bis 30MHz. Hast Du da schon Erfahrungen mit gemacht?

Ich habe auch gerade mal Deinen Code überflogen und denke, dass ich
morgen mal versuchen werde ihn in mein Projekt einzubinden. Ich hoffe
mal, dass Faktor 2 was bei meinem Problem bringt.

Kannst Du mir Deinen Vorschlag mit dem Doublebuffering nochmal erklären?
Befürchte, ich hab's nicht so ganz kapiert. Vielleicht passt es aber
auch nicht zu dem was ich bisher habe?
Bisher schaut es bei mir nämlich so aus: Ich habe einen Timer laufen,
der mir die "Systemzeit" generiert. Je nach "Uhrzeit" lese ich den
AD-Wandler aus und schreibe meine Messdaten auf die SD-Karte. Wenn ich
für diesen Schreibvorgang nested interrupts anschalte, gibt's nen Crash,
wenn nicht taucht dieses 3ms-Loch alle 26ms auf. Ich muss also dafür
sorgen, dass meine Schreibroutine in dieses Timer-Fenster passt. Oder
besser gesagt, um den Faktor 3 schneller wird.


Grüße
Jansus
Autor: Jansus (Gast)
Datum: 07.05.2008 22:01

...ich vergaß. An Funktionalität brauche ich fast nichts. Ich möchte mir
nur ein Text-File anlegen, in das meine Messdaten reingeschrieben
werden.
Autor: holger (Gast)
Datum: 07.05.2008 22:19

>Ein anderer meiner Ansätze war die SSP etwas flotter zu betreiben.

Eine langsame Karte bleibt eine langsame
Karte. Da kann man noch so viel am SPI Speed rumdrehen.
Es bringt leider nichts.

>Oder besser gesagt, um den Faktor 3 schneller wird.

Du schreibst Textdateien. Vergiss das und schreib Binärdateien.
Ein uint16 in ASCII braucht 5 Bytes. Bei Binär nur zwei Bytes.
Da hast du schon mal Faktor 2.5. Rechne die Werte aus der Datei
besser am PC in ASCII um.

Dann kannst du vermutlich auch bei EFSL bleiben.

Antwort schreiben

Die Angabe einer Email-Adresse ist freiwillig. Wenn Sie automatisch per Email über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Suchfunktion und Betreffsuche benutzen - vielleicht gibt es schon einen ähnlichen Beitrag
  • Aussagekräftigen Betreff wählen
  • Im Betreff angeben um welchen Controllertyp es geht (AVR, PIC, ...)
  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang
  • JPEG-Dateien (.jpg) nur für Fotos und Scans verwenden
  • Schaltpläne, Screenshots usw. als PNG oder GIF anhängen

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [pre]vorformatierter Text (z.B. Code in anderen Sprachen)[/pre]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel






webmaster@mikrocontroller.netImpressumWerbung auf Mikrocontroller.net