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?
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