Hallo Forum,
weiß jemand, ob es solche firmware gibt?
Danke im Voraus!
Druckbare Version
Hallo Forum,
weiß jemand, ob es solche firmware gibt?
Danke im Voraus!
Die Frage versteh ich nicht.
Meinst du eine Firmware, damit du den Tiny26 als USB-Gerät betreiben kannst? So wie es Igor Cesko mit einem AT90S2313 gemacht hat?
Ich bin neu auf dem Gebiet und kenne Igor Cesko leider nicht.
Aber du hast schon recht mit deiner Vermutung. Ich suche Firmware, mit der man den Tiny26 als USB-Gerät betreiben kann. So wie z.b. der CY7C63001A-PC von cypress:
http://www.ak-modul-bus.com/cgi-bin/iboshop.cgi?showd180!0,38830823426670,CY7C63001AFW
Gibt es nicht (bin ich mir zu 99,3% sicher). Für ein 90S2313 würd's sowas geben. Aber auch nur beschränkt.
Was hast du denn genauer vor? Warum muss es ein Tiny26 sein? Vielleicht gibt es andere Lösungen.
89XXXXX von Atmel gibt es mit USB: PICs auch glaube ich.
Aber vielleicht geht ja auch ein AVR?!
also um mein ganzes projekt zu beschreiben, müsste ich ziemlich weit ausholen. :)
um es kurz zu fassen, muss ich die ports eines microcontrollers über usb ansprechen können...unbedingt mit linux, windows kommt leider nicht in frage. die pegel an den ports werden dann verstärkt und an die elektromotoren von einem kettenfahrzeug weitergeleitet...ich will also ein rc-fahrzeug mit einem laptop steuern. klingt ziemlich verrückt, ist aber ein interessantes projekt, zumal ich das als werkstudent mache.
ich habe den controller von cypress einem der betreuungsingeniuere vorgeschlagen, soll aber nach einer günstigeren variante schauen
Bei ELV gibt's nen USB Bausatz,
ich glaub, der setzt in RS232 TTL um.
Hat 'ne eigene Firmware und Treiber dabei.
Optisch getrenntes USB-Modul UO 100, Komplettbausatz Artikel-Nr.: 68-537-89
Optisch getrenntes USB-Modul UO 100, Fertiggerät Artikel-Nr.: 68-538-66
USB-Modul UM 100, Fertiggerät Artikel-Nr.: 68-496-59
USB-Modul UM 100, Komplettbausatz Artikel-Nr.: 68-525-95
Also muss nicht der Tiny26 USB 'verstehen' können, sondern es geht nur drum, Daten vom PC (Laptop) in den Tiny zu bringen, der auf Grund der Daten sein Verhalten ändert?
Muss es ein Tiny26 sein? Der hat zufällig keine RS232 Schnittstelle. Aber Der Mega8 z.B. hätte eine. Oder einige 90S haben glaube ich eine.
Dann würd ich das über RS232 machen. Und vor dem AVR kommt ein Wandler USB <--> RS232 (TTL) FT232 bei Reichelt biete sich da an.
Auf der HP von FDI findest du (wenn es welche gibt) Treiber für Linux.
Unter Windows hättest du dann ein virtuellen COM-Port. Bei Linux dann halt /dev/duwirstschonwissenwiedasbeilinuxheisst.
Wie wäre es damit?
Dann musst du/ihr dich/euch nur auf die Programmierung des AVR konzentrieren.
Den Link zu Igors AVR <--> USB such ich dir noch raus. Aber da wird's mit der Programmierung schwerer. Vor allem, da er für Linux keine Treiber hat (glaube ich zumindest).
hi,
danke erstmal für eure Vorschläge. Ich habe jetzt die Datenblätter der beiden Microcontroller verglichen(tiny26 und CY7C63001A-PC). Der entscheidende Unterschied ist, dass der Tiny kein USB-Interface hat. Beim CY7C63001A-PC ist das USB-Interface, wenn ich mich nicht irre, ein Hardwaremodul. Mein Betreuungsingenieur meint aber, dass sich ein USB-Interface auch programmieren lässt...Voraussetzung wären natürlich gute Assembler -und perfekt USB-Protokol-Kenntnisse. Und beim Implementieren eines passenden Treibers wäre man ja auch auf sich allein gestellt.
Also ich will ja nicht die Kompetenzen des Mannes in Frage stellen, ich denke auch, dass es möglich sein muss. Aber kann mir das vielleicht trotzdem nochmal jemand bestätigen, der sich gut mit Microcontrollerprogrammierung auskennt, bevor ich diesen schweren Weg einschlage, der Möglicherweise gar nicht zum Ziel führt?
http://www.cesko.host.sk/IgorPlugUSB/IgorPlug-USB%20(AVR)_eng.htm
Das wäre "Software-USB" für AVRs.
Der Quellcode steht irgendwo zum Download. Atmel hat dafür auch eine AppNote.
Viel Erfolg damit ;)
Ich hab's mal nachgenaut, es funktioniert. Aber wenn es zuverlässig sein soll, würde ich lieber ein FT232 nehmen.
Es geht also. Und um den Treiber musst du dich wirklichmehr oder weniger alleine kümmern. Da ist die Frage, ob der Aufwand lohnt, oder ob es für dieses Projekt explizit gefordert ist, USB durch einen µC zu realisieren.
Hey, das ist ja heißer Stoff! Genau was ich brauche, danke! Und nebenbei kann ich dann auch meine Englischkenntnisse etwas auffrischen.
Also es ist zwar nicht explizit gefordert, die Schnittstelle zum rc-Fahrzeug über einen Microcontroller zu realisieren, aber um ehrlich zu sein, wüßte ich keine andere Möglichkeit, USB-Daten anders als mit einem Microcontroller zu verarbeiten. Woran hast du denn gedacht?
Es wird vielleicht ein großer Aufwand, aber ich sehe das als Herausforderung...wenn ich es schaffe, mich da richtig einzuarbeiten, habe ich einen grund stolz zu sein, glaube ich. Außerdem wäre das ein guter Grund, meinen Vertrag als Werkstudenten zu verlängern ;)
ämmm, es ist bestimmt eine dumme Frage, aber kannst du einem Anfänger vielleicht erklären, was eine AppNote ist?
Sorry, AppNote = Applicaton Note. Weiterführende Dokumentation von Atmel zu bestimmten Themen. z.B. Für RC5 senden, die Resetbeschaltung der AVRs, ... hier Gibt's die.
Die für USB hab ich nicht gefunden, aber bei Igor ist die in irgendeinem Download mit drin.
Erfolge beim umschreiben bitte gleich posten. Da hätte ich evtl auch Interesse dran.
Aber wie gesagt, ich hätte das über RS232 gemacht. Der AVR empfängt dann Befehle so in der Art wie füher die Modems. *links#, *ext1#, *stop# oder so in der Art. Alles was zwischen * und # ist der Befehl, der ausgeführt werden soll. In diesem Fall nach links fahren, zusätzliche Funktion Nr. 1 ausführen (Licht an oder so), alle Funktionen sofort anhalten.
Und um es von USB in den AVR zu bekommen, dann über einen Schnittstellenwandler wie FT232. http://www.ftdichip.com/ Hab grad nachgeschaut, Treiber für Linux scheint es zu geben.
Unter Windows hätte ich dann erstmal ein Terminal Emulator genommen um das Ausführen der Aktion zu übermitteln und dann später mit Visual Basic eine einefach Oberfläche geschrieben, die Pro Button ein Befehl über den virtuellen COM-Port schickt.
Hi, heute ist wieder mal Arbeitstag. Wir haben uns jetzt ersteinmal darauf geeinigt, eine ganz einfache Variante zu wählen, damit ich im Projekt vorankomme. Wir haben einen USB-zu-Parallel-Umsetzter bestellt. Dieser arbeitet mit dem FT245BM von FTDI. Danke für deinen Tipp, Marco!
Das soll aber nicht heißen, dass ich die komplizierte Lösung ganz verwerfe. Ich würde schon gerne selbst mal Treiber -und Firmwareprogrammierung lernen. Das werde ich dann in Angriff nehmen, sobald das Projekt mit der "einfachen" Lösung funktioniert.
Edit: Hier ist übrigens das gute Stück:
http://elmicro.com/de/dlpusb245m.html
Im data sheet habe ich übrigens auch folgendes gefunden:
sieht aus, als bräuchte ich zusätzlich noch einen Microcontroller. Finde ich irgendwie komisch. Warum kann man die Daten nicht einfach von den Datenleitungen(D0-D7) ablesen und verstärken?Zitat:
...At this point the DLP-USB245M is ready for use. Note that the DLP-USB245M will appear non-responsive if data sent from the host PC is not read from the FT245BM device by an attached microcontroller/microprocessor/DSP/FPGA/etc…
du kannst. Musst mal nach dem "Bit Banging" suchen, der FTDI kann dass. Wie kompliziert das ist hab ich allerdings keine Ahnung.Zitat:
Zitat von icecreamman
Der 'normale' LPT am PC hat eine feste (ok, sie ist einstellbar, aber danach ist sie auch festgelegt) Hardwareadresse(n). Die Adressewird einfach angesprochen und die jeweiligen Bits gesetzt/gelesen.
Wenn man z.B. ein LCD am LPT anschliesst und mit gäniger Software betreibt, werden da nicht wie beim Drucker (und dafür war der Anschluss damals nur. Deshalb haben die Leitungen/Adressen auch Namen wie Error, Paperout, ...) die Bits der Buchstaben parallel gesendet, sondern einfach nur die benötigten Bits direkt angesprochen.
Umsetzer von USB auf LPT/COM können das meistens nicht mehr. Am COM-Port kann man (sogar ohne Vorwiderstand) einfach eine LED anschliessen, und z.B. das Bit für TxD setzen und die LED leuchtet. Bei vielen (es gibt auch Ausnahmen) Wandlern von USB geht das auch nicht mehr. Die kümmern sich nur um das Übertragen der Daten und evtl um das Übermitteln eines Statuses (Paper Out, ...)
Entweder das Bit Banging wie bluebrother sagte verwenden, oder zum µC ein Text/Code schicken, der dann ausgewertet wird.
Also ich habe jetzt die AppNote über Bit Bang Mode gelesen. Es scheint genau das richtige zu sein. Denn dabei werden die an das Device gesendete Daten direkt an die Datenpins gelegt.
http://www.ftdichip.com/Documents/Ap...01_BitBang.pdf
Ich hatte dieses mal leider keine Zeit, es auszuprobieren(das Teil ist schon bestellt). Ich bin mir immer noch nicht sicher, ob ich es auch ohne einen angeschlossenen Microcontroller verwenden kann. Im Datenblatt stand ja, dass der DLP-USB245M nicht antwortet, solange kein µC dran ist. Dass im Bit Bang Modus kein µC benötigt wird, hätten sie doch dabei geschrieben oder hab ich da was falsch verstanden?
Also es geht tatsächlich auch ohne µC. Ich habe jetzt ein anderes Problem. Die Funktion FT_GetBitMode, die den Zustand an den Datenpins ausliest, funktioniert nicht.
Hat vielleicht jemand ähnliche Erfahrungen gemacht? Woran könnte das liegen? :-k