UART mit 1MBaud

[Tycho B. (asellus)]

Hallo allerseits,

bitte nicht rumschimpfen, ich weiß dass das Thema öfters auftaucht, aber 
alles, was ich bis jetzt gelesen habe hilft mir nicht weiter.
Ich will den PA-1284_P über USART mit 1MBaud ansteuern. RS232 von FTDI 
als COM-Port. Terminal: Termite

250kBaud geht, doch 500kBaud und 1MBaud liefern nur seltsame Zeichen.
500kBaud geht sogar richtig, wenn ich bei "Termite" als Baudrate 510000 
eingebe.
1Mbaud geht gar nicht, erhalte nur "üüüüüüüüüüüüüüüü".
U2Xn habe ich auch schon gesetzt, ohne Erfolg.
Was mache ich falsch?

#define F_CPU 16000000UL

#define BAUD 1000000UL      // Baudrate
#define UBRR_VAL ((F_CPU+BAUD*8)/(BAUD*16)-1) 
#define BAUD_REAL (F_CPU/(16*(UBRR_VAL+1)))     // Reale Baudrate
#define BAUD_ERROR ((BAUD_REAL*1000)/BAUD) // Fehler in Promille, 1000 = kein Fehler.
#if ((BAUD_ERROR<990) || (BAUD_ERROR>1010))
#error Systematischer Fehler der Baudrate grösser 1% und damit zu hoch!
#endif

#include "include\LcdRoutines.c"

void uart_init(void)
{
  
  UBRR0 = UBRR_VAL;
  UCSR0B |= (1<<TXEN0);
  // Frame Format: Asynchron 8N1
  UCSR0C = (1<<UCSZ01)|(1<<UCSZ00);

}
int main(void)
{
  uart_init();
  while(1)
  {
    _delay_ms(500);
    
    /* Put data into buffer, sends the data */
    
    UDR0 = 'x';
  }
}

[Ingo L. (corrtexx)]

Schreib doch mal von Hand eine 0 ins UBRR.
http://www.gjlay.de/helferlein/avr-uart-rechner.html

[Tycho B. (asellus)]

Nein, daran liegt es nicht, gerade ausprobiert.

UBRR0 =0;//= UBRR_VAL;

[Falk B. (falk)]

@ Tycho B. (asellus)

>bitte nicht rumschimpfen, ich weiß dass das Thema öfters auftaucht, aber
>alles, was ich bis jetzt gelesen habe hilft mir nicht weiter.
>Ich will den PA-1284_P über USART mit 1MBaud ansteuern.

Du meinst einen AVR?

> RS232 von FTDI als COM-Port. Terminal: Termite

>250kBaud geht, doch 500kBaud und 1MBaud liefern nur seltsame Zeichen.
>500kBaud geht sogar richtig, wenn ich bei "Termite" als Baudrate 510000
>eingebe.

Das ist ein Problem. Nicht alle Terminalprogramm können diese Baudrate 
beim Treiber richtig einstellen. Versuch mal HTERM. Aber auch dort muss 
man tricksen. Man muss die Baudrate in der config-Datei einstellen.

>Was mache ich falsch?

Das Programm sieht OK aus, wenn man mal vom fehlenden Zugriff auf das 
ober UBBR0 Byte absieht.

[Linksammler (Gast)]

16MHz Quarz ist dran?

FTDI mit Loopback-Brücke RX<>TX läuft mit 1MBaud?


Nebenbei:

Tycho B. schrieb:
> #include "include\LcdRoutines.c"

besser als
#include "include/LcdRoutines.c"
schreiben.

(Wenn man überhaupt ".c"-Dateien includiert...)

Grund: In C-Strings werden mit "\" Sonderzeichen angegeben, wie z.B. 
\n, \r, \t.

\L ist jetzt zwar kein gültiges, aber z.B.
"include\test.c" würde/sollte im aktuellen Verzeichnis nach einer Datei 
"include<TAB>est.c" suchen.

[Jörg W. (dl8dtl) (Moderator)]

Linksammler schrieb:
> FTDI mit Loopback-Brücke RX<>TX läuft mit 1MBaud?

Das sagt aber nichts über die wirkliche Datenrate aus.  Man
müsste dann schon noch mit einem Oszi nachmessen an der Brücke.

[Tycho B. (asellus)]

HTERM hat keine config-Datei dabei, habe die wohl als portable 
runtergeladen. Das Einstellen von 1000000 war seltsam, weil das Programm 
mich nach jeder Zahleingabe aus dem Eingabenfeld rausgeschmissen hat. 
Trotzdem: auch mit HTERM und 1000000 Baud klappt es nicht.

[Tycho B. (asellus)]

Mikrocontroller ist im Evaluationsboard 2.0.1 drin, also ja, 16MHz sind 
dran.

Linksammler schrieb:
> FTDI mit Loopback-Brücke RX<>TX läuft mit 1MBaud?

so, das sagt mir gerade überhaupt nichts. Wo stelle ich was ein?

[Falk B. (falk)]

@Tycho B. (asellus)

>HTERM hat keine config-Datei dabei,

Klar, du musst erstmal die Konfig speichern. Dann kannst du dort drin 
ändern.

[Linksammler (Gast)]

Tycho B. schrieb:
> so, das sagt mir gerade überhaupt nichts. Wo stelle ich was ein?

Einfach ohne Mikrocontroller eine Drahtbrücke zwischen RX und TX des 
FTDI setzten.
Alles was du sendest sollte als Echo sofort zurückkommen.

Aber, wie oben von Jörg angemerkt: eine falsche Datenrate kann's dennoch 
sein.

[Falk B. (falk)]

@Tycho B. (asellus)

>> FTDI mit Loopback-Brücke RX<>TX läuft mit 1MBaud?

>so, das sagt mir gerade überhaupt nichts. Wo stelle ich was ein?

einfach RX und TX am FT232 mit einer Drahtbrücke verbinden. Aber das 
klappt mit JEDER Baudrate. Ohne Oszi oder Logicanalyzer wird das nix.

[Tycho B. (asellus)]

Falk Brunner schrieb:
> Klar, du musst erstmal die Konfig speichern. Dann kannst du dort drin
> ändern.

alles klar, gerade gemacht, kann jetzt auch im pull down 1000000 
selektieren

