mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Intterrupt vs. Polling bei bidirektionalem Datenverkehr


Autor: Matze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

in meinem nächsten Projekt möchte ich gerne eine Alarmmeldeanlage 
realisieren, die mir via GSM-Modem den Alarmstatus per SMS übermittelt. 
Mein ATmega 1280 untersucht kontinuierlich die seriellen Daten der 
Maschine und soll bei einer Fehlermeldung eine Nachricht versenden. 
Zudem möchte ich per SMS über mein Mobilfunktelefon Befehle an mein 
GSM-Modem schicken, der uC soll diesen verarbeiten und über den USART an 
die Maschine weiterleiten

Im Forum habe ich bereits ähnliche Beiträge gefunden, allerdings haben 
sie mir bisher nur bedingt weiter geholfen.

Mein erster Gedanke war, dass ich das überprüfen der RS232-Daten mittels 
While-Schleife realisiere. Also in etwa so:


uint8_t UART_GETC (void)
{
    while (!(UCSR0A & (1<<RXC0)));
    return UDR0;
}


void main()
{

uint8_t char c;

  while( 1 ) {

    c = UART_GETC();

    if( c == Terminator )    // Terminator bspw. 0x0D

// es folgt eine Reihe an If-else-Anweisungen, die die Zeichen 
untersuchen

}
}

Allerdings gehört in eine Hauptprogrammschleife nichts, was die 
Ausführung dieser grundsätzlich verhindern kann. Und genau das mache ich 
ja beim verwenden des Interrupts.

Das Programm soll ja nun beim Auftreten einer Fehlermeldung reagieren 
und mittels einer Funktion Send_SMS() eine Benachrichtigung an mein 
Handy versenden. Zudem will ich ja auch die Maschine ansteuern. Wenn ich 
auf zwei USARTs angewiesen bin, wäre es da nicht sinnvoller mit zwei 
Interruptroutinen zu arbeiten?

Also…

ISR (USART0_RXC0_vect)  // Maschine uC
{
unsigned char data = UDR0;
}

und…

ISR (USART1_RXC1_vect)  // uC Modem
{
unsigned char data  = UDR1;
}

Ich empfange kontinuierlich Daten von der seriellen Schnittstelle und 
werte diese aus. Sende ich jetzt ein Befehl mittels Handy, wird diese 
Routine unterbrochen und ich lese am USART1 Zeichen für Zeichen des 
Befehls ein, speichere ihn zwischen, oder leite ihn einfach an den UART0 
weiter.

// Zeichen von Modem empfangen

