www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik USBN9604 NRND - Alternativen?


Autor: Christian Illy (alloc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian Illy (alloc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kommt von den FTDI-Controllern keiner in Frage?

Gruß
Tom

Autor: ... ... (docean) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dann nimm einen ftdi, dann hast einen seriellen oder parallelen bus zum 
anknoten an deinen µC

Autor: Christian Illy (alloc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: STK500-Besitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vinculum vielleicht?

Autor: Christian Illy (alloc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas R. (tinman) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jochen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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_FT... 
(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 ;)

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Christian Illy (alloc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 
;-)

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan V. (vollmars)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian Illy (alloc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian Illy (alloc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan V. (vollmars)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian Illy (alloc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian Illy (alloc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian Illy (alloc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian Illy (alloc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Anton K. (antonius)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.