atmega 8 RS232

OP #831381
Lesenswert?

Ich habe da ein Board mit einem AT mega 8 Controller. Bei der 
Initialisierung ist mir aufgefallen, dass wenn ich die RS232 
schnittstelle initialisere, der PORTD PIN PD1 immer auf high ist. Wenn 
ich versuche im Programm den PORT zu überschreiben ist das nicht 
möglich. Wird also die normale Funktionalität als I/O pPIN bei der 
Initialisierung  der RS232 überschrieben? Ist das normal, dass der pin 
immer auf high ist??


so initialisiere ich die serielle schnittstelle
1
void USART_Init( unsigned int ubrr)
2
{
3
// Set baud rate 
4
UBRRH = (unsigned char)(ubrr>>8);
5
UBRRL = (unsigned char)ubrr;
6
// Enable receiver and transmitter 
7
UCSRB = (1<<RXEN)|(1<<TXEN);
8
// Set frame format: 8data, 2stop bit 
9
UCSRC = (1<<URSEL)|(1<<USBS)|(3<<UCSZ0);
10
}


danke und lg sebastian
#831389
Lesenswert?

Sebastian Sw wrote:
> Bei der
> Initialisierung ist mir aufgefallen, dass wenn ich die RS232
> schnittstelle initialisere, der PORTD PIN PD1 immer auf high ist. Wenn
> ich versuche im Programm den PORT zu überschreiben ist das nicht
> möglich. Wird also die normale Funktionalität als I/O pPIN bei der
> Initialisierung  der RS232 überschrieben?
So ist es. Wenn Empfänger und/oder Sender des UART (hat mit RS232 
zunächst nix zu tun!) aktiviert werden (durch setzen von TXEN bzw. RXEN) 
wird die normale Pin-Funktionalität abgeschaltet.

> Ist das normal, dass der pin
> immer auf high ist??
Ja. Das ist der Ruhezustand.
Gast #831392
Lesenswert?

>Wird also die normale Funktionalität als I/O pPIN bei der
>Initialisierung  der RS232 überschrieben?

Ja.  Sobald Du das TXEN-Bit setzt passiert genau das.  Steht aber auch 
im Datenblatt unter "Alternate Port Functions", ca. Seite 54.

>Ist das normal, dass der pin immer auf high ist??

Na, was erwartest Du? "H" ist doch der "Idle"-Pegel einer seriellen 
Verbindung.
Gast #831472
Lesenswert?

>"Nö, der RX ist erstmal einfach ein Eingang."

>Ist das der grund, wieoso ich den über die PORT operationen beschreiben
>kann?

Die PORT/DDR/PIN-Register kannst Du natürlich zu jeder Zeit sowohl 
auslesen und beschreiben.  Wenn der UART-Receiver eingeschaltet ist (Bit 
RXEN gesetzt), hätte das allerdings keine Auswirkung auf den 
entsprechenden Pin, weil der dann eben von diesen Registern abgetrennt 
und zum UART-Receiver "geroutet" ist.
Gast #831481
Lesenswert?

>Der receive port ist auf low- hab ich gerade rausgefunden

Ein Eingangspin ist auf jeden Fall relativ hochohmig.  Wenn ein Pullup- 
oder Pulldown-Widerstand vorhanden ist, bestimmt er den Pegel, solange 
sonst nichts angeschlossen ist.  Ist sonst etwas (relativ niederohmiges) 
angeschlossen, legt dies den Pegel fest.  Eventuell misst Du nur deshalb 
L, weil Du gegen GND misst.
OP #831485
Lesenswert?

aha.. danke für deine antwort. d.h wenn der transmitter aktiviert ist 
und ich versuche den pin zu beschreiben, wird das einfach nicht wirksam?
für den receiver scheint es aber trotzdem so zu sein, dass ich den pin 
bescheiben kann. ich möchte nur sicher sein, dass dies nicht für den 
transmitter gilt( ich verwende nur de transmitter)

lg
OP #831506
Lesenswert?

Also ich möchte einfach ein zeichen von einem Controller zum anderen 
Controller schicken und dann je nach Zeichen die I/O pins auf high bzw. 
auf low schalten. Es findet also nur Kommunikation in eine Richtung 
statt.
Das Problem war nur dass am PORT D, ein display hängt, welches ausgaben 
tätigt und alle PINS vom PORT benutzt, ausser die ersten beiden, welche 
für die serielle schnittstelle benutzt werden. Ich habe einfach angst, 
dass mir die displayroutinen (das display hängt am controller, der 
wegschickt) die ports überschreiben, wobei diese Angst eh unbegründet 
ist, wenn immer nur weggeschickt wird. Sehe ich das richtig so? Für den 
Controlle, der empfängt habe ich das problem nicht, weil ich da nur 
gewisse ports verwende und da kein display dranhängt.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren