Hallo Leute, kurz zu meinen Anwendungsfall: Ich habe einen STM32F4 und daran eine SD Karte über SPI verbunden. Als Zugriff für das Dateisystem kommt ein FatFS zum Einsatz. Als Debugger nehme ich den Jlink her. Jetzt zu meiner Frage: Ich speichere auf der SD Karte Daten ab und möchte diese gern (ohne die SD Karte entnehmen zu müssen) auslesen. Ich würde die Daten gerne über den Jlink auslesen. Es wäre kein Problem wenn ich ein extra Programm dafür auf den STM32 flashen müsste, schön wäre aber auf PC seite (Linux) so eine Art Dateibrowser. Wer hat Ideen? Gibt es vielleicht bereits ähnliche Projekte oder Ideen? Hat sowas schonmal jemand umgesetzt?
:
Gesperrt durch User
Irgendwie geht das sicher. Im ST Link Utility gibt es eine Einstellung External Loader. Damit ist der Zugriff auf externe Speicherbausteine möglich. Ich denke damit wird ein kleines Programm in den STM32 Ram geladen und ausgeführt. Gibt auch bestimmt eine AppNote dazu.
pegel schrieb: > Im ST Link Utility gibt es eine Einstellung External Loader. > Damit ist der Zugriff auf externe Speicherbausteine möglich. Jaaaaaaa, aber: Das ist für SPI Flash. Zwar kann man SD-Karten auch über SPI ansprechen, aber das ist nur das "Low-Level" Interface. SD-Karten brauchen halt noch ein wenig "oben drauf". Und dann nochmal das Dateisystem drüber. Letzteres könnte man sich natürlich sparen, wenn man auf PC Seite ein Filesystem in einer Datei (unter Linux mit 'nem loop-dev.) anlegt und dann nur noch die einzelnen Sektoren hin und her kopiert. Das kopieren einzelner Sektoren von SD-Karte ins RAM des F4 und zurück ist sicher noch mit überschaubarem Aufwand über ein kleines Programm, dass vom Debugger in RAM geschrieben wird, möglich. Müsste man aber halt schreiben. Ob sich das lohnt, hängt auch von der Größe der Speicherkarte ab. Wieviele kByte/s bekommt man über die Leitung (des Debuggers)? Wenn man darüber ein paar GByte kopieren will, kommt da keine rechte Freude auf ...
ui schrieb: > Als Debugger nehme ich den Jlink her. Dann schau Dir mal Segger RTT an. Der Zugriff mit eigenem Programm ist via TCP/IP möglich, Terminal 0 liegt auf Port 19021. Dateizugriffe könnte man über (X,Y,Z)Modem via Telnet Client (z.B. TeraTerm Pro) lösen.
Jim M. schrieb: > Dann schau Dir mal Segger RTT an. Der Zugriff mit eigenem Programm ist > via TCP/IP möglich, Terminal 0 liegt auf Port 19021. > > Dateizugriffe könnte man über (X,Y,Z)Modem via Telnet Client (z.B. > TeraTerm Pro) lösen. Danke für den Hinweis, das schaut doch recht interessant und hilfreich aus. Da ich eh ein Betriebssystem habe wäre das quasi eine Möglichkeit: 1) Task anlegen der nicht aktiv wird bis man anfängt irgendein Steuerzeichen zum starten zu senden 2) Nur der Task wird aktiv, die restliche Software schläft implizit. 3) Einen kleines Protokoll einbauen, sowas wie "ls" und "cd" 4) Das Unterprogramm auf dem STM gibt Antworten als characters raus 5) Auch Daten können so geladen werden, muss man halt zweimal parsen (auf dem STM und am PC) 6) Wenn man die Verbindung löst legt sich der Task wieder schlafen und macht seine normalen Dinge. Hört sich doch nach nem Plan an.
ui schrieb: > Ich speichere auf der SD Karte Daten ab und möchte diese gern (ohne die > SD Karte entnehmen zu müssen) auslesen. Ich würde die Daten gerne über > den Jlink auslesen. Wieso kommst du bloß auf so eine absonderliche Idee? Weil der Jlink grad so bei dir herumliegt? Der ist für so einen Einsatzfall absolut NICHT erdacht worden. Also: bringe deiner Firmware im µC ein USB-CDC bei (Beispiel dafür gibt es hier ja genug), dann bringe deiner Firmware ein kleines Kommandoprogramm bei und implementiere dort irgend eine Art, deine Datei auf der SD-karte anzuzeigen oder per UU zum PC zu schicken. So (ungefähr) macht man das. Auf dem PC kannst du dann dein Lieblings-Terminalprogramm benutzen - welches, ist relativ egal, es muß nur in der Lage sein, den Traffic in irgendeine Datei zu loggen. W.S.
W.S. schrieb: > Also: bringe deiner Firmware im µC ein USB-CDC bei Also wenn schon mit richtigem USB, dann kann man doch gleich MSC implementieren, oder einfach einen SD-Karten-Leser. Dann kann man direkt per Windows Explorer zugreifen... PS: Ist nicht der Hauptgrund für die Nutzung von SD-Karten, dass man die einfach herausnehmen und in den PC stecken kann...?
Das Problem daran: Ich will die Kommunikation über den JLink USB-Port machen, ohne Dinge an der Hardware ändern zu müssen. Gibts denn bessere Vorschläge?
Die Frage ist, ob das irgendeinen Sinn macht. SD-Karten nimmt man, wenn's um ein großes Datenvolumen geht (bis mehrere GByte). Und so etwas bekommt man nicht in erträglicher Zeit über USB-FS (12 MBit/s physikalisch). Selbst mit einem SD-Kartenleser am PC, der nur USB-FS kann, wird heutzutage niemand mehr so richtig glücklich. Und JLink mit SWD oder JTAG knabbert davon noch krätig was ab. Mein JLink (naja, etwas älter) mag's nur bis 4 MHz SWD Takt (allerdings nicht nachgemessen ...). Noch etwas Protokoll-Overhead abgezogen und schon ist man bei sehr optimistisch max. vielleicht 300 kByte/s. Verzeichnisse browsen ok, aber Dateitransfer??? Ein paar kBytes gut, aber spätestens bei MBytes ist Schluss. Via USB-HS als Mass-Storage-Device wär natürlich eine Alternative, da braucht's auf PC-Seite nicht einmal extra Software. Auf Controllerseite sollten sich in den Beispielen von ST etwas dazu finden lassen. Aber ohne externen USB-HS-Phy geht's dann nicht (außer STM32F723, der hat einen an Bord). Wenn es um ein kleineres Datenvolumen gehen sollte (leider gab's dazu keine Info außer "Ich würde die Daten gerne über den Jlink auslesen"), würde man eher einen SPI-Flash nehmen, z. Z. so etwa bis 64 MByte bezahlbar. Aber die Problematik mit dem gemächlichen Transfer bleibt natürlich, man erspart sich zumindest die SD-Schicht ... Deshalb: Erst genau über die Anforderungen, dann über die möglichen Optionen zur Realisierung nachdenken! Da SD-Handling und Filesystem ja offenbar schon "stehen" geht's doch offenbar nur noch um den Transport. Via JLink m. E. einfach unrealistisch bei größerem Dateiumfang ...
A. B. schrieb: > Da SD-Handling und Filesystem ja offenbar schon "stehen" geht's doch > offenbar nur noch um den Transport. Via JLink m. E. einfach > unrealistisch bei größerem Dateiumfang ... Zum Datenumfang: Es wird sich um einzelne *.txt Dateien handeln. Das größte der Gefühle werden wohl vielleicht mal kleiner Bilder (max. ca. 300kB) sein. Es wird sich eigentlisch ausschließlich um log Dateien und/oder Kalibrierungsdaten handeln, nicht mehr. Der SD-Karten Anschluss ist zwar verfügbar, warum ich das gerne vermeiden wollen würde: Es handelt sich um ein Projekt bei dem Schüler/Studenten bisserl programmieren lernen sollen. Nicht alle unsere PCs haben SD-Karten anschluss, sodass es dann einfach frickelig und nicht schön handhabbar ist. Deswegen die Idee das über den Debug USB zu handhaben. Es ist auch kein Problem wenn das mal 1-2 Minuten dauert.
Wenn's was fertiges sein soll, fällt mir außer dem RTT auch nichts ein. Etwas ähnliches selber machen, sollte allerdings auch nicht schwer sein: Zwei Software-FIFOs, die Zugriffssteuerung geht implizit über die Schreib-/Lesezeiger (automatisch atomar), über den Debug-Adapter hat man ja transparent Zugriff aufs RAM des Controllers, ohne dem in die Quere zu kommen. Das ist auch der übliche Weg, wie man z. B. das Flash übers Debug-Interface programmiert. Zum Nachlesen: In openocd gibt's "target_run_flash_async_algorithm", das genau (die Host-Seite) von so einem FIFO implementiert. Zwar nur Host->Target, aber das ganze kann man natürlich auch gleichzeitig in beide Richtungen machen. Einziges potenzielles Problem: Wenn ohnehin schon größere Applikation, dann noch die RTT-Lib und X-/Y-/Z-Modem, könnte es je nach Flash-Größe eng werden. Und ständig "umflashen", nur um auf die SD-Karte zugreifen zu können, ist ja auch nicht so toll.
ui schrieb: > Es handelt sich um ein Projekt bei dem Schüler/Studenten bisserl > programmieren lernen sollen. MAL EIN BISSEL HERUMPROGRAMMIEREN? Und da denkst du dir etwas derart ungewöhnliches aus, siehst dich selber obendrein außerstande, es selbst zu realisieren - und willst damit Pädagogik betreiben? Also mein Lieber, denke dir besser etwas wirklich pädagogisch sinnvolles aus, als da wäre: - planvolles Herangehen an ein Gerätekonzept mit einem Mikrocontroller - sinnvolle Konzepte für low-level Treiber im Controller, angefangen beim simplen UART-In und -Out mit Zwischenpuffern und Entkopplung von Zugriffen und tatsächlichem Datenverkehr auf dem Übertragungsweg - bis hin zu selbigem, aber intern eben paketeweise per USB. Ein Gleiches dann auch für Dinge wie graqfische Displays, also Displaytreiber zur Hardware hin und GDI zu den Anwendungen hin. Und und und.. Sinn des Ganzen ist es, zu lernen, in der Firmware mit einer Art Schichtenmodell zu arbeiten, also die Algorithmen und die Ablaufgestaltung und die Lowlevel-Dienste voneinander zu trennen, damit nicht alles wie Kraut und Rüben durcheinander geht. Ich unterstelle mal, daß du den Schülern/Studenten tatsächlich Wissen und Können BEIBRINGEN willst - und dazu solltest du wenigstens etwas Ahnung nicht nur haben, sondern auch weitergeben können. Ich habe vor Jahren die "Lernbetty" für derartige Zwecke konzipiert und zusammen mit einigen (wenigen) anderen ist damals auch etwas draus geworden. Also versuche du mal, dein Thema, was du dir so vorgestellt hast, zu allererst in so ein (ähnliches) Dokument zu fassen. Jaja, für ein klares Konzept sollte man es möglichst frühzeitig in ein einigermaßen förmliches Dokument fassen, das sich lesen und diskutieren läßt. Zumeist merkt man beim Verfassen recht bald selber, wo man noch schwammig gedacht hat und hat dann Gelegenkeit, sich selber zu konkretisieren. Bei mir hat sich diese Verfahrensweise seit vielen langen Jahren als Geräteentwickler sehr bewährt, denn sie hält einen davon ab, in unausgegorene Spinnereien zu verfallen. W.S.
W.S. schrieb: > MAL EIN BISSEL HERUMPROGRAMMIEREN? > > Und da denkst du dir etwas derart ungewöhnliches aus, siehst dich selber > obendrein außerstande, es selbst zu realisieren - und willst damit > Pädagogik betreiben? > > Also mein Lieber, denke dir besser etwas wirklich pädagogisch sinnvolles > aus, als da wäre: > - planvolles Herangehen an ein Gerätekonzept mit einem Mikrocontroller > - sinnvolle Konzepte für low-level Treiber im Controller, angefangen > beim simplen UART-In und -Out mit Zwischenpuffern und Entkopplung von ... > läßt. Zumeist merkt man beim Verfassen recht bald selber, wo man noch > schwammig gedacht hat und hat dann Gelegenkeit, sich selber zu > konkretisieren. Bei mir hat sich diese Verfahrensweise seit vielen > langen Jahren als Geräteentwickler sehr bewährt, denn sie hält einen > davon ab, in unausgegorene Spinnereien zu verfallen. > > W.S. Vielleicht war es von mir etwas salopp ausgedrückt, aber schon (wie so oft) landen wir hier im forum bei Besserwisserei. Ja ich weiß, ich habe wenig über mein Projekt geschrieben, aber ich glaube ich konnte sehr klar in Worte fassen was das Problem ist und was ich gerne hätte. Es kamen auch ein paar gute Vorschläge, und jetzt kommst du und meinst alles besser zu wissen. Das Projekt ist schon ziemlich weit fortgeschritten, es geht auch gar nicht darum das Schüler die Welt der low-level Treiber kennenlernen. Macht manchmal Sinn, oft auch nicht. Also: leck mich.
Thread beobachten
Seitenaufteilung abschalten