Hallo zusammen, ich habe ein Problem und da bräuchte ich ein bisschen Hilfe. Hintergrund: Ich will GRBL mit einem FPGA beschleunigen. Dazu habe ich ein Board gebaut, wo der µC, SD Karte, USB und ein Spartan-6 drauf sind. Das ist im Moment mein eigenes Bastelboard, mit dem ich alles mache. Das ganze ich Hobby. Für den Anfang habe ich GRBL auf den µC portiert (XMega128) und hab auf 6 Achsen erweitert. Das funktionierte einwandfrei. Damit das FPGA überhaupt später was machen kann müssen die Daten rüber kommen. Dazu ist das FPGA wie ein externes SRAM an den EBI angebunden. Ich habe alles geändert, dass alle Werte, die die Stepper ISR braucht, im externen SRAM liegen. Das funktioniert auch einwandfrei. Dann habe ich mit dem FPGA angefangen zu entwickeln und da wäre es schön, wenn ich in der Simulation die Step-Segmente zur Verfügung hätte. Also wollte ich die in der ISR, immer wenn ein neues Segment geladen wird, auf SD Karte schreiben. Die Karte funktioniert, die verwende ich auf für die Config für das FPGA. Allerdings scheint es ein Problem zu geben, wenn ich während der ISR auf SD Karte schreiben will. Da friert das System ein. Ich vermute dass das RAM vom µC nicht reicht und er Stack überläuft. Das Board kann man ausschließen, das habe ich für andere Sachen schon verwendet. Das funktioniert tadellos und auch zusammen mit dem FPGA, da gibt es kein Thema, das mit dem hier beschriebenen zu tun hat. Vor allem, im Moment ist das FPGA noch nicht mit im Spiel. Den Code habe ich euch angehängt. Ich gehe so vor: Immer wenn ein neues Segment vom Stapel genommen wird, halte ich die Timer an, damit ich Zeit zum Schreiben habe. Dann wandel ich alle Werte in Strings, damit ich später leichter die Werte übernehmen kann. Das funktioniert alles, bis auf die Funktion ffwrites(); Sobald die eincodiert ist bleibt das System stehen. Nicht immer zur gleichen Zeit, was für mich den Anschein hat, dass da ein Problem mit dem Stack ist. Meine Frage: Wie kann ich jetzt erstmal genauer debuggen wo das Problem genau ist? Da stehe ich ein wenig auf dem Schlauch. Wie bekomme ich raus, ob das RAM zu klein ist. Der Ressourcen-Verbrauch wird beim Compilieren mit 74% angezeigt). Ich hoffe ihr könnt mir da mit auf die Sprünge helfen! Danke euch! Grüße, Jens
SD-Karte ist nicht echtzeitfähig. I/O daher nicht in einer ISR. Außerdem machen die Karten alle x KByte eine Pause zum internen bearbeiten. Cache einplanen.
Hallo Roland, danke für den Hinweis. In Echtzeit muss das nicht sein, da ich während des Schreibens ja die Timer der ISR anhalte. Das macht nichts, wenn es da eine Pause gibt. Was bedeutet die I/O ist nicht in der ISR? Bezieht sich das auf die Pins, dass die Zugriffe gar nicht gehen, oder meinst du die Zeit, die da benötigt wird. Zum Cache: Wie kann ich den planen? Gibt es da eine Faustformel oder kann ich den Wert bestimmen? Grüße, Jens
Jens W. schrieb: > Also wollte ich die in der ISR, immer wenn ein neues Segment geladen > wird, auf SD Karte schreiben. Warum willst au die SD-Karte SCHREIBEN? > Die Karte funktioniert, die verwende ich auf für die Config für das > FPGA. > Allerdings scheint es ein Problem zu geben, wenn ich während der ISR auf > SD Karte schreiben will. Da friert das System ein. > Ich vermute dass das RAM vom µC nicht reicht und er Stack überläuft. Kann sein. Es kann aber auch sein, daß dein SD-Zugriff einen Timer-Interrrupt für diverse Timeouts braucht. Wenn du den Zugriff aus der ISR heraus machst, läuft der Timer-Interrupt nicht! (Beim AVR). > Immer wenn ein neues Segment vom Stapel genommen wird, halte ich die > Timer an, damit ich Zeit zum Schreiben habe. Dann wandel ich alle Werte > in Strings, damit ich später leichter die Werte übernehmen kann. Und das alles in einer ISR? OMG! > Das funktioniert alles, bis auf die Funktion ffwrites(); Sobald die > eincodiert ist bleibt das System stehen. Nicht immer zur gleichen Zeit, > was für mich den Anschein hat, dass da ein Problem mit dem Stack ist. Nein. Siehe oben. > > Meine Frage: > Wie kann ich jetzt erstmal genauer debuggen wo das Problem genau ist? Da > stehe ich ein wenig auf dem Schlauch. Wie bekomme ich raus, ob das RAM > zu klein ist. Pack die Schreibzugriffe außerhalb der ISR in die Hauptschleife. > Der Ressourcen-Verbrauch wird beim Compilieren mit 74% angezeigt). Soso. Es gibt ja auch nur eine Resource . . .
Jens W. schrieb: > Zum Cache: > Wie kann ich den planen? Gibt es da eine Faustformel oder kann ich den > Wert bestimmen? Beitrag "Re: Geschwindigkeitsfrage AVR auf SD" Bei meinen SD-Katen Basteien damals habe ich beim Schreiben Wartezeiten von bis zu 500ms gemessen! D.h. dein Datenpuffer aka FIFO muss für diese Zeit die Daten aus der ISR zwischenspeichern können, um Datenverlust zu vermeiden.
Jens W. schrieb: > Hallo Roland, > .... > Was bedeutet die I/O ist nicht in der ISR? Bezieht sich das auf die > Pins, dass die Zugriffe gar nicht gehen, oder meinst du die Zeit, die da > benötigt wird. > Ich gehe davon aus, dass du FAT auf der Karte nutzt. Es ist prinzipiell so, dass zum schreiben auf einen Datenträger mit Dateisystem gelesen werden muss. Das Dateisystem ist dabei egal. Lesen nach schreiben kann bei SD mal ne halbe Sekunde dauern, bis die Daten anstehen. Zusätzlich zu den zu übermittelnden Steuer- und Adressdaten. Blockwechsel dauern auch, das merkst du daran, dass die Karte beim kontinuierlich schreiben plötzlich ne Pause macht und keine Daten annimmt. Daher den Schreibprozess nicht in eine ISR, das friert dir den Rest der Hütte für die Zeit komplett ein. Die I/O Register nutzen, aber in einen Zweig der main() packen, wenn kein OS verwendet wird. Bei einem OS einen niedrig priorisierten task aufsrtzen, der jederzeit schlafen kann.
:
Bearbeitet durch User
Hallo zusammen, vielen Dank für die Anregungen. Natürlich weiß ich, dass man in der ISR nicht warten soll. Aber das Schreiben in die main() zu legen wird nicht so einfach funktionieren. Ich schreibe in der ISR, da hier die Segmente geladen werden. Es gibt aber nach dem Laden eines neuen Segments nicht automatisch einen Rücksprung in die main. Da komme ich nur so oft vorbei, wie es die Schrittgeschwindigkeit zulässt. Die ISR für die Schrittmotoren läuft bei GRBL nebenläufig und komplett abhängig von den Timern (also die Schrittgeschwindigkeit). In den Pausen dazwischen werden neue Segmente berechnet und dem Puffer übergeben, aus der sich die ISR bedient. Mir ist noch nicht klar, wie ich das so gestallten kann, dass ich keine Segmente verliere. Ich kann in der ISR ein Flag setzen "schreibe daten", aber wann ich in der main da wieder vorbei komme ist nicht sichergestellt. Das kann auch zwei Segmente später sein. Die main-Schleife ist ja nicht leer, sondern da passiert das ganze Protokoll Handling zum PC, dass neuer G-Code geladen wird. Oder habe ich euch da falsch verstanden? Grüße
Jens W. schrieb: > Hallo zusammen, > > vielen Dank für die Anregungen. > Natürlich weiß ich, dass man in der ISR nicht warten soll. Aber das > Schreiben in die main() zu legen wird nicht so einfach funktionieren. Doch. Wenn man weiß, wie sowas geht. Das Stichwort fiel ja schon. FIFO. > Ich schreibe in der ISR, da hier die Segmente geladen werden. Es gibt > aber nach dem Laden eines neuen Segments nicht automatisch einen > Rücksprung in die main. Den gibt es in einer ISR nie ;-) > Mir ist noch nicht klar, wie ich das so gestallten kann, dass ich keine > Segmente verliere. Ganz einfach. Du schreibst die binären Daten in einen FIFO. Das geht sehr schnell. In der Hauptschleife wird zyklisch geprüft, ob Daten im FIFO liegen. Wenn ja, werden die gelesen und meinetwegen auch in ASCII gewandelt und auf SD-Karte geschrieben. Das kann "beliebig" langsam erfolgen, solange der FIFO ausreichend groß ist.
Ok, das mit dem FIFO leuchtet ein. Das versuche ich mal. Danke euch!
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.