Hallo,
ich hab einen Aufbau mit MCU + FT232. Die beiden liegen etwa 5cm
auseinander. Die Übertragung mit 115k2 Baud klappt, 921k6 geht in die
Hose, der Controller empfängt Murks. Das Senden vom Controller zum FT232
scheint soweit ich es sehen kann fehlerfrei zu sein (oder die Fehlerrate
ist wesentlich geringer).
Ich hab mir die Signale mit'm Oszi angesehen. Die einzige Auffälligkeit
waren Over-/Undershoots. Ich frag mich nun wie ich die wegbekomme.
Ich habe 27R in Rx/Tx gesetzt, ohne Wirkung. Ebenfalls wirkungslos blieb
die Terminierung von Rx/Tx mit jeweils 2k2 nach VCC & GND.
Ein Versuch mit einem FT230X brachte das gleiche zutage :/
Würden Kondensatoren etwas nützen, um die Spikes zu kappen?
Ralf
Hallo,
Wie ist der FT232 mit +5V (Vcc) versorgt -
a) über einen Spannungsregler an dem auch die Schaltung hängt
b) oder über USB ohne Filter etc. ?
In die Vcc würde ich immer je ein C-L-C Glied, als Siebung, einbauen.
Die Masse fächig (Kupferband) anlegen, kein 0,6mm o.ä. Draht.
Jeweils die TX könnten mit R = 27R in Reihe und dann C = ca. 33pF nach
Masse beschaltet werden.
Dann bitte mit die Oszi die Flanken am Ende des Kabels betrachten !
@Uwe:
> Wie ist der FT232 mit +5V (Vcc) versorgt -> -> b) oder über USB ohne Filter etc. ?
Ein Ferrit ist in der Versorgung, den Wert müsst ich jetzt raussuchen,
er liegt aber in der Nähe des vorgeschlagenen Wertes aus dem Datenblatt.
> In die Vcc würde ich immer je ein C-L-C Glied, als Siebung, einbauen.
Siehe oben.
> Die Masse fächig (Kupferband) anlegen, kein 0,6mm o.ä. Draht.
Ja, das hab ich befürchtet... Die Controllerplatine hat eine GND-Fläche
auf Top/Bottom, die FTDI-Platine zwar auch, aber die sitzt auf nem Stück
Lochraster, verbunden über Stift-/Buchsenleisten mit der
Controllerplatine.
Die Controllerplatine wird mit den 5V aus USB versorgt, ein LDO knüppelt
auf 3.3V runter. Der Controller verträgt auch 5V-Pegel am Rx, also habe
ich VIO vom FTDI in allen drei Varianten probiert:
1) VIO = 5V-USB
2) VIO = 3.3V-LDO
3) VIO = 3.3V-FT232
> Jeweils die TX könnten mit R = 27R in Reihe und dann C = ca. 33pF nach> Masse beschaltet werden.
Also jeweils so nah wie möglich am Tx-Pin platzieren?
> Dann bitte mit die Oszi die Flanken am Ende des Kabels betrachten !
Okay.
@Holger:
> Welcher Controller?
SiLabs C8051F800. SYSCLK interner Oszillator @ 24.5MHz, Baudrate über
externen 14.7456MHz Quartz.
Ralf
>> Welcher Controller?>SiLabs C8051F800. SYSCLK interner Oszillator @ 24.5MHz
Und der soll fast 1MBit über UART machen?
Besorg dir mal nen ARM. Bei deiner Hardware liegt das
Problem nicht. Eher in deiner Software. Zu langsam.
holger schrieb:> Und der soll fast 1MBit über UART machen?
Das sind 265 CPU-Zyklen je Byte, da langweilt sich der 8051 ja zu Tode.
Für nen Interrupthandler als FIFO reicht das dicke.
Versuch mal ein einfaches Testprogramm, das nur ein Echo sendet:
@Holger:
>>SiLabs C8051F800. SYSCLK interner Oszillator @ 24.5MHz> Und der soll fast 1MBit über UART machen? Besorg dir mal nen ARM. Bei> deiner Hardware liegt das Problem nicht. Eher in deiner Software. Zu> langsam.
Wieso? Das ist ein Single-Cycle-Core.
@Peda:
>> Und der soll fast 1MBit über UART machen?> Das sind 265 CPU-Zyklen je Byte, da langweilt sich der 8051 ja zu Tode.> Für nen Interrupthandler als FIFO reicht das dicke.
Sehe ich auch so, selbst wenn meine Interrupt-Implementierung vielleicht
oversized sein mag.
Ausserdem würde ich bei einem schlechten FIFO-Handling eher auf
verschluckte als auf fehlerhaft empfangene Daten tippen.
> Versuch mal ein einfaches Testprogramm, das nur ein Echo sendet:
Ich habe momentan eine interruptgesteuerte Implementierung, mit der ich
das so schon probiert habe. Aber du hast recht, mit Polling hab ich den
Echo-Test noch nicht gemacht.
Werd ich gleich mal probieren.
Ralf
Ralf schrieb:>>>SiLabs C8051F800. SYSCLK interner Oszillator @ 24.5MHz
Hast du auch überprüft mit welchen Fehler der UART-Baudrategenerator die
921k6-Baud generieren kann? Bei höheren Baudraten hat man da
normalerweise einen größeren Fehler und man muß entweder die
Taktfrequenz oder die gewählte Baudrate ändern.
@Fritz:
> Hast du auch überprüft mit welchen Fehler der UART-Baudrategenerator die> 921k6-Baud generieren kann? Bei höheren Baudraten hat man da> normalerweise einen größeren Fehler und man muß entweder die> Taktfrequenz oder die gewählte Baudrate ändern.
Deswegen:
>> SYSCLK interner Oszillator @ 24.5MHz, Baudrate über externen 14.7456MHz>> Quartz.
Ralf
@Uwe:
>> Jeweils die TX könnten mit R = 27R in Reihe und dann C = ca. 33pF nach>> Masse beschaltet werden.
Hat nichts gebracht, der Empfang ist genauso besch...eiden wie zuvor.
Allerdings kann ich den Signalverlauf hier nicht messen, das muss ich
nächste Woche tun.
Mehr Kapazität?
Ralf
Kann sein, muss aber nicht. Ich hatte auch noch einen PL2303 probiert
und der hat nicht richtig funktioniert, da kam dauernd UART overrun.
FTDI habe ich nicht getestet.
GND habe ich nicht verbunden weil FPGA Board und PC Mainboard die
gleiche Masse haben, also quasi verbunden.
Edit:
Wenn du mir deine Anschrift gibst schicke ich dir gerne die PL2303HX
(schaffen offiziell 6M Baud
http://www.adafruit.com/datasheets/PL2303HX.pdf ) die ich nicht
verwende. Ich glaube das sind 3 Stück oder so ...
Einen oder zwei CP2102 hab ich auch noch die ich nicht brauche, aber da
habe ich schon jeweils den USB-Stecker weggelötet weil ich die auf den
Pfostenstecker auf dem PC Mainboard stecken wollte.
Eigentlich sollte das aber auch gut mit dem FTDI laufen. Guck mal ob ein
Logicanalyzer der RS232 kann dir die richtigen Daten anzeigt.
> Ich hab mir die Signale mit'm Oszi angesehen. Die einzige Auffälligkeit> waren Over-/Undershoots
da Du Deine eingeleiteten Dämpfungsmaßnahmen als
> ohne Wirkung> Ebenfalls wirkungslos
beschreibst, liegt die Ursache für Deine Over-/ Undershoots IMHO bei
einem schlecht angepassten Tastkopf und dürften somit nicht Ursache für
die schlechte Datenübertragung sein.
Wie greifts Du das Signal ab?
Das könnte hilfreich sein:
http://www.mikrocontroller.net/attachment/112028/WB_Oszi-Tastkopf_004.jpg
Viel Erfolg!
Ich hatte ein ähnliches Problem, und zwar das mein Platine ein Jumper
für VCCIO (3V3, 5V) hat.
Bei Jumper offen und 115K alles ging.
Erste bei höher Baudrate ging es nicht mehr.
Also Jumper geschlossen und es ging.
@Uwe:
Die R-C Kombination in der Tx-Leitung vom FT232R zum Controller hat bei
22R/33pF keine Verbesserung gebracht und bei 220pF logischerweise die
Sache verschlimmert ;)
@Gustl:
> Die Daten kommen von einem FPGA, auch 921600 8N1. An den Tx Pin habe ich> direkt den Rx Pin vom UART Controller gelötet und umgekehrt. Und es> klappt hervorragend. Ich verwende statt FTDI einen CP2102
So hab ich's im Prinzip auch, bis auf FT232R anstatt CP2102.
> Ich hatte auch noch einen PL2303 probiert und der hat nicht richtig> funktioniert, da kam dauernd UART overrun.
Wundert mich nicht, ProLific ist bekannt dafür nicht zu funktionieren...
> GND habe ich nicht verbunden weil FPGA Board und PC Mainboard die> gleiche Masse haben, also quasi verbunden.
oO Glückstreffer, behaupte ich mal.
> Guck mal ob ein Logicanalyzer der RS232 kann dir die richtigen Daten> anzeigt.
Jepp, das werd ich mal tun.
@F.H.:
> liegt die Ursache für Deine Over-/ Undershoots IMHO bei einem schlecht> angepassten Tastkopf und dürften somit nicht Ursache für die schlechte> Datenübertragung sein.
Sehe ich mittlerweile auch so. Ich habe den GND-Bezug auch nicht direkt
in der Nähe der Tx-Leitung abgegriffen, was sicherlich auch noch den
Eindruck von Over-/Undershoots verstärkt hat.
@PeDa:
Ich hab den vorgeschlagenen Echotest gemacht, sowohl per Interrupt als
auch per Polling - beides fehlerbehaftet. Der Controller empfängt die
Daten falsch (geprüft mit Debugging/Breakpoint). Also tippe ich entweder
auf GND-Bouncing oder klingelnde Leitungen (wobei das ja bei dem Versuch
mit der Terminierung hätte besser werden müssen, denke ich).
Soweit ich sehen kann, hat der originale 80x2-Kern eine 2-aus-3
Entscheidung beim Empfang getroffen, um den Bitwert zu bestimmen. Der
SiLabs-Kern nimmt wohl nur ein Sample - schade.
@Robert:
Wie ich weiter oben geschrieben hatte, bin ich diesen Weg ebenfalls
schon gegangen.
So, als nächstes werde ich die Controllerschaltung jetzt mal mit einem
separaten Netzteil versorgen anstatt über USB.
Ist zwar ein 5V/4A Schaltnetzteil, aber mal schauen, ob sich was
ändert...
Ralf
Update: Der Test mit einem Logic-Analyzer steht noch aus, mich würde
aber gerade interessieren, ob jemand einen FT232R, FT230 oder einen
CP2103 mit 921600 Baud erfolgreich betrieben hat.
Ralf
Ich habe einen FTDI232H mit 3MBaud getestet, den CP2103 mit 1MBaud und
gerade auch mit 921600, kein Problem. Als uC habe ich aber einen Cortex
M4 STM32F4.. der läuft mit 168 MHz und hat UARTs mit eigenem flexiblem
Baudrategenerator und man brauch keine speziellen Quarzfrequenzen um
krumme Baudraten zu erreichen. Verwendet habe ich Billigmodule von ebay
mit ca. 15cm Leitungen zwischen Pfostensteckern.
Habe einen kurzen Blick auf das Datenblatt des C8051F800 geworfen, dabei
ist mir aufgefallen, dass die Baudratebeispiele bei externen Quarz nur
bis ca. 230000 Baud angeführt waren. Gibt es da vielleicht eine
Beschränkung irgendwo in den Specs? Könnte mir vorstellen, dass bei
getrenntem Sysclock und Baudrateclock Synchronisationscyclen notwendig
sind um von einer Frequenzdomain zur anderen zu gelangen, das könnte die
nutzbare Baudrate beim Empfang limitieren.
Deine Frage sollte mMn daher lauten: Hat schon jemand den C8051F800 mit
921600 Baud betrieben?
PS: Solltest dir mal überlegen ob du nicht doch auf eine modernere
Plattform (z.B. ARM) umsteigen solltest.
> Habe einen kurzen Blick auf das Datenblatt des C8051F800 geworfen, dabei> ist mir aufgefallen, dass die Baudratebeispiele bei externen Quarz nur> bis ca. 230000 Baud angeführt waren. Gibt es da vielleicht eine> Beschränkung irgendwo in den Specs? Könnte mir vorstellen, dass bei> getrenntem Sysclock und Baudrateclock Synchronisationscyclen notwendig> sind um von einer Frequenzdomain zur anderen zu gelangen, das könnte die> nutzbare Baudrate beim Empfang limitieren.
Eine Beschränkung habe ich nicht gefunden, daher sollte das m.E.
eigentlich klappen.
Ich werde jetzt mal eine Testapplikation aufsetzen, die auch für SYSCLK
den externen Quarz verwendet und schauen ob es dann funktioniert.
> Deine Frage sollte mMn daher lauten: Hat schon jemand den C8051F800 mit> 921600 Baud betrieben?
Jepp, die Frage werde ich jetzt auch mal dem SiLabs Support um die Ohren
hauen :D
> PS: Solltest dir mal überlegen ob du nicht doch auf eine modernere> Plattform (z.B. ARM) umsteigen solltest.
Ich bin bereits am Umsteigen, für die dicken Brocken habe ich bereits
Cortex-M3 im Einsatz. Nur ist dieses Projekt so weit fortgeschritten,
dass eine Migration keinen Sinn gemacht hätte - durch das Problem mit
der Baudrate wird's aber wieder sinnig. Außerdem waren die LPC800 bei
Projektstart noch nicht verfügbar, diese liegen aber preislich gleich
mit den F800ern.
Ralf
Kurzes Update: der Test mit dem LogicAnalyzer erübrigt sich. Nach
aktuellem Stand funktioniert es, wenn ich den externen Oszillator als
SYSCLK verwende. Das heisst SiLabs muss mal das Datenblatt überarbeiten
;)
Jetzt muss ich nur noch schauen, wie ich die restlichen Timings gehalten
bekomme...
Ralf
>Nach aktuellem Stand funktioniert es, wenn ich den externen Oszillator als>SYSCLK verwende. Das heisst SiLabs muss mal das Datenblatt überarbeiten>;)
Das heisst du hast versucht einen internen RC Oscillator
für eine UART Verbindung zu benutzen? Kein Wunder das das
nicht funktioniert. Da muss kein Datenblatt neu geschrieben werden.
@Holger:
> Das heisst du hast versucht einen internen RC Oscillator> für eine UART Verbindung zu benutzen? Kein Wunder das das> nicht funktioniert. Da muss kein Datenblatt neu geschrieben werden.
Richtig lesen bitte: für 115k2 -> ja, interner Oszillator, reicht mit
24.5MHz, 2% Toleranz und single-cycle-core locker aus. Für alles drüber
externer Quarz.
Ergo: Doch Datenblatt überarbeiten.
Ralf