[Tycho B. (asellus)]

Falk Brunner schrieb:
> einfach RX und TX am FT232 mit einer Drahtbrücke verbinden. Aber das
> klappt mit JEDER Baudrate. Ohne Oszi oder Logicanalyzer wird das nix.

Oszi hätte ich da, allerdings ist mir gerade nicht ganz klar was ich 
nachschauen soll. Uart sync Taktrate?

[Ingo L. (corrtexx)]

Also Termite kann 1MBaud, ich habe das vor längerer Zeit auch mit nem 
FTDI erfolgreich getestet...

Daran sollte es eigentlich nicht liegen. Wie lang is n die Leitung?

[Tycho B. (asellus)]

Ingo Less schrieb:
> Wie lang is n die Leitung?

Digitus RS232 Stick mit dem FTDI-Chip ist direkt am Evalboard 
angeschlossen.

[Falk B. (falk)]

@ Tycho B. (asellus)

>Oszi hätte ich da, allerdings ist mir gerade nicht ganz klar was ich
>nachschauen soll.

OMG!

> Uart sync Taktrate?

Sende zeichen und miss die Bit/Byte Zeiten.

[Amateur (Gast)]

Wenn das Loop-Back funktioniert, heißt das aber nur: "Einer kann’s". Oft 
hapert es daran, dass der andere diese nicht-Standard Baudrate nicht 
kann.

Beim Rechner mal in die Einstellungen gucken. Bei der Hardware ins 
Handbuch und auf den Rechnertakt schauen.

1 MBaud, mit all seinen Problemen, nutzt nichts wenn einer der 
Teilnehmer immer wieder eine Pause einlegt.

[Thomas E. (thomase)]

Tycho B. schrieb:
> Oszi hätte ich da, allerdings ist mir gerade nicht ganz klar was ich
> nachschauen soll. Uart sync Taktrate?

Sende fortlaufend 0x55 mit einem Stopbit. Das ergibt eine Frequenz von 
500KHz.

mfg.

[Tycho B. (asellus)]

Thomas Eckmann schrieb:
> Sende fortlaufend 0x55 mit einem Stopbit. Das ergibt eine Frequenz von
> 500KHz.

Soll ich sowohl den FTDI als auch den Mikrocontroller überprüfen, oder 
ist es eher der letzte, der unter Verdacht steht?

[Dieter F. (Gast)]

Ich könnte mir vorstellen, dass nicht der (bei 16 MHz nicht vorhandene) 
Baudratenfehler auf dem AVR zuschlägt, sondern der Baudratenfehler auf 
der Gegenseite ...

http://www.mikrocontroller.net/articles/Baudratenquarz

Möglicherweise kommt noch eine teilweise fliegende Verkabelung (meine 
Spezialität :-) ) hinzu.

[Tycho B. (asellus)]

Dieter Frohnapfel schrieb:
> Möglicherweise kommt noch eine teilweise fliegende Verkabelung (meine
> Spezialität :-) ) hinzu.

Wie gesagt, alles auf dem Evalboard + 50cm USB-Kabel zum PC.

[Falk B. (falk)]

@ Tycho B. (asellus)

>Soll ich sowohl den FTDI als auch den Mikrocontroller überprüfen, oder
>ist es eher der letzte, der unter Verdacht steht?

Kann man wirklich so dämlich sein, wenn man ein Oszi rumstehen hat?

Leute gibt's?

[Tycho B. (asellus)]

Thomas Eckmann schrieb:
> Sende fortlaufend 0x55 mit einem Stopbit. Das ergibt eine Frequenz von
> 500KHz.

ok, ich kenne mich mit dem Aufbau von Uart nicht aus, deswegen habe ich 
erstmal 0 geschickt -> erhalte Pulse mit 1µs high time und 10 µs 
Periode.
0xFF -> wieder 10 µs Periode, high time 9µs
0x55 -> 2 µs Periode, 1 µs high time, also 500kHz

[Tycho B. (asellus)]

Falk Brunner schrieb:
> Kann man wirklich so dämlich sein, wenn man ein Oszi rumstehen hat?

Ja, kann man :) Un mein Oszi hat 30000 gekostet :P

[Falk B. (falk)]

@Tycho B. (asellus)

>ok, ich kenne mich mit dem Aufbau von Uart nicht aus,

Dann wird es höchste Zeit, das zu ändern!

>erstmal 0 geschickt -> erhalte Pulse mit 1µs high time und 10 µs
>Periode.
>0xFF -> wieder 10 µs Periode, high time 9µs
>0x55 -> 2 µs Periode, 1 µs high time, also 500kHz

Schick mal EINZELNE Zeichen mit Pause. Mit deinem 30000 Euro Oszi kann 
man triggern, dann kannst du dir das Byte mit Start- und Stopbit 
anschauen.

ein 0x00 erzeugt einen LOW Pulse mit 9 Bits, das Stopbit ist wieder 
HIGH.

Ein 0x01 erzeugt dir einen kurzen Puls am Anfang von exakt einer 
Bitzeit.

[Tycho B. (asellus)]

0x01
low, zwei pulse, high

erster puls: ca. 0,8µs
low pegel : ca. 1µs
zweiter Puls: ca. 1µs
low pegel: 7µs
high pegel ohne ende

[Jörg W. (dl8dtl) (Moderator)]

Tycho B. schrieb:
> erster puls: ca. 0,8µs

Der ist suspekt, der Rest passt.

Wir haben hier problemlos 1 MBaud mit einem FT232 an einem ATmega256RFR2
benutzt, Gegenseite war pyserial, aber Teraterm unter Windows kann es
auch.

[Tycho B. (asellus)]

0x00

low
puls:0,7µs
low :9µs
igh

[Tycho B. (asellus)]

ok, wenn ich eine 500µs pause einfüge, dann sieht es anders aus

int main(void)
{
  uart_init();
  _delay_ms(500);
  
  while(1)
  {    
    /* Put data into buffer, sends the data */
    
    UDR0 = 0x00;
    while (1)
    {
    }
  }
}

0x00 nur ein low von 9µs länge

0x01
high
low 1µs
high 1µs
low 7µs
high

[MWS (Gast)]