ISR (USART1_RXC1_vect) {
unsigned char x  = UDR1;
void putch() = x;

// void putch (unsigned char x) {
// while (!(UCSR0A & (1 << UDRE0)));
// UDR0 = x;
// }

In meiner Main würde ich also zunächst die entsprechenden AT-Kommandos 
an mein Modem zur Initialisierung schicken (aufwecken, Pin-Eingabe, 
etc). Das Sperren und Freigeben der globalen Interrupts wäre hier noch 
nicht nötig.

Wenn das Modem Sende und Empfangsbereit ist, initialisiere ich USART0 
und USART1 und springe in meine Hauptprogrammschleife, die die seriellen 
Daten am USART0 untersucht. Wenn bspw. eine Fehlermeldung detektiert 
wird sende ich mit Hilfe der Funktion Send_SMS() eine Nachricht. Hierbei 
müsste ich vor dem Ausführen der Funktion die globalen Interrupts 
deaktivieren und nach Ausführung wieder aktivieren, oder? Nicht das mir 
da der USART1 dazwischenfunkt.

Ich bin mir nicht sicher was ich in diesem Fall tun soll! Das 
Untersuchen der Daten mittels Polling und Empfangen von Befehlen mittels 
Interrupt, löst das nicht ne Art Kollision aus?

Wie ihr seht, verwirrt mich das Ganze etwas und ich wäre froh, wenn mir 
diesbezüglich jemand weiterhelfen könnte. Über Tipps und Hinweise würde 
ich mich freuen!

Viele Grüße,
Matze

Autor: oldmax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi
Also, ich habe bisher nur mit Atmega8 und Assembler gearbeitet, aber 
vielleicht hilft dir trotzdem diese Info.
Ich habe einen kleinen Speicherbereich von ca. 30 Bytes als Buffer 
deklariert. Kommt in der ISR - Empfang ein Zeichen an, wird er in den 
Buffer eingetragen und ein Schreibzeiger erhöht. Erwischt er die 
Buffergrenze setze ich ihn wieder auf 0, damit habe ich einen 
Ringspeicher. Im Programm vergleiche ich nun diesen Schreibzeiger mit 
einem Lesezeiger. Sind diese beiden unterschiedlich, weiß ich, das ein 
Zeichen angekommen ist. Also werte ich es aus und führe den 
Schreibzeiger nach. Das Programm hat alle Zeit der Welt für die 
Bearbeitung und die Routinen werden auch nur aktiv, wenn es notwendig 
ist.
Ich denke, das auch du in ähnlicher Form vorgehen kannst.
Gruß oldmax

Autor: Lehrmann Michael (ubimbo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matze schrieb:
> Allerdings gehört in eine Hauptprogrammschleife nichts, was die
> Ausführung dieser grundsätzlich verhindern kann. Und genau das mache ich
> ja beim verwenden des Interrupts.

Dann wäre ja jeder Interrupt sinnlos ...

Man muss die Interrupts natürlich immer intelligent maskieren. Das gilt 
gerade dann, wenn man zeitkritische Anwendung hat. Es ist ja nicht so, 
dass Interrupts die während der ISR auftreten verloren gehen. Diese 
werden dann halt leicht zeitverzögert nach Ablauf der ersten ISR 
ausgeführt.

Alles von dir ansgesprochene solle in ISR(s) von statten gehen.

Autor: Huch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist ein bischen schwierig Dir bei diesem Stand Deiner Kenntnisse 
weiterzuhelfen.

Da sind: Der globale Interrupt, die einzelnen Interrupts, 
Initialisierungen, Texterkennung, Nebenläufigkeit.

Es ist ratsam erstmal mit einzelnen Aspekten zu beginnen um die 
Kenntnisse zu erwerben die Du für das Gesamtprojekt brauchst.

Um Dir aber eine Sorge zu nehmen: An sich ist es möglich das Projekt zu 
verwirklichen. Wenn man es "richtig" macht ist das kein Problem.

Um gleich auf Interrupts und ihren Einfluss auf das Hauptprogramm 
einzugehen:
Interrupts werden prinzipiell so kurz wie irgend möglich programmiert.
Stell Dir vor, dass es so etwas wie einen Zyklus gibt. Er besteht aus 
dem Ereignis, das den Interrupt auslöst, dessen Bearbeitung im Interrupt 
(so kurz wie möglich, wie gesagt) und der Bearbeitung der Daten wie sie 
im Interrupt hereingekommen sind im eigentlichen Hauptprogramm.
Die Summe der Verarbeitungszeiten im Interrupt und im Hauptprogramm darf 
höchstens gross sein wie die Ereignisse auftreten.
Dabei hat man aber verschiedene Variationsmöglichkeiten um die Zeit 
günstig zu verteilen. Buffer usw.
Im Interrupt selbst verarbeitet man in der Regel keine Daten, vergleicht 
nichts oder macht sonst irgendwas mit den Daten. (Das ist mehr eine 
Faustregel als ein Gesetz. Für den Anfänger aber sollte es erstmal 
Gesetz sein).
Der Interrupt soll eigentlich nur Eingangsdaten wegspeichern und dem 
Hauptprogramm mitteilen, das solch ein Interrupt aufgetreten ist. Das 
Hauptprogramm selbst liest dann die vorher gespeicherten Daten und 
interpretiert sie.
Durch die Regel, das die "Zykluszeit" ausreichen muss ist auch 
sichergestellt, das eine Unterbrechung durch den Interrupt die 
Gesamtfunktion nicht negativ beeinflusst. Selbst wenn das Hauptprogramm 
gerade einen Text vergleicht, schadet das nichtst, denn es hat ja Zeit 
genug, die gerade eingetroffenen Daten erstmal_ _vorläufig zu 
ignorieren und mit denen weiterzumachen die es gerade am Wickel hat.

Dieser kurze Überblick soll Dir zeigen, dass man systematisch an das 
Problem herangehen kann, das es aber andererseits auch nicht wirklich 
trivial ist.

Ich würde Dir daher wärmstens empfehlen, erstmal einfache Dinge zu 
programmieren und damit herumzuspielen. Z.B. könntest Du mal in einem 
Interrupt eine LED blinken lassen. Im Hauptprogramm die Anzahl zu zählen 
und evtl. auszugeben.

Anfänger neigen dazu im Interrupt der Texte empfängt, schon die Texte 
oder wenigstens das Textende zu erkennen. Das erste ist nicht sinnvoll, 
das zweite kann man machen ist aber meist unnötig.

Der zweite Schritt wäre einfach mal einen Textempfang und Senden via 
Interrupt zu programmieren und einfache Befehle im Hauptprogramm zu 
erkennen.

Eine Rundumerklärung wäre an dieser Stelle einfach viel zu umfangreich. 
Du musst Dich dem Thema Schritt für Schritt nähern. Bei den 
Einzelschritten sind wir Dir hier gerne behilflich.

Viel Erfolg.

Autor: Huch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich sehe gerade, das Du anscheinend Deinen ersten Post wesentlich 
editiert hast, während ich dabei war die Antwort zu schreiben. Das ist 
ungünstig, da es die Antwort entwertet.

Autor: Huch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hoffe ich habe mich da nicht geirrt. Aber irgendwie kam mir der Post 
verändert vor.

>Allerdings gehört in eine Hauptprogrammschleife nichts, was die
>Ausführung dieser grundsätzlich verhindern kann. Und genau das mache ich
>ja beim verwenden des Interrupts.

Das ist überhaupt kein Problem, solange die Bedingung der "Zykluszeit" 
nicht verletzt wird.

Deine skizzierten Interruptroutinen sind soweit OK. Aber die hier von 
olmdax angeregte Verwendung eines Ringpufferst ist zu empfehlen.

Autor: Matze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,
vielen Dank für die Antworten. Vor allem der Beitrag von Huch, hat mir 
doch sehr weiter geholfen. Ok, die Interrupts verwende ich also nur um 
die Eingangsdaten wegzuspeichern.

ISR(USART1_RXC_vect) {

char array [20];
int counter = 0;
uint_8 data;
uint_8 StringLaeng = 20;
data = UDR;

array [counter] = data;
counter++;
If (counter < StringLaeng – 1)
counter = 0;
}

Ich empfange also den ankommenden Befehl (20 Zeichen lang), im Falle 
einer empfangenen SMS, und speichere die einzelnen Zeichen in einem 
Buffer. Das geschieht alles noch in der IR. Nun soll eine Funktion das 
Array bzw. die einzelnen Zeichen auslesen und und an den UART0 
weiterleiten. Wäre für die Analyse der seriellen Daten eine IR ebenfalls 
sinnvoll? Verständnisfrage: Wenn ich aber permanent Zeichen via 
Interrupt empfange, gibts da nicht Probleme wenn eine SMS eintrifft?

> Es ist ja nicht so,
> dass Interrupts die während der ISR auftreten verloren gehen. Diese
> werden dann halt leicht zeitverzögert nach Ablauf der ersten ISR
> ausgeführt.

Ich meine, wir haben dann ja ne extrem hohe Zeitverzögerung, wenn ich 
meine Prüfroutine anstatt Polling mit IR durchführen würde. Ich empfange 
ja permanent Zeichen. Denkfehler meinerseits?

Wie ich das jetzt verstanden habe soll ich sowohl für die Prüfroutine 
(Polling), als auch für die IR (Empfangen eines Befehls) eine Art 
Ringpuffer anlegen, um bei einer IR, getriggert durch eine SMS, ich in 
meiner Main die restlichen Zeichen noch abarbeiten kann.

Eine Frage habe ich noch: Wie kann ich den bspw. die SMS am besten 
Versenden? Wenn ich in meiner Main eine Fehlermeldung entdecke, muss ich 
ja ebenfalls ein Art Interrupt verwenden, oder? D.h., ich muss dies 
mittels Software-Interrupt einläuten. Wie provoziere ich so ein Software 
Interrupt?

Vielen Dank nochmal für die Antworten, ich weiß das wirklich sehr zu 
schätzen. VG

Autor: Matze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Könnte mir zum letzten Beitrag vielleicht nochmal jemand weiterhelfen? 
Vielen Dank!

Da muss natürlich noch das data = UDR1 rein.

> ISR(USART1_RXC_vect) {

> char array [20];
> int counter = 0;
> uint_8 data;
> uint_8 StringLaeng = 20;
> data = UDR;

  data = UDR1
> array [counter] = data;
> counter++;
> If (counter < StringLaeng – 1)
> counter = 0;
> }

Autor: Remote One (remote1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matze schrieb:
> Könnte mir zum letzten Beitrag vielleicht nochmal jemand weiterhelfen?
> Vielen Dank!

Das was in deinem Beitrag steht ist schon einmal grundsätzlich falsch - 
sry.

All deine Variablen sind lokal in der ISR angelegt. Das heißt, das bei 
jedem Aufruf der ISR diese "neu erstellt" werden, da sie beim Verlassen 
der ISR wieder freigegeben werden. Heißt also, dass ein Großteil deiner 
Variablen global angelegt werden muss und zudem auch noch volatile.
Schau dir doch in der Artikelsammlung einfach mal die Verwendung des 
UART an (AVR-GCC-Tutorial/Der UART: Interruptbetrieb). Da hatte ich 
auch einmal ein Beispiel zum Empfang von Zeichen via Interrupt 
eingestellt.

Autor: Matze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Remote one,
Danke für die Antwort...Kurze Frage, hab ich das vom vorletzten Beitrag 
grundsätzlich richtig verstanden?

> Ich empfange also den ankommenden Befehl (20 Zeichen lang), im Falle
> einer empfangenen SMS, und speichere die einzelnen Zeichen in einem
> Buffer. Das geschieht alles noch in der IR. Nun soll eine Funktion das
> Array bzw. die einzelnen Zeichen auslesen und und an den UART0
> weiterleiten. Wäre für die Analyse der seriellen Daten eine IR ebenfalls
> sinnvoll? Verständnisfrage: Wenn ich aber permanent Zeichen via
> Interrupt empfange, gibts da nicht Probleme wenn eine SMS eintrifft?

> Es ist ja nicht so,
> dass Interrupts die während der ISR auftreten verloren gehen. Diese
> werden dann halt leicht zeitverzögert nach Ablauf der ersten ISR
> ausgeführt.

> Ich meine, wir haben dann ja ne extrem hohe Zeitverzögerung, wenn ich
> meine Prüfroutine anstatt Polling mit IR durchführen würde. Ich empfange
> ja permanent Zeichen. Denkfehler meinerseits?

> Wie ich das jetzt verstanden habe soll ich sowohl für die Prüfroutine
> (Polling), als auch für die IR (Empfangen eines Befehls) eine Art
> Ringpuffer anlegen, um bei einer IR, getriggert durch eine SMS, ich in
> meiner Main die restlichen Zeichen noch abarbeiten kann.

Eine Frage habe ich noch: Wie kann ich den bspw. die SMS am besten
Versenden? Wenn ich in meiner Main eine Fehlermeldung entdecke, muss ich
ja ebenfalls ein Art Interrupt verwenden, oder? D.h., ich muss dies
mittels Software-Interrupt einläuten. Wie provoziere ich so ein Software
Interrupt?

Autor: Remote One (remote1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also, ich hab jetzt nicht alles genau gelesen, aber 20 Zeichen sind 
schon sehr wenig. Wenn eine SMS ankommt, merkst du das ja durch den 
Empfang von entsprechenden Steuerstrings des Mobiltelefons oder des GSM 
Modems. D.h. du sammelst via Interrupt alle empfangenen Zeichen ein und 
vergleichst bei vollständigem Empfang in einer State Machine und führst 
entsprechende Aktionen durch, z.B. SMS abrufen. Je nach Typ des 
Mobiltelefons / GSM Modems kommen da aber nicht nur die Klartextzeichen 
an, sondern noch jede Menge Overhead (TelNr. etc.). Also schon einmal 
mehr als 20 Zeichen.

Das Senden einer SMS ist schon wieder eine neue Aufgabe. D.h., wenn du 
in deiner State Machine festgestellt hast, dass ein Fehler aufgetreten 
ist, dann wird eine Textnachricht versendet. Das kann eigentlich im 
Hauptprogramm geschehen. Es ist ja egal, ob du dafür 100ms mehr oder 
weniger benötigst. Die größte Zeit geht bei der Vermittlung verlogen. Zu 
Silvester kann das auch mal einen halben Tag dauern ;)

Du solltest dir also erst einmal einen Plan machen, was du alles willst. 
Danach musst du abschätzen wie schnell das erledigt werden muss (Empfang 
so schnell wie mgl., damit neues Zeichen eintreffen kann, Senden kann 
auch mal dauern - also Hauptprogramm).
Wenn ich das richtig verstanden habe, dann willst du einfach auf 
einkommende SMS in einer gesonderten Art und Weise reagieren
Auch wenn ich den ein oder anderen jetzt nerve, aber ich habe zu einem 
ähnlichen Thema mal einen Artikel verfasst:
Versenden von SMS mittels Mobiltelefon
Da du lernbegierig bist, solltest du das nicht einfach so verwenden, 
sondern versuchen das selbst zu machen.
Fang am Besten mit mehreren kleinen Programmen an:
 Zeichen empfangen via Interrupt
 SMS Versenden
 SMS dekodieren
 etc.
Am Ende spielt dann alles schön zusammen ;)

Autor: Matze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Remote One,
vielen Dank für deine Antwort, ich werde mich rein knien und deine 
hilfreichen Tipps/Hinweise aufarbeiten. Ich hab halt immer noch das 
Problem, dass ich mir die Ausführung der SMS-Routine zu lange vorstelle. 
Ich meine, wenn ich ein Fehlermeldung detektiere und dann eine SMS 
versenden will, müssen ja weiterhin die seriellen Daten untersucht 
werden. Und genau dieser "Konflikt" macht mir bisher noch etwas 
Kopfzerbrechen.
Bei Fragen werde ich mich natürlich nochmals melden. Vielen Dank nochmal 
für die Antworten!
Euch und Dir natürlich einen guten Rutsch ins neue Jahr!
Gruß,
Matze

Autor: Remote One (remote1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matze schrieb:
> Ich meine, wenn ich ein Fehlermeldung detektiere und dann eine SMS
> versenden will, müssen ja weiterhin die seriellen Daten untersucht
> werden. Und genau dieser "Konflikt" macht mir bisher noch etwas
> Kopfzerbrechen.

Angenommen du arbeitest mit 19200baud / 8n1. Dann überträgst du 1920 
Zeichen pro Sekunde. Ein Zeichen benötigt also ca. 0,5ms.
Wenn ein kompletter Datensatz angekommen ist, wird dieser ausgewertet 
und dann ein neuer erwartet. Während der Auswertung dürfen keine neuen 
Daten mehr ankommen oder werden einfach ignoriert (zumindest bei FIFO).
Du musst also gewährleisten, dass deine State Machine so schnell wie 
möglich durcharbeitet und den Zeichenpuffer (FIFO) wieder freigibt für 
einen neuen Datensatz. Wenn der Vergleich erst einmal durch ist und der 
Puffer wieder freigegeben ist, hast du parallel zum Empfang des neuen 
Datensatzes ja "unendlich" viel Zeit deine SMS zu versenden. Das Senden 
der SMS wird dann eben manchmal durch den Empfang eines neuen Zeichens 
unterbrochen - ist ja aber nicht weiter schlimm.

Nun ist es so, dass viele Mobiltelefone einen Datensatz mit \r\n 
abschließen. Du weißt ja aber schon bei dem \r, dass das Ende des 
Datensatzes erreicht ist. Also wäre es nicht so schlimm, wenn du das 
nachfolgende Zeichen nicht empfängst. Du hast also ca. 1ms Zeit um den 
Vergleich durchzuführen. Angenommen du arbeitest mit einem Atmel auf 
16MHz - dann dauert ein Takt 62,5ns. Bei einer Befehlsausführungszeit 
von 1 Befehl je Takt (zumindest die einfachen) wären dass 16000 Befehle 
die du überschlagsmäßig ausführen kannst. Selbst wenn du "nur" von den 
0,5ms ausgehst und evtl. von 2 Takten je Befehl - ist das immer noch 
jede Menge.
Sollte das nicht reichen, kannst du immer noch die Baudrate runter 
drehen (9800 / 8n1 ist auch noch weit verbreitet).

Wenn ich mich nicht verrechnet habe und völligen Stuss erzählt habe, 
dann brauchst du dir da keine Gedanken machen. Ich konnte bei mir bis 
dato zumindest auch noch nie ein solches Problem erkennen.

In dem Sinne, gesundes Neues und lass es dir mal durch den Kopf gehen ;)

Autor: Matze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,
zunächst einmal, wenn auch etwas verspätet, noch ein frohes Neues!
ich hab mein Projekt nun in kleinere Aufgaben zerstückelt, so wie es ihr 
gesagt habt. GSM-Initialisierung, SMS-Senden, etc.

Ich hätte da noch eine Frage: Wenn eine Alarmmeldung auftritt möchte ich 
gerne in die SMS den Alarmtyp+die Uhrzeit in der er aufgetreten ist. 
Also ich hätte das jetzt per AT+CCLK? vom Modem abgefragt. Hat von euch 
vielleicht jemand ne andere Idee, wie man das am geschicktesten lösen 
könnte? In C gibts ja noch die Headerdatei <time.h>, die allerdings 
nicht in der libc ist.

Autor: Remote One (remote1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matze schrieb:
> Hat von euch
> vielleicht jemand ne andere Idee, wie man das am geschicktesten lösen
> könnte? In C gibts ja noch die Headerdatei <time.h>, die allerdings
> nicht in der libc ist.

Die geschickteste Antwort hast du selbst geliefert (zumindest wenn die 
Zeit im Mobiltelefon richtig eingestellt ist). Alles andere (DCF77, RTC 
...) wäre viel zu aufwendig.

Die <time.h> kannst du glaube ich für eine richtige Zeitangabe 
vergessen. Ich kenne die jetzt nicht unbedingt, aber 
höchstwahrscheinlich liefern die dortigen Funktionen lediglich die 
aktuelle Rechenzeit. Also die Systemzeit beim PC. So etwas funktioniert 
natürlich nicht bei einem µC.

Autor: Matze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das blöde ist nur, dass nach einem Reset oder Unterbrechen der 
Stromversorgung ich die Uhrzeit immer wieder neu einstellen muss und 
mein Programm ja nicht weiß, wie viel Uhr es gerade ist. Wenn ich mein 
Programm starte, muss ich ja immer die Uhrzeit via AT-Befehl AT+CCLK=... 
eingeben. Gibt es da ein Befehl der die Uhrzeit aktualisiert bzw. 
updatet?
VG

Autor: Uhrzeit (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also mir ist ein derartige Lösung nicht bekannt. Evtl. musst du dass 
dann halt mit dem uC regeln...

Autor: Remote One (remote1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matze schrieb:
> Wenn eine Alarmmeldung auftritt möchte ich
> gerne in die SMS den Alarmtyp+die Uhrzeit in der er aufgetreten ist.

Ist eigentlich unsinnig, da der Empfänger ja sieht, wann die SMS 
eingegangen ist.

Matze schrieb:
> Das blöde ist nur, dass nach einem Reset oder Unterbrechen der
> Stromversorgung ich die Uhrzeit immer wieder neu einstellen muss und
> mein Programm ja nicht weiß, wie viel Uhr es gerade ist. Wenn ich mein
> Programm starte, muss ich ja immer die Uhrzeit via AT-Befehl AT+CCLK=...
> eingeben. Gibt es da ein Befehl der die Uhrzeit aktualisiert bzw.
> updatet?

Dann schalte dein Modem eben nicht komplett ab. Bei den Mobiltelefonen 
läuft beim Ausschalten auch die Uhr weiter. Du musst einfach etwas an 
deinem Konzept ändern. Bring doch erst einmal dein Projekt voran. Die 
Zeiteinstellung ist glaube ich dein geringstes Problem.

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.