Forum: Mikrocontroller und Digitale Elektronik USB CardReaderWriter & Atmega

Was hast du vor?????

Hallo

@jens123
ganz einfach:

-Atmega kennenlernen ist das promäre Ziel (Hobby)

Falls es gelingt ein Atmega-System wie eine SD-Card anzusprechen,
lassen sich da so manche Anwendungen (spielereien) denken.
zB: ich kopiere vom PC Daten auf eine "scheinbare" SD Karte mit
Standardtools (Explorer)-da ist aber keine SD Karte- sondern ein LCD
Display, oder LEDS, oder ein Motor, oder oder....
Das ganze in umgekehrter Richtung könnte man als "Datenerfassung"
nutzen!
Stell dir vor ich emuliere eine 256 MB SD Karte mit x Atmegas so kann
ich 256 000 000 Temperaturen abfragen oder bloß 128 000 000 bei 16 bit
etc. etc.
Moderne Leute würden dann schon von GRID-Computing reden!!!

Spass bei Seite:

Ich will die "Atmega" Welt für mich erschließen, nicht einfach
vorhandenes nachbauen, ein Standard_Streaming_Interface (USB) mit
geringem Aufwand nutzen und die "ganze" Prozesswelt (Außenwelt) über
eine Art "shared" Memory (Mein-SD-Emulator) an den PC ankoppeln. Das
ganze wird dann hinter einer Java Oberfläche bzw. hinter einer
Webanbindung (Servlets) versteckt (bedient). Dies ist das einzige, was
ichbei diesem Thema kann.
 Das Atmegasystem soll dabei die möglichst "intelligente" Adaption
vornehmen. Dann kann ich z.B:  Temperatursensoren und Anzeigen wie
Files ansprechen.
Bisher nur Traum.....

Achim

"Gespinne" ist vielleicht ein etwas harter Ausdruck, aber ziemlich
unrealistisch ist die Sache schon.

Damit Du den Cardreader mit einem Microcontroller ansteuern kannst,
musst Du dem Microcontroller die Fähigkeiten eines USB Host verpassen -
das ist sehr viel komplizierter als ein USB Device. Du bräuchtest
entsprechende Hardware, die Du mit dem AVR ansteuern müsstest, und
obendrein müsstest Du den USB-Protokollstack mehr oder weniger selbst
entwickeln (oder für irrsinnig viel Geld von einer Embedded-Firma
kaufen).

