Hi ich hab eine Frage. wenn ich eine serielle Schnittstelle zwischen 2 Atmega 644 realisieren will, muss ich irgend etwas besonderes beachten? weil wenn ich die daten von einen µC zum PC und vom PC dann zum 2ten µC schicke funktioniert es, wenn ich es direkt mache nicht. hoffe ihr könnt helfen
Code? -TXE/RXE über Kreuz angeschlossen? -UART/USART richtig initialisiert?
RX->TX TX->RX GND->GND und gleiche Betriebsspannung sollte genügen. Je nachdem wie deine Daten aussehen und welches Terminalprogramm du am PC nutzt wäre es denkbar, dass der PC noch \n\r oder ähnliches mitschickt. Andere Fehlerquelle wäre Baudrate/Taktquelle & Baudratenfehler. Könnte sein, dass der PC da Fehlertoleranter ist.
Im Anhang ist der Code rx und tx ist ausgekreuz aja und die baudrate ist 921600 BAUD
muss man bei der leitung zwischen den 2 avrs was beachtet ausser das sie ausgekreuzt sein muss?
Hi Wo ist in 'empfangen.c' die UART-Initialisierung? MfG Spess
ah das war in anderem file. da ist die initialisierung
Alex Glaser schrieb: > muss man bei der leitung zwischen den 2 avrs was beachtet ausser das sie > ausgekreuzt sein muss? An sich nicht. Du hast doch an beiden AVR einen Quarz drann, oder nicht? Für erste Tests würde ich auch abspecken. Den ganzen SD Krempel raus. AVR1 schickt an AVR2 ständig ein 'x' und der gibt das irgendwo aus. Dann kann man auch kontrollieren und den PC an die Sendeleitung zusätzlich drannhängen und kontrollieren ob da tatsächlich was gesendet wird. Dito in die umgekehrte Richtung.
ja habe bei beiden avrs einen quarz mit 14,7456MHz, ist aber bei beiden programmen auch so definiert ja das hab ich heut schon gemacht im jetzt will ich nur noch von einem µC zum anderen senden und der soll das dann wieder ausgeben der erste µC schickt es richtig. es scheitert am empfangen
Alex Glaser schrieb: > der erste µC schickt es richtig. es scheitert am empfangen Na dann. Gegentest: Sende AVR weg, PC ran und in die Tasten klimpern.
Bei deiner Sendroutine fällt mir auf, dass du nie ein '\n' auf die Reise schickst, der Empfänger aber darauf wartet.
habe jetzt ein \n angehängt und es geht immer noch nicht wenn ich einen string vom pc zum µC sende geht es, das dieser den string ausgibt. also weis ich nicht was ich noch ändern kann
Du stocherst im Nebel. Schaff dir eine Möglichkeit, wie und wo der Empfänger ausgeben kann was er empfängt. Auf gut Glück irgendwelche Modifikationen anzubringen ohne dem Programm bei der Arbeit zusehen zu können, bringt einen selten weiter. Fakten müssen her. Fakten wie beispielsweise: Was empfängt der Empfänger wirklich? Falls du schon eine Ausgabemöglichkeit hast, würde ich als allererstes hier
1 | uint16_t uart_getc(void) |
2 | {
|
3 | while (!(UCSRA & (1<<RXC))) // warten bis Zeichen verfuegbar |
4 | ;
|
5 | return UDR; // Zeichen aus UDR an Aufrufer zurueckgeben |
6 | }
|
das Zeichen ausgeben, welches empfangen wurde.
ich kann mit einen seriell to usb wandler schaun was der erste avr sendet
Falls du schon eine Ausgabemöglichkeit hast, würde ich als allererstes hier
1 | uint16_t uart_getc(void) |
2 | {
|
3 | while (!(UCSRA & (1<<RXC))) // warten bis Zeichen verfuegbar |
4 | ;
|
5 | return UDR; // Zeichen aus UDR an Aufrufer zurueckgeben |
6 | }
|
das Zeichen ausgeben, welches empfangen wurde. Den \n noch irgendwie speziell markieren, so dass du ihn siehst.
Alex Glaser schrieb: > ich kann mit einen seriell to usb wandler schaun was der erste avr > sendet Nicht was der erste sendet. Was der zweite empfängt! Der zweite muss ausgeben, was er so reinkriegt. Was der erste sendet hast du ja mitlerweile zur Genüge verifiziert.
ich bekomme immer nur ein \0 und sonst nichts. ausser wenn ich es vom pc aus sende dann bekomme ich den richtigen string
Wie sieht der Empfangscode jetzt aus? Du hast berücksichtigt, dass du aus UDR nur einmal lesen darfst?
1 | uint16_t NextChar; |
2 | uint16_t StringLen =0 ; |
3 | |
4 | NextChar = uart_getc(); |
5 | |
6 | |
7 | while( 1) { |
8 | *Buffer++ = NextChar; |
9 | uputc(NextChar); |
10 | StringLen++; |
11 | NextChar = uart_getc(); |
12 | |
13 | }
|
Warum uart_getc() einen uint16_t liefert bzw. nextChar ein uint16_t sein muss, ist mir zwar nicht ganz klar, aber es sollte eigentlich keinen Unterschied machen. Hmm ....
und uart_getc schaut aus wie du es mir geschrieben hast
Alex Glaser schrieb:
> und uart_getc schaut aus wie du es mir geschrieben hast
Ist schon ok.
Ich hatte den Verdacht, du hättest so etwas gemacht
1 | uint16_t uart_getc(void) |
2 | {
|
3 | while (!(UCSRA & (1<<RXC))) // warten bis Zeichen verfuegbar |
4 | ;
|
5 | uputc( UDR ); |
6 | return UDR; // Zeichen aus UDR an Aufrufer zurueckgeben |
7 | }
|
Wenns vom PC aus funktioniert und vom AVR aus nicht, andererseits der erste AVR an den PC sauber senden kann dann kann ich mr nur noch vorstellen, dass die Baudraten ganz leicht daneben liegen.
was kann man da machen? soll ich es mit einer niedrigeren baudrate probieren?
Versuchs mal mit 9600. Anderseits könntest du noch kontrollieren, ob auch beide µCs mit dem Baudratenquarz laufen. Nicht das bei dem zweiten der interen 8MHz RC-Oszillator rennt. Gruß Rainer
habs mit einer niedrigeren baud rate probiert und geht auch nicht. habs mir dann mal mitn oszi angschaut und wenn ich mich mit dem tastkopf auf gnd und mit dem tastkopf auf die sendeleitung gehalten habe hat es auf einmal funktioniert und wenn ich den tastkopf weggegeben hab, hat es wieder nicht funktioniert. ich befürchte das ich irgendwo einen kontaktfehler habe, oder weist du vllt was da sein könnte?
(Sonst fehlende) Masseverbindung wird über das Oszilloskop hergestellt?
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.