PIC DMX Empfänger EUSART Problem

[Flo (sandiegoo)]

Hallo Zusammen,

ich bin gerade dabei einen DMX Empfänger zu bauen.

Mein Problem ist gerade das ich das Break nicht erkennen kann bzw das es 
nur schlecht erkannt wird.

Mein Versuchsaufbau: PC(RS232, 57600baud) -> Wanlder zu TTL -> 
PIC(18F4420, 115000baud)

Anzeige: LCD

Theorie: Wenn ich nun eine 0(dez) sende sollte das FERR bit gesetzt 
werden, da das Byte zu lange war. So ist auch die Methode um das Break 
Signal zu erzeugen. Das FERR bit soll später bei der richtigen baud von 
250k das Break des DMX Signals auswerten .

Praxis: Wenn ich eine 0 sende werden ca 50 - 80% aller gesendeten Daten 
ignoriert bzw das FERR bit wird nicht gesetzt.

Was ich schon alles getestet habe:

- neuer Controller -> keine veränderung
- baud beim Computer und im µC gleich setzten(300-115000 getestet) und 
ASCII Zeichen senden und am Display anzeigen lassen -> funktioniert 
einwandfrei
- getestet mit 8 und 20 MHZ Taktfrequenz

 lcd_initialize();

 //USART
        
        TRISCbits.TRISC7 = 1;           //USART als Eingänge festlegen
        TRISCbits.TRISC6 = 1;

      RCSTAbits.SPEN = 1;    //USART enable
        TXSTAbits.SYNC = 0;             //Asynchron mode
        RCSTAbits.RX9 = 0;              //9bit receive off
        RCSTAbits.ADDEN = 0;            //Adress setection off

  RCSTAbits.CREN = 1;             //enable receive

  TXSTAbits.TXEN = 0;    //Transmit disable
  TXSTAbits.BRGH = 1;    //Hohe Baudrate

  BAUDCONbits.BRG16 = 1;          //16bit Mode

  SPBRGH = 0x00;      //0x208= 9600 Baud bei 20MHZ 0x2C = 115000
  SPBRG = 0x2C;      //Baud Rates = 250 k  bei 20MHZ Wert: 19 ,bei 8 MHZ Wert: dec 7


    INTCONbits.GIE = 0; //all interrupts dissabled


while(1)
{
        unsigned char buffer = 0;

         if(RCSTAbits.FERR)
                {
                 buffer = RCREG;
                 lcd_write_pgm("2");
                   
                }
         if(PIR1bits.RCIF)           //if reseived a byte correctly
           {

                buffer = RCREG;         //discrd it
            }
}

Was mache ich falsch? Oder ist meine Theorie schon falsch bitte um Hilfe 
:)

Gruß Flo

[Florian (Gast)]

Keiner eine Idee warum das so ist?

[Max H. (hartl192)]

Warum sollte eigentlich das Senden einer b'00000000' übers UART einen 
Framing Error erzeugen?

[spontan (Gast)]

>Mein Versuchsaufbau: PC(RS232, 57600baud) -> Wanlder zu TTL ->
>PIC(18F4420, 115000baud

Verschieden Baudraten sind nicht so der Hit. Da muß man wissen was man 
tut.

[Florian (Gast)]

Weil es nur die hälfte der Baud ist die gesendet wird und somit das Byte 
(0b0000000) doppelt so langen Low Pegel hat wie das was der PIC 
erwartet.

Auch nachzulesen in diversen anderen DMX Foreneinträgen.

Beim DMX Signal wird am Anfang ein Break gesendet das den Anfang einer 
Neuen Datenreihe zeigt. 0b00000000 bei der halben Baud Das ist genau das 
gleiche wie ich im Versuchsaufbau gemacht habe nur mit eben niedriger 
Baud was aber am prinzip nix ändert.

[Florian (Gast)]

spontan schrieb:
> Mein Versuchsaufbau: PC(RS232, 57600baud) -> Wanlder zu TTL ->
> PIC(18F4420, 115000baud
>
> Verschieden Baudraten sind nicht so der Hit. Da muß man wissen was man
> tut.

in der theorie weis ich ja was ich da tu. Hab ich ja auch geschrieben 
nur in der Praxis funktioniert das nicht und die Frage ist warum.

[Flo (sandiegoo)]

mal anders gefragt... was gibt es denn noch für Möglichkeiten das Break 
des DMX Signals abzufragen?

[Falk B. (falk)]

@ Florian B. (sandiegoo)

>mal anders gefragt... was gibt es denn noch für Möglichkeiten das Break
>des DMX Signals abzufragen?

Frame Error + empfangenes Byte = 0x00, das ist ziemlich zuverlässig.

Aber dein Sender (PC) hat das Problem, dass er zwischen Break und den 
normalen Daten die Baudrate umschalten muss. Und gerade USB-UART 
Umsetzer brauchen dafür eher lange. Und man muss sicher sein, dass der 
FIFO im Sender (PC) leer ist, sprich, die 0x00 schon gesendet wurde. 
Alles ziemlicher Mist. Sowas macht man besser anders. Am einfachsten mit 
einem 2. Mikrocontroller, dort hat man keine Probleme wie am PC.

[Flo (sandiegoo)]

> Aber dein Sender (PC) hat das Problem, dass er zwischen Break und den
> normalen Daten die Baudrate umschalten muss. Und gerade USB-UART
> Umsetzer brauchen dafür eher lange. Und man muss sicher sein, dass der
> FIFO im Sender (PC) leer ist, sprich, die 0x00 schon gesendet wurde.
> Alles ziemlicher Mist. Sowas macht man besser anders. Am einfachsten mit
> einem 2. Mikrocontroller, dort hat man keine Probleme wie am PC.

Danke für die Info. Werde das mal mit nem 2 µC testen.

Tritt der Fehler mit dem PC auch auf wenn ich immer die gleiche Baud 
eingestellt lasse? Und nur versuche sozusagen immer den Break zu senden 
auf Knopfdruck.

[Falk B. (falk)]

@ Florian B. (sandiegoo)

>Tritt der Fehler mit dem PC auch auf wenn ich immer die gleiche Baud
>eingestellt lasse? Und nur versuche sozusagen immer den Break zu senden
>auf Knopfdruck.

Nein, das geht problemlos. Aber dann kannst du keine Daten senden.
Da kann man erstmal eine LED am PIC toggeln lassen, um zu sehen, dass 
der BREAK erkannt wird. Rein zu Testzwecken kann man natürlich die 
Baudrate manuell umstellen und dann normale DMX-Daten senden. HTERM ist 
dein Freund.

Man könnte mit einem FT232 und dem TXEN-Signal auf den konfigurierbaren 
CSBUS Pins eine Trickschaltung bauen, die beim erstmaligen Sendebeginn 
einen BREAK erzeugt. Dann muss man nie die Baudrate umstellen. Siehe 
Anhang.

C1/R1 als Hochpass stellen ein einfaches Monoflop dar, welches dafür 
sorgt, dass das TX Signal für eine bestimmte Zeit dauerhaft LOW wird. 
Das passiert aber nur bei der fallenden Flanke von TXEN, wenn ein neuer 
Burst an DMX-Daten vom PC kommt. Als Break sendet man dann nicht 0x00 
sondern 3x 0xFF. Die Zeitkonstante muss so angepasst werden, dass 
während des 3. 0xFF der HIGH-Pegel am Ausgang wieder erreicht wird. 
Danach geht die Sendung der normalen DMX-Kanäle 0-N los, das Ganze ohne 
Lücke. Damit bleibt TXEN dauerhaft LOW.