PIC DMX Empfänger EUSART Problem

Flo OP #3615295
Lesenswert?
• ▲
▼ 
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

1
 lcd_initialize();

2


3
 //USART

4
        

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

6
        TRISCbits.TRISC6 = 1;

7


8
      RCSTAbits.SPEN = 1;    //USART enable

9
        TXSTAbits.SYNC = 0;             //Asynchron mode

10
        RCSTAbits.RX9 = 0;              //9bit receive off

11
        RCSTAbits.ADDEN = 0;            //Adress setection off

12


13
  RCSTAbits.CREN = 1;             //enable receive

14


15
  TXSTAbits.TXEN = 0;    //Transmit disable

16
  TXSTAbits.BRGH = 1;    //Hohe Baudrate

17


18
  BAUDCONbits.BRG16 = 1;          //16bit Mode

19


20
  SPBRGH = 0x00;      //0x208= 9600 Baud bei 20MHZ 0x2C = 115000

21
  SPBRG = 0x2C;      //Baud Rates = 250 k  bei 20MHZ Wert: 19 ,bei 8 MHZ Wert: dec 7

22


23


24
    INTCONbits.GIE = 0; //all interrupts dissabled

25


26


27
while(1)

28
{

29
        unsigned char buffer = 0;

30


31
         if(RCSTAbits.FERR)

32
                {

33
                 buffer = RCREG;

34
                 lcd_write_pgm("2");

35
                   

36
                }

37
         if(PIR1bits.RCIF)           //if reseived a byte correctly

38
           {

39


40
                buffer = RCREG;         //discrd it

41
            }

42
}


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

Gruß Flo
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Florian Gast #3616070
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Florian Gast #3616093
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Falk B. #3616559
Lesenswert?
• ▲
▼ 
@ 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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Flo OP #3616674
Lesenswert?
• ▲
▼ 
> 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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Falk B. #3616760
Lesenswert?
• ▲
▼ 
@ 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.
Angehängte Dateien:
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren