mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Siemens S35 Kommunikation über RS232 (STK500)


Autor: Bastian F. (bastian_f)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich versuche einen Atmega8, der in einem STK500 steckt, mit meinem S35 
reden zu lassen, was leider nicht so richtig funktioniert.
Benutzt wird ein billiges ebay Datenkabel (P5=GND, P2=TxD, P3=RxD), 
welches dann auch genau so an das STK500 verbunden wurde, also direkt an 
PD0 bzw PD1 und GND.
Spreche ich das Telefon via Hterm und aktiviertem DTR an funktioniert 
dies auch, nur über den Mikrocontroller kommt nichts an, was anscheinend 
an DTR liegt, da ich nicht verstehe, wie ich das im Programm 
"aktivieren" kann.
http://www.mikrocontroller.net/articles/AVR-Tutori...
Hier habe ich gelesen, dass ich den Handshake mittels 0x11 herstellen 
kann, aber entweder habe ich das ganze nicht verstanden, es falsch 
eingesetzt oder (am ehesten) beides zusammen.
Ich benutzte die UART Bibliothek von Peter Fleury.

Um genau zu sein, wird zwar was auf dem LCD ausgegeben (Kommunikation 
scheint zu gehen), aber das Handy reagiert nicht auf die AT Befehle.
ZB ausschalten (AT^SMSO), was via Hterm funktioniert).

Eventuell kann mir ja jemand auf die Sprünge helfen.
Danke!
#include <stdio.h>
#include <stdlib.h>
#include <inttypes.h>
#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/pgmspace.h>
#include <util/delay.h>
#include "lcd-routines.h"
#include "includes.h"
#include "uart.h"
#define UART_BAUD_RATE      19200

int main () {

  unsigned int c;
  char buffer[7];
  DDRD  &= ~(1<<PD3);
  PORTD &= ~(1<<PD3);

  lcd_init();
  uart_init(UART_BAUD_SELECT(19200,4000000L));
  sei();

  while (1) {
    c = uart_getc();

    if ( c & UART_NO_DATA ) {
      /*
       * no data available from UART
       */
    }

    else {
      itoa( c, buffer, 10);
      lcd_string(buffer);
    }

    if (debounce( PIND, PD3 )) {
      uart_putc(0x11);
      uart_puts("AT^SMSO");
      uart_putc(13);
      uart_putc(10);
    }
  }
}

Autor: Beobachter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
benutztz mit Hterm auch das ebay-Kabel ?
Wenn ja, wie kommst Du darauf das es DTR ist ?
Einfach mal ein vollbelegtes RS232-Kabel nehmen und
den DTR entsprechend setzen.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das "Datenkabel" des S35 benutzt eine parasitäre Spannungsversorgung für 
die im Kabel verbauten RS232-Pegelwandler. Daher genügt es nicht, dieses 
Kabel nur mit RxD/TxD und Masse zu verbinden, sondern es müssen zwingend 
die anderen Handshakeleitungen auf korrektes Potential gelegt werden, 
was für einen PC kein Problem darstellt.

Einfacher wäre es hier, auf das Datenkabel komplett zu verzichten und 
das Telephon komplett ohne Pegelwandler mit dem µC zu verbinden -- wenn 
ich mich recht erinnere, nutzt das Telephon 3V-TTL-Pegel, die direkt mit 
der UART eines µC verbunden werden können, wenn der auch mit 3V 
betrieben wird.

Autor: Bastian F. (bastian_f)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Danke erstml für die Hinweise.
Ich dachte, da nur diese drei Leitungen am Handy ankommen, würde es auch 
reichen nur diese zu beschalten.
Na ja.
Da ich den Atmega mit 5V betreibe, kann ich das Handy ja nicht einfach 
so anschließen, sondern wohl so wie in der angehängten Schaltung.
Nur habe ich aber leider grade keine 2.7V Zenerdioden da.
Kann ich diese mit 3.6V Zenerdioden ersetzen (ansonsten habe ich noch 
1N4148 und 1N4001 da)?

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
D1 und den Widerstand kannst Du weglassen - der mit 5V betriebene µC hat 
keine Probleme mit einem niedrigeren Spannungspegel (solange der nicht 
unter der unteren Schaltschwelle für einen High-Pegel liegt).