Laut Simulation im AVR-Studio 6.1 wird bei obigem (erstem) Code das 
TXC0-Flag 160 Takte nach Beschreiben des UDR0 gesetzt.

1 Startbit, 8 Datenbit, 1 Stopbit = 10 Bits, jedes Bit 16 Takte, passt 
genau.

[Dieter F. (Gast)]

Könntest Du so ein schönes 0x55 mit Stopbit bitte mal aus HTERM heraus 
senden und am FTDI-Ausgang mit dem Oszilloskop messen?

[Tycho B. (asellus)]

MWS schrieb:
> passt genau.
ja, den Eindruck habe ich auch.
habe jetzt das Oszi an FTDI angeschlossen, die Flanken sind deutlich 
abgeflachter und die Timings stimmen nicht mehr
bei 0x01 das letzte low, das 7µs haben sollte, hat FWHM 7,2µs

[Falk B. (falk)]

@ Tycho B. (asellus)

>low, zwei pulse, high

Schon mal was von einem Screenshot gehört? Das können heute selbst 300 
Euro Billigoszis.

>erster puls: ca. 0,8µs

Darf nicht sein, im Ruhezustand muss dort dauerhaft HIGH anliegen.

>low pegel : ca. 1µs
>zweiter Puls: ca. 1µs
>low pegel: 7µs
>high pegel ohne ende

das klingt OK.


HHHHHHH L H L L L L L L L H HHHHHHHH
        S 0 1 2 3 4 5 6 7 S
        T                 T
        A                 O
        R                 P
        T

[Dieter F. (Gast)]

Findet sich eine FTDIPORT.INF auf Deinem Rechner - und könntest Du die 
mal bitte einstellen?

[Falk B. (falk)]

@Tycho B. (asellus)

>habe jetzt das Oszi an FTDI angeschlossen, die Flanken sind deutlich
>abgeflachter und die Timings stimmen nicht mehr
>bei 0x01 das letzte low, das 7µs haben sollte, hat FWHM 7,2µs

SCREENSHOT! Wie misst du? Mit einem 10:1 Tastkopf? Masse richtig 
angeschlossen?

[Tycho B. (asellus)]

0x55
mist, mit 50µs Darstellungsbereich habe ich 25 Perioden, die Timings des 
ftdi stimmen also auch. warum klappt es denn nicht?

[Dieter F. (Gast)]

Tycho B. schrieb:
> 25 Perioden

Bei einmal 0x55 senden hast Du 25 Perioden?

[Tycho B. (asellus)]

Dieter Frohnapfel schrieb:
> Findet sich eine FTDIPORT.INF auf Deinem Rechner - und könntest Du die
> mal bitte einstellen?

[Tycho B. (asellus)]

Dieter Frohnapfel schrieb:
> Bei einmal 0x55 senden hast Du 25 Perioden?

nein, sorry, war eine Sequenz 55 55 55 55 usw, die ich geschickt habe

[Tycho B. (asellus)]

Falk Brunner schrieb:
> SCREENSHOT!

am ftdi mit 55 sequenz

[Falk B. (falk)]

Stell mal EIN EINZELNES 0x01 Byte bildschirmfüllend dar und miss mit dem 
Cursor die Zeiten.

[Tycho B. (asellus)]

Falk Brunner schrieb:
> Wie misst du? Mit einem 10:1 Tastkopf? Masse richtig
> angeschlossen?

Masse ist richtig angeschlossen, kein Tastkopf, direkte Klemmen

[Dieter F. (Gast)]

Tycho B. schrieb:
> am ftdi mit 55 sequenz

Schade (für Dich eher nicht :- ) - ich hatte auf die Nutzung der 
vordefinierten Baudraten in der FTDIPORT.INF getippt.

"The FtdiPort232.NT.HW.AddReg section of FTDIPORT.INF contains the 
ConfigData string and it is this string that controls the baud rate 
calculation.
The FTDIPORT.inf file may be viewed and edited with any text editor e.g. 
WordPad.
...
The following lists the standard values and their respective baud rates
10,27 => divisor = 10000, rate = 300
88,13 => divisor = 5000, rate = 600
C4,09 => divisor = 2500, rate = 1200
E2,04 => divisor = 1250, rate = 2,400
71,02 => divisor = 625, rate = 4,800
38,41 => divisor = 312.5, rate = 9,600
9C,80 => divisor = 156, rate = 19,230
4E,C0 => divisor = 78, rate = 38,461
34,00 => divisor = 52, rate = 57,692
1A,00 => divisor = 26, rate = 115,384
0D,00 => divisor = 13, rate = 230,769
06,40 => divisor = 6.5, rate = 461,538
03,80 => divisor = 3.25, rate = 923,076
00,00 => RESERVED
D0,80 => divisor = 208.25, rate = 14406"

[Falk B. (falk)]

@ Tycho B. (asellus)

>> Wie misst du? Mit einem 10:1 Tastkopf? Masse richtig
>> angeschlossen?

>Masse ist richtig angeschlossen, kein Tastkopf, direkte Klemmen

Warum glaubst du, hat der liebe Gott den Tastkopf erfunden? Damit du 
dein 30000 Euro Oszi mit zwei Strippen Klingeldraht anklemmst? Eher 
nicht. Was mal wieder den schönen Satz beweist.

Everything is easy with the right tool. But a fool with a tool is still 
a fool.

Nutze einen 10:1 Taskopf und staune.

[Tycho B. (asellus)]

Falk Brunner schrieb:
> Stell mal EIN EINZELNES 0x01 Byte bildschirmfüllend dar und miss mit dem
> Cursor die Zeiten.

über HTERM ein einzelnes 0x01 gesendet und am ftdi abgegriffen
interessanterweise muss ich immer zwei mal schicken, damit das Oszi ein 
mal getriggert wird, beim ersten mal passiert nichts

[Dieter F. (Gast)]

Tycho B. schrieb:
> ftdi abgegriffen

Wenn meine Brille nicht schief sitzt und ich richtig rechne sieht das 
nach ca. 3% Fehler aus.

[Tycho B. (asellus)]

Falk Brunner schrieb:
> Nutze einen 10:1 Taskopf und staune.

Es wird sich nichts verändern. Die Timings bleiben dieselben ob ich nu 
1MOhm, 10MOhm oder einen kapazitiven Abgleich mache.

