Serielle Schnittstelle - Input Echo

[orcss]

Hallo,

Ich bin grad dabei mit dem Pi die serielle schnittstelle anzusprechen und habe folgendes Problem:
Wenn ich etwas empfange, wird das Zeichen direkt zurück geschickt, was nicht unbedingt optimal ist ;)
hab bisher in Erfahrung gebracht, dass sich das irgendwie per stty einstellen lässt, nach man page studieren und rumprobieren hab ich es allerdings nicht hinbekommen.
Kann mir da jemand weiterhelfen?
Danke schon mal.
Gruß,
Ivo

[Kampi]

Hey,

schau mal hier:

http://kampis-elektroecke.de/?page_id=1682

Vielleicht hilft dir das ja weiter (funktioniert übrigens auch mit einem USB-Seriell Wandler. Der heißt dann nur ttyUSB0 oder so).

[orcss]

Danke für die Antwort,
hab auf deiner Seite schonmal vorbeigeschaut aber nicht die Lösung des Problems gefunden:
vielleicht ein bisschen genauer:
Die Andere Seite der seriellen Schnittstelle schickt zur Bestätigung das geschickte Zeichen wieder zurück und dieses wird dann direkt wieder zurückgeschickt. Also empfängt die andere Seite (ein Roboter) das Zeichen doppelt, was bei toggle befehlen nicht so praktisch ist.

[peterfido]

Da fehlen mir noch ein paar Infos. Worüber wird kommuniziert? USB-Seriell Wandler oder die "integrierte" ttyAMA0? Welche Sprache wird verwendet? C, sh, bash, python? Wie wird die Schnittstelle genau initialisiert?

[Kampi]

Genau.
Poste mal bitte beide Programme/Abläufe zu dem ganzen.
Weil das ist nicht das "normale" Verhalten der UART Schnittstelle vom rPi das es einfach Daten wieder zurück schickt, frei nach dem Motto "Will ich nicht haben" ;)

[orcss]

Hey,
die Geschichte passiert schon bevor ich versuche zu empfangen.
Sobald ttyAMA0 auf die korrekte Baudrate eingestellt ist werden empfangene Zeichen zurückgeschickt.
Hier die Test Datei auf dem Atmega 32, die wenn ich sie starte fröhlich blinkt.


atmega 32




usart initialisierung

UCSRC |= (1<<URSEL)|(1<<UCSZ0)|(1<<UCSZ1); // Asynchron, 8N1
UBRRH=(uint8_t)(UART_BAUD_CALC>>8); // Baudrate wählen
UBRRL=(uint8_t)UART_BAUD_CALC;

UCSRB |= (1 << TXEN); // UART TX (senden) einschalten
UCSRB |= (1 << RXEN); // UART RX (empfangen) einschalten


usart funktionen:

void usart_putc(unsigned char c) // Ein Zeichen senden
{
while(!(UCSRA & (1 << UDRE))); // warte, bis UDR bereit
UDR = c; // sende Zeichen
}


int16_t usart_getc_nowait (void)
{
// Liefert das empfangene Zeichen, falls etwas empfangen wurde; -1 sonst
return (UCSRA & (1 << RXC)) ? (int) UDR : -1;
}




testprogramm:

while(1)
{
empfangen=usart_getc_nowait();
if(empfangen=='B')
{
if (!z_led_links)
{
led_links(gelb);
z_led_links=1;

}
else
{
led_links(aus);
z_led_links=0;
}
}

if(kontroll_zaehler>=50) // Sekunde
{
led_rechts(gruen);
usart_putc ('B');

kontroll_zaehler=0;
}
}

[peterfido]

