Es gibt ja zu Hauf USB Sticks in die man eine SD Karte reinstecken kann um diese auszulesen.
Gibt es aber auch das umgekehrte ? Ich habe schon versucht zu googlen, aber wenn dann nur immer die erstere Variante gefunden.
Ich habe ein Device das einen SD Kartenslot hat und kein USB, ich würde dort gerne USB Sticks als Alternative einstecken. Gibt das Lösungen oder stell ich mir das zu einfach vor.
Das Gerät ist ein 3D Drucker der eben nur einen SD Karten Slot hat, also nur eine TXT Datei und schnell muss es auch nicht sein. Die
SD Wifi-Lösung soll ja sehr Fehlerhaft sein und wird abgelehnt. Was benötigt es um das umzusetzen
bzw. warum geht das in die eine Richtung problemlos anders herum aber
nicht ?
bzw. warum geht das in die eine Richtung problemlos anders herum aber
nicht ?
Weil USB schlau ist und SD doof.
USB verlangt einen Massenspeicher, die Art des Speichers dahinter ist dem Gerät egal, darum kümmert sich der Stick selber.
SD ist ein Blockspeicher, und woher soll der Adapter wissen was in Block 76467 liegen muss? Das könnte die Datei xy.txt sein, aber auch ein Icon. Oder die FAT. Oder alter Müll, der gelöscht wird.
Die
SD Wifi-Lösung soll ja sehr Fehlerhaft sein. Was benötigt es um das
umzusetzen
So eine Karte und WLAN.
Die Karte kann FAT lesen und muss dem Gerät vorgaukeln gezogen worden zu sein.
Dann kannst du via WLAN die Datei tauschen und die Karte sagt "ich bin wieder da".
Das funktioniert nicht mit allen Geräten, und auch die Stromaufnahme des WLAN ist für manchen SD-Slot ein Problem.
Die KArten selbst funktionieren absolut großartig.
Den Drucker via Kabel mit einem RPi o.ä. anzusteuern ist keine Option?
Stichwort Octoprint z.B.
USB verlangt einen Massenspeicher, die Art des Speichers dahinter ist
dem Gerät egal, darum kümmert sich der Stick selber.
SD ist ein Blockspeicher
Eben, genau wie USB-MSD.
Das Problem ist ein anderes und besteht eigentlich aus drei Teilproblemen:
Ein Adapter muß schon verdammt fix sein, um Richtung Host eine SD-Karte zu simulieren.
Er kann SD nicht in vollem Umfang abbilden (das "S" in SD stört hier gewaltig, zumindest dann, wenn der Host Wert darauf legt, das diese Funktionen vorhanden sind)
SD-Card-Geräteschnittstellen sind sehr oft schon rein mechanisch völlig ungeignet, um auch nur eine USB-Buchse nach "außen" zu bringen. Geschweige denn auch noch so, dass man einen Stick daran stöpseln könnte.
(das "S" in SD stört hier
gewaltig, zumindest dann, wenn der Host Wert darauf legt, das diese
Funktionen vorhanden sind)
Welche Geräte nutzen das denn noch? Ich hab schon ewig kein SD-Gerät mehr gesehen, das irgendwas gesperrt hätte, das letzte war ein Telefonanlagen-Wartemusik-MP3-Player von ca. 2010, der eine Lizenz/gesicherte KArte und eine spezielle Firmware hatte (Also normalen MP3-Player kaufen, Firmware verändern, bingo spielt nur noch spezielle Karten, die woanders auch nicht mehr gehen. Karte/Gerät-Kopplung).
Ein Adapter muß schon verdammt fix sein, um Richtung Host eine SD-Karte
zu simulieren.
Da hast du allerdings Recht, das kommt noch obendrauf.
Schließlich ist bei SD ja kein nennenswert schlauer Controller drin, das ist letztendlich ein SPI-Speicher, der Master gibt den Takt vor.
Da muss der Adapter halt das USB-Medium cachen... ;)
Quote:
Das Modul und seine Firmware wurden von dem GitHub-Benutzer ardyesp entwickelt. Es ist ein SD-Kartenadapter, auf dem ein microSD-Kartensteckplatz und ein ESP8266 untergebracht sind. Auf dem ESP8266 läuft ein WebDAV-Server, den man übers WLAN ansprechen kann.
Könnte man nicht die SD Geschichte beibehalten und dort noch ne USB host Geschichte dran tüdeln oder wieder zu einfältig ?
Es ist ein SD-Kartenadapter, auf dem ein microSD-Kartensteckplatz und
ein ESP8266 untergebracht sind.
Dein Gerät redet mit der microSD-Karte, und wenn der ESP darauf zugreifen will, ist die Karte aus Sicht des Geräts vorübergehend entfernt, so dass es keine Kollisionen gibt.
Also ganz naiv betrachtet sollte das schon möglich sein. Wenn ich mich richtig erinnere gibt es in den sd specs gewisse timeouts für die command response und block data welche die Karte einhalten muss, irgendwas um die ~100-500ms, müsste man nachlesen. Wenn dein usb host es schafft innerhalb dieser Zeitspannen die Daten vom stick zu lesen sollte es funktionieren. Ich kenne jetzt die usb mass storage specs nicht aber würde naiver Weise davon ausgehen das der usb host genauso wie der sd host block bzw. sector data vom stick anfragt. FAT ist halt FAT, meiner Meinung nach, aber ohne die specs genau zu kennen kann ich da auch nur mutmaßen.
Ich habe ein Device das einen SD Kartenslot hat und kein USB, ich würde
dort gerne USB Sticks als Alternative einstecken. Gibt das Lösungen oder
stell ich mir das zu einfach vor.
Es gibt "Geräte", keine Ahnung wie die heißen und welches Fabrikat das war, hat ein Kollege mal angeschleppt, die haben einen SD-Karten Stecker zum Anschluß an ein Device und auf der "anderen Seite" einen USB-Stecker für den PC. An der Seite war ein Slot, in den eine SD-Karte rein gehörte. Damit konnte man die SD-Karte vom PC aus bespielen und dann via Software auf den SD-Karten Stecker umschalten. Dabei ist dann allerdings die Karte immer auf ein Gerät geschaltet, das andere kann nicht gleichzeitig drauf zugreifen. Erspart halt das Abziehen und Umstecken der SD-Karte.
Technisch möglich wäre das schon:
Ein (schneller) MCU simuliert die SD Karte und hat selbst einen USB Host mit USB Stick. Aber es gibt sicher bessere Lösungen:
Wenn du die SD Karte ohne Umstecken befüllen möchtest, damit kannst du die SD Karte wahlweise per PC oder Zielgerät nutzen:
https://shop.linux-automation.com/usb_sd_mux-D02-R01-V02-C00
Da scheint etwas mehr Geschwindigkeit notwendig zu sein.
https://hackaday.io/project/19783/logs
Da wird ein fpga eingesetzt, werde mal die fertigen Lösungen, die da verlinkt sind, ansehen.
Ich hab einen 3D Drucker, einen FLSun 5Q, der hatte so ein Teil dabei. Am PC wird der USB Stick eingesteckt, fuer den Drucker zieht man die SD Karte raus. Gibt's also fertig.
Mal die Platine(n) inspizieren, ob es da nicht Lötpunkte gibt,
die einem Footprint für irgendwas USB-artiges gleichkommen.
entweder für 'ne Buchse direkt oder 4 Lötpads/-ösen in einer Reihe.
Es gibt genügend Geräte in denen doch eine
USB-Konnektivität versteckt möglich ist,
die nur nicht aussen zugänglich gemacht wurde.
Falls vorhanden, dort eine USB-Buchse, annem Stück Kabel, anlöten
Die Industrie will ja gerne
mit möglichst wenig Bauteilen/Baugruppen
möglichst viele verschiedene Geräte bauen.
USB verlangt einen Massenspeicher, die Art des Speichers dahinter ist
dem Gerät egal, darum kümmert sich der Stick selber.
SD ist ein Blockspeicher, und woher soll der Adapter wissen was in Block
76467 liegen muss? Das könnte die Datei xy.txt sein, aber auch ein Icon.
Oder die FAT. Oder alter Müll, der gelöscht wird.
Du scheinst zu glauben, dass bei USB das Handling des Dateisystems schon im Stick selbst passiert. Dem ist nicht so. Ein USB-Stick ist genau wie eine SD-Karte ein "dummer" Blockspeicher.
Ein Adapter muß schon verdammt fix sein, um Richtung Host eine SD-Karte
zu simulieren.
Warum? Man liest doch immer wieder, dass sich SD-Karten jederzeit Hunderte von Millsekunden an Auszeit nehmen können. Das kann so ein Adapter ja dann auch einfach tun.
Weil das, was Du beschreibst, auf einer Protokollebene überhalb der grundlegenden Kommunikation geschieht. Die grundlegende Kommunikation aber erfolgt mit heutigen SD-Karten mit sehr hoher Geschwindigkeit - bei UHS-1-Karten können dabei Datenraten von knapp 100 MByte/sec erreicht werden.
Und /damit/ muss die Simulation klarkommen. Die kann dann, nach dem Empfang eines Datenblocks, zwar erst mal 'ne Pause machen, aber den Datenblock muss sie entsprechend flott entgegennehmen können.
Das geringste, was die Simulation schaffen muss, sind die 12.5 MByte/sec der Ur-SD-Karten, was 25 MHz QSPI-Takt entspricht. Aber bereits mit der SD-Spezifikation 1.10 wurde diese Taktfrequenz auf 50 MHz verdoppelt, was in einer Übertragungsrate von 25 MByte/sec resultiert.
Mit UHS-1 wurde die Taktfrequenz auf 100 und sogar 208 MHz angehoben, womit die per UHS-1 möglichen knapp 100 MByte/sec heutiger Karten möglich wurden.
Hier ist also ein Test mit einer möglichst steinalten SD-Karte angesagt (< 1 GByte), um herauszufinden, ob der 3D-Drucker überhaupt den Uralt-Standard mit 25 MHz unterstützt.