www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik USB schneller als mit den FTDIs


Autor: Tobias M. (mhad-ngad)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nabend Zusammen,
ich möchte für meine Anwendung aus verschiedenen Gründen einen STR730 
(ARM7-Core) nutzen. Ich plane unter anderem große Datenmengen, die ich 
von AD-Wandlern und vom CAN aufzeichne auf einer CF-Karte abzulegen. Um 
die Daten dort wieder runterzukriegen, würde ich gern USB verwenden. Nun 
kriegt man mit den FTDIs meines Wissens nach nur max 3Mbit/s hin. Daher 
habe ich überlegt einen PIC oder AVR mit direktem USB-Interface zu 
verwenden, um dann per UART oder wie auch immer mit diesem zu 
kommunizieren und eine schnellere Verbindung herzustellen, da ich mit 3 
Mbit/s bei Datenmengen von bis zu 2 GByte sonst Stunden zum runterladen 
benötige. Hat jemand ne Idee oder fällt euch vielleicht ne deutlich 
einfachere Möglichkeit zur Datenübertragung ein? Die CF-Karte zu 
entfernen und direkt an den Rechner zu stöpseln kommt nicht in Frage.

Gruß

Tobi

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
USB 480Mbps ist in Controllern eher selten anzutreffen, daher sind's 
ohnehin nicht mehr als 12Mbps (theoretisch). Gibt's keine STR7 mit USB 
drin?

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
doch, hab ich mich auch schon gefragt, bei den 750ern.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PIC18F2550 schafft gerade mal so 88kB/s. Mehr ist da nicht
drin.

Autor: Tobias M. (mhad-ngad)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habt Ihr Erfahrungen aus der Praxis, was die ARMs effektiv über das 
USB-Interface schauffeln können? Den 730er habe ich wegen der 3 CANs 
genommen. Die 750er haben nur einen und damit genau einen zu wenig für 
meine Anwendung. Wobei ein externer CAN-Controller vermutlich weniger 
kritisch ist, als externes USB, oder?

Gruß

Tobias

Autor: 2921 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der unguenstige Aspekt an USB ist einen PC Treiber zu schreiben.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du es beim Datentransport eilig hast, scheint mir ein µC mit 
internem 100Mbps Ethernet sinnvoller. Fehlende CAN Kanäle kannst du ja 
ggf. extern erweitern, da ist die Datenrate ja nun erheblich geringer.

Ausserdem ist die Softwareseite auf dem PC bei Ethernet erheblich 
einfacher.

Autor: Tobias M. (mhad-ngad)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja,
nicht zwingend, soweit ich weiss. Zumindest die FTDIs liefern ja schon 
Treiber mit, die über die emulierte Com-Schnittstelle hinausgehen. Wie 
es bei den ARMs ist, weiss ich ehrlich gesagt nicht.

Autor: Tobias M. (mhad-ngad)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andreas: Daran habe ich auch schon gedacht, allerdings muss ich dann 
auf dem µC TCP/IP oder UDP implementieren. Das ist vermutlich auch kein 
Zuckerschlecken...

Autor: Jonas G. (jonny)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
die stacks gibt es ja notfalls fertig :)

Autor: Supa Micha (supa_micha)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

vielleicht könntest du auch einfach nur einen anderen externen USB 
Controller als den FTDI nehmen. Es gibt da ja durchaus auch welche, die 
High Speed unterstützen. Ist dann natürlich nicht mehr das 
Rundum-Sorglos-Paket wie mit dem FTDI.

Optimale Lösung denke ich wäre sicherlich, wenn du den MCU bei der 
USB-Kommunikation aussen vorläst. Du schließt also ein USB High Speed 
Controller und deinen MCU parallel an die CF-Karte. Wenn du deine Daten 
aufnimmst, spricht nur der MCU mit der Karte. Wenn du die Daten 
ausliest, spricht nur der USB Controller mit der Karte. Dabei könnte das 
ganze als Mass Storage Device angesprochen werden.

Ein Beispiel für einen USB Full Speed Controller ist z.B. der TUSB6250. 
Auch von Cypress gibt es ähnliche.

Viele Grüße
Michael

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
UDP ist ziemlich einfach. Einfacher als USB. Und für TCP gibt's fertige 
Lösungen.

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du die Daten auf der Karte in einem für den PC lesbaren Dateisystem 
speichern kannst, dann könntest du sie auch mit einem Kartenleser 
auslesen.

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das hört sich ja alles ganz gut an:

