POCSAG Decodierung - Frage an Programmierspezialisten

Hallo,
zu meiner Ausgangssituation:

Ich bin gerade dabei mir eine SMS-Alarmierung zu realisieren. Die Meldungen werden über die Datenschnittstelle des BOSS925 empfangen.
Klappt soweit auch alles ganz gut. Als nächstes wollte ich den Boss925 durch einen internen Empfänger ersetzen.
Als Empfänger dient ein Empfängerboard aus einem Alphapoc Melder. Das demodulierte Signal wird von einem PIC16F84 mit "RX-Pager Software" ausgwertet und per RS-232 an einen AtMega8 weitergeleitet. Der Atmega passt den übertragenen Text auf meine Wünsche an und gibt den angepassten Text per RS-232 weiter (entweder an die Alarmierungsstation, oder einfach nur so an ein Terminalprogramm). Später soll er auch Mehrfachaussendungen unterdrücken
und RICs filtern.

Zu meinem Problem:

Wenn nur ein oder zwei RICs ausgesendet werden funktioniert alles wunderbar. Sind es jedoch mehrere RICs schafft es der Atmega nicht alle RICs zu verarbeiten. Ich habe schon mehrere Versuche durchgeführt.
Wenn ich alle RICs auf einmal einlese und später im Atmega trenne bricht die Übertragung nach einigen Zeichen ab, da der Puffer der Schnittstelle voll ist.
Wenn ich jede einzelne RIC einlese und verarbeite klappt das mit der 1. Meldung auch noch, wenn ich dann die 2. Meldung einlesen will wurde der Anfang der Meldung im Puffer schon von der 3. Meldung überschrieben. Bräuchte also einen größeren Puffer.

Ich hoffe ihr habt mein Problem verstanden und könnt mir helfen. Ich bräuchte entweder eine Änderung in der Hardware oder Tipps wie ich das Problem per Software lösen könnte z.B. so eine Art virtueller Puffer.

Hi,

JA - was erwartest du denn...
Du verwendest einen AVR - Das kann nicht funktionieren ;-)

Nee - aber mal im ernst:
Was soll man zu deinem Problem jetzt sagen... Was passiert hast du ja schon selbst erkannt. Nur gibt es dafür jetzt keine universelle Abhilfe.

Auch wenn ich kein AVR Fan bin (hätte man nicht gemerkt, oder?) so würde es mich doch sehr wundern wenn der ATMEGA8 nicht genug "Dampf" hätte um die langsam (9K6, das ist ja fast morsen...) ankommenden Daten vom 16F84 rechtzeitig aus dem Empfangspuffer zu holen und trotzdem noch die eigendliche Verarbeitung zu erledigen.

Daher würde ich sagen es ist recht ineffizient programmiert und das musst du ändern! Aber wie? Dazu müsste man Hellsehen können.

Vom Ablauf her muss aber klar sein, das der 16F84 ein sehr alter µC ist der sehr kaum Speicherreserven hat. Er ist also gar nicht in der Lage irgendetwas zwischenzuspeichern. Verschlimmernd kommt hinzu das bei diesem die ganze RS232 Mimik rein über die Software gelöst wird. Natürlich könnte man diesen "oldie" durch etwas moderneres Ersetzen. Wenn sich jemand mit Pic auskennt ist es überhaupt kein Problem den durch einen 16F628 oder 16F88 zu ersetzen und den Decoderteil der Software fast 1-1 zu übernehmen, den RS232 Teil aber auf etwas effizienteres umzustellen. Dann könnte man im AVR Ric nach RIc abarbeiten... (Oder man nimmt gleich etwas "großes" und macht ALLES in einem µC - selbst ein PIC18F sollte da dreimal reichen... Von ARM oder MIPS ganz zu schweigen...)

Aber ehrlich gesagt würde ich das so sein lassen, den 16F84 als Auswerterbaustein belassen und diesen Bereich wie jeden anderen DecoderIC behandeln.
Das bedeutet: Du musst die Daten Abholen wie sie kommen. Also alle RICs ununterbrochen einlesen und dabei aber dafür sorgen das der Puffer sich ebend nicht komplett füllt!

