Atmega8 UART CTS,RTS (Fragen zu Steuerleitungen)

[Ruediger (Gast)]

Hey Leute, ich versuche mit nem uC ein GSM Modem anzusprechen. Leider 
reicht es dafür nicht wenn ich nur RX,TX und GND verbinde denn das Modem 
benötigt anscheinend die Steuerleitungen (RTS,CTS und möglicherweise 
auch DSR,DTR)
Der uC sitzt auf nem STK500. Habt Ihr ne Ahnung ob die Steurleitungen 
automatisch aktiv sind,oder was ich machen muss um diese zu aktivieren?
Das ist mein Vorläufiger Code,der meiner Meinung nach OHNE 
Steuerleitungen ist?! Vielen Dank für die Hilfe, Rüdiger

/* UART-Init beim AT90S2313 */
#include <avr/io.h> 

#ifndef F_CPU
/* In neueren Version der WinAVR/Mfile Makefile-Vorlage kann
   F_CPU im Makefile definiert werden, eine nochmalige Definition
   hier wuerde zu einer Compilerwarnung fuehren. Daher "Schutz" durch
   #ifndef/#endif 
 
   Dieser "Schutz" kann zu Debugsessions führen, wenn AVRStudio 
   verwendet wird und dort eine andere, nicht zur Hardware passende 
   Taktrate eingestellt ist: Dann wird die folgende Definition 
   nicht verwendet, sondern stattdessen der Defaultwert (8 MHz?) 
   von AVRStudio - daher Ausgabe einer Warnung falls F_CPU
   noch nicht definiert: */
#warning "F_CPU war noch nicht definiert, wird nun nachgeholt mit 8000000"
#define F_CPU 8000000UL  // Systemtakt in Hz - Definition als unsigned long beachten 
                         // Ohne ergeben sich unten Fehler in der Berechnung
#endif
 
#define BAUD 9600UL      // Baudrate

#include <util/delay.h>
  
 
// Berechnungen
#define UBRR_VAL ((F_CPU+BAUD*8)/(BAUD*16)-1)   // clever runden
#define BAUD_REAL (F_CPU/(16*(UBRR_VAL+1)))     // Reale Baudrate
#define BAUD_ERROR ((BAUD_REAL*1000)/BAUD) // Fehler in Promille, 1000 = kein Fehler.
 
#if ((BAUD_ERROR<990) || (BAUD_ERROR>1010))
  #error Systematischer Fehler der Baudrate grösser 1% und damit zu hoch! 
#endif
 

/* USART-Init beim ATmega16 */
 
int main(void)
{
    UCSRB |= (1<<TXEN);                // UART TX einschalten
    UCSRC |= (1<<URSEL)|(3<<UCSZ0);    // Asynchron 8N1 
 
    UBRRH = UBRR_VAL >> 8;
    UBRRL = UBRR_VAL & 0xFF;



 while (!(UCSRA & (1<<UDRE)))  /* warten bis Senden moeglich                   */
    {
    }
 
    void long_delay(uint16_t ms) {
    for(; ms>0; ms--) _delay_ms(1);}

  
  UDR = 'A';
  long_delay(10);
  UDR = 'T';
  long_delay(10);
  UDR = 'D';   
  long_delay(10);
  
  UDR = '0';
  long_delay(10);
  UDR = '2';
  long_delay(10);
  UDR = '4';   
  long_delay(10);

  UDR = '1';
  long_delay(10);
  UDR = '4';
  long_delay(10);
  UDR = '0';   
  long_delay(10);

  UDR = '0';
  long_delay(10);
  UDR = 'x';
  long_delay(10);
  UDR = 'x';   
  long_delay(10);
  

  UDR = 'x';
  long_delay(10);
  UDR = 'x';
  long_delay(10);
  UDR = 13;   
  long_delay(10);


}

[Oliver (Gast)]

Ruediger schrieb:
> abt Ihr ne Ahnung ob die Steurleitungen
> automatisch aktiv sind,oder was ich machen muss um diese zu aktivieren?

Weder noch. Die gibt es gar nicht.
Also nimmst du dir einfach zwei bis vier normale IO-Pins, nennst die im 
Geiste und auf dem Schaltplan RTS,CTS ,DSR, DTR, und programmierst die 
so, dass das Modem am anderen Ende zufrieden ist. Natürlich müssen die 
Signale dann auch über einen Max232 geführt werden.

Oder aber du machst das, was Generationen von RS232-Kabelbastler vor dir 
auch schon in solch einem Fall gemacht haben, und lötest die passenden 
Brücken in den Stecker am Modem.

guggst du hier:
http://www.mikrocontroller.net/articles/RS-232#Flu.C3.9Fsteuerung

Oliver

[Hc Z. (mizch)]

Die Handshakeleitungen müssen in Software implementiert werden, wenn man 
sie braucht.  Zunächst aber einmal solltest Du eine hundsnormale 
Senderoutine ohne Warteschleifen auf die Beine bringen können (was da 
oben steht, macht doch einen sehr unbeholfenen Eindruck), bevor Du Dich 
ans Handshake machst.

[Rufus Τ. F. (rufus)]

Ruediger schrieb:
> while (!(UCSRA & (1<<UDRE)))  /* warten bis Senden moeglich                   */
>     {
>     }
>
>     void long_delay(uint16_t ms) {
>     for(; ms>0; ms--) _delay_ms(1);}
>
>
>   UDR = 'A';
>   long_delay(10);
>   UDR = 'T';
>   long_delay(10);
>   UDR = 'D';
>   long_delay(10);

Du hast da irgendwas entscheidendes nicht verstanden.

Einerseits gibt es in C keine "lokalen Funktionen" (und long_delay ist 
eine innerhalb von main deklarierte), und andererseits solltest Du den 
Code zum Versenden eines Zeichens ohne Delay aufbauen können.

