Hallo Leute, ich habe einen Card Reader/writer von Aldi-Süd gekauft. Mein (naives?) Ziel ist es da irgendwie einen Atmegaxx dran zu bauen. - Emulation einer CF Karte? - Emulation einer SD Karte? - Emulation einer SM Karte? - Emulation eines Ms Karte? ==> CF würde sich anbieten von der Größe des Einschubs ==> SD würde sich anbieten von der Einfachheit? Oder: -intern was dranbauen? Da meine Hardwarekenntnisse jedoch nicht ausgeprägt sind ist das "letzte" schwierig? Intern ist ein "Tausendfüssler" SI IC1210 M128LQ (?) http://www.icsi.com.tw/english/products/logic.htm Die "GOOGLE"-Informationensind bis jetzt spärlich ausgefallen. Das Datasheet muß man anfordern? Ist sowas üblich? Angaben: -USB1.1/2.0 -IIC (Ext. Flash ROM) Hat jemand in dieser Richtung schon geforscht? Hat jemand das Datasheet vom icsi IC1210 M128LQ Ziel: -Ankopplung eines Atmega-Systems über einen Standard USB-Read/Writer - Vom PC aus kann man dann auf jede Karte kopieren zB.: Atmega als MMC Einschub auf SD-Card etc... - oder eine SD - Emulator wird als datenerfassung-slot mißbraucht ein Memoryblock wird auf IO's umgelenkt? Ist das Ganze gespinne oder was meinen die Experten? MfG Achim
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
Bitte 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.