Ansonsten ist das Thema Pegelwandlung 3V<->5V in diesem Forum gewiss 
schon etliche tausend Mal ausgekippt worden ...

Autor: Harald Wilhelms (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bastian F. schrieb:

> Nur habe ich aber leider grade keine 2.7V Zenerdioden da.

Nimm doch blaue LEDs. die haben zur Stabilisierung teilweise bessere
Daten als Z-Dioden.
Gruss
Harald

Autor: Bastian F. (bastian_f)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nur Grün, Gelb und Rot vorhanden.

Autor: cskulkw (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Bastian,

bei mir hatte ich nur einen der Steuerleitungen auf 5 Volt gelegt und 
schon funktioniert es.

cskulkw

Autor: Bastian F. (bastian_f)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falls es jemanden interessieren sollte, so habe ich es nun erfolgreich 
hinbekommen:
                ____
AVR/RX o-------[____]--------o S35 Pin 5
                100ohm
                ____
AVR/TX o-------[____]----+---o S35 Pin 6
                100ohm   |
                        -+-
                        / \ 3.6V Z-Diode
                        -+-
                         |
AVR/GND o----------------+---o S35 Pin 1

Jetzt muss ich es nur noch hinkriegen, die Ausgabe vom Handy an das LCD 
in Klartext umzuwandeln...

Autor: Bastian F. (bastian_f)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bastian F. schrieb:
> Jetzt muss ich es nur noch hinkriegen, die Ausgabe vom Handy an das LCD
> in Klartext umzuwandeln...

Anstatt lcd_string und Variablen-/Arrayverwurschtelei einfach lcd_data 
verwenden hat was ;)

Nun gibt es aber folgendes Problem.
Das Handy reagiert brav auf uart_puts("AT^SMSO\r"); und geht aus, bei 
allen anderen Befehlen wie zB uart_puts("AT+CGMI\r");  bekomme ich immer 
einen ERROR ausgegeben. Woran liegt das denn nun?

Autor: Beobachter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wahrscheinlich daran das der Befehl vom Handy nicht unterstützt wird
oder ein Syntax-Fehler im Befehl. Eventuell gibt es ja eine
AT-Befehlsliste des Handys im www.

Autor: Bastian F. (bastian_f)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, die gibt es. Und genau daher habe ich den Befehl.
Unterstützt wird er auch, da der selbe Befehl via Hterm mit einem OK und 
entsprechender Ausgabe quittiert wird.

Autor: cskulkw (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beim S25 antwortet das Telefon bei 19200 kBaud sauber, wie man es vom 
Hyperterminal etc. gewohnt ist. Bei anderen Baudraten mußte ich immer 
Byteweise mit einer wartezeit zw. den Bytes senden. Das Autobauding hat 
bei dem Handy wohl seine Grenzen.

Aber Du solltest besser \r\n (0x0D, 0x0A) beim Senden benutzen. Bei 
manchen Befehlen funktioniert die Akzeptanz auch bei mir nicht.

Mit dem S25 kodiere und dekodiere ich SMS, die im PDU-Format gesendet 
werden. Bei eine SMS von 160 Zeichentext, mußte der Controler schnell 
mal 500 Byte verarbeiten können. Deshalb habe ich mir dann einen Mega 
mit mehr RAM ausgesucht. Wenn Du mehr vorhaben solltest, könnte Dir der 
RAM im mega8 irgendwann zu eng werden.

Der ATmega644P (DIP) kann noch im STK500 betrieben werden, hat 4 k RAM, 
kostet ca. 6-7 Euro bei Reichelt und hat ein OCD zum Debuggen on Chip. 
Außerdem kannst Du den mit 20Mhz betreiben.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.