Ich hätte den Vorschlag sich den Blackfin Prozessor
anzusehen und sich ein Application Board zu besorgen.
Der läuft mit Linux oder auch native mit einfachen Programmen.
Datendurchsatz ist da massig vorhanden und wenn man Linux benutzen
würde hätte man sofort auch Netzwerkunterstützung.
Eine AD-Wandler Platine muss man ja denke ich sowieso erstellen,
die könnte man dann einfach mit einem Linux Treiber über die IOs
abfragen.
Somit würde sich also vom Know-How ergeben:

- Compiler und/oder Toolchain anschauen
- Linux Treiber entwickeln (man kann da mit einfachen Beispielen
  anfangen)
- Platine mit AD-Wandlern designen
- Server Applikation schreiben die die Daten vom Board über
  TCP/IP bereitstellt
- Client Applikation z.B. für Windows schreiben

Gruß Sven

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>  ich möchte für meine Anwendung aus verschiedenen Gründen einen STR730
> (ARM7-Core) nutzen

Sorry, im ersten Satz überlesen.

Autor: Tobias M. (mhad-ngad)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Thomas:
leider werde ich die Karte nicht entfernen können, wenn das Gerät 
erstmal in Betrieb ist.
@Sven:
Rein vom Prinzip her ging es mir bei der Auswahl des µCs um eine 
einigermaßen erprobte Plattform, mit 2 CANs integriert, wenn möglich, 
und Peripherie in Form von UART, SPI, Timern usw. Von daher ist der 
Blackfin wohl auch keine schlechte Wahl, zumal in meinem Projekt auch 
ein sehr fitter Linuxprogrammierer involviert ist und ich mich auf die 
Hardware konzentrieren könnte. Offensichtlich ist aber noch kein 
Chiphersteller auf die Idee gekommen, mehr als einen CAN zu spendieren, 
wenn man schon Ethernet und oder USB an Board hat.

Nach kurzem Infos sammeln im Netz ist der Blackfin wohl doch etwas 
oversized für meine Anwendung. Im Grunde wird das nur ein 
konfigurierbarer Datenlogger.

Gruß

Tobias

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ethernet plus 2-Kanal CAN findet sich in den neuen LPC2300/2400.

Autor: Tobias M. (mhad-ngad)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andreas:
Ich las leider schon viel vom verbuggtem CAN in den LPCs, hast Du 
Erfahrung damit?

Gruß

Tobi

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das dürfte sich auf den CAN Controller vom alten LPC2129 (sowie 
LPC2194,...) beziehen. Der hat einige Bugs, darunter einer der FullCAN 
in Hardware ausschliesst. Aber wenn man diese Bugs umschifft 
funktioniert er. Hat mir jedenfalls keinen Ärger bereitet, andererseits 
ist meine App auch nicht sonderlich anspruchsvoll.

Die Errata-Liste vom LPC2300 sieht deutlich zivilisierter aus, da 
scheint man nur auf Overruns aufpassen zu müssen. Allerdings ist das 
Teil recht neu, und Errata-Listen pflegen mit den Jahren zu wachsen.

Autor: Tobias M. (mhad-ngad)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andreas:
Ja, das mit den leeren Erratas bei jungen Controllern kenne ich leider 
auch...allerdings gibt es den auch mit integriertem SD/MMC Interface, 
was sehr reizvoll für die Datenspeicherung ist.

Gruß

Tobias

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich würde mir den Controller nach dem Flaschenhals aussuchen, also in 
deinem Fall die externe Verbindung. CAN ist leicht dazugestrickt.
Wenn möglich, nimm auf jeden Fall Ethernet.

Autor: Tobias M. (mhad-ngad)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich nehme an mit Ethernet wird der Lesezugriff auf das Speichermedium 
der Flaschenhals. Hat einer von euch Erfahrung mit dem möglichen 
Datendurchsatz über Ethernet mit ARMs?

Gruß

Tobias

Autor: Robert Teufel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bin ich erst mal froh, dass ich nicht als erster die LPCs in Spiel 
gebracht habe ;-)

Die LPC23xx haben schone einen hohen Durchsatz wenns um Ethernet geht, 
sogar einen eigenen Bus, eigene 16k SRAM, eigene DMA Controller sind 
spendiert worden, damit im Spitzenbelastungsfall die CPU noch was 
anderes tun kann, z.B. CAN messages abzuholen oder USB (ebenfalls 
unterstuetzt mit einer eigenen DMA).