Da fehlen mir noch ein paar Infos. Worüber wird kommuniziert? USB (http://www.rn-wissen.de/index.php/USB)-Seriell Wandler oder die "integrierte" ttyAMA0? Welche Sprache wird verwendet? C, sh, bash, python? Wie wird die Schnittstelle genau initialisiert?

Ich meinte mehr die Raspberry Seite.

[orcss]

auf Raspberry Seite hab ich per shell nur die baud rate konfiguriert also:
stty -F ttyAMA0 ispeed 9600 ospeed 9600
und dann wird schon jedes geschickte zeichen zurückgeschickt.

[peterfido]

Kopiere mal die Datei nach dem Entpacken auf den Raspi und führe diese mal aus. (Rechte 755, evtl. mit sudo vorneweg)

Diese stellt den Port auf 9600 BAUD ein und schaltet das Echo ab.
Dann gleich Dein Programm testen.

Ist es danach immer noch so, dann liegt das Problem tiefer.

[orcss]

Hat erstmal nichts geändert. :/
hat die datei einfach alle "echo*" einstellungen deaktiviert?
Damit hatte ich nämlich auch schon rumprobiert.
Hier mal die Ausgabe von stty -F ttyAMA0 -a nach ausführens deines Programms.

speed 9600 baud; rows 24; columns 80; line = 0;
intr = <undef>; quit = <undef>; erase = <undef>; kill = <undef>; eof = <undef>;
eol = <undef>; eol2 = <undef>; swtch = <undef>; start = <undef>; stop = <undef>;
susp = <undef>; rprnt = <undef>; werase = <undef>; lnext = <undef>;
flush = <undef>; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

[peterfido]

Der Quellcode ist ein Auszug aus meinen anderen Projekten (http://www.rn-wissen.de/index.php/Raspberry_PI:_Internetradio#Empf.C3.A4nger), wo der Raspbi mit AVRs kommuniziert.

Witzigerweise läuft Dein oben angegebener Befehl (stty -F ttyAMA0 -a) bei meinen beiden Raspbis gar nicht.

Der erste sagt:

stty: ttyAMA0: Inappropriate ioctl for device

Der zweite sagt:

stty: ttyAMA0: No such file or directory

Beide "Systeme" arbeiten aber einwandfrei. Evtl. hast Du noch andere Pakete installiert?

Die Ausgabe von
stty -F /dev/ttyAMA0 -aAuf dem ersten:



root@raspberrypi ~ > stty -F /dev/ttyAMA0 -a
speed 19200 baud; rows 0; columns 0; line = 0;
intr = <undef>; quit = <undef>; erase = <undef>; kill = <undef>; eof = <undef>; eol = <undef>; eol2 = <undef>; swtch = <undef>;
start = <undef>; stop = <undef>; susp = <undef>; rprnt = <undef>; werase = <undef>; lnext = <undef>; flush = <undef>; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke



und auf dem zweiten, welcher von Grund auf neu eingerichtet wurde:


speed 19200 baud; rows 0; columns 0; line = 0;
intr = <undef>; quit = <undef>; erase = <undef>; kill = <undef>; eof = <undef>; eol = <undef>; eol2 = <undef>; swtch = <undef>;
start = <undef>; stop = <undef>; susp = <undef>; rprnt = <undef>; werase = <undef>; lnext = <undef>; flush = <undef>;
min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke


Edit:
Also bis auf die Geschwindigkeit, Zeilen und Spalten identisch.


Edit:
Hast du vielleicht einen Kurschluß oder niederohmige Verbindung zwischen TX und RX?

- - - Aktualisiert - - -

Wie ist die Hardware aufgebaut? Die Pegel sind angepasst? Feine Brücken zwischen TX und RX ausgeschlossen? Auch nicht durch zu niedrigohmige Widerstände miteinander verbunden?
Anbei der von mir genutzte Pegelwandler.

24932

[orcss]

Vielen Dank!

Unser momentan verwendeter Pegelwandler besteht nur aus einem Spannungsteiler:


___ ___
TXD AVR ---|___|---o---|___|----o
1K | 2K |
| |
| |
RXD PI GND

RXD AVR ------------------- TXD PI

GND AVR ------------------- GND PI

Vorher hatten wir den "XBee Explorer Regulated" missbraucht (https://www.sparkfun.com/products/9132).
Das Verhalten ist in beiden Fällen dasselbe.

Gruss
M.

[peterfido]

Vom TX des Pi zum RX des AVR würde ich mindestens einen Längswiderstand einbauen. Einmal den Port des AVR falsch gesetzt und dem Pi wird es warm.
Kommt denn auch ein Echo zurück, wenn statt des AVR ein Terminalprogramm mit dem Pi spricht?


Edit:
Das Echo könnte auch kommen, wenn die Masseverbindung fehlerhaft ist.

[orcss]

Kommt denn auch ein Echo zurück, wenn statt des AVR ein Terminalprogramm mit dem Pi spricht?


Irgendwie versteh ich nicht ganz, was du meinst?
*verwirrt*

[Kampi]

Er möchte wissen ob auch ein Echo zurück kommt wenn du deinen PC an das Pi anschließt (mittels USB/RS232 Wandler. Auf 3,3V Pegel achten!).
Du sendest also per PC was an dein Pi und simulierst damit deinen AVR. Wenn das Zeichen dann wieder im Terminal erscheint, welches du eingegeben hast, ist ein Echo zurück gekommen. Falls du ein Zeichen eintippst und es erscheint nicht im Terminal am Rechner kommt kein Echo zurück und der Fehler liegt am AVR und nicht am Pi.

[orcss]

Es gibt ja drei mögliche Fehlerquellen:
-AVR
-Pegelwandler
-Pi
Einen Fehler beim AVR gibt es nicht, da wir per XBEE und Hyperterminal die Geschichte schon getestet haben und alles einwandfrei funktioniert hat.
Also bringt der Test wohl keine neue Erkenntnis (wir müssten ja den selben Pegelwandler verwenden), oder?

Gruß Ivo und M.

[peterfido]

So ein bißchen Mitarbeit sollte bei der Fehlersuche schon sein. Ich habe die Hardware nicht hier. Meine Raspbis arbeiten mit dem von mir verlinkten und compilierten Quellcode echofrei. Das Problem vermute ich beim Pi oder in der Hardware. Hardware wäre z.B. durch eine Verbindung RX/TX, bzw. GND hochohmig. Dann noch evtl. die Spannungsversorgung.

Den Pegelwandler kannst Du nur zum PC nutzen, wenn danach noch ein TTL/USB Wandler kommt. Schließt Du die Signale eines USB-RS232 Wandlers direkt an den Raspi an, wird dieser leiden oder gar zerstört. Du schreibst vom Xbee. Diesen per Wandler an den Raspi und den gleichen Test wie mit dem AVR durchführen.

Ich selbst nehme für solche Tests den FTDI. Dieser lässt sich mit 3,3V auf der IO Seite betreiben und spart so Pegelwandler. Andererseits kann er auch 5V und so direkt an den AVR.

Eine weitere Fehlerquelle ist die Software auf dem Pi. Läuft da im Hintergrund noch eine Software, welche an der seriellen Schnittstelle lauscht bzw. sendet?

Da fällt mir noch eine Idee ein. Einfach am Raspbi RX mit TX verbinden, ohne weitere Hardware außer einem Logiktester.

Dann einmal was per Echo über /dev/ttyAMA0 absenden.
echo hallo > /dev/ttyAMA0 Wenn jetzt tatsächlich ein Echo vom Raspbi kommen sollte, dann wird der sich ständig immer wieder das selbe senden und der Logiktester sollte mitblinken. Für den Test empfehle ich eine langsame Baudrate, um das Blinken besser zu erkennen.

Ist kein Logiktester zur Hand, kann der AVR dienlich sein. Einfach das Signal auf einen Eingang ohne Pullups und dessen Zustand auf einem Ausgang an eine LED.

[orcss]

So nach viel rumprobieren mit dem XBee usw. konnten wir nun ein Hardwareproblem ausschließen.
Durch zufall bin ich auf jemanden gestoßen, der ein und auslesen nicht in der shell sondern mit "minicom" macht, das wohl irgendwelche schönen einstellungen vornimmt denn:
sobald ich "minicom" einmal starte funktioniert input und output (ohne echo) sowohl in minicom als auch in der shell. Beim neustart resettet sich die geschichte allerdings wieder.
Aber es klappt auf jeden Fall scho

Vielen Dank noch mal für die Hilfe ;)
Gruß, Ivo

[peterfido]

Das ist merkwürdig. Wie schaltest du die ttyAMA0 eigentlich frei, um sie nutzen zu können? Evtl. ist da der Hund begraben.