Ganz unmöglich ist die Angelegenheit aber nicht, ein verrückter Japaner
hat mit einem AVR einen USB Host für Lowspeed-USB-Geräte (1.5 MBit/sec)
entwickelt - allerdings muss man japanisch können, um mehr davon zu
verstehen (http://www.asahi-net.or.jp/~qx5k-iskw/robot/usbhost.html).
Als Beweis kann man dort einige MPG-Dateien herunterladen, die zeigen,
wie ein Microcontroller einige LEDs einschaltet, wenn auf einer
angeschlossenen Maus eine Taste gedrückt wird.
Hier http://www.asahi-net.or.jp/~qx5k-iskw/robot/usbhost/usbh08.jpg ein
Bild der Hardware, auf der deutlich ein AT90S2313 erkennbar ist.

Allerdings muss zusätzlich zum grundlegenden USB-Protokollstack auch
noch Unterstützung für "Mass Storage Devices" - nichts anderes ist
der Kartenleser - und für die zu erwartenden Dateisysteme (FAT16/FAT32)
entwickelt werden, was wohl die Verwendung eines 32-Bit-Microcontrollers
mit deutlich mehr als 4 kByte Speicher nahelegt. Naheliegend ist dann
die Verwendung eines Controllers, auf dem ein embedded Linux läuft,
weil dafür die entsprechende USB-Unterstützung nicht neu entwickelt
werden muss. Auch Dateisystemtreiber sind Linux nicht fremd.
Nur: Welcher Controller, den man löttechnisch noch selbst verarbeiten
kann (also kein BGA-Gehäuse), eignet sich hierfür?

Es gibt Geräte ("syncbox"), die zwei "Mass Storage Devices"
ansteuern können und Daten von einem auf das andere kopieren können,
würde mich mal interessieren, was da für Controller drin sind.

Oh, ich habe Deinen letzten Beitrag nicht mitbekommen - Dir scheint es
ja an etwas anderem gelegen zu sein; wenn ich das richtig verstehe,
möchtest Du mit einem AVR eine SD-Card simulieren. Tricky, da dieses
Interface sehr schnell ist (im Gegensatz zum AVR) und
höchstwahrscheinlich auch ziemlich schlecht dokumentiert.

Wenns nur darum geht, dem AVR einige wenige Daten (also nicht mehrere
Megabytes) zu übertragen, erscheint die Verwendung eines
USB-Seriell-Adapters (von FTDI) deutlich sinnvoller; der verkauft sich
dem PC gegenüber als serielle Schnittstelle und kann per Kommandozeile
angesprochen werden (copy bla.txt com3:) -

Hallo

@Rufus T. Firefly bei der seriellen Schnittstelle habe ich aber nicht
die ganzen standard "Dateifunktionen" das sollte ja gerade der GAG
sein.
Hinter den emulierten SD_Blöcken verbirgt sich zum Beispiel eine
Temperaturerfassung. Ich kann die dann zb: mit Excel laden und
darstellen. Anschluß über einen billigen SD-Cardreader (Billiger als
FTDI... Chip)!!!!!
Ich möchte nicht die USB-Host Schnittstelle nachbilden. Ich möchte auf
dem PC alle Hilfmittel für Dateifunktionen "nutzen". Stell dir vor
ich kopiere zyklisch eine Datei von der SD-Card auf meine Hardisk mit
zyklischem >copy x:erfassung.sd d:temperaturen.xxx .....

...etc.

Schon habe ich eine Datenerfassung!

Immer noch "gespinne" ?

Achim

Ja, immer noch "gespinne".
Du müsstest eine SD-Card (oder CF, SM, was auch immer) emulieren, die
vom PC über den Cardreader beschrieben/gelesen wird - und genau das
lässt sich nicht mit einem Microcontroller hinbekommen, da der dafür
vieeeeel zu langsam ist. Also wäre ein PLD nebst 'ner ganzen Menge
Speicher erforderlich (irgendwohin müssen die vom PC draufkopierten
Daten ja hinkommen).
"'ne ganze Menge" bedeutet einige Megabyte; halt die kleinste
ansprechbare SD-Karte oder CF oder was auch immer.
Dieser Speicher wiederum müsste vom Microcontroller gelesen werden,
aber auf gar keinen Fall geschrieben werden, da das das OS des
angeschlossenen Rechners nicht mitbekäme; simultaner Zugriff zweier
Systeme auf ein gemeinsames Dateisystem ist nicht angesagt.

Ausserdem: Was bitte ist an
copy com3: blafusel.txt
keine Dateifunktion?

Das kopiert seriell empfangene Daten in eine Textdatei und bricht beim
ersten empfangenen Ctrl-Z (0x1a) ab; die Handshakeleitungen müssen
allerdings sinnvoll verdrahtet sein (ohne geht's nicht).

Hallo

@Rufus T. Firefly
..Ausserdem: Was bitte ist an
copy com3: blafusel.txt
keine Dateifunktion?
...

natürlich ist das eine Dateifunktion! Keine Frage!

aber nur ein kleiner Teil der Standard-Funktionen. So kann ich
keinerlei Directory_Funktionen durchführen. Oder Unterschiedliche
Dateien Ansprechen. Ich habe im Hinterkopf, daß ich von JAVA über die
vorhandenen Dateifungtionen auf den "USB" Emulator zugreife. Unter
anderem unterstützt JAVA nicht (direkt,native)die USB Schnittstelle,
das wäre dann auch ein angenehmer nebeneffekt.

Wichtig!!
Nochmal Rufus. Es geht nicht um Rechthaberei oder Klugscheißerei
sondern ganz einfach um die Machbarkeit so etwas zu machen. Manche
Dinge haben sich aus einer "Spinnerei" entwickelt.

Noch ne Frage:Kann man die USB schnittstelle nicht langsamer betreiben,
so daß der Microcontroller mitkommt. Mir geht es in diesem Fall nicht so
sehr um Geschwindigkeit. Gibs da nicht sowas wie ein Handshaking ?
MFG
Achim

Was Du da vorhast, scheitert an einigen grundlegenden Problemen.

Ein "Mass Storage Device" ist ein Gerät, das dem angeschlossenen Host
den Zugriff auf einzelne Sektoren ermöglicht. Die gesamte Verwaltung
eines etwaigen Dateisystems wird vom Host durchgeführt. Daher ist
dieses Konzept nicht dafür geeignet, von anderer Seite
Schreibzugriffe auf Sektoren des "Mass Storage Devices" vorzunehmen,
da der Host (und dessen Dateisystemtreiber) nichts davon mitbekommt.
Das wäre nur dann möglich, wenn das Gerät vor dem Schreibzugriff beim
Host abgemeldet, dann beschrieben und danach wieder am Host angemeldet
würde - was der Grundidee widerspräche.

Ob nun das "Mass Storage Device" so erzeugt wird, daß ein
herkömmlicher Kartenleser via USB an den Host angeschlossen wird und
"nur" der Speicherteil durch Simulation einer wie auch immer
gearteten Speicherkarte (SD/CF/MM/etc.) erzeugt wird, oder ob die
gesamte Funktionalität (ohne Kartenleser) mit einem Microcontroller
abgehandelt wird, ändert nach wie vor nichts an der Einschränkung, daß
übliche Betriebssysteme keine simultanen Mehrfachzugriffe auf
Dateisysteme auf Sektorebene zulassen.

Die Geschwindigkeit der USB-Schnittstelle ist an dieser Stelle auch
nicht das entscheidende Kriterium, wobei ich mir nicht sicher bin, ob
ein "Mass Storage Device" auch als Low-Speed-Device implementiert
werden könnte (1.5 MBit/sec statt 12 MBit/sec) - wie aber ausreichend
dargelegt, ist das irrelevant.

Für die angedachte Lösung erscheint mir eine Kommunikation mit einer
seriellen Schnittstelle durchaus ein gangbarer Weg - vielleicht ist
Java, wenn man noch nicht mal sowas damit machen kann, einfach nicht
das geeignete Werkzeug für solch eine Anwendung?

Alternativ wäre ein deutlich schickerer (und auch mit dem Java-Hype
vereinbarer) Ansatz der, ein Ethernet-Interface und einen Webserver
oder FTP-Server auf dem Microcontroller zu implementieren.
Das ist durchaus auch mit sehr schmalbrüstigen Microcontrollern
hinzubekommen (8051 und RTL8019) und wurde auch schon oft genug
gemacht. Und mit Java oder vergleichbaren fortschrittlichen
Entwicklungssystemen sollte es möglich sein, Daten via FTP von irgendwo
abzuholen.
Etwas anspruchsvoller auf der Java-Seite wäre die Implementierung eines
eigenen socketbasierten Protokolles, was aber den Microcontroller
entlasten dürfte, da der Overhead des Web- resp. FTP-Servers entfiele.
Ein weiterer Vorteil wäre hier die erzielbare räumliche Trennung von
Microcontrollersystem und ansteuernden PC; bei USB beträgt die maximale
Kabellänge nämlich gerade mal 5m.

Ich halte das ganze durchaus fuer machbar. Ein AVR wird sicherlich eine
Smartmediakarte (am einfachsten) oder eine MMC-Karte (aufwendiger wegen
MMC-Interface) emulieren koennen.
Auch ein sektorweiser Zugriff ist moeglich. Davon kann sich jeder
ueberzeugen der noch die Faehigkeiten hat debug zu bedienen.

Das ganze ist aber schon ein grosser Aufwand von zweifelhaften Wert der
einem am Ende eine eher langsame und holprige Datenuebertragung liefern
wird.

Mit einem aehnlichen Aufwand kann man sich einen USBN9604 an einem AVR
anschliessen und kann dann den direkt ueber USB auslesen. Das ist
insofern eine viel bessere Loesung weil man wenn man es einmal laufen
hat, danach jeden beliebigen Microcontroller mal eben so einfach an USB
anschliessen kann.
Oder wenn man faul und lernresistent ist nimmt man halt so einen FTDI,
aber ich finde den 9603/4 schoener.

Olaf

Hallo

vielen Dank für die Beiträge. Ich werde darüber nochmals nachdenken.

Nochmals zum Grundgedanken:

-Ich wollte einen billigen Cardreader (SD-Card nehmen) ==> null
  Aufwand,billig
- Auf der PC Seite mit Standard-Treiber per C,Java,C++ auf diese
  zugreifen (das kann ich, da bin ich zu Hause)
-SD-Card Emulator mit einem ATMEGA bauen mit externer Peripherie
  (Temperatur,Stellglieder, LCD,LED's ...etc)
-Primär zum kennenlernen der noch unbekannten Atmega-Welt
-Ich dachte das von Ullrich Radig entwickelte SD/MMC Projekt als
 Startprojekt zu nehmen und dannn eben keine Karte beschreiben sondern
 zu lesen und das von der Peripherie. Den Hardwareaufwand (6 Leitungen
und 6 Widerstände anzuknuppeln) hätte ich noch geschafft.
-Mit WinHex könnte ich meine Hardware ansehen ohne ein Protokoll
PC<=>Atmega zu entwickeln. Im Klartext ich wollte transparent auf die
Hardware zugreifen. Der Aufwand liegt natürlich in der
Emulatorsoftware, aber das will ich ja lernen.

Der von olaf vorgeschlagene Weg ist natürlich ok, bedingt aber ne
größere Hardwareentwicklung (die ich aber nicht kann). Ferner muß dazu
auf der PC SeiteSoftware(treiber) entwickelt werden.

Ich war der naiven Meinung ich lese mit dem SD_Emulator meine
Temperaturen etc. direkt mit Datei==>öffnen direkt in zB.: Excel ein.

In diesem Sinne
Achim

@olaf: Auch eine Smartmedia-Karte (was nichts anderes ist als ein
Flash-Baustein in anderem Gehäuse) wird man nicht mit einem AVR
emulieren können.
Sieh' Dir mal das Datenblatt (genauer: die Interface-beschreibung)
eines solchen Bausteines an (Samsung beschreibt das recht ausführlich)
- und Du wirst feststellen, daß das mit einem Controller einfach nicht
zu realisieren ist. Es geht ja nicht darum, mit einem Controller auf
eine SM-Karte (bzw. xD-Karte, was exakt das gleiche ist) zuzugreifen,
sondern eine nachzuahmen - was eben voraussetzt, daß man auch das
Timing hinbekommt. Da der entsprechende Baustein eine Zugriffszeit von
50 nsec hat (beim sequentiellen Auslesen der Daten einer Page) und es
keinen Handshake-Mechanismus gibt, der hier drosselnd eingreifen kann,
wäre hier ein beträchtlicher Hardwareaufwand vonnöten - mit Software
auf einem Microcontroller ist das einfach nicht hinzubekommen. Die
kleinste 3.3V-SM-Karte ist 4 oder 8 MByte groß - der Controller müsste
ausserdem diesen Speicherbereich irgendwie zur Verfügung stellen. Gut,
das ließe sich mit entsprechendem Hardwareaufwand auch noch
hinbekommen, aber das ganze Projekt wird damit nicht minder
wahnwitzig.

(Hier ein Link auf das Datenblatt einer SM-Karte
http://www.samsung.com/Products/Semiconductor/Flash/FlashCard/SmartMedia/128MByte/K9D1G08V0A/K9D1G_12.PDF)

Egal, welche Art von Speicherkarte emuliert werden soll (und olaf hat
mit der Einfachheit von SM durchaus recht), das ist alles mit einem
Microcontroller kaum hinzubekommen. Das serielle Interface einer
MM/SD-Card wird vermutlich auch ein Timing aufweisen, das um einiges
schneller ist, als irgendein Microcontroller ohne spezielle
Hardwareunterstützung hinbekommen kann, bei MS (Memorystick) wirds auch
nicht anders aussehen. Auch das parallele Interface von CF ist nicht
minder anspruchsvoll.

Sofern man darauf verzichtet, ein Dateisystem zu verwenden, sondern nur
sektorweise auf das "Mass Storage Device" (den Kartenleser mit
SM-Emulator) zugreift, treffen sicherlich einige von mir erwähnten
Einschränkungen nicht zu.
Wenn aber eine so professionelle Programmiersprache gewählt wird, mit
der noch nicht einmal simpelste Kommunikation mit einer seriellen
Schnittstelle möglich ist, dann bezweifle ich sehr stark, daß damit
direkte Zugriffe auf einzelne Sektoren eines Laufwerks möglich sein
werden. Außerdem sind unter richtigen Betriebssystemen* dafür
Administratorberechtigungen erforderlich; Programme zur Datenerfassung
sollte man so schreiben, daß sie diese nicht benötigen.

Wenn denn schon auf Dateiebene auf Daten zugegriffen werden muss, dann
erscheint die Entwicklung eines Filtergerätetreibers sinnvoller. Dieser
kommuniziert via USB oder serieller Schnittstelle oder was auch immer
mit der tatsächlichen Hardware und stellt seine Resultate im
Dateisystem zur Verfügung, so daß mit CreateFile darauf zugegriffen
werden kann.
Das allerdings bietet auch eine serielle Schnittstelle - wir drehen uns
hier irgendwie im Kreis.


Mir erscheint es sinnvoller, zu lernen, wie man mit Java auf eine
serielle Schnittstelle zugreift - das lässt sich mit anderen
Programmiersprachen auch ohne Probleme hinbekommen, sogar mit VB geht
das.
Wenn die vermeintliche Eleganz des Dateizugriffs gewünscht wird, ist
halt ein enormer Aufwand zu betreiben, wobei der von mir gemachte
Vorschlag des via Ethernet angebundenen FTP-Servers sicherlich noch
recht einfach zu implementieren ist. Wird hierfür eine PPP-Verbindung
genutzt, kann man sich auch die Ethernet-Schnittstelle sparen, benötigt
nur eine einfache serielle Schnittstelle (Windows - DFÜ-Netzwerk) und
kann trotzdem über TCP/IP mit dem angeschlossenen Gerät kommunizieren.



*) kein Windows95 oder einer seiner Aufgüsse (98, Me), sondern ein
NT-basiertes Windows (NT selbst, W2K oder XP)

Ich hab ja nicht gesagt das Smartmedia einfach ist, es ist nur
einfacher. Notfalls muss man da halt ein FPGA <BG> oder nur ein
DualPortRam mit etwas Logic zwischensetzen.
Ist klar, ich wuerd mir auch eher in den Fuss schiessen als so etwas zu
machen, aber wenn das Ziel ist unbedingt Aldikram aufzubrauchen dann
soll es so sein.

An den OP: Die Umkehrung bekannten Codes welcher MMC Karten liesst ist
nicht moeglich. Bisher hat noch alles was ich gesehen habe eine MMC
Karte im SPI-Mode angesprochen. Die Cardreader werden aber IMHO alle
den MMC-Mode verwenden. Das wird dann richtig aufwendig. Dann lernt man
wenigstens mit einem FPGA umzugehen. :-)

Die groesse des Speichers ist uebrigens nicht das Problem. Man kann den
PC ja bescheissen und ihn immer dieselben 512Byte fuer jeden Sektor
vorspiegeln.

Man koennte vielleicht noch am Reader eine MMC Karte anschliessen und
die Datenuebertragung belauschen und wenn ein ganz bestimmter Sektor
gelesen wird dann blendet sich der AVR ein. Das ist dann mal eine
richtige Gurkenloesung!

Was uebrigens das Programmieren angeht. Ich spreche meinen
Mega8+USB9604 nur unter Linux an da mir Microscheiss nicht auf dem
Rechner kommt. Da war die PC-Seite nur wenige Stunden Arbeit und ich
hab es zum erstenmal gemacht. (mit libusb1.18)

Was uebrigens die Ahnung von Hardware angeht. Einen Mega8 mit USBN9604
ans laufen zu bekommen und den dann in C zu programmieren erfordert
ERHEBLICH weniger wissen von Hardware als die obigen Gurkenloesungen.


Olaf

Hallo

@Rufus T. Firefly da ist wohl was falsch angekommen! Von JAVA kann man
natürlich auf die COM Schnittstelle zugreifen (W2K).
Das Argument mit dem Timing sehe ich natürlich ein. Ich dachte da wird
nach jedem Byte ein Handshaking gemacht.
Ansonsten nochmals zur Klarstellung es handelt sich da um eine
HEIM-Hobby-BEREICH Anwendung zum kennenlernen vom ATMEL!
Die Argumente zeigen mir jedoch, dass es Hardwaremässig nicht geht.
Für die Argument vielen Dank, hat mir viel Zeit erspart. Also hat die
Anfrage was gebracht!!!

Im geschäftlichen Bereich geht natürlich prefessioneller zu!!!!
Aber das sind auch anderere preisliche Kategorien (Millionen)!
http://www.fzk.de/
http://www.fzk.de/stellent/groups/itp/documents/published_pages/itp__20_10__index.php#TopOfPage
Bei der Datenerfassung von ca.: 2000 Sensoren hatte ich wesentlichen
(Software)-Anteil.

@olaf da wurde kein ALDI-Kram verwendet. Der Unterschied ist schon
klar.
Wo bekommt man den USB9604 her?

Sorry nichts für ungut, ich mag auch keine Gurkenloesungen!!!
MfG
Achim

Den 9604 müsste man bei Segor oder ähnlich gut sortierten Händlern
erhalten können.

Den Hinweis (mit den vielen Ausrufungszeichen) ignorieren wir hier
geflissentlich. Beeindrucken können wir uns nur selbst, und das am
besten.

Hallo

@Rufus T. Firefly Deine Argumentation, dass ein SD-Karten-Emulator
"technisch" unmöglich ist da der Microcontroller das Timing nicht
einhalten kann, kann ich zwischenzeitlich nicht verstehen. Ich möchte
ja nicht die maximale USB Bus gGeschwindigkeit nutzen sonder dem
"File-Schnittstellen" Standard zu einer SD-Karte.

Ich komme zu dem Ergebnis dass dieses machbar sein muß, ohne großen
Hardwareaufwand.
Begründung:
- Es existiert eine Softwarelösung (-IGOR -improved USB to RS232
converter + another interfaces-). Das zeigt mir, dass vom Timing her
das Anbinden eines Atmels an USB möglich ist.Ich möchte aber nicht eine
Atmel/Software Lösung sonder einen USB Cardreader. Die weiteren IGOR
Schnittstellen:
... Featur-ZITAT fürATmega:
-  USB converter to three 8-bit input-output ports (16-bits together)

   each pin can be as input or output, option of pull-up resistor on
    input pin
    * USB read/write into internal data EEPROM memory : 512 byte
      EEPROM to store own data (e.g. calibration data of your product)
    * eventually possibility to use ATmega8 peripherals (not yet
     implemented):
      - 6-channel AD converted: 4x10bit + 2x8bit
      - PWM channel
    * possibility to add own functions: cca 3K memory words (from
    whole 4K words memory) of Flash is free for next user extensions -
    specific functions (crypto functions for hardlocks, USB to
    "something" converter - e.g. USB<>I2C, USB<>PS2, ... . )
    * eventually possibility of firmware upgrade through USB (now not
     implemented - project for another developers :-) )
...Ende Zitat...
Die Adresse möchte ich nicht angeben, da in einem anderen Thread schon
von Marketing gesprochen wurde. Das Ganze ist auch eine Atmel Appp.
Note. (Avr 309 ?)

Weiterin hat Ullrich Radig die MMC bzw. SD Kartenanbindung in einem
Projekt beschrieben. Dort wird beim Schreiben und Lesen immer auf eine
Response der Karte gewartet. Das interpretiere ich als Handshaking
(?).
Auf Grund dieser beiden Projekte finde ich meinen Ursprungsgedanken
eine SD Kartenemulation welche Prozeßperipheri hinter eine SD
Kartenschnittstelle Verbirgt gar nicht so Übel. Denkbar wäre auch eine
z.B.128MB Karte wobei der Emulator eine 256 MB Karte vorgaukelt. Die
zweite Partition von 125MB bindet auf transparente Weise externe
Hardware zB. Temperatursensoren ein.
Im Gegensatz zur IGOR Lösung möchte ich den USB Teil nicht via Software
erledigen sonder mit einem "billigen" Standard USB Cardreader.
Vorstellung:
Ich stecke einen Adapter in den SD-Slot auf dem sich mein Atmega mit
SD-Card und Prozeßanbindung befindet. Die Anbindung an den PC erfolgt
mit der Standardsoftware über die USB Schnittstelle.
Über den Wert einer solchen Anbindung kann man unterschiedlicher
Meinung sein, darüber möchte ich jedoch nicht diskutieren.

Ich hätte gerne von der "erfahrenen" Projektentwicklern von  USB bzw.
MMC/SD Anbindungen ein Statement über die Machbarkeit.
Für mich sieht es nach einem ersten Studium der beiden Projekte (USB
MMC/SD) so aus al müßte das gehen.

Mfg
Achim

Ps.:@Rufus T. Firefly ich möchte damit  gesichert niemanden
Beindrucken... Mir geht es ausschließlich um mein neues Hobby Atmel.
Die Anerkennung im Geschäft habe ich durch meinen Gehalt. Verzicht auf
Ausrufezeichen...Bitte aber keine Diskussionen mehr in dieser Richtung.
Sollte da was falsches angekommen sein, SORRY! Mir geht es nur um die
sachliche(fachliche) Diskussion wozu das Forum in erster Linie auch da
ist.
Ich habe von diesem Forum schon sehr viel über die Atmel Welt gelernt.
Dafür Allen vielen Dank. Ich hoffe ich kann irgendwann auch was in
diesem Forum zurückgeben. Danke.

Die Software-USB-Anbindung von Igor ist nett, aber hier wahrscheinlich
fehl am Platze.
Einerseits ist das - wie üblich - ein USB-Device (das an einen Host
angeschlossen wird), also nicht dazu geeignet, einem AVR die
Kommunikation mit anderen USB-Devices zu ermöglichen.
Andererseits ist das ein *Low-Speed*-Device, das also nur mit 1.5
MBit/sec angesprochen wird, wie Tastaturen und Mäuse.
Ob die USB-Spezifikation es vorsieht, daß ein "Mass Storage Device"
über eine Low-Speed-Schnittstelle angesteuert werden kann, entzieht
sich meiner Kenntnis, ich würde aber (als Skeptiker, der ich bin) nicht
davon ausgehen.
Wenn aber kein "Mass Storage Device" implementiert wird, dann kann
man sich den ganzen Aufriß auch sparen und ein wesentlich
unkomplizierteres Hardware-IC verwenden, das - im Gegensatz zum
Igor-Interface - auch als echte virtuelle serielle Schnittstelle
angesprochen werden kann (FT232 bzw. FT245), ohne daß spezielle
Interface-DLLs auf der PC-Seite verwendet werden müssen.
Das entfernt sich von der hier ursprünglich angedachten Lösung doch
recht weit.

Das USB-Lowspeed-Interface arbeitet, wie bereits erwähnt, mit 1.5
MBit/sec - ob die von Igor verwendeten Mechanismen aber auf das
bedeutend schnellere SD-Karten-Interface umgesetzt werden können, wo
bereits die Igor-Lösung ein Übertakten des Prozessors (Betrieb mit 12
statt 8 MHz) erfordert?

Was die Emulation des SD-Interfaces betrifft:
Selbst wenn SD-Karten ein Interface mit Handshake-Leitungen besitzen,
und dieses Interface einen Mechanismus vorsieht, um einem lesenden
Device klarzumachen, daß es noch einen Moment warten muss, impliziert
das noch lange nicht, daß es möglich ist, dieses Interface mit einem
Microcontroller zu emulieren.
Bei den bei SD-Karten üblichen Datenübertragungsraten von - was weiß
ich - etwa 1 MByte/sec oder mehr wird davon auszugehen sein, daß es
gewisse Mindestanforderungen für die Geschwindigkeit gibt, mit der eine
SD-Karte auf Lesezugriffe antworten muss.
Und die wird signifikant über der mit einer Softwareimplementierung des
Interface erreichbaren Geschwindigkeit liegen.
Ein Kartenleser wird die Zusammenarbeit mit einer "grottenlangsamen"
SD-Karte schlichtweg verweigern, weil er diese für defekt hält.
Näheres kann man nur der SD-Spezifikation entnehmen, die ich jetzt
gerade nicht auswendig kenne. Bitte: Beschaffen und durchlesen.

Andersrum wird ein Schuh draus:
Der SD-Karte ist's annähernd egal, wie schnell sie gelesen wird -
daher ist es natürlich nicht sonderlich schwierig, eine SD-Karte mit
einem Microcontroller zu lesen. Daraus aber den Umkehrschluss
abzuleiten, daß es deswegen auch möglich sein muss, eine SD-Karte zu
simulieren, ist schlichtweg falsch.
(olaf hat hierzu auch einige aufschlussreiche Anmerkungen von sich
gegeben).

Außerdem:
SD-Karten haben keine "file-Schnittstelle", sondern sind, wie alle
anderen Speichermedien auch, blockorientiert aufgebaut. Dateien werden
vom Betriebssystem des Systemes verwaltet, an die das Speichermedium
angeschlossen ist (Wie oft muss ich das eigentlich wiederholen?).
Damit ist die - zunächst durchaus nicht unlogisch erscheinende -
Anbindung über eine simulierte Speicherkarte in einem
Standardkartenleser nicht ohne großen Aufwand auf der auf PC-Seite zu
entwickelnden Software möglich.

Der PC, an den der Speicherkartenleser nebst (simulierter)
Speicherkarte angeschlossen ist, rechnet eben nicht damit, daß sich das
Dateisystem auf der Speicherkarte gewissermaßen "hinter seinem Rücken"
ändert, was bei der vorgeschlagenen Lösung aber der Fall wäre.
Daher müsste die Software auf dem PC die Speicherkarte als Block-Device
unter Umgehung des Dateisystemes ansprechen (nichts anderes tut der in
diesem Thread bereits erwähnte Hex-Editor). Das ist natürlich möglich,
stellt aber das Grundkonzept in Frage, weil es dann eben nicht mehr
elegant und einfach wird.

Ein eleganter und einfacher Zugriff auf Dateiebene ist IMHO nur über
ein Netzwerkinterface möglich - und das kann sogar (via PPP) über eine
serielle Schnittstelle implementiert werden, bedarf also keinerlei
komplizierter oder schwer zu beschaffender Hardware.
Hierfür ist lediglich ein TCP/IP-Stack auf dem Prozessor zu
implementieren (das geht sogar auf PICs und der MCS51-Familie), der
über PPP (oder SLIP) mit der Außenwelt kommuniziert. Den Stack benutzt
ein FTP-Server oder Webserver, der auf Anforderung die gewünschten
Daten liefert.
Das ist einfach und ausreichend oft von anderen Leuten implementiert
worden.
Wenn eine größere Geschwindigkeit gefordert ist, als mit einer
seriellen Schnittstelle (und PPP/SLIP) erreichbar, dann wird halt ein
einfacher Ethernet-Controller (RTL8019) an den Microcontroller
drangehängt und ein echtes 10 MBit-Netzwerk verwendet. Auch kein
Problem, wurde auch ausreichend oft gemacht.
Auf der Anwendungssoftwareseite wäre das auch keinerlei Unterschied,
der Zugriff auf einen Web/FTP-Server ist vom Transportmedium
unabhängig.
Dazu muss kein Dateisystem implementiert werden, ebensowenig müssen auf
der Anwendungsseite irgendwelche speziellen Klimmzüge durchgeführt
werden (Blockdevice, Sektorweiser "Datei"-Zugriff etc.).

Also: Warum nicht so? Warum an einer aus mehreren Gründen
(SD-Emulation, Dateisystem) problematischen Lösung festhalten?

Hallo

@Rufus T. Firefly vielen Dank für Deine ausführliche Antwort.

Ich wollte nie das IGOR Interface dazu verwenden (siehe oben)...
...
Ich möchte aber nicht eine
Atmel/Software Lösung sondern einen USB Cardreader
....

Diese Lösung hatte ich nur erwähnt, da ein Prozessor dies Softwaremäßig
emuliert und daraus abgeleitet, daß die von mir angestrebte Card-Reader
Lösung vom Ansatz her gehen müßte. AdapterKarte in den SD-Schlitz und
fertig ist die Anbindung auf der PC-Seite, das ist mein Ziel.

Der EMU sollte natürlich schon ein Filesystem mit FAT emulieren, daher
das hartnäckige festhalten an der "File-Schnittstelle". Falls man
nicht mit dem WindowsExplorer auf den I/O Bereich mit "Drag and Drop"
lesen kann wäre das Ziel verfehlt. Ferner sollte man schon mit Excel mit
Datei laden (nicht auf der Ebene Sektor 326 und 456 halb ladene)einen
Sensorbereich laden können Ich möchte nicht vom PC aus Sektoren etc.
verwalten. Der PC sieht nur das FileSystem. Das Verwalten macht der
EMU. Die Geschwindigkeit ist egal. Diese ist in jedem Fall schnell
genug, falls es überhaubt geht.

TCP/IP Stack ist ne ganz andere Baustelle. Für so ne Ankopplung würde
ich zum Beispiel das Tini-Board von DALLAS bzw. Maxim nehmen. Oder ein
ITX basierendes System. Das wäre eine ganz andere Zielsetzung.

Nochmal es geht nicht um rechthaberei sonder alleine um die
Machbarkeit.

MfG
Achim

Filesystem: Genau darum geht es aber. Eine SD-Karte ist, wie jede andere
Speicherkarte auch, eben kein Filesystem und wird vom Rechner, an den
sie angeschlossen ist, eben nicht als Dateisystem, sondern als
Blockdevice angesprochen.
Ein auf der Karte abgelegtes Dateisystem wird vollständig vom PC
verwaltet - die Karte sieht nur Sektor/Block-Zugriffe.
Und so sieht auch die Hardwareschnittstelle der Karte ausschließlich
Sektor/Block-Zugriffe.

Und so sollte allmählich klar werden, wo das Problem begraben liegt.

Dem PC 'hintenrum' in sein von ihm verwaltetes Dateisystem
reinzuschreiben ist eben nicht angesagt, weil er das nicht mitbekommt.

Da Dateisysteme üblicherweise über einen Lesecache angesprochen werden,
würde ein wiederholtes Lesen ein und der selben Datei (und Ändern eines
Sektors der Datei durch den "Kartensimulator") auch zu keinem Erfolg
führen, da der PC sich nicht genötigt sieht, die Daten erneut aus der
Speicherkarte in den Cache zu lesen.

Fällt der Groschen* jetzt?


*) Groschen, ehemalige Währungseinheit in Österreich bzw. Ugs. für
"10-Pfennig-Münze"

