mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Wie baue ich eine USB Kommunikation auf?


Autor: Patrick B. (p51d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Miteinander

Bei einem "kleinen" Projekt muss ich ca 1,44M Bit/s Nutzdaten 
übertragen.
Daher fällt RS232 leider ganz weg.

Bis jetzt ist mir nur USB als Alternative eingefallem, nur ist das ganze 
Neuland für mich. Nur das Problem ist, bei den Dokumanten, sie ich bis 
jetzt studiert habe, komme ich nicht ganz mit:
http://www.sprut.de/electronic/interfaces/usb/usb.htm
http://interface.centraltreasure.com/files/pdf/usb...

Und hier habe ich noch eine Firmware gefunden, aus deren Code ich nicht 
schlau werde:
http://www.obdev.at/products/vusb/index-de.html

kennt jemand von euch eine wirklich informativ und praxisorientierte 
Seite, wo USB gut erklährt ist, auf der MCU und auf der PC Seite, die 
alles schön erklährt ist. Anschliessend muss ich wohl auch noch eine 
entsprechende Applikation mit GUI schreiben.

Ausserdem habe ich noch eine Frage: was würdet ihr für ein MCU 
empfehlen? bis jetzt habe ich mich nur mit AVR beschäftigt, weil die 
ersten Versuche mit PIC mir nicht so gut gefallen haben. Selbst mit dem 
C18 Compiler habe ich mich nicht so anfreunden können. Die Register un 
Bits sind nicht so schön definiert.

Danke für eure Hilfe
P51D

: Verschoben durch Moderator
Autor: John-eric K. (mockup)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie wäre es mit einem FTDI Chip
http://www.ftdichip.com/Documents/DataSheets/DS_FT...

Der schafft 3MBaud also 3Mbit bei RS232 mit TTL-Pegeln siehe Seite 1 
gleich.

Gruß John

Autor: Patrick B. (p51d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
den FT232 kenne ich schon, nur habe ich bis jetzt angenommen, dass man 
beim MCU die Baudrate einstellen muss, und mir ist bis jetzt keiner 
bekannt, der über 1M Baud geht.

Zudem muss man auf der PC Seite auch die Baudrate einstellen, da der 
FTDI "nur" eine RS232 über USB Simuliert. Kenne kein Terminal das über 
500k Baud schafft.
Ich arbeite mit Docklight und das schafft auch nur 256k Baud

Oder habe ich etwas übersehen?

Aber Danke für die Antwort

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du eine eigene Software schreibst, kannst du den SerialPort mit 
beliebigen Baudraten einstellen. Ich arbeite mit dem FTDI bei 921.600 
Baud, das klappt wunderbar. Das kann man der DCB eifach so übergeben. 
Klar, die meisten "Terminal" Programme erlauben maximal 115.200, aber 
das liegt rein an der Software. Aber wenn du 1,44 MiBit/s kontimuierlich 
übertragen willst, brauchst du bei USB einiges mehr an Geschwindigkeit, 
sonst machen die die Übertragungspausen einen Strich durch die Rechnung. 
Die nächst einfachere Stufe wäre der FT245, der schafft im FIFO Modus 1 
MiByte/s, das könnte reichen. Oder halt der neue FT2232H, der schafft 
über 20 MiByte/s dank USB 2.0 und ist genauso einfach anzzsprechen (FIFO 
Modus und D2XX DLL).

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> den FT232 kenne ich schon, nur habe ich bis jetzt angenommen,
> dass man beim MCU die Baudrate einstellen muss, und mir ist bis
> jetzt keiner bekannt, der über 1M Baud geht.

Der Atmega8 schafft laut Datenblatt bei 20 Mhz Takt bis zu 2,5Mbit/s.

Autor: Patrick B. (p51d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok

um etwas Verwirrung zu vermeiden muss ich wohl noch was wiederholen und 
ergänzen:
Bei so einer Geschwindigkeit würde ich mir dann ein Protokoll erstellen, 
dass bei der Übertragung nicht viel schief gehen kann. und das ganze 
dann 30'000 mal pro Sekunde

SOH (1 Byte)
Command (1 Byte)
Number of Bytes (1 Byte)
Parameter (6 Byte)
CRC (1 Byte)
EOT (1 Byte)

würde demnach 11 Bytes sein und dies würde einer Baudrate von 3,3M Bit 
entsprechen.

das mit dem FT2232H werde ich mir genauer ansehen.

PC-seitig kann ich die baudrate einstellen wie ich will, aber beim mcu 
nicht.
Kennt jemand ein mcu der die Baudrate wenn möglich voll ausschöpft? wenn 
möglich ein avr, da ich bei diesen die meisste erfahrung habe.

Autor: John-eric K. (mockup)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also bei http://www.der-hammer.info/terminal/ kann man auch andere 
Baudraten eintippen. Habe einen Atmega128 mit 500KBaud betrieben um 
einen Eprom zu programmieren.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Patrick B. schrieb:
> den FT232 kenne ich schon, nur habe ich bis jetzt angenommen, dass man
> beim MCU die Baudrate einstellen muss, und mir ist bis jetzt keiner
> bekannt, der über 1M Baud geht.

Dann nimm einen FT245, der benutzt den gleichen Treiber auf der PC-
Seite, weil er das gleiche Protokoll spricht, aber die eingestellte
Baudrate ist schnuppe, da er zum µC hin parallel angebunden wird.

Ansonsten kannst du noch über AT90USBxxx nachdenken, wenn du bei einer
reinen AVR-Lösung bleiben willst.  Als Firmware würde sich dann wohl
was auf der Basis von Dean Cameras LUFA anbieten.

Autor: Patrick B. (p51d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Dann nimm einen FT245, der benutzt den gleichen Treiber auf der PC-
> Seite, weil er das gleiche Protokoll spricht, aber die eingestellte
> Baudrate ist schnuppe, da er zum µC hin parallel angebunden wird.

• Data transfer rate to 1 Megabyte / second - D2XX Direct Drivers.
• Data transfer rate to 300 kilobyte / second - VCP Drivers.

beim vcp treiber wären das 2.4M Bit /sec
wenn ich die software auf einem terminal aufbaue reicht das nicht

der d2xx treiber ist auf usb standart?

ok, generelle frage: würdet ihr bei so hohen baudraten auf einen anderen 
prozessor umsteigen? mit schnellerem quarz?

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Patrick B. schrieb:
> Jörg Wunsch schrieb:
>> Dann nimm einen FT245, der benutzt den gleichen Treiber auf der PC-
>> Seite, weil er das gleiche Protokoll spricht, aber die eingestellte
>> Baudrate ist schnuppe, da er zum µC hin parallel angebunden wird.
>
> • Data transfer rate to 1 Megabyte / second - D2XX Direct Drivers.
> • Data transfer rate to 300 kilobyte / second - VCP Drivers.
>
> beim vcp treiber wären das 2.4M Bit /sec
> wenn ich die software auf einem terminal aufbaue reicht das nicht

Leider sind das alles Burst-Transfer-Raten.

> der d2xx treiber ist auf usb standart?

Das ist eine FTDI Implementierung und erfordert deren DLL.

> ok, generelle frage: würdet ihr bei so hohen baudraten auf einen anderen
> prozessor umsteigen? mit schnellerem quarz?

Naja, der Prozessor muss deine Daten schon anliefern können. Wenn du das 
FIFO Interface des FT245 nutzt, brauchst du auch keinen Baudratenquarz, 
der sonst bei so hohen Baudraten schon vorteilhaft wäre. Wie oben 
geschrieben, ich arbeite mit 921.600 Baud und da hängt ein MSP430 mit 
7,3728MHz Quarz dran.

Autor: Patrick B. (p51d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bei maximal 3.6MBit/sec wäre das 450kByte, was durchaus noch im 
Möglichen Bereich vom FT245 liegt.

das mit dem c wird dann warscheinlich noch ne knacknuss, aber ich denke 
das ich das hinkriege.
Um den d2xx treiber zu nutzen müsste dann die gui darauf zugreifen?
Aber erstmals geht es um das board, und die pc applikation kommt später 
noch. da werden wahrscheinlich sicher noch fragen auftauchen.

danke nochmals für die Antworten

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie Christian es schon gesagt hat: "Leider sind das alles 
Burst-Transfer-Raten."

Folgende Daten sind Werte aus einem reellen Projekt:
Atmega324P @11.0592 MHz (da Batterie-Betrieb) mit einem FT245RL

Ich erreiche nur einen Durchsatz von 80kB/s, weil:
-Lesen der SD-Karte braucht seine Zeit
-Berechnung des CRC braucht seine Zeit
-Die Uebertragung zum FT245 braucht seine Zeit

Ich beabsichte den Quarz auf 16,667 MHz zu erhöhen und die CKDIV8 Fuse 
zu setzen. Dann habe ich die Möglichkeit, im Batteriebetrieb mit 8,33Mhz 
zu takten und bei angeschlossener USB (min. 4,2V) den Takt auf 16Mhz zu 
erhöhen.
Hoffe, dass ich dann zumindest die 100KB/s Grenze knacke.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wo kommen denn deine Daten her? Kommen die wirklich kontinuierlich? 
Lassen die sich stoppen? Wenn nicht, musst du noch geschickt puffern. 
Wir haben bei Messungen hier festgestellt, dass Windows, selbst wenn es 
nichts anderes zu tun hat, bis zu 30ms Pause einfach so einlegt, bei 
kontinuierlicher USB Übertragung. Im Mittel erreichen wir mit dem 
cypress FX2 zwar knapp 40MB/s, aber eben nur im Mittel. Geht man von den 
30ms aus, dann noch etwas Reserve, müsstest du 50ms puffern können, das 
sind bei deinen 1,44MiBits/s (180 kiByte/s) dann etwa 9kiByte, die du 
als Puffer-Speicher brauchst.

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian R. schrieb:
> Wo kommen denn deine Daten her? Kommen die wirklich kontinuierlich?

Nein, nicht kontinuerlich. Die PC-Software fordert nonstop Daten in der 
Grössen von ca. 40kB an. Für 5 MBytes brauch ich über eine Minute dafür.

Auf MCU-Seite habe ich einen Buffer, der 512 Bytes gross ist. Hab' mich 
auch schon gefragt, ob ein grösser Buffer was nützen würde. Müsste aber 
dann auf den Atmega644P wechseln.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In diesem Fall ist der FT245 genau das richtige. Die Begrenzung bei der 
Geschwindigkeit liegt vor allem beim µC, mit einem flotten Controller 
sind im Mittel >500kByte/s möglich. Puffern braucht man die Daten auf 
dem µC nicht wirklich, dazu hat der FT245 einen eigenen Puffer. Schaden 
tut es aber auch nicht, um möglichst schnell neue Daten nachliefern zu 
können, wenn der FT245 seinen Pufferinhalt an den PC übertragen hat.

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Benedikt K. schrieb:
> Die Begrenzung bei der Geschwindigkeit liegt vor allem beim µC

Dem kann ich nur beipflichten.

Autor: Potter S. (potter68)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab das jetzt mal nur so überflogen. Zwei Sachen:

- wenn Du einen virtuellen COM-Port erstellst (wie das die FTDI ja 
machen), dann musst Du keine Baud-Raten einstellen. Das USB-Protokoll 
verwendet bei der Übertragung der Daten die schnellste Rate - und zwar 
automatisch.

- ich glaube auch, dass Dein Protokoll auf uC-Seite der Flaschenhals 
sein wird. Daten generieren, aufbereiten und in den USB-Puffer schreiben 
braucht seine Zeit. Es wird also sehr viel vom Controller-Takt und der 
Qualität Deiner Firmware abhängen.

Gruß Potter68

Autor: Patrick B. (p51d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ralf H. schrieb
>- wenn Du einen virtuellen COM-Port erstellst (wie das die FTDI ja
>machen), dann musst Du keine Baud-Raten einstellen. Das USB-Protokoll
>verwendet bei der Übertragung der Daten die schnellste Rate - und zwar
>automatisch.

Was meinst du damit? Wenn ich den MCU über den virtuellen COM-Port 
verbinde, und dann Daten mmittels einem Terminal sende brauche ich doch 
die Baudrate. Bei einem c++ Programm muss man doch auch angeben, wie die 
rs232 Schnittstelle läuft (Bitanzahl, Parität, Stoppbit...)

Wenn das ganze interrupt gesteuert ablaufen lasse und wie schon erwähnt 
ein grosser puffer benutze, sollte doch bei einem 20MHz Quarz das 
programm nachkommen, oder? schön mit switchs programmiert um möglichst 
einen schnellen durchlauf zu erreichen

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Patrick B. schrieb:
>> Ralf H. schrieb
>>- wenn Du einen virtuellen COM-Port erstellst (wie das die FTDI ja
>>machen), dann musst Du keine Baud-Raten einstellen. Das USB-Protokoll
>>verwendet bei der Übertragung der Daten die schnellste Rate - und zwar
>>automatisch.
>
> Was meinst du damit? Wenn ich den MCU über den virtuellen COM-Port
> verbinde, und dann Daten mmittels einem Terminal sende brauche ich doch
> die Baudrate. Bei einem c++ Programm muss man doch auch angeben, wie die
> rs232 Schnittstelle läuft (Bitanzahl, Parität, Stoppbit...)

Das zielte wohl eher auf den FT245 ab. Den kannst du auch als virtuellen 
COM port auf der PC_Seite betrachten, auf der MCU Seite hast du dann ein 
FIFO-Interface. Da ist die Baudrate dann egal.

Wenn du mit dem FT232 eine virtuelle serielle machst und auch zwischen 
FT232 und der MCU seriell bist, musst du die Baudrate usw. natürlich 
passend einstellen.

> Wenn das ganze interrupt gesteuert ablaufen lasse und wie schon erwähnt
> ein grosser puffer benutze, sollte doch bei einem 20MHz Quarz das
> programm nachkommen, oder? schön mit switchs programmiert um möglichst
> einen schnellen durchlauf zu erreichen

Das weißt nur du, denn wir kennen weder das Programm nich die Quelle der 
Daten....mit einem 512 Byte Puffer wirst du aber sowieso keine 
kuntinuierliche Datenrate im MBit-Bereich hinbekommen, vermute ich. Da 
macht dir der Windows Scheduler einen Strich durch die Rechnung.

Autor: Patrick B. (p51d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian R. schrieb:
> Patrick B. schrieb:
>> Wenn das ganze interrupt gesteuert ablaufen lasse und wie schon erwähnt
>> ein grosser puffer benutze, sollte doch bei einem 20MHz Quarz das
>> programm nachkommen, oder? schön mit switchs programmiert um möglichst
>> einen schnellen durchlauf zu erreichen
>
> Das weißt nur du, denn wir kennen weder das Programm nich die Quelle der
> Daten....mit einem 512 Byte Puffer wirst du aber sowieso keine
> kuntinuierliche Datenrate im MBit-Bereich hinbekommen, vermute ich. Da
> macht dir der Windows Scheduler einen Strich durch die Rechnung.

Momentan habe ich die Hardware auch noch nicht, bin am Anfang der 
Planung.
Was ist der Windows Scheduler? Von sowas habe ich noch nie gehört.

Autor: Reinhard S. (rezz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Patrick B. schrieb:

> Was ist der Windows Scheduler? Von sowas habe ich noch nie gehört.

Das ist das Stück Software, welches den einzelnen Programmen die 
Rechenzeit/Hardwareressourcen zuteilt und auch wieder wegnehmen kann 
damit andere Programme auch noch zum Zuge kommen.

Autor: Potter S. (potter68)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Ralf H. schrieb
>>- wenn Du einen virtuellen COM-Port erstellst (wie das die FTDI ja
>>machen), dann musst Du keine Baud-Raten einstellen. Das USB-Protokoll
>>verwendet bei der Übertragung der Daten die schnellste Rate - und zwar
>>automatisch.
>
> Was meinst du damit? Wenn ich den MCU über den virtuellen COM-Port
> verbinde, und dann Daten mmittels einem Terminal sende brauche ich doch
> die Baudrate. Bei einem c++ Programm muss man doch auch angeben, wie die
> rs232 Schnittstelle läuft (Bitanzahl, Parität, Stoppbit...)

Kleine Korrektur: Das Terminal-Programm übergibt bei einem virt. 
COM-Port die Daten an den USB-Host. Der hat natürlich keine Zeit, 
mehrere MBytes mit einer Baudrate von 1200 (Beispiel) zu übertragen. 
Deshalb geht er her und schickt das Zeug schnell raus (MBit/s) und legt 
sich dann wieder schlafen.

Genau das passiert auch beim FTDI. Allerdings ist es so, das der ja über 
UART an den uController angeschlossen ist, und hier wiederum wird dann 
die vorgegeben Baudrate verwendet, also 1200.

Wenn Du jetzt aber her gehst, und die USB-Schnittstelle selbst 
programmierst (also Mikrocontroller mit USB und kein FTDI), dann fällt 
die Drossel mit den 1200 Baud weg, da dann keine UART mehr im Spiel ist. 
Das verwendete USB-Protokoll (CDC-Klasse) weiss dann durchaus immer 
noch, welche Baudrate zu Grunde liegt (das muss aus 
Kompatibilitätsgründen ja auch so sein [siehe FTDI]), aber sie spielt 
bei einer Übertragung ausschliesslich über die USB-Leitungen keine 
Rolle.

Autor: Anja (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Patrick,

> Bei so einer Geschwindigkeit würde ich mir dann ein Protokoll erstellen,
> dass bei der Übertragung nicht viel schief gehen kann. und das ganze
> dann 30'000 mal pro Sekunde

> würde demnach 11 Bytes sein und dies würde einer Baudrate von 3,3M Bit
> entsprechen.

Ich denke Dein Protokoll ist der falsche Ansatz um hohe Datenraten bei 
USB zu erzielen.
Wenn ich mich richtig erinnere wird der Slave-Endpoint maximal alle 1ms 
gepollt. und dann der Endpoint-Buffer mit entsprechendem Füllgrad 
übertragen.

D.h. für maximale Übertragungsrate würde ich ein Protokoll wählen bei 
dem die Endpoint-Buffer-Größe (z.B. 128 Bytes) bei jedem 1ms-Transfer 
maximal ausgenutzt wird. Bei 11 Bytes / Übertragung kommst Du maximal 
auf 11000 Bytes/sec.

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mehmet Kendi schrieb:
> Ich erreiche nur einen Durchsatz von 80kB/s, weil:
> -Lesen der SD-Karte braucht seine Zeit
> -Berechnung des CRC braucht seine Zeit
> -Die Uebertragung zum FT245 braucht seine Zeit

Ich habe jetzt ein paar Aenderungen vorgenommen und komme auf eine Rate 
von 170kB/s.
- Die Frequenz wurde von 11,052 Mhz auf 16,667 MHz erhöht.
- Die Daten von der SD-Karte werden direkt zum FT245 gesendet und nicht 
erst über den Umweg eines Buffers.
- Auf die CRC-Berechnung wurde verzichtet, da
  a) es in der Vergangenheit nie zu einem CRC-Fehler gekommen ist
  b) die Daten nicht sicherheitsrelevant sind

Autor: Patrick B. (p51d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, erstmals danke für die Antworten noch nachträglich
Jetzt hatte ich mal wieder etwas freie Zeit gefunden, mich wieder dem 
Problem widmen zu können.

Anja schrieb:
> Ich denke Dein Protokoll ist der falsche Ansatz um hohe Datenraten bei
> USB zu erzielen.
> Wenn ich mich richtig erinnere wird der Slave-Endpoint maximal alle 1ms
> gepollt. und dann der Endpoint-Buffer mit entsprechendem Füllgrad
> übertragen.
>
> D.h. für maximale Übertragungsrate würde ich ein Protokoll wählen bei
> dem die Endpoint-Buffer-Größe (z.B. 128 Bytes) bei jedem 1ms-Transfer
> maximal ausgenutzt wird. Bei 11 Bytes / Übertragung kommst Du maximal
> auf 11000 Bytes/sec.

Sorry, aber von diesen wenigen Zeilen verstehe ich nur ein Bruchteil, da 
ich leider immer noch nicht viel weiter bei dem "wie funktioniert USB 
beim MCU"-Problem bin.

Ich werde mal Probeweise den MCU mit 2,5Mb/s füttern und sehen ob das 
reicht, da ich jetzt mal alles soweit gekürzt und zusammengefast habe, 
reicht diese Rate aus.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Patrick B. schrieb:
>> D.h. für maximale Übertragungsrate würde ich ein Protokoll wählen bei
>> dem die Endpoint-Buffer-Größe (z.B. 128 Bytes) bei jedem 1ms-Transfer
>> maximal ausgenutzt wird. Bei 11 Bytes / Übertragung kommst Du maximal
>> auf 11000 Bytes/sec.
>
> Sorry, aber von diesen wenigen Zeilen verstehe ich nur ein Bruchteil, da
> ich leider immer noch nicht viel weiter bei dem "wie funktioniert USB
> beim MCU"-Problem bin.
>
> Ich werde mal Probeweise den MCU mit 2,5Mb/s füttern und sehen ob das
> reicht, da ich jetzt mal alles soweit gekürzt und zusammengefast habe,
> reicht diese Rate aus.

Ist ja auch nicht schlimm, wenn du das nicht verstehst, denn USB ist 
relativ(!) kompliziert. Die Specs sind aber frei verfügbar und deswegen 
solltest du, ehe du dich an das Programmieren begibst mal entsprechende 
Lektüre lesen und dich informieren wie das bei USB abgeht.

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

ich das ehemals auf meiner USBisp Hardware (M8@8MHz + FT245) mal 
getestet. Maximal erreichte Datenrate mit VCP-Treibern und einer kleinen 
Java-Applikation dahinter die die Daten in eine Datei geschrieben hat 
waren 600kB/s -> 4,8MBit/s (Nutzdatenrate)

Geht also.

Matthias

Autor: Patrick B. (p51d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok, hab jetzt mal den FT232 ausprobiert:
Laut Datenblatt unterstützt der ATmega644 eine maximale Baudrate von 
2.5MBit bei einem 20MHz Quarz

Beim Test hat das ganze aber nur bis 500kBit funktioniert. Bei 2.5MBit 
hat der MCU zwar Daten empfangen, aber nicht das, was ich gesendet 
habe...

jetzt ist die Frage, wieso läufts nicht:
Die UART habe ich so gesetzt:
UBRR0H = 0;                              // Baud = 2,5Mbps
UBRR0L = 0;                             // 
UCSR0A |= (1<<U2X0);                      // RS232 Settings: double speed
UCSR0B |= (1<<RXCIE0)|(1<<RXEN0)|(1<<TXEN0);          // Complete Interrupt, RX und TX einschalten
UCSR0C |= (1<<UCSZ01)|(1<<UCSZ00);                // Asynchron, 8-Bit

Als Terminal habe ich Docklight und Hterm versucht, bei mit dem gleichen 
Resultat.

Ich habe auch schon gelesen, dass zum Teil Probleme mit dem Mainboard 
des PC's auftreten könne, aber da weiss ich nichts weiteres.
Funktioniert das ganze überhaupt mittels Terminal oder muss ich da eine 
Windows-Applikation schreiben?

MFG
P51D

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.