Soweit ich weiss sind so langsam die Teile der Rev "B" zu haben, die 
haben fast alle Erratas soweit bekannt beseitigt und laufen auch volle 
Geschwindigkeit bei 72 MHz. Die kommen und gehen sehr schnell bei 
Digikey. Zu meinem Erstaunen gibt es dort einige LPC24xx, im Grunde 
dasselbe Teil aber zusaetzlich mit einem externen Bus.

STR73x wuerde ich deshalb nicht unbedingt empfehlen, weil es sich um 
wirklich alte Technologie handelt und sobald die Automotive Anwendung 
mal nicht mehr in Serie produziert wird es wohl auch mit der 
Restlebensdauer des STR73x nicht mehr so lange hin sein. Der STR75x ist 
da eine ganz andere Geschichte, der ist noch recht jung, gefertigt in 
viel neueren Prozessen und kann auch 5V, den wird es wohl noch lange 
Zeit geben, ebenso den STR9x, der zwar dafuer, dass es ein ARM9 ist in 
der Performance zu wuenschen uebrig laesst aber sich definitiv mit den 
schnellsten ARM7 messen kann. Also wenn ST, vielleicht muss es nicht 
gerade der 730 sein.

Gruss, Robert

Autor: Tobias M. (mhad-ngad)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Robert,
wo ich dich gerade am Wickel habe: Ich habe mich eben mal durch das 
Errata des LPC2378 
http://www.standardics.nxp.com/support/documents/m...
gewühlt. Da ist der CAN.1 Fehler nach wie vor nicht behoben. Allerdings 
verstehe ich die Fehlerlösung nicht so richtig:

Workaround:1. Recovering from this situation is only possible with a 
soft reset to the CAN controller.
2. If software cannot read all messages in time before a third message 
comes in, it is recommend to change the acceptance filtering by adding 
further acceptance filter group(s) for messages, which are normally 
rejected. With this approach, the third incoming message is accepted and 
the Data Overrun condition is avoided. These additional messages are 
received with the corresponding
group index number can be easily identified and rejected by software.

1. Mit einem Softreset des CAN controllers kriege ich ihn wieder zum 
Laufen.
2. Wenn die Software es nicht packt, die Receive Buffer zu leeren, bevor 
eine dritte Nachicht den Data Overrun auslöst, dann soll man die 
Acceptance Filter so anpassen, dass Sie Nachrichten durchlassen, die sie 
vorher geblockt haben, weil dann die dritte Nachricht ohne auslösen des 
Overruns akzeptiert wird? Das widerspricht sich doch irgendwie...denn 
gerade wenn diese dritte Nachricht dann durchkommt, versucht er sie in 
einem der Receive Buffer abzulegen und merkt, dass die noch nicht 
gelesen worden ist und schon ist der Overrun da...oder nicht?

Gruß