Hallo

@Rufus T. Firefly für solche Probleme wurden  die Befehle flush, fopen,
 fclose ... bei den Programmiersprachen  erfunden.
Außererdem ist es so, das wenn zB.: ein File in einem Editor geladen
ist und dieser File in einem anderen Editor verändert wurde nachgefragt
wird ob der File neu geladen werden soll.
Es gibt in fast jedem mir bekannten Programm dieser Art einen
"RELOAD", bzw. "REFRESCH" Knopf, welcher ein erneutes Laden der
Datei durchführt und dieses sicherlich nicht aus dem Cache..... odder?

Nimm einfach mal einen einfachen WebBrowser und lade dort eine BS
Textdatei ändere mit einem Editor den Text (abspeichern nicht
vergessen) und DU wirst erstaunt sein was man nach einem RELOAD sieht.
Stell dir nun die Textdatei steht auf einer SD-Karte da gehts auch.
Dann stell Dir vor das kommt vom EMU...

Bei der Radig, Klabunde etc. Anbindung der MMC/SD Karten wird das FAT16
Filesystem auch vom Atmega verwaltet. Wo ist also das Problem?

MfG
Achim

*)insofern ist der Groschen noch nicht gefallen.

flush und Konsorten bewirken mitnichten, daß das OS seinen Lesecache
leert und eine Datei erneut vom Speichermedium liest. Das betrifft nur
das Handling von Dateien am "anderen Ende" eines
Dateisystemtreibers.

