Hi, ich plane zur Zeit ein Projekt mit dem USBN9604 als PC-Schnittstelle zu realisieren. Allerdings sagt National, dass der Chip nicht mehr für neue Designs empfohlen wird, zeigt allerdings keine Alternativen auf. Gibt es da irgendetwas vergleichbares (Features, Package, Preis), was man da stattdessen heutzutage verwenden sollte/kann? Grüße, Chris
Das duerfte wohl seinen Grund darin haben das man in Anwendungen wo frueher der USBN eingesetzt wurde, heute einen Microcontroller mit integriertem USB Interface einsetzt. Und davon gibt es ja jede Menge von fast jedem Hersteller. Solltest du das vorhaben schau dir mal den noch recht neuen M16C/6C an. Es gibt eine ziemliche gute Unterstuetzung von Renesas was Treiber und Beispielsoft angeht. Das nimmt einen eine MENGE Arbeit ab. Olaf
Hi Olaf, danke für die Antwort =) Die Mikrocontroller-Plattform (Fujitsu 16FX) steht bei mir allerdings schon fest und integriertes USB gibt es da dann nicht (bzw nur einen in einem 144er Package, das ist für die Anwendung völlig oversized). Daher suche ich ganz speziell nach so einem dedizierten USB-Controller. Kann ja eigentlich auch nicht sein, dass es das heutzutage ausschließlich über uC mit integriertem Controller gibt :( Grüße, Chris
dann nimm einen ftdi, dann hast einen seriellen oder parallelen bus zum anknoten an deinen µC
Hi, FTDI hat (soweit ich das überblicken kann) nur special purpose Controller, sprich UART/FIFO (bzw bei manchen noch mit so extras wie SPI etc). Das hilft mir aber nicht, da ich direkten USB-Zugriff brauche. Das einzige was wohl grob in die Richtung ginge wäre der VNC1L, aber so ganz direkt ist das dann ja auch nicht mehr :( Grüße, Chris
Dann nimm doch den kleinsten Controller mit integriertem USB und tue einfach so als ob das dein neuer USBN Ersatz ist. :-) Allerdings wenn es von Fujitsu ein groesseres Modell mit USB gaebe dann wuerde ich den auch nehmen. Das ist doch wohl einfacher und billiger einen fetteren Controller zu nehmen als zwei Bausteine, Quarze, Platinenflaecher usw, zu verschwenden. Klar, man fuehlt sich komisch wenn von 144Pinnen dann 80 unbenutzt sind, aber da muss man dann durch. Kannst du ja ordentlich Debugging Infos ausgeben. :-D Ausserdem wenn du mit den FTDIs nicht leben kannst dann doch wohl weil du bestimmte Ansprueche an Uebertragungrate oder Reaktionszeit hast. Dann bietet sich doch auch an sich das USB direkt in den Prozessor zu holen. Es gab aber auch noch einen anderen USB Controller. Mir faellt leider die Nummer nicht mehr ein, ST211 oder so aehnlich. Der konnte Slave und Host. Ich weiss aber nicht ob es den noch gibt. Oder nimm einen ISP1760. Der hat nur 128Pinne. :-) Olaf
Hi, Olaf schrieb: > Dann nimm doch den kleinsten Controller mit integriertem USB > und tue einfach so als ob das dein neuer USBN Ersatz ist. :-) Hm, könnte ich natürlich tun, aber dann bräuchte ich wieder ne zweite FW, müsste mir nen Protokoll für ein Interface ausdenken, andre Toolchain ... Gefällt mir nicht so wirklich ;) > Allerdings wenn es von Fujitsu ein groesseres Modell mit USB > gaebe dann wuerde ich den auch nehmen. Das ist doch wohl einfacher > und billiger einen fetteren Controller zu nehmen als zwei Bausteine, > Quarze, Platinenflaecher usw, zu verschwenden. Überlegt hab ich das ja schon, aber der Controller ist für Privat noch schwerer zu bekommen als der, den ich verwenden wollte. Davon abgesehen dürfte das mit dem externen USBN9604 eben nicht wirklich viel komplexer/teurer kommen, da dieser ja recht einfach zu verwenden ist (paralleler Bus, wenig externe Beschaltung). Und eine MCU mit USB kostet ja dafür auch mehr als eine ohne. > Klar, man fuehlt sich komisch wenn von 144Pinnen dann 80 unbenutzt sind, > aber da muss man dann durch. Kannst du ja ordentlich Debugging Infos > ausgeben. :-D Jau, 100 Diagnose-LEDs hätten schon was stylisches. Da könnte ich sogar gleich sämtliche Bits der empfangenen CAN-Messages 1:1 darstellen und mir das USB-Interface sparen ;) > Ausserdem wenn du mit den FTDIs nicht leben kannst dann doch wohl weil > du bestimmte Ansprueche an Uebertragungrate oder Reaktionszeit hast. > Dann bietet sich doch auch an sich das USB direkt in den Prozessor zu > holen. Jo, die FTDIs sind halt einfach zu spezialisiert und durch ihre Funktionen selber limitiert. Also zB die USB->RS232-Dinger können einfach nicht mehr als 1 MBit/s, und das ist (bei CAN 1 MBit/s) zu wenig. Ich brauche soweit ich das sehe halt einfach einen Controller, bei dem ich selber die USB-Pakete schnüren kann, da USB ja sonst auf Grund seiner Architektur doch eine sehr begrenzte Bandbreite liefert. Aber mit einem externen USB-Controller, wie dem USBN9604, dürfte ich recht gut hinkommen. Der kann selber USB 1.1 Full-Speed und durch das parallele Interface kann ich den einerseits extremst einfach ansteuern (quasi genauso einfach wie ein MCU-internes HW-Macro) als auch sehr schnell. > Es gab aber auch noch einen anderen USB Controller. Mir faellt leider > die Nummer nicht mehr ein, ST211 oder so aehnlich. Der konnte Slave und > Host. Ich weiss aber nicht ob es den noch gibt. > Oder nimm einen ISP1760. Der hat nur 128Pinne. :-) Jau, nen USB-Controller mit 128 Pins wenn ich mich schon gegen den uC mit USB mit 144 Pins sträube ;D Aber das andre schau ich mir nochmal an, danke für den Hinweis. @STK500-Besitzer: Den VNC1L hab ich mir die Tage auch mal angeschaut. So wie ich das sehe hat man da bald wieder mehr Arbeit, das Ding zu programmieren, als die eigentliche Applikation. Ist sicher für manche Applikationen ganz Nett, hier passt es denke ich eher nicht so gut ;) Grüße, Chris
und warum nicht etwas vom Cypress ? Natürlich können sachen wie "West Bridge Antioch" in BGA package (die anderen sind noch mehr oversized) sein, aber es kann genau so gut - vor allem um den USBN "ersetzen" ein FX2LP sein - SSOP oder QFN gehäuse. Zum coden gibts genug gute beispiele von Cypress, es sollte dich nicht länger als einen tag arbeit kosten um gleich funktion wie der USBN hatte zu erriechen.
> Also zB die USB->RS232-Dinger können > einfach nicht mehr als 1 MBit/s, und das ist (bei CAN 1 MBit/s) zu > wenig. Laut Datenblatt http://www.ftdichip.com/Documents/DataSheets/DS_FT232R_V205.pdf (jedenfalls für den FT232R - hab die anderen nicht angeschaut) stimmt das nicht. "This gives achievable baud rates in the range 183.1 baud to 3,000,000 baud" Also vielleicht doch wieder etwas interessanter geworden ;)
Christian Illy schrieb: > ich plane zur Zeit ein Projekt mit dem USBN9604 als PC-Schnittstelle zu > realisieren. Allerdings sagt National, dass der Chip nicht mehr für neue > Designs empfohlen wird > Überlegt hab ich das ja schon, aber der Controller ist für Privat noch > schwerer zu bekommen als der, den ich verwenden wollte. Um was geht es denn nun genau, privat oder gewerblich? Für ein privates Projekt spielt doch das "nicht für neue Designs empfohlen" praktisch keine Rolle. Wenn dir der USBN9604 zusagt, dann nimm den, und gut. In Einzelstückzahlen wirst du den sicherlich noch etliche Jahre bekommen können.
> Um was geht es denn nun genau, privat oder gewerblich?
Das wundert mich auch. Privat habe ich auch einfach fuenf USBN9604
rumliegen und werde damit sicher noch lange hinkommen.
Ich dachte es geht hier um Stueckzahlen und Kohle. Da muss man dann
natuerlich was anderes nehmen.
Olaf
Hi, @FT232: Stimmt, da war was mit >1 MBaud/s ... Aber wirklich gut gefällt mir das trotzdem nicht. USB ist nunmal keine streamorientierte Schnittstelle, also wäre mir ein direkter Zugriff auf die USB-Endpoints lieber. Dann kann ich meine Daten auch entsprechend in geeignete Pakete verpacken. @Privat: Joa, ist privat. Allerdings halt ein OpenSource-Projekt, das auch in drei Jahren noch nachbaubar sein soll ;) Hab mir auch schon überlegt, das einfach zu ignorieren, da man ja aktuell noch ran kommt. Aber der bittere Beigeschmack, dass es quasi jeden Tag so weit sein kann, dass es keine mehr gibt, bleibt :( Aber mangels direkter Alternativen (also was, wo ich Kontrolle über die Endpoints hab und nach Möglichkeit (recht) kleines Package) werd ich es wohl wirklich mit einem USBN realisieren ... Mal schaun, wann der dann nicht mehr verfügbar ist :D Jetzt brauch ich nur noch einen für einen Breadboard-Prototypen ;) Danke an alle für die Hinweise. Wenn natürlich noch jemandem was direkt vergleichbares einfällt freue ich mich nach wie vor über eine Meldung ;) Grüße, Chris
Bei einem interessanten OpenSource-Projekt findet sich sicherlich jemand, der den USBN durch etwas anderes ersetzt. Ist es uninteressant... naja, dann ist es auch egal; baut eh keiner nach ;-)
AM nähesten kommt der Cypress FX2LP. Der Quasi-Standard bei USB 2.0 Device Controllern. Direkter Zugriff auf alle EndPoints, verschiedene Verbindungen nach außen (Slave FIFO, GPIF....) und kleines Gehäuse. Kostenlose Toolchain (SDCC) und Firmware Update direkt über USB. Kein programmer nötig. Dazu noch unter Windows, Linux Mac einsetzbar, geht auch prima mit der LibUSB. FXload unter Linux für den Firmware-Upload. Für open-source ideal. Wird ja auch im GnuRadio eingesetzt. Und den gibts sicher noch lange.
Hi Chris, darf ich fragen, wieso du die Fujitsu 16FX einsetzt, gibts dafür gcc, wäre ja für ein Opensource Projekt relevant? Haben die Prozis sonstige Besonderheiten die für deine Anwendung von Bedeutung sind? Gruß Stefan
Christian R. schrieb:
> AM nähesten kommt der Cypress FX2LP. ...
Hm, sieht an sich ja nicht schlecht aus, aber soweit ich das überschauen
kann sind die Interfaces doch nicht all zu variabel. USART ist langsam
(wohl nur für Config sinnvoll) und im "kleinen" Package (56 Pins) hat
das ding keinen parallelen Bus sondern nur FIFO-Zugriff auf
Datenbereiche. Und dazu kommt noch, dass man wohl jedesmal beim Start
des Controllers erst eine FW laden muss, sprich wieder externe
Beschaltung mit Speicher erforderlich ist :(
Wäre wohl eher interessant, wenn man eine Applikation hat, wo man den
Chip auch als primäre MCU nutzen kann.
Vielleicht hab ich aber auch was überlesen? :D
Stefan V. schrieb: > darf ich fragen, wieso du die Fujitsu 16FX einsetzt klar darfst du ;) > gibts dafür gcc, wäre ja für ein Opensource Projekt relevant? Nein, aber eine kostenlose Compiler-Toolchain (genau genommen sogar noch ne freie IDE dazu, aber da nimmt man lieber Eclipse ;) ) > Haben die Prozis sonstige Besonderheiten die für deine > Anwendung von Bedeutung sind? Ja, größter Grund: Ich bin mit der HW vertraut und entwickle PC-seitige Software dafür (Entwicklungsumgebung per Eclipse, Debugger) ;) Außerdem hat das Teil halt nen ordentliches CAN-Makro, Taktrate (wichtig, damit ich kontinuierliche 1 MBit/s vom CAN zum PC schaufeln kann ;) ), RAM, OnChip-Debugging ... Das war erstmal das, was mir spontan dazu einfällt. Chris
Hi Chris, >> gibts dafür gcc, wäre ja für ein Opensource Projekt relevant? > Nein, aber eine kostenlose Compiler-Toolchain (genau genommen sogar noch > ne freie IDE dazu, aber da nimmt man lieber Eclipse ;) ) danke für die Info. Die Toolchain gibts wahrscheinlich nicht für Linux - schade. Ansonsten bin ich mal gespannt was du dann veröffentlichst, wenn dein Projekt soweit ist. Gruß Stefan
Hi Stefan, Stefan V. schrieb: > danke für die Info. Die Toolchain gibts wahrscheinlich nicht für Linux - > schade. Ansonsten bin ich mal gespannt was du dann veröffentlichst, wenn > dein Projekt soweit ist. Die Toolchain gibt es nur für Windows, allerdings funktioniert die mit Wine auch problemlos unter Linux (hab ich schon gemacht und in Version 2.0 des Eclipse-Plugins will ich definitiv direkt Linux supporten). Nur das Flash-Downloading geht aktuell nur unter Windows mangels Linux-Flash-Tool. Wird aber auch von mir direkt in Eclipse integriert (genau wie der Debugger) und damit plattformunabhängig ;) Grüße, Chris
> Nein, aber eine kostenlose Compiler-Toolchain (genau genommen > sogar noch ne freie IDE dazu, aber da nimmt man lieber Eclipse ;) ) Waren das die mit der Oberflaeche die noch fuer Win3.11 geschrieben ist? Ich hatte letztens wieder einen Gratiscontroller von Fujitsu der der Transistor Gijutsu beilag. Der Controller war ganz interessant, z.b 1Gbyte Flashrom, integrierte VGA erzeugung. USB Slave und USB host integriert, Wohl eigentlich als Steuerteil fuer DVD-Player gedacht. Aber die Oberflaeche zum programmieren war nun...aeh..bizarr! Olaf
Christian Illy schrieb: > Hi, > > @FT232: Stimmt, da war was mit >1 MBaud/s ... Aber wirklich gut gefällt > mir das trotzdem nicht. USB ist nunmal keine streamorientierte > Schnittstelle, also wäre mir ein direkter Zugriff auf die USB-Endpoints > lieber. Dann kann ich meine Daten auch entsprechend in geeignete Pakete > verpacken. Wie wär's mit dem FT245R, der bietet zwar auch keinen direkten Zugriff auf die Endpoints, wird aber parallel angesteuert. Oder den MAX3420E verwenden, direkter Zugriff, Anschluss über SPI http://www.maxim-ic.com/quick_view2.cfm/qv_pk/4751 Ansonsten einen "richtigen" Controller bspw. die neuen PSoC3 von Cypress, die haben u.a. CAN und USB integriert oder einen kleinen SiLabs-Controller mit USB und dazu einen externem CAN-Controller.
Hi, Olaf schrieb: > Waren das die mit der Oberflaeche die noch fuer Win3.11 geschrieben ist? So schaut sie zumindest aus, ja ;) > Ich hatte letztens wieder einen Gratiscontroller von Fujitsu der der > Transistor Gijutsu beilag. Der Controller war ganz interessant, z.b > 1Gbyte Flashrom, integrierte VGA erzeugung. USB Slave und USB host > integriert, Wohl eigentlich als Steuerteil fuer DVD-Player gedacht. Welcher Controller war das denn? Besonders das mit dem GByte Flash erstaunt mich nun doch etwas. Oder war das ein externer Speicher? > Aber die Oberflaeche zum programmieren war nun...aeh..bizarr! Joa, deswegen ja die Entwicklung des Eclipse-Plugins ;) Arc Net schrieb: > Wie wär's mit dem FT245R, der bietet zwar auch keinen direkten Zugriff > auf die Endpoints, wird aber parallel angesteuert. Jo, aber die parallele Ansteuerung eliminert nicht die Problematik mit USB und Datenströmen ;) Von daher wäre nichtmal der parallele Zugriff sondern vor allem die Kontrolle über die Endpoints wichtig. > Oder den MAX3420E verwenden, direkter Zugriff, Anschluss über SPI > http://www.maxim-ic.com/quick_view2.cfm/qv_pk/4751 Der schaut mal echt gut aus, auf den ersten Blick (hab ja hier auf der Arbeit nicht viel Zeit ;) ) stört nur die Spannungsversorgung mit 3.3 V. Wenn es sowas jetzt noch mit 5 V gäbe (und im absoluten Idealfall noch mit weniger Pins ;D ) wäre es ne echt verdammt gute Alternative zum USBN9604. Das schau ich mir später nochmal genauer an. > Ansonsten einen "richtigen" Controller bspw. die neuen PSoC3 von > Cypress, die haben u.a. CAN und USB integriert oder einen kleinen > SiLabs-Controller mit USB und dazu einen externem CAN-Controller. Externer CAN-Controller kommt für mich nicht in Frage, da dort wieder unnötige Verzögerungen beim Empfangen entstehen, so dass die Zeitmessung nicht mehr so akkurat wäre, wie ich mir das vorstelle ;) Auch würde ich ungern schon wieder eine komplett neue Architektur nehmen, besonders da die 16FX eben genau das bieten, was ich will (mal vom USB abgesehen ;) ). Grüße, Chris
So, nachdem ich nun ein paar Tests durchgeführt hab geb ich hier doch mal ein Update ;) Beim Durchschauen der FTDI-Seite war mir ja das letzte mal aufgefallen, dass es wieder nen neuen Chip gibt: FT2232H. Also hatte ich den mal bestellt, da das ein High-Speed-Device ist und (angeblich) bis zu 12 MBaud USART kann. Bisherige Tests haben ergeben, dass ich recht gut auf wenigstens 9 MBaud komme und das ohne jegliche Probleme. Wobei ich bisher nen recht einfachen Test nutze, d.h. auf UC-Seite wirklich kontinuierlich Daten über USART raushaue. In der Praxis wäre das ja nicht ganz so kontinuierlich und daher vielleicht etwas andres verhalten. Wie dem auch sei, für mich scheint der Chip jetzt wirklich so ziemlich das Optimum zu sein. - sehr schnell - einfache Handhabung auf UC-Seite - Zwei Kanäle -> ich kann einen für das Programmier/Debug-Interface des UCs verwenden Wenn da bei den andren Tests nichts negatives mehr kommt werde ich wohl dabei bleiben. Grüße, Chris
Und nochmal ein kleines Update: Habe kurze Tests mit dem Chip durchgeführt. Zumindest bei konstantem Datenstrom bekommt man ohne Schwierigkeiten 6 MBit/s Nutzdaten hin. Allerdings nur mit direkter USB-Ansteuerung (ftd2xx libftdi libusb), da die Windows-VCPs wohl nicht wirklich darauf ausgelegt sind. Kann das Teil also eigentlich nur empfehlen ;) Grüße, Chris
Ich bin auch auf der Suche nach einer Alternative zum USBN9604, der an einen Fujitsu 16FX (64 oder 100Pin) über den externen Bus einfach anzukoppeln wäre. Mit dem FTDI UM232R hatte ich nur einen Teilerfolg. Eigentlich will ich nur Datenpakete mit einer gleichbleibendebn Länge von 12Byte zwischen PC und Mikrocontroller austauschen. Der Transfer vom MC zum PC lief entgegen meiner Befürchtung ausreichend schnell. (100 Pakete/Sec für eine Visualisierung). Aber in der umgekehrten Richtung, also vom PC zum MC, trat dann ein unerwartetes Problem auf: Zwischen den Datenpaketen, die im Abstand von 100ms gesendet wurden, entstanden Pausen von bis zu drei Sekunden. Ursächlich hierfür ist die Zeit die der Aufruf FT_WRITE (Lib D2XX) konsumiert. Der Aufruf erfolgt in einem Workerthread. Auf meine Anfrage beim sonst so rührigem Support von FTDI erhielt ich erst auf Nachfrage nach knapp 4 Wochen diese Antwort: ---- Zitat When we write to the device we are passing the data to the USB host controller that creates the packets and schedules the transfer to the chip. As such we have little / no control over this scheduling. You can try increasing the driver priority or adding a sleep (0) after a write to try to speed up responsiveness. ---- Zitat Ende Dem vorgeschlagenen Lösungsweg bin ich nicht gefolgt, da ich mir von einem sleep(0) nach dem Aufruf keine Verbesserung verspreche und die Erhöhung der Priorität möchte ich meinen (potentiellen) Kunden nich zumuten. Mit einem USB-CANmodul habe ich dieses Problem nicht, selbst wenn der PC im Abstand von 10ms Datenpakete versendet.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.