Hallo Leute! Möchte mit einem Atmega32 Zeichen auf den PC senden. Als Converter arbeiter ein FT232R von FTDI. Nur kommt leider lauter Mist am Hyperterminal an. Baudrate und Code im Atmega funktionieren allerdings, da ich das ganze auch schon mit einem MAX232 getestet habe. Wenn ich den MC rausnehme und TX und RX vom FT232R verbinde kommen die Daten die ich vom PC sende auch schön wieder zurück. Nur beim Zusammenspiel zwischen MC und FT232R happert es ein wenig. Der MC läuft noch auf dem internen Takt mit 8MHz - vielleicht ist der Takt wirklich zu ungenau und der FT232R kommt damit nicht klar... was meint ihr?
Hallo, was für ne Baudrate hast du? Hast du die Leitungen ausgekreuzt zw. ft232 und atmega (denk schon, sonst würd gar nix ankommen) 8MHz geht definitiv mit zB 9600Bd
Ja Baudrate ist 9600. Leitungen habe ich ausgekreuzt, sonst würd gar nigs kommen, wie du schon gesagt hast... das komische ist, dass mit dem max232 alles funktioniert, das heißt am programm bzw. der Baudrateneinstellung im AVR kann es nicht liegen.
wie sieht der ft232 aus? hast du dich an die standardschaltung vom datenblatt gehalten? also Cs an 3V3 und so?
Mit welcher Spannung versorgst du den mega32? Auf welcher Spannung liegt der VCCIO Pin vom FT232?
Am 3V3 Ausgang habe ich einen Kondensator gegen Masse. Den Mega versorge ich mit 5V, mit der gleichen Spannung versorge ich auch den FT232. Masse von USB und Platinenversorgung habe ich zusammengeschlossen Aber ich sehe gerade dass ich VCCIO nicht beschaltn habe! Das gefällt mir gar nicht, da nachträglich eine Leitung anlöten kann man vergessen oder?
nö, wenn du dünnen draht hast müsste das klappen, hab schon einiges an den ft232 gelötet ;) wenn vccio keine spng hat weiß er nicht, auf welchem level er rx und tx machen soll. deswegen bekommst du wahrscheinlich müll, weil "ab und zu" ne 1 gesehen wird oder nicht.
Wie ist das denn eigentlich zu sehen: Muss die Baudrate des Atmega die gleiche sein wie sie der Rechner erwartet? Oder sind das zwei getrennte vorgänge, also MC -> FT232 und FT232 -> PC und für jeden der Vorgänge muss also die Baudrate stimmen ... ich habe die Leitungen ebenso gekreuzt wie im Datenblatt angegeben, VCCIO an 5V angeschlossen wie den Atmel auch. Wenn ich in der Konsole "echo "\n" > /dev/ttyUSB0" eingebe, leuchtet auch eine der LEDs, wenn ich allerdings mit dem Atmel sende, passiert gar nichts. Ich habe allerdings auch die beiden Leitungen RTS# und CTS# nicht angeschlossen. Hat jemand einen guten Debugging-Tipp? Vielleicht den, dass man auf jeden Fall den FT232 programmieren muss weil vorher gar nichts geht? Im Datenblatt finde ich auch keinen Hinweis auf eine Wald-und-Wiesen-Baudrate die immer geht oder so, daher denke ich dass die Baudrateneinstellung für den FT232 vom Treiber auf Rechnerseite übernommen wird.
Genau, der FT232 übernimmt die Baudrate vom Treiber. Du musst am Rechner nur die selber Baudrate wie am Atmega einstellen dann klappt das auch ;-) wenn du "nur echo blabla" machst kanns sein, dass "irgendwas" nicht stimmt mit deiner Schnittstelle. Du musst auf jeden Fall ein stty davor machen damit zumindest die Baudrate stimmt. Verwende mal gtkterm oder hterm, damit ist das Fehlerpotential schon mal weg. > Wenn ich den MC rausnehme und TX und RX vom FT232R verbinde kommen > die Daten die ich vom PC sende auch schön wieder zurück. was ja bei jeder Baudrate funktioniert.
Ach ja, hier noch der Code mit dem ich das getestet habe. Ich habe ihn mir hier aus dem Tutorial zusammenkopiert und nochmal im Datenblatt geschaut: Die C-Beispiele sind ähnlich.
1 | #define F_CPU 20000000UL // Systemtakt in Hz - Definition als unsigned long beachten
|
2 | // Ohne ergeben sich unten Fehler in der Berechnung
|
3 | |
4 | #define BAUD 9600UL // Baudrate
|
5 | |
6 | // Berechnungen
|
7 | #define UBRR_VAL ((F_CPU+BAUD*8)/(BAUD*16)-1) // clever runden
|
8 | #define BAUD_REAL (F_CPU/(16*(UBRR_VAL+1))) // Reale Baudrate
|
9 | #define BAUD_ERROR ((BAUD_REAL*1000)/BAUD) // Fehler in Promille, 1000 = kein Fehler.
|
10 | |
11 | #if ((BAUD_ERROR<990) || (BAUD_ERROR>1010))
|
12 | #error Systematischer Fehler der Baudrate grösser 1% und damit zu hoch!
|
13 | #endif
|
14 | |
15 | #include <avr/io.h> |
16 | #include <util/delay.h> |
17 | |
18 | /* UART-Init Bsp. ATmega16 */
|
19 | |
20 | void uart_init(void) |
21 | {
|
22 | UCSRB |= (1<<TXEN); // UART TX einschalten |
23 | UCSRC |= (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0); // Asynchron 8N1 |
24 | |
25 | UBRRH = UBRR_VAL >> 8; |
26 | UBRRL = UBRR_VAL & 0xFF; |
27 | }
|
28 | |
29 | int main (void){ |
30 | |
31 | while (1) { |
32 | while (!(UCSRA & (1<<UDRE))) |
33 | {
|
34 | }
|
35 | |
36 | UDR = 'x'; |
37 | |
38 | while (!(UCSRA & (1<<UDRE))) |
39 | {
|
40 | }
|
41 | |
42 | UDR = '\n'; |
43 | |
44 | _delay_ms(1000); |
45 | |
46 | }
|
47 | |
48 | |
49 | |
50 | }
|
sieht jetzt nicht wirklich komplex aus der code ;-) ich berechne die baudrate immer lieber mit dem da: http://www.gjlay.de/helferlein/avr-uart-rechner.html da weiß ich dann auch, was in den registern steht... _delay_ms() nimmt glaub ich nur 8bit-Werte
Hm, ich hab jetzt beides geändert: 129 and UBRR und das Delay auf 255 ms runtergeschraubt. Trotzdem sehe ich nichts. Ich werde mal mit einem Oszilloskop schaueb, ob der AVR etwas an den Pins macht.
Ok, habe was empfangen. Ich hab die Beispiele aus dem Datenblatt 1:1 abgetippt und es kommt was an, einen richtigen Unterschied zum Tutorial konnte ich aber noch nicht feststellen. Naja, jetzt erfreu ich mich erstmal an den Zeichen die da über den Schirm flackern.
In deinem Code definierst du F_CPU mit 20 MHz redest oben aber von internen 8 MHz. Auch wenn das hier keine Auswirkungen hat, sollte man sowas immer beachten und vor allem glatt ziehen!
Muetze1, ich bin nicht der Originalposter sondern hab mich da nur eingehängt :)
Thread beobachten
Seitenaufteilung abschaltenBitte 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.