Tobias

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
tja, das scheint ne ewige und schwierige Geschichte zu sein, so ein 
CAN-Controllerchen zu integrieren.
Ich hätte da echt keinen Bock drauf, mich mit solchen Dingen 
rumzuschlagen. Für kleines Geld gibts den MCP2515 oder SJA1000. Damit 
habe ich immer schnell und effektiv alle CAN-Probleme erledigen können 
und auf getestete und funktionierende Software zurückgreifen können. 
Nebenbei erlaubt das mir,den Controller meiner Wahl zu nehmen.
Ein Design läuft mit dem AT90CAN128, dass hat mich ne Menge Zeit 
gekostet :-(.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
crazy horse wrote:

> tja, das scheint ne ewige und schwierige Geschichte zu sein, so ein
> CAN-Controllerchen zu integrieren.

Und die Ironie daran ist, dass auch Microchip selbst von dieser Seuche 
befallen ist. Auch da hat der Versuch, µCs mit integriertem CAN 
rauszubringen, vor allem für deftig gewürzte Buglisten gesorgt 
(PIC18Fx58,2580,PIC30,PIC24-ECAN). Während der MCP2515 in der aktuellen 
Version vergleicherweise sauber ist.

Autor: Tobias M. (mhad-ngad)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm, ich habe schon in mehreren Designs PIC18F4580 und PIC18F8680 
benutzt. Da hatte ich überhaupt keine Probleme mit den integrierten 
CAN-Controllern.

Gruß

Tobias

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mag sein, aber dessen Bugs sind ärger als die vom MCP2515.

Was mich besonders stört, ist ein Bug, der scheinbar in allen 
integrierten Versionen drin steckt und bislang nur im MCP2515 behoben 
wurde: Wenn aus irgend einem Grund an passender Stelle in der Interframe 
Gap eine Störung kommt, dann kann ein Frame mit falscher ID 
rausrutschen, dessen CRC zur defekten ID passt, somit nicht als defekt 
erkennbar ist. Das muss allerdings kein Problem sein - ist das Timing 
aller Nodes in Ordnung und der Bus sauber, dann passiert nichts.

Auch ein paar andere Bugs von 2580 stören mich etwas. Insgesamt wirkt 
der alte 258 auf mich diesbezüglich besser als der 2580.

Autor: Willivonbienemaya .. (willivonbienemaya)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Kaiser wrote:
> Und die Ironie daran ist, dass auch Microchip selbst von dieser Seuche
> befallen ist. Auch da hat der Versuch, µCs mit integriertem CAN
> rauszubringen, vor allem für deftig gewürzte Buglisten gesorgt
> (PIC18Fx58,2580,PIC30,PIC24-ECAN). Während der MCP2515 in der aktuellen
> Version vergleicherweise sauber ist.

Das ECAN Modul in den neuen dsPICs ist wesentlich überarbeitet im 
Vergleich zum "alten" MCP2515. Die haben zB DMA.
Ich hab die ECAN Module der 33er schon benutzt und ich kann berichten, 
dass die Sache funktioniert. Die im Errata beschriebenen Probleme 
beziehen sich eher auf Randanwendungen die wohl sogut wie nie vorkommen 
(zB: Loopback Mode).

Die Erratas der LPC hingegen haben mich bis jetzt immer davon abgehalten 
diese mal zu testen.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Willivonbienemaya .. wrote:

> Die im Errata beschriebenen Probleme
> beziehen sich eher auf Randanwendungen die wohl sogut wie nie vorkommen
> (zB: Loopback Mode).

Mich stören die Probleme mit den Error Countern. Denn ein Randproblem 
ist das mitnichten - eine Node allein am Bus und man ist in nullkommanix 
am Limit. Auch die Overflow-Problematik ist ärgerlich.

Und das erwähnte Interframe Gap Problem ist trotz der Überarbeitung 
drin.

Autor: Willivonbienemaya .. (willivonbienemaya)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, eigentlich hast du da recht.
Bei mir funktioniert der CAN zwar ganz gut, aber wenn ich mir anschau 
was da schon alles als "workaround" im code steht stimmts schon. das 
muss nicht sein.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nochma zum Anfang zurück: Wenn du eh schon eine CF-Karte da dran hast, 
ist doch das einfachste, parallel an den ATA-Bus, den der ARM zur 
Verfügung stellt, einen Cypress 68300 dran zu hängen. Der kann 
Bus-Sharing, wenn du dann das USB Kabel ansteckst und den einen Pin da 
freigibst, meldet der sich als Massenspeicher an, und du kannst die 
Daten von deiner CF-Karte mit einigen MByte/s runter ziehen.
So machen wir das. Eine Logik sorgt dafür, dass jeweils der andere 
ATA-Master den Bus auf Tristate schaltet.

Autor: Tobias M. (mhad-ngad)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Chris,
dann müsste ich aber die Daten in FAT auf der Karte ablegen, oder?

Gruß

Tobias

Autor: Condi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jain, nur das auslesen unter Windows wird schwerer da du direkt auf den 
Speicher zugreifen musst. Du kannst die auch im Rechner formatieren und 
dann eine Große Datei anlegen und dann nur zwischen den End und 
Anfangsblöcken der Datei auf die Karte schreiben.

Kannst du nicht auch ne 2te Karte reinbauen? Kann ja auch SD oder so 
sein, dann kannst du bei bedarf auf die Karte kopieren und dann per 
Kartenleser auslesen. Dann kann der auch weiter loggen.

Es gibt auch CF Sata converter.

Autor: Tobias M. (mhad-ngad)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, eine 2te Karte geht leider nicht, da die Größe der Schaltung 
kritisch ist und sie im Fahrzeug so verbaut sein wird, dass man nicht 
rankommt.

Gruß

Tobias

Autor: Condi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Tobias M. (mhad-ngad)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hik,
danke für den Link. Allerdings wäre da natürlich das Problem, wie man 
beides zusammen nutzbar auf einer Platine vereint. Also auf der einen 
Seite auf die SD-Karte schreiben, auf der anderen Seite per USB 
auslesen. Da müsste ich vermutlich auch per FAT auf die Karte schreiben. 
Warum ich immer auf FAT rumreite: Die Datenraten, die von meinem Logger 
auf die Karte fließen, könnten so hoch werden, dass FAT deutlich zu viel 
Overhead erzeugt, abgesehen von der Implementierung, die ich ja auch 
noch hinbekommen muss :)

