Hallo Ich möchte meinen Atmel (und PSoc) mit einem USB Interface versehen. Die Lösungen die ich gefunden habe, sind sehr teuer (>30 Euro) oder aufwendig (SMD) oder beides. Dann hab ich bei eBay die leeren Festplattengehäuse mit USB 2.0 Interface entdeckt die für 5 bis 20 Euro zu haben sind. Je nach Model mit Kabelsatz, Stromversorgung, Chipsatz und eben auch, einem oft recht ansprechenden, Gehäuse. Es wäre doch eine Möglichkeit den MC dort rein zu pfriemeln und so einen kostengünstigen USB Anschluss in einem schmucken Gehäuse zu haben. Der Software auf der PC-Seite würde der MC als externe Harddisk erscheinen und könnte so sehr einfach angesprochen werden. Allerdings herrscht in diesen Gehäusen die IDE. Weiss denn jemand was über das Protokoll? Und ob sich ein AVR oder PSoC dort anschliessen lässt? Oder bin ich hier total auf dem Holzweg? Peter
naja ich glaube einen IDE Clienten zu erstellen wird recht schwer. leichter ist es da schon mit einem AVR eine IDE Festplatte oder so anzusteuern. Für deine Anwendung sehe ich da allerdings schwarz. Da gibt es doch diese netten USB Chips, welche dem rechner eine virtuelle COM schnittstelle vorgaukeln, die sind doch perfekt für deine ansprüche. Und was hast du gegen SMD? Wenn du allerdings einen PIC verwenden möchstest: Die neuen PIC18F haben auch schon ne USB Schnitstelle (teilweise 2.0) integriert.
jo bist scho aufn holzweg, oba der is gonz sche morsch scho hahhahaha, denk da liaba wos gscheites aus ois wia nur bledidln
@Netbandit: Danke für den Tipp mit dem PIC18F. Die USB Chips von FTDI schon eine feine Sache - aber sie sind eben nur in SMD zu haben. Und ich hab zu unruhige Finger für sowas ;-) Diese Chips gibt es aber auch schon fertig aufgebaut auf einer Platine mit Steckkontakten für DIL 28 mit Quarz und Buchse und so. Aber die kosten > 30 Euro plus Transport aus England.
ja da sind dann die PIC wohl eine wirklich gute Lösung, die gibt es in der Regel auch als PDIP... gucke mal auf www.sprut.de der hat da ne Tabelle mit allen möglichen PICs dort steht welche PIC18F in PDIP zur verfügung stehen und USB haben.
Bei dieser Sache solltest du beachten,daß zu jedem USB-Gerät auch ein entsprechender Windowstreiber gehört.Du kannst dann nur die Funktionen nutzen die dieser Treiber bietet.Abdesehen davon müsstest du mir dem AVR eine Festplatte mit dem entsprechenden Timing nachbilden.Und wenn Du dazu noch die Anzehl der benötigten Pins in Betracht ziehst habe ich meine Zweifel an deinem Projekt. USB zu Seriell Wandler sind übrigens auch in Deutschland erhältlich (Conrad,ELV,Reichelt...). MfG Hartmut
Ich habe das mal gemacht - allerdings mit einem FPGA. Funktionierte super und im Gegensatz zu den FTDI Chips sehr schnell (> 40MBit/s, 5MByte/s) und ohne Treiber (da MassStorage kompatibel und simples Dateien-IO, fread, ...). Für Controller oder Bastelprojekt aber wohl ein bischen zu viel. jörn
@Jörn G. Das interessiert mich. Kannst Du da bitte nähere Infos posten? Gruß Michael
Habe nichts hier, was ich so einfach posten könnte. Zudem war das doch alles recht kompliziert (vor allem rauszufinden, welche ATA-Specs + Commands wichtig sind, welche man weglassen kann und welche vom PC-Bios Hersteller, bzw ATA-Bridge-Hersteller falsch benutzt werden). War ca. 1 Jahr Arbeit und mündete in meiner Studienarbeit. Ohne FPGA macht das aber wohl absolut keinen Sinn, da die Adressier-, Lese-Schreiboperationen schon "in Hardware" dekodiert und ausgeführt werden müssen, damit das Sinn macht, ansonsten wird das langsamer als alles andere und man kann sich die Arbeit sparen. Ich habe ATA, Plattenplatz, und Inhalte simuliert damals, mit virtuellen Dateien usw. Man konnte sogar davon DOS booten und dann einfach eine Textdatei öffnen, einen Befehl reinschreiben, speichern und das FPGA hat dann z.B. eine LED geschaltet - das war aber eher Spass. Lustig war auch, mit einem Tastendruck den Inhalt einer Datei zu verändern. Also erst steht in input.txt drin "No Button" und bei Tastendruck am FPGA liest man anschliessend plötzlich "Button 1 pressed" in der selben Textdatei. Schön war auch dass aufgrund von ATA und Massstorage, das ganze direkt ohne Bridge-Adapter unter DOS, mit Firewire oder USB-Bridge unter Mac, Windows und Linux sofort ging, ohne Treiber zu installieren. Die Datenübertragung muß man schon richtig über Winapi Dateioperationen machen, da Windows ansonsten alles cached und gar nicht erst neue Daten von der virtuellen Festplatte anfordert. Heute würde ich das aber evtl. anders machen. Ich würde wohl einen USB2.0-Flashdrive nehmen und dann nur den Flash-Chip simulieren mit einem FPGA. Ein Flashdrive mit 64MB bekommt man heute ja eigentlich geschenkt - dann vielleicht Flash runterschneiden/löten oder zumindest so einen Chip nehmen und eine kleine Platine selber machen. Also ein Interface bauen, dass so einen Flashchip simuliert. Dann von "hinten" Daten reinschieben in den virtuellen Flash. Microcontroller kann aber sowas sicherlich nicht, da die Timing dann noch kürzer sind, als bei z.B. PIO ATA. Das würde aber vermutlich schneller sein, da man weniger Aufwand damit verbrät Dateisystem usw. zu simulieren. Wenn es ganz ganz einfach (und nicht extrem schnell) sein soll, dann würde ich vielleicht auch einen einfachen CPLD nehmen, der nur als Schnittstelle zwischen einem DSP/Controller und einer ATA-USB-Bridge fungiert. Also Adressdekodieren und Abbilden alleinig der 14 ATA-Register. Dann würde zumindest dieses Timing-kritische Zeugs "in Hardware ablaufen". Filesystem muß man nicht simulieren, man kann ja auch von WIndows problemlos z.B. die Daten immer von einem ganz bestimmten Festplattensektor lesen und beim Senden in einem anderen Sektor schreiben - auch auf einer "unformatierten virtuellen Festplatte". Die wichtigsten Befehle "identify drive, read sectors, ..." muß man aber natürlich in jedem Fall 100% OK implementieren, da ansonsten gar keine Festplatte unter Windows erkannt wird. Ob das evtl. sogar 100% (langsam) auf einem AVR passieren könnte? Ich bin mir gar nicht so sicher damit derzeit... Mmm mal nachsehen... Also nach dem setzen der Adressleitungen, gibts ne kurze Pause und dann "muß der PC (die Bridge) mindestens 80ns Read oder Write anlegen" - das ist zu kurz für einen AVR, um die Adresse zu dekodieren und die Daten einzulesen oder auszugeben - also doch keine Chance ohne CPLD/FPGA. jörn
Herzlichen Dank an alle und speziell an Jörn! Auch wenn (wieder mal) eine Idee gestorben ist. Besser so, als nach zig schlaflosen Nächten. Peter
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.