[Jörg W. (dl8dtl) (Moderator)]

Tycho B. schrieb:
> Die Timings bleiben dieselben ob ich nu 1MOhm, 10MOhm oder einen
> kapazitiven Abgleich mache.

Aber vielleicht siehst du ja dann wenigstens saubere Flanken.

[Tycho B. (asellus)]

Dieter Frohnapfel schrieb:
> Wenn meine Brille nicht schief sitzt und ich richtig rechne sieht das
> nach ca. 3% Fehler aus

Entschuldigung, wenn ich hier schon ein solch geniales Gerät zu stehen 
habe...
ich habe cursors eingeblendet

[Falk B. (falk)]

@ Tycho B. (asellus)

>über HTERM ein einzelnes 0x01 gesendet und am ftdi abgegriffen

Sieht OK aus bezügliche der Signalqualität. Aber Das Timining ist um ca. 
200ns zu schnell, d.h. 2,3% Fehler. Das ist grenzwertig. Das kann der 
FT232 genauer.

[Falk B. (falk)]

@Tycho B. (asellus)

>> Wenn meine Brille nicht schief sitzt und ich richtig rechne sieht das
>> nach ca. 3% Fehler aus

>Entschuldigung, wenn ich hier schon ein solch geniales Gerät zu stehen
>habe...
>ich habe cursors eingeblendet

Hier sind es nur 0,6% Fehler. Komisch.

[Tycho B. (asellus)]

man sollte natürlich immer die selbe, steigende oder fallende flanke 
nehmen...

[Jörg W. (dl8dtl) (Moderator)]

Tycho B. schrieb:
> ich habe cursors eingeblendet

Da der Ruhepegel H ist, solltest du besser auf die fallende Flanke
triggern.

[Tycho B. (asellus)]

noch einmal mit 55 sequenz
23 perioden 45,8µs gesamtzeit -> 1,99µs/periode

[Arduinoquäler (Gast)]

Jörg Wunsch schrieb:
> Da der Ruhepegel H ist, solltest du besser auf die fallende Flanke
> triggern.

Da hat er ein supergeiles Gerät und man muss ihm jeden Finger
einezln führen .....

[Falk B. (falk)]

@ Tycho B. (asellus)

>    LeCroy25.png

>man sollte natürlich immer die selbe, steigende oder fallende flanke
>nehmen...

Hmmm, 1,84us für 2 Bit ist zu schnell, das wären 8,6% Fehler!

Was ist hier los?

Miss mit einem GESCHEITEN TASTKOP!

[Tycho B. (asellus)]

nochmal dasselbe für µController

Arduinoquäler schrieb:
> Da hat er ein supergeiles Gerät und man muss ihm jeden Finger
> einezln führen .....

ja voll schlimm man! Der erste sinnfreie Beitrag im Thread, gratuliere!

[Jörg W. (dl8dtl) (Moderator)]

Tycho B. schrieb:
> nochmal dasselbe für µController

Kannst du das denn jetzt nochmal für ein Byte machen?

In den anderen Screenshots erschien das erste Startbit immer zu kurz,
während die laufende Sequenz OK ist.

[Falk B. (falk)]

@ Tycho B. (asellus)

>    LeCroy27.png

Das sieht schon anders aus. Hast du endlich den Tastkopf gefunden? Nun 
hast du DEUTLICH mehr Bandbreite, was man auch an den Störungen durch 
den höchstwahrscheinlich ungünstigen Masseanschluß sehen kann ;-)

[Tycho B. (asellus)]

Falk Brunner schrieb:
> Hast du endlich den Tastkopf gefunden?

nein, die Flanken am Ausgang des µKontrollers sind deutlich steiler.
jetzt habe ich aber einen Tastkopf )
ab jetzt also mit einem Tastkopf, ach wenn ich nicht glaube, dass 
daudurch sich etwas ändert

Jörg Wunsch schrieb:
> Kannst du das denn jetzt nochmal für ein Byte machen?

anbei, 0x55

[Jörg W. (dl8dtl) (Moderator)]

Tycho B. schrieb:
> anbei, 0x55

Sieht völlig OK aus.

Können die denn nun miteinander reden?

[Tycho B. (asellus)]

einzelnes 0x01 am FTDI gemessen, mit 1:1 Tastkopf

[Falk B. (falk)]

@ Tycho B. (asellus)

>einzelnes 0x01 am FTDI gemessen, mit 1:1 Tastkopf

Bist du ein Komiker oder nur leseschwach? Warum woll sagte ich mehrfach 
ZEHN zu EINS Teiler?

[Tycho B. (asellus)]

Tycho B. schrieb:
> einzelnes 0x01 am FTDI gemessen, mit 1:1 Tastkopf

hier ist wieder ein sehr hoher Fehler, das erste low ist nur 846ns lang

[Tycho B. (asellus)]

Falk Brunner schrieb:
> Bist du ein Komiker oder nur leseschwach?

Hast du denn gelacht? Also. :)
jetzt 1:10
0x01 FTDI einzelnes Zeichen

[Falk B. (falk)]

@ Tycho B. (asellus)

>hier ist wieder ein sehr hoher Fehler, das erste low ist nur 846ns lang

Ja. Das kann aber OK sein, denn der FTDI hat einen gebrochenrationalen 
Baudratenteiler. Der arbeitet intern mit 48 MHz. Allerdins wäre dann sie 
Zeitauflösung ~20ns, nicht 150ns, die hier fehlen. Merkwürdig.

[uwe (Gast)]

> >einzelnes 0x01 am FTDI gemessen, mit 1:1 Tastkopf

>Bist du ein Komiker oder nur leseschwach? Warum woll sagte ich mehrfach
>ZEHN zu EINS Teiler?
Lach...

[Tycho B. (asellus)]

uwe schrieb:
> Lach...

man sollte aber schon wissen, dass EGAL wie gedämpft ein Signal ist, 
seine Grundfrequenz ändert sich nicht, gelle?

[Mitlesa (Gast)]

Tycho B. schrieb:
> man sollte aber schon wissen, dass EGAL wie gedämpft ein Signal ist,
> seine Grundfrequenz ändert sich nicht, gelle?

Offensichtlich hast du nicht mal eine Ahnung warum man mit
10:1 Tastkopf messsen sollte.