Mein momentaner Favorit wäre daher doch das Auslesen per LAN, da es 
vermutlich auch von der externen Beschaltung die kleinste Lösung ist. 
Leider hat sich noch niemand dazu geäußert, ob er Erfahrung mit dem 
LAN-Durchsatz der LPCs hat.

Gruß

Tobi

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
FAT muss nicht sein. Kannst die Karte dann auch über die Windows API 
Funktionen als RAW-Device öffnen und blockweise auslesen. CreateFile(..) 
in der MSDN ma suchen.
Das geht dann auch von beiden Seiten recht fix. Also µC und Windows. 
Kannst ja dann immer blockweise sehr schnell schreiben, ohne auf Dateien 
usw. zu achten.

Autor: Tobias M. (mhad-ngad)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm,
damit wäre der Cypress doch wieder im Spiel. Habt Ihr gute Erfahrungen 
damit gemacht? Gibt es irgendwelche Fallen, auf die ich achten sollte?

Gruß

Tobias

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also wir haben den mittlerweile in 2 Projekten im Einsatz. In der 
beschriebenen Konfiguration. Wichtig ist vor allem ein sauberer und 
SCHNELLER Reset. Da gibts aber ein Dokument bei Cypress. Reset 
Conditions oder sowas.
Ein RC-Glied am Reset geht nicht, es muss ! ein Reset-Chip sein.
Ansonsten Plug&Play. Einstecken, EEPROM Programmieren, neu anstecken 
Festplatte.

Wenn du ohne FAT arbeitest, musst du vorher abklären, ob Windows 
überhaupt einen Laufwerksbuchstaben vergeben will....aber soweit ich das 
in Erinnerung hab, kann man auch auf physikalische Laufwerke 
zugreifen....müsste man dann bloß rausfinden, wo genau das Laufwerk 
hängt.
Aber das lässt sich ja mit einem Kartenleser und einer unter Linux auf 
EXT2 oder so formatierten Karte im Vorfeld abklären. Ansonsten ist FAT 
ja nicht sooo aufwendig, und bei einer nicht-fragmentierten Karte kannst 
du ja die Daten auch ein einem Fort draufschreiben.

Achso, und lies dir GENAU das Dokument zum Sharen des ATA-Bus durch.

Autor: Tobias M. (mhad-ngad)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist gut zu wissen, danke! Man neigt ja doch zum Überlesen, wenn man 
nur bestimmte Infos sucht ;) Ich muss zugeben, dass ich noch nicht das 
ganze Datenblatt gelesen habe bzw. nur überflogen, kann man das EEPROM 
des Chips per USB programmieren?

Gruß

Tobias

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, da gibts eine Manufactoring Software samt Treiber von Cypress. Ohne 
progr. EEPROM meldet der sich als Manufactoring Device. Dann einfach das 
passende File rein und gut ist. Ist aber alles gut beschrieben. Beim 
Layout solltest du gleich einen Jumper in der SDA-Leitung des EEPROMS 
vorsehen, da kannst du immer wieder programmieren. Einmal als 
Massendatenspeicher programmiert lässt es sich schwer wieder in den 
Urzustand zurück versetzen. Mit Jumper gehts prima. Machen wir immer so.

Autor: Tobias M. (mhad-ngad)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für die Tipps!

Gruß

Tobias

Autor: Olly Krings (rossi75)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
2921 wrote:
> Der unguenstige Aspekt an USB ist einen PC Treiber zu schreiben.

Es gibt ne Firma "Thesycon", die bieten einen selbstkonfigurierenden 
Treiber an... Ist allerdings kommerziell und kostet etwa 1500 Euro für 
die nicht-share/free-ware-Version

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.