Forum: Mikrocontroller und Digitale Elektronik U(S)ART zwischen Atmega644PA und Atmega168


von Sebastian E. (lasometer01)


Angehängte Dateien:

Lesenswert?

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

: Bearbeitet durch User
von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

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();
vergessen. Es ist übrigens eine ganz schlechte Idee, ein _delay_ms(1000) 
in eine ISR zu schreiben. Damit blockierst du wirklich alles.

: Bearbeitet durch User
von WR (Gast)


Lesenswert?

Hallo,

wenn Du die zwei Rechner so verbindest funktionierts:

644P                   168
PD0  verbinden mit     PD1
PD1  verbinden mit     PD0

Gruss Werner

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

WR schrieb:
> 644P                   168
> PD0  verbinden mit     PD1
> PD1  verbinden mit     PD0

Hat er doch:

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

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

von Sebastian E. (lasometer01)


Angehängte Dateien:

Lesenswert?

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.

: Bearbeitet durch User
von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

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.

von Sebastian E. (lasometer01)


Lesenswert?

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

von Dietrich L. (dietrichl)


Lesenswert?

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

Nur zu Vollständigkeit: die GNDs hast Du auch verbunden?

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

Sebastian E. schrieb:
> Wenn ich im Besitz eines UART - USB oder UART - RS232 Adapters währe
> könnte ich es natürlich machen

Son Dings gibts bei jedem PC Schrotter für unter 10 Euro.

von Sebastian E. (lasometer01)


Lesenswert?

Dietrich L. schrieb:
> Sebastian E. schrieb:
>> Angeschlossen habe ich es so:
>> 644PA         168
>> PD0(TXD0) --> PD1(RXD)
>> PD1(RXD0) --> PD0(TXD)
>
> Nur zu Vollständigkeit: die GNDs hast Du auch verbunden?

Ja

von Sebastian E. (lasometer01)


Lesenswert?

Matthias S. schrieb:
> Sebastian E. schrieb:
>> Wenn ich im Besitz eines UART - USB oder UART - RS232 Adapters währe
>> könnte ich es natürlich machen
>
> Son Dings gibts bei jedem PC Schrotter für unter 10 Euro.

ich bau mir schnell selbst einen. Max232 und 1µF Kondensatoren hab ich 
noch irgendwo.
Am Montag kauf ich gleich einen UART-USB Adapter

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
Noch kein Account? Hier anmelden.