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 !
>der Controller empfängt Murks.
Welcher Controller?
@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:
1 | int main() |
2 | {
|
3 | // hier init UART einfügen
|
4 | for(;;){ |
5 | if( RI ){ |
6 | RI = 0; |
7 | SBUF = SBUF; |
8 | }
|
9 | }
|
10 | }
|
@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
Hallo, ich nutze zwar nicht deinen Aufbau, aber auch ich will irgendwie Daten auf USB und in den Rechner bekommen. 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, gibt es extrem günstig, 3€ incl. Versand bei Ebay. http://www.ebay.de/itm/CP2102-Module-Modul-USB-to-TTL-Converter-Konverter-Red-RS232-neu-/251159450468?pt=Elektromechanische_Bauelemente&hash=item3a7a451364 Ich habe nur Rx und Tx verbunden, Treiber ist im Linux Kernel und für Windows zum nachinstallieren, total super.
Du meinst der FTDI kommt nicht richtig mit? Hmmm...
> Ich habe nur Rx und Tx verbunden
Na, den GND hast du sicherlich auch genommen, oder? ;)
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
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.