[Ralf D. (rad)]

Die Ungleichheit von Low- und High-Bitzeit fällt ja schon im Bild 
LeCroy24.png auf ... ist ja aber - zumindestens wenn sie in solcher 
Größenordnung bleibt - nicht wirklich relevant für eine UART.

Interessant wäre das selbe Bild, also mit der selben Bemaßung von 
fallender Startbitflanke bis zur steigenden Stopbitflanke des µC.
Besser noch wären jeweils zwei unmittelbar nacheinander gesendete 0x01 
so das man von Startbit bist Startbit messen und vergleichen kann.

[Tycho B. (asellus)]

Mitlesa schrieb:
> Offensichtlich hast du nicht mal eine Ahnung warum man mit
> 10:1 Tastkopf messsen sollte.

Soll ich meinen rausholen und wir machen 'nen richtigen Vergleich? So 
von Mann zu Mann? Wer wovon wieviel Ahnung hat? Oder willst du mir etwas 
erzählen, was du nicht auf Wiki gelesen hast?

[Tycho B. (asellus)]

Ralf D. schrieb:
> Interessant wäre

Ralf, vielen Dank für die Anregung. Ich werde morgen früh an dieser 
Stelle weitermachen und die von dir gewünschten Bilder reinstellen. 
Würde mich freuen, wenn du vorbeischaust.

[Ralf D. (rad)]

schmunzel ...
Ich komme auch gerne persönlich vorbei und helfe. Also Honorar 
akzeptiere ich das LeCroy. Dafür lass ich Dir dann auch mein Agilent 
54621D von 2003 da; bei dessen Bandbreite ist 1:1 oder 10:1 fast noch 
egal ;)

Schönen Feierabend

[Mitlesa (Gast)]

Ralf D. schrieb:
> Interessant wäre das selbe Bild, also mit der selben Bemaßung von
> fallender Startbitflanke bis zur steigenden Stopbitflanke des µC.

Mit dem Luxus - Equipment das er hat sollte ein einzelnes Byte
darzustellen absolut kein Problem sein.

[Detlev T. (detlevt)]

Tycho B. schrieb:
> Mikrocontroller ist im Evaluationsboard 2.0.1 drin

Und in dem steckt ein MAX232, der laut Datenblatt (TI) nur bis 120kbps 
geht...

Das kann ja so nicht funktionieren.

[MWS (Gast)]

Da stand doch am Anfang was anderes:

Tycho B. schrieb:
> RS232 von FTDI

welches sich ein bisserl von dem hier unterscheidet:

Detlev T. schrieb:
> Und in dem steckt ein MAX232, der laut Datenblatt (TI) nur bis 120kbps
> geht...

MAX232 von FTDI kenn' ich nicht.

[Detlev T. (detlevt)]

@MWS
Ich meinte nicht den USB/RS232-Umsetzer am PC, sondern die Gegenstelle 
auf dem Board, das laut TO ein "Evaluationsboard 2.0.1" ist. So etwas 
gibt es bei Pollin für wenig Geld - Die Leistung ist entsprechend. 
Dessen Pegelwandler macht die hohen Raten einfach nicht mit.

[MWS (Gast)]

Detlev T. schrieb:
> Ich meinte nicht den USB/RS232-Umsetzer am PC, sondern die Gegenstelle
> auf dem Board, das laut TO ein "Evaluationsboard 2.0.1" ist.

Das habe ich schon verstanden und damit hast Du auch den Nagel auf den 
Kopf getroffen.

Aber ich kann mir jetzt vorstellen was das FTDI im Eingangspost 
bedeutet: der TE verwendet wohl ein FTDI USB/RS232 Kabel, mit dem er auf 
den Max232 des Evaluationboards geht.

Auch wenn's sein Kabel mitmacht - die sollten 1MBaud schaffen - so 
packt's der Max232 nicht.

Für mich hat sich das im Eingangsport dagegen nach FT232RL angehört, der 
schafft 3MBaud und deswegen fand' ich's wert, darauf hinzuweisen.

[Dieter F. (Gast)]

Falk Brunner schrieb:
> gebrochenrationalen
> Baudratenteiler. Der arbeitet intern mit 48 MHz.

Nop - die werden über Vorteiler auf 3 MHz gebracht. Und von da sollte es 
mit einem Teiler durch 3 glatt auf 1 MHz gehen.

Wenn es nicht der Eingangsbaustein auf dem Pollin?-Board ist, dann wird 
wohl der FTDI-Treiber nicht optimal steuern.

[Falk B. (falk)]

@ Dieter Frohnapfel (jim_quakenbush)

>> gebrochenrationalen
>> Baudratenteiler. Der arbeitet intern mit 48 MHz.

>Nop - die werden über Vorteiler auf 3 MHz gebracht.

Wollen wir wetten, dass dem nicht so ist? Nur weil in der Formel die 3 
MHz drinstehen, arbeitet der intern noch lange nicht mit 3 MHz. Dann 
sonst könnte er kaum gebrochenrational mit 1/8 bzw. 0.125 Auflösung 
arbeiten. Möglicherweise ist es einfach eine DDS.

>Wenn es nicht der Eingangsbaustein auf dem Pollin?-Board ist,

Doch, das klingt plausibel und einmal mehr ein Grund, IMMER WIEDER auf 
die Netiquette zu verweisen! Dazu gehört eine GESCHEITE Beschreibung 
des Aufbaus! Optimal mit Schalplan und Bild!

>dann wird
>wohl der FTDI-Treiber nicht optimal steuern.

Glaub ich nicht so ganz. Erst recht nicht, wenn das erste Bit um 150 ns 
kürzer ist.

[Dieter F. (Gast)]

Falk Brunner schrieb:
> Wollen wir wetten, dass dem nicht so ist?

Hmm - 1 Tafel Milka Haselnuss Schokolade :-)

AN_120:

A Baud rate for the FT232R, FT2232 (UART mode) or FT232B is generated 
using the chips internal 48MHz clock. This is input to Baud rate 
generator circuitry where it is then divided by 16 and fed into a 
prescaler as a 3MHz reference clock. This 3MHz reference clock is then 
divided down to provide the required Baud rate for the device's on chip 
UART. The value of the Baud rate divisor is an integer plus a 
sub-integer prescaler.

