dsPCI33 / UART / DMA

[Uli N. (uln)]

Bei meiner aktuellen Aufgabe muss ich eine Slave Applikation/Gerät, 
realisiert mit dsPCI33, um einige Funktionen erweitern.

Meine Befürchtung, dass das, mittels DMA realisiertze RS232-Protokoll 
anfällig gegen Versetzungen sein müsste, hat sich schnell bestätigt - 
sowie ich die Slave-Applikation zu Debug-Zwecken anhalte und wieder 
starte, hängt sich die Kommunikation auf. Beim Anhalten der 
Slave-Applikation entdeckt die Master-Applikation/Gerät zunächst einen 
Timeout und beginnt im 150ms-Takt ein fixes Pattern zu senden, z.B.::

'P', 'A', 'T', 'T', 'E', 'R', 'N', '\x0D', '\x03'

Beim Wiederstarten der Slave-Applikation empfängt diese zunächst eine 
nicht
korrekt ausgerichtete Nachricht, geht ihrerseits in einen 
Initialisierungszustand über, indem sie dann aber typischerweise für 
"immer und ewig" eine versetzte Variante der erwarteten Nachricht 
erhält, z.B.:

'\x0D', '\x03', 'P', 'A', 'T', 'T', 'E', 'R', 'N'

Da ich aus Kompatibilitätsgründen das Protokoll nicht verändern kann, 
habe ich auf der Slave-Seite beim Empfang einer  "misaligned" Nachricht 
einen zusätzlichen Zustand eingefügt, in dem zunächst 50ms gewartet, 
dann das Receive-Fifo mittles

while (U1STAbits.URXDA) 
{ unsigned int tmp; 
    tmp = U1RXREG;              // Receive Fifo loeschen
}

gelöscht wird, bevor ich die Slave-Applikation in den 
Initialisierungszustand schicke.

Das funktioniert häufig wie gewünscht, in vielleicht 10% der Fälle tritt 
aber ein seltsames Problem auf - die enpfangenen Nachrichten bestehen 
nur noch aus einem fixen Charakter, meist '\x03', seltener '\x0D', noch 
seltener 'N' (die Wahrscheinlichkeit für das 'Auftreten eines Zeichens 
aus der Menge {'P', 'A', 'T', 'T', 'E', 'R', 'N', '\x0D', '\x03'} könnte 
stark von rechts nach links fallen).

Ich hab' keine Idee, wass da passiert und würde mich über "kreative" 
Tipps freuen.

[fop (Gast)]

Warten bringt da eher nix. Keine Ahnung, was der UART macht, wenn er 
überrannt wird. Eventuell musst Du auf jeden Fall so einen Überlauf 
erkennen und den UART zurück setzen.
Ansonsten musst Du die Empfangenen Daten zeichenweise auswerten.
Ich habe mir immer einen Zähler gemacht, wie viele Zeichen des Patterns 
schon richtig waren.

Zähler auf 0

wenn Zeichen empfangen
    wenn Zeichen gleich Zeichen im Pattern an Position Zähler
            Zähler hochzählen
            wenn Zähler höher als Pattern Zeichen hat
                 Jubeln, wir ham's
    sonst
         wenn Zeichen gleich erstes Zeichen Pattern
            Zähler auf 1
         sonst
            Zähler auf 0
sonst
   nix
und nocheinmal ab "wenn Zeichen empfangen"

[Proletikus (Gast)]

Ist ja logisch dass ein Echtzeitsystem nich per Breakpoint ge-debugt 
werden kann. Da muessen andere Methoden her.
Allerdings scheint dermassen viel an Theorie zu fehlen, dass .. vergiss 
es einfach.

Wenn waehrend des Empfangs Meldungen ausgewertet muessen, sollte man's 
nicht mit einem DMA machen, sondern per normalem Interrupt, und dort 
eine Zustandsmaschine mitlaufen lassen, die das macht. Allenfalls kann 
man auf DMA umschalten, wenn die Blocklaenge bekannt ist.

[Uli N. (uln)]

Wenn das Synchronisationspattern alle 150ms in einm Burst übertragen 
wird, sollte ich eigentlich mittels einer Pause, nach der das 
Receive-Fifo leergeräumt wird, die implementierte DMA-Engine wieder mit 
dem Nachrichtenstrom synchronisieren können, da der DMA-Interrupt ja 
normalerweise zum Ende eines Burst aktiv wird und im Falle eines 
Versatzes eben innerhalb des Bursts auftritt.

___###_________________________________________###_________________________________________###___
    |            |                                | 
 Versatz        FIFO                            wieder 
entdeckt     leerräumen                        synchron

Und Frage war eben, ob jemand eine Idee hat, was den dsPIC33 so 
aufstellen kann, dass er jedes empfangene Byte in ein fixes Zeichen 
konvertiert?

Obwohl mit Auftreten des DMA-Interrupts die DMA-Engine zunächst wieder 
inaktiv ist und damit doch ein kurzfristiger pollender Betrieb des UARTs 
zum Leerräumen des Receive-Fifos möglich sein sollte, scheinen sich 
diese in die Quere zu kommen - denn wenn ich in dem zusätzlichen Zustand 
statt "warten und Receive-Fifo ausräumen" die DMA-Engine benutze, um so 
lange einzelen Zeichen zu empfangen, bis ich ein '\x03' (STX) sehe, 
tritt das Problem mit der Konvertierung in ein fixes Zeichen nicht 
auf.Ich kann
dann wieder die implementierte DMA-Engine - State Machine weiterwerkeln 
lassen.

[Uli N. (uln)]

Proletikus schrieb:
> Ist ja logisch dass ein Echtzeitsystem nich per Breakpoint ge-debugt
> werden kann.

Mit dem Debugger Einsatz provoziere ich nur Stituation, wie sie auch 
durch Leitungsstörungen auftreten können - die Kommunikation sollte 
danach wieder von selbst anlaufen - dass das bisher nicht funktionierte 
aber nicht notwendig war => verdammtes Glück gehabt!

Nachdem ich den "Hack" jetzt anders realiseirt habe, läuft die 
Kommunkikation wieder problemlos an - dennoch würde mich interessieren, 
mit was man dem dsPIC33 dermaßen aufstellen kann?