Uart Fehler

[Sp666dy]

N'abend,

also weil ich es noch nie brauchte habe mich noch nie mit Uart beschäftigt, da es aber jetzt mal dran ist, bin ich seit zwei Tagen
am Probieren und es klappt irgendwie nicht.

Ich hab das Beispiel von Rn-wissen genommen.

Leider kommen nur Zeichen an.

Ich habe TX/RX mal kurzgeschlossen und wenn ich über ein terminal was raus gebe kommt auch das richtige an.

Hab ich was übersehen?

Benutze den Rn-Control(Atmega32)


#include <avr/io.h>

#define F_CPU 16000000L
#define USART_BAUD_RATE 9600
#define USART_BAUD_SELECT (F_CPU/(USART_BAUD_RATE*16L)-1)


//-----------------------------------------------------
void _writeString (const char *string)
{
while (*string)
{
while (!(UCSRA & (1<<UDRE)))
{}


UDR = *string++;
}
}


//-----------------------------------------------------
void main()
{
UCSRB = (1<<TXEN);
UCSRC = (1<<URSEL)|(1 << UPM1)|(1 << UCSZ1)|(1 << UCSZ0);
// UCSRC = (1<<URSEL) | (1<<UCSZ1) | (1<<UCSZ0);
UBRRL = (unsigned char) USART_BAUD_SELECT;


_writeString ("Hallo, Welt!\n");


// Endlossschleife nach Verlassen von main
}

[PicNick]

uint16_t ubrr = (uint16_t) ((uint32_t) F_CPU/(16*BAUDRATE) - 1);


gib mach das ganze casting dazu, auch wenn's bescheuert aussieht.

[Sp666dy]

Ne hat leider auch nicht geklappt, es kommt jedes Zeichen an, nur nicht das was ankommen soll... So ein kurzer Code, was kann man denn da übersehen haben.

hab den auf extern 16.000 64 ms gestellt, und noch die Optimierung auf das unterste.

Gruß David

[PicNick]

Du setzt UPM1 (Parity even enabled)
Weiss das Terminal auch was davon ?
Probier mal ohne

[Sp666dy]

Ja hatte schon einmal mit und einmal ohne ausprobiert...

[PicNick]

Hartnäckig.
Also stelle das Terminal auf 8-Bit 1 Stop no parity, no handshake, 9600 Baud
Das UPM1 lass also aus.

Setze mal UBRR Wert "zu Fuß" (9600 bei 16 MHZ) #define USART_BAUD_SELECT 0x67
Check nochmal die Fuses wegen der Clock=16 MHZ
Statt "Hallo, Weilt" schicke "AAAAAAAA" ( 8 mal "A")
sag dann, welche Art Schmierzeichen zu kriegst und ob es 8 sind oder mehr oder weniger

[Sp666dy]

Also es kommt Dezimal="01011111" und als zeichen 8 mal = "_"

Hoffe man kann damit was anfangen

[Bumbum]

Hallo,

sowas hatte ich auch schon mal. Benutzt du einen Quarz? Ohne habe ich nie eine stabile UART-Kommunikation hinbekommen. Das Ergebnis so so ähnlich aus wie bei dir.

Es könnte auch an deiner Verkabelung liegen. A = 65dez = 01000001bin. Bei dir scheints genau invertiert anzukommen. (Ich habe jetzt nicht genau die Start-/Stop-Bits im Kopf, sieht aber tatsächlich komplett invertiert sein)

Viele Grüße
Andreas

[Sp666dy]

also ich benutze es im Moment zur Probe Rn-control. (16MHz) Verkabelung kann man nicht ändern, weil ein port ist ja zum senden ein zu empfangen, senden tut der Mic ja, der dritte ist ja masse, also sollte die Verkabelung falsch sein, würde er ja nichts senden. Wie ich das inventwierte weg bekomme, weis ich aber nicht, der Code ist ja so wie er bei RN-wissen steht.