[Ralf D. (rad)]

Falk Brunner schrieb:
> Glaub ich nicht so ganz. Erst recht nicht, wenn das erste Bit um 150 ns
> kürzer ist.

Es würde mich nicht wundern wenn das "analoge" Frontend, der 
Pegelwandler von Logik- zu RS232-Pegeln, im FTDI unsymetrische 
Propagation Delays für steigende und fallende Flanken offenbart ...

Aber der Kasus Knaktus liegt sicher im MAX232 des µC-Boards ...

[Falk B. (falk)]

@ Dieter Frohnapfel (jim_quakenbush)

>Hmm - 1 Tafel Milka Haselnuss Schokolade :-)

Angenommen!

>AN_120:

>A Baud rate for the FT232R, FT2232 (UART mode) or FT232B is generated
>using the chips internal 48MHz clock. This is input to Baud rate
>generator circuitry where it is then divided by 16 and fed into a
>prescaler as a 3MHz reference clock. This 3MHz reference clock is then
>divided down to provide the required Baud rate for the device's on chip
>UART. The value of the Baud rate divisor is an integer plus a
>sub-integer prescaler.

Ich kenne die Passage. Aber ebenso kenne ich die Grundlagen der 
Digitaltechnik, welche es schlicht nicht ermöglichen, einen Takt kleiner 
als 1 Takt zu teilen. Man kann also die 3 MHz nicht durch z.B. 2,125 
teilen wie im Datenblatt angegeben, wenn NUR diese 3 MHz verfügbar 
wären. Darum muss die Schaltung etwas cleverer sein. Und irgendwelche 
Tricks mit Gatterlaufzeiten lohnen sich bei 3 MHz keine Sekunde.

Anders herum wird ein Schuh draus. 3x8=24, was verdächtig nach 48/2 
aussieht. Damit kann man die "scheinbaren" 1/8 Taktschritte problemlos 
teilen. Oder halt direkt mit DDS. Ein 14 Bit Akku mit 48 MHz getaktet 
und den Teiler oben direkt als Increment verwendet könnte klappen. Oder 
ein Bresenham, was aber das Gleiche ist.

3MHz / 2,125 = 1,4117 MHz -> 708,3 ns
708,3ns * 48 MHz = 34 Takte

Na, wessen Pause ist nun lila?

[Dieter F. (Gast)]

Falk Brunner schrieb:
> Angenommen!

O.K., hatte ich weiter oben schon zitiert:

The following lists the standard values and their respective baud rates
10,27 => divisor = 10000, rate = 300
88,13 => divisor = 5000, rate = 600
C4,09 => divisor = 2500, rate = 1200
E2,04 => divisor = 1250, rate = 2,400
71,02 => divisor = 625, rate = 4,800
38,41 => divisor = 312.5, rate = 9,600
9C,80 => divisor = 156, rate = 19,230
4E,C0 => divisor = 78, rate = 38,461
34,00 => divisor = 52, rate = 57,692
1A,00 => divisor = 26, rate = 115,384
0D,00 => divisor = 13, rate = 230,769
06,40 => divisor = 6.5, rate = 461,538
03,80 => divisor = 3.25, rate = 923,076
00,00 => RESERVED
D0,80 => divisor = 208.25, rate = 14406"

Es wird durchaus mit krummen Werten gearbeitet ...

Weiter steht da:

The exact Baud rate may not be achievable - however as long as the 
actual Baud rate used is within +/-3% of the required Baud rate then the 
link should function without errors. When a Baud rate is passed to the 
driver where the exact divisor required is not achievable the closest 
possible Baud rate divisor will be used as long as that divisor gives a 
Baud rate which is within +/- 3% of the Baud rate originally set.
For example:
A non-standard Baud rate of 490000 Baud is required.
Required divisor = 3000000 / 490000 = 6.122
The closest achievable divisor is 6.125, which gives a baud rate of 
489795.9, which is well within the allowed +/- 3% margin of error. 
Therefore 490000 can be passed to the driver and the device will 
communicate without errors.

[Falk B. (falk)]

@ Dieter Frohnapfel (jim_quakenbush)

>O.K., hatte ich weiter oben schon zitiert:

Alles schön und gut, das geht aber an der Streitfrage vorbei.
Die lautet immer noch.

"Arbeitet der Baudgenerator intern direkt mit 48 MHz oder mit 3 MHz"

Meine Antwort ist 48 MHz! Die 3 MHz sind bestenfalls ein Referenz, die 
irgendwie mit verkocht wird. Aber der echte Teiler läuft mit 48 MHz!
Klar, an die echten Logikschltpläne werden wir kaum rankommen.

>03,80 => divisor = 3.25, rate = 923,076

Das mal als Beispiel. 3MHz / 3.25 = 923.076 Hz klar.

Man kann aber auch rechnen 48 MHz / (3,25 * 16) = 923076 Hz

Man hätte den ganzen Kram wahrscheinlich deulich einfacher schreiben 
können, das man klassisch wie immer 48 MHz / N teilt, wobei N=16 oder N 
> 32 und gerade sein muss. Kommt aufs gleiche raus und ist weniger 
mysteriös.
Damit ist klar, dass die Bitlänge in der Schrittweite von 1/48 MHz, ggf 
auch das Doppelte, verstellt werden kann. Das ist ein ganz klassischer 
Teiler. Da ist sogar der MSP430 einen Schritt weiter, der kann nämlich 
jedes Bit des 10 Bit RS232 Rahmens individuell um einen Mastertakt 
strecken oder auch nicht, damit kriegt man noch krummere 
Teilerverhältnisse hin. Die Berechung ist aber nicht ganz trivial und 
man macht das besser mit dem Tool von TI, das da irgendwo rumfliegt.

>Es wird durchaus mit krummen Werten gearbeitet ...

Das war nie die Frage. Sondern wie dies intern real umgesetzt ist.

>The exact Baud rate may not be achievable - however as long as the
>actual Baud rate used is within +/-3% of the required Baud rate then the

Alles nix neues.

[Dieter F. (Gast)]

Falk Brunner schrieb:
> Alles schön und gut, das geht aber an der Streitfrage vorbei.
> Die lautet immer noch.
>
> "Arbeitet der Baudgenerator intern direkt mit 48 MHz oder mit 3 MHz"