Probiers mal so:

(das hier außerhalb von main!)

void sendezeichen(char zeichen)
{
  while (!(UCSRA & (1<<UDRE)))  /* warten bis Senden moeglich                   */
    {
    }
 
  UDR = zeichen;
}

und in main

  sendezeichen('A');
  sendezeichen('T');
  sendezeichen('D');
  sendezeichen('0');
etc.

[Ruediger (Gast)]

Erstmal vielen Dank für die schnelle Antwort! Unbeholfen trifft es 
leider  ziemlich gut... Noch dazu steh ich im Moment tierisch auf der 
Leitung! Wenn ich das GSM-Modem über den Rechner mim Hyperterminal 
ansteuer,funktioniert das tadelos wenn ich Flusssteuerung auf KEINE 
stelle. Werden denn dann in dem Fall die Steuerleitungen gar nicht 
genutzt?
Ich verstehe nämlich nicht warum die Kommunikation vom Pc aus klappt 
aber vom uC nicht!! Und da lag meine Vermutung halt bei den 
Steuerleitungen,aber wenn der PC die ja auch nicht nutzt,darf ich wohl 
nochmal von vorne anfangen zu suchen,warum es nicht klappt...
Rüdiger

[spess53 (Gast)]

Hi

>Ich verstehe nämlich nicht warum die Kommunikation vom Pc aus klappt
>aber vom uC nicht!! Und da lag meine Vermutung halt bei den
>Steuerleitungen,aber wenn der PC die ja auch nicht nutzt,darf ich wohl
>nochmal von vorne anfangen zu suchen,warum es nicht klappt...

Klappt den eine Kommunikation zwischen AVR und PC?

MfG Spess

[Ruediger (Gast)]

Ja die funktioniert Tadelos!! Das ist ja was ich nicht verstehe!
PC -> Modem klappt
uC -> PC    klappt
uC -> Moden klappt nicht!

zum verrückt werden!!

Rüdiger
Ps: habs auch schon mim nullmodemkabel probiert...

[Ruediger (Gast)]

Das hab ich schon öfters gehört,aber im Prinzip müsste mein uC doch auch 
DTE sein?! Naja,ich hab auf jeden Fall beide Varianten getesten, RX-TX 
getauscht und RX-TX nicht getauscht. Beides hat nicht geklappt...
Die Brücke zwischen DTR - DSR und CTS - RTS hat leider auch nichts 
gebracht.
Wenn der PC bei der Einstellung Flusssteuerung=KEINE wirklich nur TX,RX 
und GND verwendet ist der einzige unterschied zwischen dem PC und dem uC 
dass der PC 12V Pegel hat und der uC 5V Pegel.
Aber ist das Modem denn da so penibel? Ich mein der PC empfängt ja auch 
was der uC sendet?! Rüdiger

[Rufus Τ. F. (rufus)]

Genau wie sind PC und µC sowie PC und Modem miteinander verbunden?

[Ruediger (Gast)]

Verbindung PC-Modem = Normales Serielles Kabel (dient nur der 
Verlängerung,kann das Modemkabel auch direkt an den Com-port hängen)

Verbindung PC-uC = ebenfalls normales Serielles Kabel!

Hab vorhin testweise mal bei dem seriellen Kabel alle kabel 
durchgeschnitten mit ausnahme von Tx,RX und GND. Danach klappte dann 
auch die Verbindung zwischen PC und Modem nicht mehr! Das heißt selbst 
ohne Flusssteuerung verwendet der PC anscheinend mehrere Pins als nur 
die 3...
 (confused) Rüdiger

[Hc Z. (mizch)]

Der PC erzeugt auch bei abgeschaltetem Hardare-Handshake diese Signale 
so, dass die Gegenseite nicht blockiert wird (falls diese diese Signale 
beachtet).

Auf den PCs reichen überdies 3 Leitungen, weil Pullups dafür sorgen, 
dass unbeschaltete Handshake-Leitungen so liegen, dass sie nichts 
blockieren.

Offensichtlich mag Deine Gegenseite definierte Pegel sehen.  Man kann 
ihr deshalb auf ihren Handshake-Empfangsleitungen die passenden Pegel 
geben.  Praktischerweise lassen sie sich von ihren eigenen 
Handshake-Sendeleitungen ableiten.  Üblich ist, RTS mit CTS zu verbinden 
und DTR mit DSR und DCD.

Ein paar Brücken, und es sollte gehen.

[Simon K. (simon)]

Ruediger schrieb:
> Verbindung PC-Modem = Normales Serielles Kabel (dient nur der
> Verlängerung,kann das Modemkabel auch direkt an den Com-port hängen)
>
> Verbindung PC-uC = ebenfalls normales Serielles Kabel!

Das geht nicht! Entweder dein Mikrocontroller ist ein DTE (und steuert 
das Modem an) oder er ist ein DCE (und wird vom Computer angesteuert).
In deinem Falle versuchst du ein DCE (Mikrocontroller) an ein anderes 
DCE (Modem) anzuschließen. Dabei liegen die Tx-Ausgänge und die 
Rx-Eingänge beider DCEs auf den gleichen Pins und erzeugen einen 
Kurzschluss.

Entweder du änderst die Belegung des Steckers am Mikrocontroller, oder 
du musst irgendeine Art gekreuztes Kabel (mglw. wo alle Handshakes 
mitgekreuzt sind) verwenden.

Was Hc Zimmerer sagt, kann darüber hinaus auch noch zutreffen. Ich 
arbeite auch gerade mit einem Tetra Modem, das ebenfalls die Handshake 
Signale benötigt. Ist ja auch ziemlich normal bei Modems.