U(S)ART zwischen Atmega644PA und Atmega168

OP #4905692
Ich versuche momentan einen Atmega644PA und einen Atmega168 per UART zu 
verbinden.

beim Atmega168 soll, wenn Daten vom Atmega644PA gesendet werden ein 
Interrupt ausgelöst werden. Es soll dann etwas gemacht werden und direkt 
danach eine Antwort gesendet werden.

Da ich noch ein Anfänger bin habe ich mir zuerst diese beiden Programme 
geschrieben.

Code vom Atmega168 und 644 sind im Anhang


Es soll vom Atmega168 zum 644PA etwas gesendet werden. Darauf soll der 
644PA Antworten und auf diese Antwort(über den Interrupt) soll wieder 
geantwortet werden.

Der Code den ich beigefügt habe ist nicht komplett. Ich habe das zeug 
was nichts mit dem USART zu tun hat weggelassen (übersicht). Display und 
ein RFID Lesegerät (beide über SPI angeschlossen. zusätzlich zu den SPI 
Pins werden PB1,PB0, PC5 und PD7 verwendet(2x SS, D/C (data/command) und 
Reset ).

Ich gebe das Empfangene beim Atmega644PA über das Display aus. 
Theoretisch, denn sehen tue ich nichts. Ich habe  also unter dem 
USART_Recieve() vom 644PA eine Ausgabe auf den Bildschirm eingefügt . Da 
diese ebenfalls nicht zu sehen ist wird der MCU in der While-Schleife 
Feststecken, sprich es kommen keine Daten an bzw. es werden keine 
gesendet.

Angeschlossen habe ich es so:
644PA         168
PD0(TXD0) --> PD1(RXD)
PD1(RXD0) --> PD0(TXD)

Unter dem Oszi habe ich auf RXD und TXD durchgehend HIGH.
An was könnte das liegen?

Hoffentlich habe ich nichts einfaches übersehen...
Ich freue mich schon auf eure Antworten
Sebastian
Angehängte Dateien:
OP #4905729
Matthias S. schrieb:
> Sebastian E. schrieb:
>> 644.c
>
> 'Undefined reference to 'USART_Recieve()'?
>
> So wird das nichts. Poste Code, der kompiliert und den Fehler zeigt.
>> 168.c
>
1
> sei();
2
>
> vergessen. Es ist übrigens eine ganz schlechte Idee, ein _delay_ms(1000)
> in eine ISR zu schreiben. Damit blockierst du wirklich alles.

Hier sind beide Projekte. Das delay mache ich noch weg.

Matthias S. schrieb:
> Allerdings ist mir noch aufgefallen, das du auf dem 168er den Sende IRQ
> freigibst, ohne eine ISR dafür zu haben.

Ich lösche das Bit für den Interrupt und probiere es noch einmal.
Angehängte Dateien:
(Firma: matzetronics) #4905737
Oh nee, die ZIPs öffne ich jetzt nicht. Mach dir doch einfach mal eine 
Routine, bei der du einen MC gegen den PC antreten lässt - z.B. mit 
USB-> UART adapter und HTerm.
Dann machst du das auf dem anderen auch. Dann kannst du ohne Blindflug 
auch gleich den Interpreter testen, der auf die seriellen Kommandos 
antworten soll.
OP #4905743
Matthias S. schrieb:
> Oh nee, die ZIPs öffne ich jetzt nicht. Mach dir doch einfach mal eine
> Routine, bei der du einen MC gegen den PC antreten lässt - z.B. mit
> USB-> UART adapter und HTerm.
> Dann machst du das auf dem anderen auch. Dann kannst du ohne Blindflug
> auch gleich den Interpreter testen, der auf die seriellen Kommandos
> antworten soll.


Wenn ich im Besitz eines UART - USB oder UART - RS232 Adapters währe 
könnte ich es natürlich machen

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 9 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.