Na, dann streite Dich noch ein wenig - für mich ist das recht klar:

Falk Brunner schrieb:
> This 3MHz reference clock is then
>>divided down to provide the required Baud rate for the device's on chip
>>UART.

Ich habe übrigens mal einen ATMega32 mit der Baudrate arbeiten lassen, 
auf einem board mit MAX232N.

Oben (gelb) das Eingangssignal und unten (blau) das Ausgangssignal - 
scheint die Vermutung mit dem unzureichenden MAX232N zu bestätigen. Habe 
aber auch kein 30.000 €-Equipement :-( - bitte also die unzureichende 
Qualität zu entschuldigen.

[Falk B. (falk)]

@ Dieter Frohnapfel (jim_quakenbush)

>> "Arbeitet der Baudgenerator intern direkt mit 48 MHz oder mit 3 MHz"

>Na, dann streite Dich noch ein wenig - für mich ist das recht klar:

Wer glaubt zu wissen, muss wissen, er glaubt.

>>> This 3MHz reference clock is then
>>>divided down to provide the required Baud rate for the device's on chip
>>>UART.

Dann erklär mir mal, wie man einen normalen 3 MHz Takt mit 1/8 Takt 
Auflösung teilt.

>Ich habe übrigens mal einen ATMega32 mit der Baudrate arbeiten lassen,
>auf einem board mit MAX232N.

>Oben (gelb) das Eingangssignal und unten (blau) das Ausgangssignal -
>scheint die Vermutung mit dem unzureichenden MAX232N zu bestätigen.

Nö, schon wieder falsch. Was dort rauskommt ist Matsch. Beim OP ist es 
"nur" ein Pulsbreitenverfäschung. Die Schaltung des OP hat ein Problem, 
aber dennoch deutlich mehr Bandbreite als dein IC.

> Habe
>aber auch kein 30.000 €-Equipement :-( - bitte also die unzureichende
>Qualität zu entschuldigen.

Das hat den OP nicht gerettet. Dich auch nicht. Technik ersetzt kein 
logisches Denken.

[Ralf D. (rad)]

Falk Brunner schrieb:
> Nö, schon wieder falsch. Was dort rauskommt ist Matsch. Beim OP ist es
> "nur" ein Pulsbreitenverfäschung. Die Schaltung des OP hat ein Problem,
> aber dennoch deutlich mehr Bandbreite als dein IC.

öhm ... vom OP haben wir doch noch gar keine Bilder "hinter" dem MAX232 
zu sehen bekommen sondern nur die TX - Seite des FTDI ...

[Dieter F. (Gast)]

Falk Brunner schrieb:
> Das hat den OP nicht gerettet. Dich auch nicht.

Damit werde ich leben müssen.

Falk Brunner schrieb:
> Technik ersetzt kein logisches Denken.

Hier stimmen wir überein.

Dann werde ich mal meine unqualifizierten Äußerungen für mich behalten 
und mit Spannung auf die Lösung warten.


Falk Brunner schrieb:
> Dann erklär mir mal, wie man einen normalen 3 MHz Takt mit 1/8 Takt
> Auflösung teilt.

Das kannst Du ja "Future Technology Devices International Ltd." fragen - 
ich kann es nicht. Aber ich habe es auch nicht geschrieben - lediglich 
zitiert.

[Falk B. (falk)]

@ Ralf D. (rad)

>öhm ... vom OP haben wir doch noch gar keine Bilder "hinter" dem MAX232
>zu sehen bekommen sondern nur die TX - Seite des FTDI ...

Nö, wir wissen gar nicht genau, wo der OP wie gemessen hat. Es hat ja 
auch gefühlt 100 Beiträge gedauert, bis er sich mal erbarmt hat, einen 
Tastkopf zu benutzen. ich glaube nicht, dass der FTDI Flanken mit 100ns 
und mehr Anstiegszeit produziert.

[Dieter F. (Gast)]

Falk Brunner schrieb:
> Beim OP ist es
> "nur" ein Pulsbreitenverfäschung. Die Schaltung des OP hat ein Problem,
> aber dennoch deutlich mehr Bandbreite als dein IC.

Nur noch eine Frage: Wenn der "OP" tatsächlich das Pollin-Board mit dem 
MAX232N nutzt - und der MAX232N kann (falls Du das nicht auch 
anzweifelst)

Data rate One TOUT switching 120 kbit/s

dann spielt die "Pulsbreitenverfälschung" ggf.doch nicht die 
entscheidende Rolle - oder?

So, jetzt gehe ich schlafen und schaue mir morgen an, wie es weiterging. 
Gute Nacht.

[Falk B. (falk)]

@ Dieter Frohnapfel (jim_quakenbush)

>dann spielt die "Pulsbreitenverfälschung" ggf.doch nicht die
>entscheidende Rolle - oder?

Keine Ahnung. Man muss mal Klarheit schaffen WAS da wirklich auf dem 
Tisch liegt und WO WIE gemssen wird.

[Tycho B. (asellus)]

Ralf D. schrieb:
> öhm ... vom OP haben wir doch noch gar keine Bilder "hinter" dem MAX232
> zu sehen bekommen sondern nur die TX - Seite des FTDI ...

doch, das war am Jumper 1 abgegriffen, also hinter dem MAX232

Falk Brunner schrieb:
> Es hat ja
> auch gefühlt 100 Beiträge gedauert, bis er sich mal erbarmt hat, einen
> Tastkopf zu benutzen.

ich hab' mal zwei Bilder rangehängt, damit wir uns verstehen. Die 
Timingdifferenz liegt innerhalb der Messunsicherheit.

Vielen Dank an Alle, besonders an Detlev T. Die Erklärung ist plausibel, 
erklärt auch, warum ich bis 250kBaud gehen konnte (Spec großzügig 
geschrieben, guter Sicherheitspuffer, Produktstreuung o.ä.), 500k 
klappte auch, aber nur wenn ich bei HTERM 510k eingegeben habe und 
vermutlich mit deutlicher Fehlerrate (nicht überprüft).

Plausibel, aber innerhalb der nächsten Stunden von mir nicht zu 
überprüfen. Gibt es denn eventuell einen IC mit gleichem Layout und 
Belegung, so dass ich den einfach mal austauschen kann? Wenn nicht, dann 
läuft's auf ein anderes Evalboard oder Selbstentwicklung hinaus.

Grüße
Tycho

PS. Die hier im Thread von mir gezeigten Messungen sind auch mit 
deutlich preiswerteren Oszis genauso durchführbar. Die kürzesten 
Ereignisse sind ca. 50ns lang (einzelne fallende Flanke), so dass nach 
Nyquist-Shannon ein Oszi mit 50-100 MHz Bandbreite und Triggerfähigkeit 
vollkommen ausreichend ist. Speichern, Screenshots, Cursors ist alles 
nice to have, aber nicht unbedingt notwendig.

[Tycho B. (asellus)]

Falk Brunner schrieb:
> Doch, das klingt plausibel und einmal mehr ein Grund, IMMER WIEDER auf
> die Netiquette zu verweisen

LOOOOOL! Ausgerechnet von dir! Falk, benutze jedes andere Wort, nur 
bitte nicht die Netiquette! )))))