Der Vergleich mit zwei unterschiedlichen Texteditoren oder
Editor/Webbrowser hinkt, da in diesem Falle ein und derselbe
Dateisystemtreiber die Datei beschreibt, also sehr wohl mitbekommt, daß
die Datei verändert wird.
So eine Konstellation liegt aber hier nicht vor.

Nein, der Groschen scheint wirklich noch nicht gefallen zu sein.

Auch die Tatsache, daß man ein FAT-Dateisystem mit einem
Microcontroller ansprechen kann, hilft hier nicht - zuviele Köche
verderben den Brei bzw. zwei Dateisystemtreiber können nicht ohne
Synchronisationsmechanismen auf ein und dasselbe Dateisystem zugreifen.
Und genau da liegt der Hase im Pfeffer - es gibt keinen
Synchronisationsmechanismus.
Vielleicht zum Vergleich folgendes Konstrukt:
Man nehme zwei PCs mit SCSI-Controller, eine SCSI-Platte und verbinde
alles miteinander (und sorge dafür, daß der eine SCSI-Controller eine
andere SCSI-ID als der andere erhält). So ist - hardwareseitig - der
mehr oder weniger simultane Zugriff zweier PCs auf eine Festplatte
realisierbar.
Und das Resultat?
Feinster Datensalat - weil der eine PC nicht mitbekommt, daß der andere
schreibt, werden alle Änderungen, die durchgeführt werden, nicht
erkannt. Spätestens beim Anlegen von Dateien oder Vergrößern von
Dateien geht das allerschönstens in die Hose.