Im Prinzip besteht dein Programm dann aus zwei Teilprozessen: Das Abholen der DAten und zwischenspeichern. Der Zwischenspeicher kein einmal -je nahc datenmenge und reserven- der interne SRAM des µC sein oder aber ein externer Speicherbaustein vorzugsweise I2C (bei Atmel TWI genannt). 24C16 oder so. SPI geht natürlich auch.
Dieser Prozess hat absolute Priorität -würde das Interruptgesteuert händeln.

Der zweite Teilprozess ist die Verarbeitung der Daten. Hier holst du dir die Daten aus dem Zwischenspeicher verarbeitest diese und gibst die wieder aus. Zwischen den ankommenden Daten sollte dafür MASSIG Zeit sein...

Vom Ablauf der Zwischenspeicherung stelle ich mir ein vorgehen vor wo du einen festen Speicherbereich vorsiehst und die Daten zyklisch einfach nacheinander immer Adresse nach adresse dahin wegschreibst. ISt das ende des Speicherbereiches erreicht springst du wieder nach vorne. Zum Lesen greifst du dann mit einem Pointer auf die jeweilige Adresse zu.
Das sollte vom Ablauf her am einfachsten sein. Normalerweise sollte in diesem Verarbeitungsprozess sogar noch die Doppelempfangsprüfung hineinpassen. Also das doppelte Telegramme erst gar nicht verarbeitet werden. Aber das hat auch keine Not das so weit vorzuverlegen...

Der Speicherbereich muss halt so groß sein sein dass genug zwischengespeichert werden kann. Bei der RS232 Ausgabe würde ich wenn möglich versuchen so schnell wie möglich zu sein. Wenn deine Empfänger 19K2 oder noch schneller unterstützen nutze das auch. So kannst du vermeiden laufende Ausgaben unterbrechen zu müssen.
Natürlich muss der µC das können, also einmal die Geschwindigkeit an sich sich - und dann noch zwei Baudraten gleichzeitig. Das können längst nicht alle. (Wenn es nur um daten an den PC geht, dann ist USB ganz nett, das wird mit dem AVR nur nichts mehr USB AVRs sind schwierig zu bekommen- ein Pic18F2550 währe dann das mittel der Wahl- hervoragendes Framework - auch für Anfänger geeignet und überall für unter 5 Eur. zu bekommen)

Falls auch bei geschickter Programmierung das Timing nicht reicht, dann bleibt dir halt nichts anderes übrig als dich vom ATMEGA8 zu verabschieden und auf etwas "besseres" zu setzen. (z.B. Pic18F, 24F oder gar 32F, ARM7 bzw. CortexM3 oder meinetwegen auch Atmega32) Da kannst du dann noch einen Videoausgang dranbasteln und nebenher auf dem Computer ein Game daddeln ;-)

Gruß
Carsten

Hallo zusammen

Meine Auswerteschaltung beruht auf einen ATMEGA 32. Er macht die Auswertung schickt die empfangen Ric mit Text, Datum, Uhrzeit und Unterric an einen UART und speichert auch noch alle Empfangen Ric mit Datum, Uhrzeit, Unterric und Text in eine I2C EEProm ab. Ausserdem kann ich noch 12 Ric's eingeben die dann zusätzlich auf ein GLCD ausgegeben werden. Bis heute hatte ich noch keine Probleme mit der Schaltung. Der Empfänger ist aus einem Motorola LX2. Die Software hab ich in Bascom geschrieben. Der ATMEGA 8 sollte das eigentlich auch hinbekommen da es ja nur um die UART Auswertung geht.

mfg
Michael

Der Eingangspuffer hat (bei BASCOM) max. 255 Bytes und die laufen halt schnell voll.
Allerdings gibt es auch einen Befehl zur Füllstandsabfrage.
Natürlich muß man dann auch einen Plan B haben und wissen, wohin man den Pufferinhalt dann abspeichert.

MfG

Frank

Erstmal Danke für eure Beiträge.
Werde jetzt mal schauen wie ich mein System neu programmiere.