[Dieter F. (Gast)]

Tycho B. schrieb:
> doch, das war am Jumper 1 abgegriffen, also hinter dem MAX232

Und da hast du bei 1 MBaud noch solch tolle Signalform? Obwohl der 
MAX232 das eigentlich gar nicht kann? Ich bin verwirrt ...

[Frank M. (ukw) (Moderator)]

Tycho B. schrieb:
> LOOOOOL! Ausgerechnet von dir! Falk, benutze jedes andere Wort, nur
> bitte nicht die Netiquette! )))))

Falk weist - zu Recht - sehr oft auf die Netiquette hin. Du verwechselst 
diese offenbar mit "nett zueinander sein". Das ist aber eine komplett 
unzureichende Interpretation Deinerseits, denn offenbar hast Du sie noch 
nicht gelesen:

             Netiquette
                 ^
                 Hier klicken

Insbesondere bezieht sich Falk hierbei auf das Kapitel "Klare 
Beschreibung des Problems".

[Falk B. (falk)]

@ Tycho B. (asellus)

>> zu sehen bekommen sondern nur die TX - Seite des FTDI ...

>doch, das war am Jumper 1 abgegriffen, also hinter dem MAX232

Toll! Wenn du das deutlich eher gesagt hättest und freundlicherweise auf 
das Datenblatt verwiesen hättest, hätten wir uns viel sinnlosen Eiertanz 
erspart. Jaja, dann wäre das Forum öd und leer und alle Problem mit 
einer Handvoll Beträgen erledigt.

http://www.pollin.de/shop/downloads/D810074B.PDF

Seite 6, JP1

[Ralf D. (rad)]

Dieter Frohnapfel schrieb:
> Und da hast du bei 1 MBaud noch solch tolle Signalform? Obwohl der
> MAX232 das eigentlich gar nicht kann? Ich bin verwirrt ...

Mich hat das heute morgen dann auch gewundert aber ein Blick in das 
Datenblatt http://datasheets.maximintegrated.com/en/ds/MAX220-MAX249.pdf 
dieses Dinosauriers bei Maxim erklärt es wohl:

Der Receiver (RS232 -> TTL) hat deutlich weniger typisches und maximales 
Propagation Delay als der Transmitter (TTL -> RS232) und in beiden 
Richtungen ist diese bei steigender und fallender Flanke auch noch 
unterschiedlich.

Wieso jemand (in diesem Fall Pollin) diesen Uraltbaustein überhaupt noch 
einsetzt obwohl schon recht lange (> 10 jahre) deutlich bessere 1MBaud 
und 3MBaud Varianten verfügbar sind ist mir völlig unverständlich :-(


@ Tycho B. (asellus)
Ich hoffe Du erkennst jetzt wie hilfreich es gewesen wäre wenn Du schon 
in Deinem EP den gesammten Aufbau vollständig und deutlich exakter 
beschrieben hättest. Dann wäre kein ganzer Tag dafür drauf gegangen ...

[Falk B. (falk)]

@ Ralf D. (rad)

>Wieso jemand (in diesem Fall Pollin) diesen Uraltbaustein überhaupt noch
>einsetzt obwohl schon recht lange (> 10 jahre) deutlich bessere 1MBaud
>und 3MBaud Varianten verfügbar sind ist mir völlig unverständlich :-(

Weil kein Schwein RS232 mit 1Mbaud nutzt, schon gar nicht auf einem 
spottbilligen Evalboard!

[Ralf D. (rad)]

Falk Brunner schrieb:
> @ Ralf D. (rad)
> Weil kein Schwein RS232 mit 1Mbaud nutzt, schon gar nicht auf einem
> spottbilligen Evalboard!

schmunzel ...
Dann bin ich wohl ein schwarzes Schwein ;-)

[Frank B. (f-baer)]

Nur mal so als Hinweis:

Dein 30k-Oszi hat mit an Sicherheit grenzender Wahrscheinlichkeit einen 
Protokoll-Decoder für UART, mit dem du dir das Ausmessen der 
High-/Low-Zeiten hättest sparen können. Der Button dazu ist sogar auf 
deinen ersten Screenshots zu sehen.
Kurz die Tastspitze (!) an den TX vom µC gehalten, und du hättest genau 
dein vom AVR gesendetes Byte gesehen, zwischen MAX232N und FT232 wäre 
Müll auf der RX und TX gewesen, und am RX vom MAX232N hättest du exakt 
gesehen, was du mit dem PC schickst. Dazu hätte dir der Oszi auch noch 
die Baudrate ausgespuckt und die Frage nach dem Baudratenfehler 
beantwortet.

Das hätte ungefähr 5 Minuten gedauert, dann hättest du, oder jemand hier 
im Forum, bemerkt, dass der Pegelwandler das Problem darstellt. Von da 
bis zum Lesen des Datenblattes wäre es nur noch ein kurzer Schritt 
gewesen.

Bitte beim nächsten Mal nicht mit dem teuren Equipment pranzen, wenn man 
es sowieso nur auf dem Niveau eines Analog-Oszi von 1980 bedienen kann. 
Ein 30k-Oszi nutzt nur, wenn man ihn bedienen kann, sonst ist es einfach 
nur teurer Elektroschrott.