Damit das ganze funktioniert, müsste der Dateisystemtreiber des PCs
dazu gebracht werden, vor jedem einzelnen Lesezugriff das komplette
Dateisystem neu zu initialisieren - d.h. die FAT einzulesen und zu
interpretieren und auch die Directoryeinträge der betreffenden Dateien
neu zu lesen.

Und selbst das hülfe nicht, da der PC nicht herausfinden kann, wann der
am anderen Ende befindliche PC damit fertig ist, im Dateisystem
herumzufuhrwerken.

Genauso sieht es beim SD-Simulanten aus, auch der weiß nicht, wann der
PC seine Daten abgeholt hat resp. der PC weiß nicht, wann der Simulant
seine Daten zuende geschrieben hat.

Ist das jetzt vielleicht eine Groschenfallhilfe?

Hallo,

euer Thread ist wirklich sehr sehr interessant. Ich habe ein ähnlich
gelagertes Problem. Will diese Diskussion hier aber nicht stören.
Eventuell könntet Ihr mal bitte meine Frage lesen?

Vielen Dank
Björn

Hallo womisa,

Du kennst dich mit der Programmierung auf PC-Ebene aus. Gut. Und
möchtest bischen Mikrocontroller lernen. Gut. Irgendwelche von dem
Controller gemessenen Daten sollen nun unbedingt als "Dateien" auf
"dem Desktop" "sichtbar" sein. Nagut, wenn man es braucht. Also
mein Vorschlag unter Berücksichtigung deiner Vorkenntnisse (spart
Zeit!):
- Atmel-Controller (evtl. mit externem eeprom oder mmc-Karte wenn viele
Messdaten gespeichert werden sollen) mit 5Eur-USB-Controller oder 5-EUR
USB-Seriell-Kabel an den PC
- Der Atmel stelle über die Schnittstelle einfach Befehle für das
Abfragen der Daten bereit. (z.B. "Gib alle Daten von Adresse 0 bis
1023" aus)
Soweit ist aller machbar und hier und auf anderen Seiten gut
dokumentiert.
Und jetzt kommts:
- Auf dem PC läuft ein von dir geschriebener Dienst, der nach deinem
Gerät sucht, und, sobald eins gefunden wurde, komplett alle Daten
ausliest und sie in ein frei wählbares Verzeichnis schiebt. Je nach
Anforderung sogar in Echtzeit (sobald neuer Messwert eintrifft, wird
die "Messdatei" erweitert usw.). Somit brauchst du auch kein tcp-ip
und ftp usw. auf dem Controller.

Wenn du also das mit dem direktem Zugriff auf ne Datei brauchst/willst,
wird so vieles auf die PC-Seite verlagert, die du ja beherrschst. Und
von der Bedienung her merkt man auch keinen Unterschied. Die Kosten von
5EUR für nen usb-Chip oder ein entsprechendes usb-Seriell-Kabel bei epay
dürften auch deinen usb-Kartenleser noch unterbieten.

mfg,
STefan