Das einzige was ich mir vorstellen kann, wäre das RX/TX an Port C ist, weil die led gehen auch bei "00" an und bei "ff" aus.

Gruß David

[Bumbum]

Ich kenne das RN-Control leider nicht. Mit dem Pinning hast du recht. Die Verbindungen selbst hast du richtig gemacht.
Aber ein Inverter ist ja schnell gebaut und getestet. Zwei Widerstände und ein NPN-Transistor und fertig.

z.B. über 1kOhm des Ausgangs des RN-Controls an die Basis des Transistor (z.B. BC547). Emitter auf Masse, Collector an den Eingang deines PC und an einen Pull-Up-Widerstand. (kann auch 1kOhm sein)

[PICture]

Hallo!

@ Sp666dy

... ungefähr so:

VCC
+
|
.-.
| | Rc
| | ~1k
'-'
|
+-----> Aus (zum PC)
Rb ~1k |
___ |/
Ein >-----|___|--| T
|>
|
===
GND

(created by AACircuit v1.28.6 beta 04/19/05 www.tech-chat.de)

[Sp666dy]

Ich benutze aber das Rs232 Modul (http://www.shop.robotikhardware.de/shop/catalog/product_info.php?products_id=250)

Setze ich das dann zwischen Rx vom Rn-control zum Modul?

Aber inventiert kann es nicht sein, denn dann wären die einsen und Nullen ja Inventiert, oder?

[Bumbum]

Danke PICture, genau so habe ich es gemeint.

@Sp666dy: Genau. Zwischen RN-Control und dem seriellen Eingang deines Moduls. Und bei dir sind die Einsen und Nullen invertiert! Das habe ich dir doch in meinem letzten Beitrag erklärt. Es ist nur nicht 1:1 das Byte invertiert, weil durch die Start- und Stop-Bits auch noch etwas daneben geht.

Probiers einfach aus, und dann sehen wir weiter.

Viele Grüße
Andreas

[Sp666dy]

Nach mehreren Versuche kann ich nun sagen das der Rn-control bisssschen kompliziert ist.

Als erstes habe ich im Datenblatt nachgeguckt und gesehen das rx an PD0 ist, so habe ich die Inventierte Schaltung
zusammen gelötet und an PD0 gelegt.

Ergebnis "________" also genau das gleiche.

Dann bin ich von ausgegangen das an PD0 noch nichts vorher inventiert ist und hab die Schaltung an den extra angefertigten RX-Pin angeschlossen und es kam raus "AAAAAAAA"

Also Fazit:

Beim Rn-Control ist PD0 ganz normal RX und am PIN RX ist das Signal inventiert.

Ich bedanke mich an alle für eure mühe, denn ich hätte nie gesehn das es inventiert wäre, weil die 1 und 0 nicht genau umgekehrt waren.

Gruß David

[Klebwax]

Nach mehreren Versuche kann ich nun sagen das der Rn-control bisssschen kompliziert ist.
.
.
.
Beim Rn-Control ist PD0 ganz normal RX und am PIN RX ist das Signal inventiert.


Das kann ich so nicht sehen. RS232 Treiber (wie z.B. MAX232) invertieren immer das Signal. Bei einem HW-UART ist das schon im Chip berücksichtigt. Das Rn-control macht es also vernünftigerweise genauso wie alle anderen auch.

MfG Klebwax

[Bumbum]

Zustimmung! Im Endeffekt liegt es daran, welche Komponenten man "verheiratet". So wie ich das sehe ist das RN-Control da sogar flexibel, weil man entweder an den AVR-Pin direkt kann, oder an den invertierten.
Man muss als Entwickler schon mal kurz in die Datenblätter schauen, ob die Pegel und die Logik-Pegel zueinander passen, und nicht einfach blind zusammenstecken. ;-)

Viele Grüße
Andreas