Hallo Leute, ich habe versucht die im Tutorial angeführt UART nachzubauen. Mit einzelnen Zeichen klappts super, jedoch mit den strings leider nicht so. Bei der Ausgabe sieht man jedoch nur ein komplett zerhacktes Array. Die ersten beiden Zeichen und die beiden letzen kann ich ausgeben (mehr steht auch nicht im Array. ich fürchte es handelt sich dabei um ein zeitliches Problem. Ich schreibe und lese gleichzeitig das UDR1 Register aus. Ich denke hier liegt das Problem. Ist es überhaupt möglich gleichzeitig senden und empfangen mit "größeren" Datenmengen? Ich schicke mittels UART von meinem uC eine Nachricht(TX) an meinen (den selben) uC(RX) und gebe diese dann mittels Array aus. Habt ihr einen Plan wie ich das realisieren könnte? MfG Elias
Womit erzeugst Du den Takt? Der interne RC-Oszillator ist nicht ausreichend genau, um für UART-Anwendungen verwendet zu werden, da brauchst Du einen stabilisierten Takt, sei es mit Quarz, Keramikresonator oder externem Quarzoszillator.
Ich sehe zwei freigeschaltete Interrupts für die kein Interruptroutine existiert. Folge uC reset.
in der main CPU_PRESCALE(CPU_8MHz); bestimme ich die clock. Was ist denn daran ungenau? MfG Elias
holger schrieb: > Ich sehe zwei freigeschaltete Interrupts für > die kein Interruptroutine existiert. Folge uC reset. OCIE0A erlaubt den comapre match, welcher unten in einer ISR aufgerufen wird TOIE0 erlaubt nur den überlauf des Timer0 Registers MfG Elias
>TOIE0 erlaubt nur den überlauf des Timer0 Registers
Der läuft auch ohne Erlaubnis über;)
Der zweite ist RXCIE1.
Für beide fehlt eine Interruptroutine,
oder gib diese beiden Interrupts nicht frei wenn
du sie nicht benötigst.
Elias 1234 schrieb: > in der main > CPU_PRESCALE(CPU_8MHz); > bestimme ich die clock. Was ist denn daran ungenau? Da legst Du fest, daß das 8 MHz sein sollen. Wo kommen die her? Was ist die Taktquelle? Wie sind die sogenannten "Fuses" gesetzt? http://eleccelerator.com/fusecalc/fusecalc.php?chip=at90usb1286
Rufus Τ. Firefly schrieb: > Elias 1234 schrieb: >> in der main >> CPU_PRESCALE(CPU_8MHz); >> bestimme ich die clock. Was ist denn daran ungenau? > > Da legst Du fest, daß das 8 MHz sein sollen. Wo kommen die her? Was ist > die Taktquelle? > > Wie sind die sogenannten "Fuses" gesetzt? > > http://eleccelerator.com/fusecalc/fusecalc.php?chip=at90usb1286 Ok hiermit habe ich mich noch nicht beschäftigt. Aber ich glaube hier liegt auch nicht das Problem, da ja sonst die single char Übertragung auch nicht funktieren würde, was sie aber tut =/ MfG Elias
Elias 1234 schrieb: > Aber ich glaube hier > liegt auch nicht das Problem, da ja sonst die single char Übertragung > auch nicht funktieren würde, was sie aber tut =/ Doch, das kann schon miteinander zu tun haben. Probier mal aus, kleine Pausen zwischen den übertragenen Zeichen zu lassen. Und sorge dafür, daß Du einen stabilisierten Takt verwendest. Desweiteren solltest Du Dich mal mit dem Thema Baudratenfehler beschäftigen.
Das Thema mit den Pausen hat mich ein wenig experimentieren lassen. Dabei bin ich dahinter gekommen, dass beim senden Blitzartig alle char´s in das register gelegt werden. Das würde erklären warum ich auf der Empfangsseite so einen schmarn empfange. Ich werd mal versuchen die Sende Seite alle 10us(oder träger) mit einem char zu füttern. Den stabilen Takt mache ich danach. Wenn ich das richtig verstanden habe, muss ich dazu nur den Chip auslesen und dann richtig konfig.Sprich die Fuses richtig einstellen. MfG Elias
Elias 1234 schrieb: > Dabei bin ich dahinter gekommen, dass beim senden Blitzartig alle char´s > in das register gelegt werden. Das würde bedeuten, daß Deine Zeichensenderoutine nicht korrekt funktioniert; genauer, daß diese Schleife hier
1 | while (!(UCSR1A & (1<<UDRE1))) |
2 | {
|
3 | }
|
nicht das tut, was sie soll, nämlich warten, bis die USART zum Senden bereit ist. Das klingt merkwürdig. Ist das wirklich genau der von Dir verwendete Code?
Elias 1234 schrieb: > Ich werd mal versuchen die Sende Seite alle 10us(oder träger) mit einem > char zu füttern. Solange du die nicht implementierten Interrupts immer noch frei gegeben hast, brauchst du erst mal überhaupt nichts anderes "probieren". Die sind dein erstes 'Problem'. Entweder du implementierst sie oder du gibst die INterrupts nicht frei. So einfach ist das. Machst du weder das eine noch das andere, dann wird jeder auftretende Interrupt (und die treten auf) mit einem Prozessor-Reset 'bestraft'.
Elias 1234 schrieb: > Den stabilen Takt mache ich danach. Wenn ich das richtig verstanden > habe, muss ich dazu nur den Chip auslesen und dann richtig konfig.Sprich > die Fuses richtig einstellen. Nein, die Internen 8Mhz sind viel zu ungenau und stark Temperaturabhänig, trotz kalibrierungsbyte. Du brauchst für beide µC eine stabile externe Taktquelle. Das kann z.B ein Quarz sein. Für UART 9600 Baud bietet sich ein 9,8304Mhz Quarz an. Zusätzlich brauchst du passende Keramik Kondensatoren, in diesem Fall tun es 22pf. Erst wenn das angeschlossen ist, werden die Fuses auf External Crystal umgestellt. http://www.mikrocontroller.net/articles/Quarze_und_AVR
DrWright schrieb: > Elias 1234 schrieb: >> Den stabilen Takt mache ich danach. Wenn ich das richtig verstanden >> habe, muss ich dazu nur den Chip auslesen und dann richtig konfig.Sprich >> die Fuses richtig einstellen. > > Nein, die Internen 8Mhz sind viel zu ungenau und stark > Temperaturabhänig, trotz kalibrierungsbyte. > > Du brauchst für beide µC eine stabile externe Taktquelle. Das kann z.B > ein Quarz sein. Für UART 9600 Baud bietet sich ein 9,8304Mhz Quarz an. > Zusätzlich brauchst du passende Keramik Kondensatoren, in diesem Fall > tun es 22pf. Erst wenn das angeschlossen ist, werden die Fuses auf > External Crystal umgestellt. > > http://www.mikrocontroller.net/articles/Quarze_und_AVR Ok ich verstehe, jedoch handelt es sich um einen Irrtum das ich 2 uC habe. Ich möchte ja nur eine Übertragung mit einem uC realisieren. Das beudeutet für mich, ich habe immer den selben Takt für Eingang u. Ausgang (sprich immer die selbe BAUD). Ein kleines Problem dabei ist das ich das selbe Register für das senden u. Empfangen verwende =/ URD1 -> hier wandern die Daten zuerst hinein. Danach wird das senden wieder freigeben mittels Flag, und dann nach kommt das empfangen. Witzig dabei ist das ich nur ein kabel zwischen Rx u. Tx gelegt habe. Hin und wieder gibt er mir sogar die char am Bildschirm aus obwohl keine Verbindung zwischen den Port´s ist. Ich denke das liegt einfach am URD1 Register.
Karl Heinz schrieb: > Elias 1234 schrieb: > >> Ich werd mal versuchen die Sende Seite alle 10us(oder träger) mit einem >> char zu füttern. > > Solange du die nicht implementierten Interrupts immer noch frei gegeben > hast, brauchst du erst mal überhaupt nichts anderes "probieren". > > Die sind dein erstes 'Problem'. Entweder du implementierst sie oder du > gibst die INterrupts nicht frei. So einfach ist das. Machst du weder das > eine noch das andere, dann wird jeder auftretende Interrupt (und die > treten auf) mit einem Prozessor-Reset 'bestraft'. Ok, wenn ich das richtig vertsanden habe crasht mein uC jedes mal wenn ich einen Interrupt implementiere und die zugehörige ISR dazu nicht aufrufe + zusätzlich freigabe der Interrupts mittel sei(); Das bedeutet das ich nur 2 Interrupts eingestellt habe. TIMSK0 |= (1<<OCIE0A | 1<<TOIE0); und nur den Compare verwende. sollte ich es beser so schreiben : TIMSK0 |= (1<<OCIE0A | 0<<TOIE0); Oder liege ich total daneben? MfG Elias
Elias 1234 schrieb: > Ok ich verstehe, jedoch handelt es sich um einen Irrtum das ich 2 uC > habe. Ich möchte ja nur eine Übertragung mit einem uC realisieren. Und ... wohin überträgt Dein µC? Der führt ja keine Selbstgespräche, sondern redet mit einem PC, der aber wiederum eine eigene (und in diesem Fall quarzstabilisierte) Taktquelle verwendet. Hast Du denn mittlerweile mal versucht, Dich an die Dir gegebenen Ratschläge zu halten, oder ist das hier ein Wettbewerb im Fragen, aber Antworten ignorieren? > Ein kleines Problem dabei ist das ich das selbe Register für das senden > u. Empfangen verwende =/ Das ist kein Problem, so ist die UART-Hardware halt aufgebaut. > crasht mein uC jedes mal wenn > ich einen Interrupt implementiere Würdest Du Interrupts implementieren, hättest Du ja entsprechende Interrupthandler geschrieben. Da Du das aber nicht getan hast, darfst Du die Interrupts nicht einschalten. Hast Du Dich schon mal damit beschäftigt, was ein Interrupt ist, und was ein Interrupthandler (ISR) macht?
Es reicht wenn du den Overflowflag einfach weglässt.
TIMSK0 |= (1<<OCIE0A);
Ausserdem hast du den UART Empfangsinterrupt gesetzt, den du auch nicht
abfragst, dort hängt sich der µC auch auf.
>>>UCSR1B |= (1<<TXEN1 | 1<<RXEN1 | 1<<RXCIE1); //schalte Übertragung ein<<<<
Zu den Quarz... auch wenn du nur 1 µC Verwendest brauchst du eine
"stabile" Taktquelle, weil das UART Signal kein Sync mitschickt. Die
Geschwindigkeit die du aus der Baudrate berechnest ist abhänig vom CPU
Takt.
DrWright schrieb: > auch wenn du nur 1 µC Verwendest brauchst du eine > "stabile" Taktquelle, weil das UART Signal kein Sync mitschickt. nö, wenn er nur mit sich selber redet brauchts keinen Quarz, da geht der interne Oszillator mit Sicherheit, ist natürlich etwas sinnfrei, aber so ist nun Mal sein Testaufbau
Walter schrieb: > nö, wenn er nur mit sich selber redet Das tut er aber nicht, da ist schließlich ein GPS-Modul angeschlossen, das die Strings liefert, die zu empfangen er versucht.
Rufus Τ. Firefly schrieb: > Walter schrieb: >> nö, wenn er nur mit sich selber redet > > Das tut er aber nicht, da ist schließlich ein GPS-Modul angeschlossen, > das die Strings liefert, die zu empfangen er versucht. ich habe das hier gelesen: Elias 1234 schrieb: > Ich schicke mittels UART von meinem uC eine Nachricht(TX) an meinen (den > selben) uC(RX) und das Wort GPS kommt im ganzen Thread nur in deinem Beitrag vor??
Walter schrieb: > und das Wort GPS kommt im ganzen Thread nur in deinem Beitrag vor?? Da habe ich wohl zwei Threads durcheinandergebracht. Daß er aber mit seinem µC keine Selbstgespräche führen wird, davon ist auszugehen. Denn irgendwo erfolgt schließlich "die Ausgabe": Elias 1234 schrieb: > Bei der Ausgabe sieht man jedoch nur ein komplett zerhacktes Array.
klingt jetzt blöd aber ich kommuniziere tatsächlich mit ein und dem selben Controller. was per infra rot mittlerweile ganz gut funktioniert.
Elias 1234 schrieb: > klingt jetzt blöd aber ich kommuniziere tatsächlich mit ein und dem > selben Controller. Dein Controller redet mit sich selbst? Und wozu soll das gut sein? Kommunikation bedeutet im allgemeinsprachlichen Gebrauch, daß zwei Seiten beteiligt sind. Selbstgespräche sind keine Kommunikation.
Rufus Τ. Firefly schrieb: > Walter schrieb: >> und das Wort GPS kommt im ganzen Thread nur in deinem Beitrag vor?? > > Da habe ich wohl zwei Threads durcheinandergebracht. > > Daß er aber mit seinem µC keine Selbstgespräche führen wird, davon ist > auszugehen. Rufus Τ. Firefly schrieb: > Elias 1234 schrieb: >> klingt jetzt blöd aber ich kommuniziere tatsächlich mit ein und dem >> selben Controller. > > Dein Controller redet mit sich selbst? > > Und wozu soll das gut sein? > > Kommunikation bedeutet im allgemeinsprachlichen Gebrauch, daß zwei > Seiten beteiligt sind. Selbstgespräche sind keine Kommunikation. Ich muss sagen, dass ist der unterhaltsamste Thread, den ich seit langem gelesen habe. Bitte mehr!
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.