1. Home
  2. Chat
  3. Forum
  4. Kalender
    1. Termine
    2. Karte
  5. Lexikon
    1. Letzte Änderungen
  6. Marktplatz
    1. Bewertungen
  • Anmelden
  • Registrieren
  • Suche
Dieses Thema
  • Alles
  • Dieses Thema
  • Dieses Forum
  • Artikel
  • Forum
  • Termine
  • Lexikon
  • Marktplatz-Eintrag
  • Seiten
  • Erweiterte Suche
  1. PA-Forum
  2. Forum
  3. Hobby Forum
  4. Hobby-Selbstbau und Reparatur Party-Technik

DMX-Empfang / Startbyte

  • SimonFB
  • 23. Mai 2008 um 18:01
  • SimonFB
    Beiträge
    1.875
    • 23. Mai 2008 um 18:01
    • #1

    Hallo ihr Spezialisten!

    Ich versuche grade mit meinem LightCo zu kommunizieren, scheitere aber regelmäßig :?

    Der Reihe nach:

    Projekt: DMX zu Lighttalk Wandler
    Ich will mein DigitalLightCurtains über DMX steuern können. Derzeit geht es aber erstmal nur um das korrekte Auslesen der DMX-Daten. Der Rest ist das fast trivial, da ich schon eine komplette Software fertig habe, die Lighttalk spricht und versteht :wink:

    Zielhardware:
    DilNet/9200 (StarterKit 23). Drin steckt ein AT91RM9200. Ist ntürlich völlig oversized, aber für die späteren Funktionen (zB. Umschalten 8Bit/16 Bit oder Einschalten Speed-Kanal per Webinterface) schon sinnvoll.
    Als RS485 zu RS232 Wandler wollte ich die gleiche Eingangsbeschaltung nehmen, die Hendrik beim Demux verwendet. Sollte doch gehen, oder? Meine Elektronikkenntnisse sind nicht sonderlich fundiert... :roll:
    Momentan werkelt ein fertiger Adapter aus der Bucht dran.
    Auf der Kiste läuft übrigens uLinux mit 2.4er Kernel, die Konfiguration der Baudrate geschieht händisch.

    Zum Problem:
    Die Daten werden fehlerfrei ausgelesen (damit meine ich die Werte der einzelnen DMX-Kanäle), aber ich scheitere an der Erkennung des Startbytes, respektive der des Reset/Break. Folgender Code platziert "Start" irgendwo im Datenstrom, aber sicherlich nicht vor dem ersten Kanal.

    Code
    bytesRead = read(*fd, &readByte, 1); //hole 1 Byte
    
    
    
    
    if(bytesRead==0){ //Lesefehler
    	firstTimeout = GetCurrentUs(); //Zeit sichern
    	do{
    		bytesRead = read(*fd, &readByte, 1);
    	}while(bytesRead==0); //Lesen bis erstes Zeichen korrekt empfangen
    }
    
    
    
    
    if(firstTimeout < (GetCurrentUs() - 88) && (u8)readByte==0){ //Es sind min. 88uS vergangen, Startbyte ist 0
    	printf("\nStart ");
    	do{
    		bytesRead = read(*fd, &readByte, 1);
    		printf("%d ",(u8)readByte);
    	}while(bytesRead==1); //Lesen bis Reset
    }
    Alles anzeigen


    Edit: diese Sequenz läuft natürlich in einer Endlosschleife, hab ich nur nicht kopiert.

    Ich hoffe mein versteht meinen Spaghetti-Code ein bisschen, sonst erläutere ich gerne meine Gedanken dazu. Ich will auch keinesfalls eine fertige Lösung haben, sondern eher
    eine Anregung in welcher Richtung der Fehler zu suchen ist - ich will ja dabei auch ein bisschen was lernen :wink:

    Besten Dank vorab,
    Simon

    Am Anfang war das Licht

  • ljbigfish
    Beiträge
    1.080
    • 23. Mai 2008 um 19:18
    • #2

    Hallo,


    willst du den Empfang nicht über Interrups lösen?? Wär warscheinlich die bessere Variante. Ich kann mal die Routine raussuchen, die ich für den 90S2313 geschrieben hab.
    Muss mal schauen, ob ich das noch finde. Ist aber wirklich yC C++

    Als Wandler von rs486 auf TTL kannst du schon den sn75176 nehmen. Musst nur den Empfangsmodus aktivieren. (Einfach das Pin für die Umschaltung auf Masse ziehen)
    Hab aber lange nichts mehr in der Richtung gebastelt. :cry:


    Viele Grüße
    Simon

  • SimonFB
    Beiträge
    1.875
    • 23. Mai 2008 um 22:00
    • #3

    Über eine ISR hatte ich auch schon nachgedacht. Spart mir wahrscheinlich massig CPU-Leistung. Aber wenn die ISR nur bei empfangenen Zeichen 'anspringt', wie erkenne ich dann die Resets vorm Startbyte? Irgendwie steh ich da ein bisschen auf dem Schlauch :cry:

    Am Anfang war das Licht

  • ljbigfish
    Beiträge
    1.080
    • 23. Mai 2008 um 22:18
    • #4

    Abend,

    den Code habe ich leider auf meinem PC nicht gefunden. Der liegt irgendwo in den tiefen irgendeines Laptops von mir.


    Aber ich habs so gelöst, dass bei jedem empfangenen Bit die Service-Routine ansprigt.
    Zuerst wird der Register durchsucht, ob es ein Reset gab.
    Dann wir die Zählvariable immer um 1 erhöht und bei erreichter Startadresse wird das empfangene Byte in die Datenvariable(n) / String geschoben.
    Wenn es einen Reset gab, wird die Zählvariable einfach wieder auf 0 gesetzt.


    Bei dem String kann man Zählvariable als Pointer fungieren lassen. Oder man legt einfach noch eine Pointer-Variable an. (wenn man z.b. ab Startadresse nur 8 Byte braucht).

    Auf die Daten im String / in den Variablen kann man dann jeder Zeit zugreifen. z.B. Wenn die Sende-Routine wieder neue Bits braucht.


    Viele Grüße und viel Erfolg beim Programmieren
    Simon

  • mario scholz
    Beiträge
    28
    • 25. Juli 2008 um 00:06
    • #5
    Zitat von &quot;SimonFB&quot;

    Über eine ISR hatte ich auch schon nachgedacht. Spart mir wahrscheinlich massig CPU-Leistung. Aber wenn die ISR nur bei empfangenen Zeichen 'anspringt', wie erkenne ich dann die Resets vorm Startbyte?


    Falls das Thema noch aktuell ist: zumindest bei den Controllern der ATmega Reihe geht das über einen Frame-Error.
    Der Reset wird ja übertragen, in dem die Leitung über einen längeren Zeitraum auf LOW gezogen wird, was aber im RS232 Protokoll (dieses spricht die beim ATmega verwendete UART Schnittstelle) nicht vorkommt.
    Das löst dann einen Interrupt aus und führt zum setzen des entsprechenden Statusbits. Darüber kriege ich dann den Reset mit.

    Nach dem Start wartet der empfänger erstmal auf den Reset, ansonsten wird bei jedem Empfangsvorgang überprüft, ob es da evtl einen Reset gab und falls ja, wechselt mein Empfänger wieder in den Zustand "Warte auf Startbyte".

    Falls noch Fragen sind, kannste auch gerne ne PN schicken.

    ~ Mariosch

  • SimonFB
    Beiträge
    1.875
    • 5. August 2008 um 21:09
    • #6

    Vielen Dank!
    Hab hier leider ne Weile nicht reingeguckt, inzwischen hab ich das Problem gelöst.
    Die eingesetzte Hardware war leider nicht in der Lage, den FE zu erkennen, weil Linux den Zugriff auf Hardwareebene nicht zuließ.
    Hab jetzt den Umweg über einen Atmega162 gewählt, so war es stressfrei.

    Danke an alle für die Hilfe,
    Simon

    Am Anfang war das Licht

Anstehende Termine

  • PA-Forum Stammtisch LeatCon

    Donnerstag, 8. Oktober 2026, 13:00 – 14:00
  • Competent Person for Event Rigging according to IGVW SQQ 2 | Level 1 | Munich (English)

    Dienstag, 13. Oktober 2026 – Freitag, 23. Oktober 2026
  • Combined seminar for experts in lifting gear and lifting beam systems (AnschlägerPlus)

    Dienstag, 13. Oktober 2026 – Donnerstag, 15. Oktober 2026
  • Virtueller Stammtisch im Chat

    Dienstag, 13. Oktober 2026, 21:00 – 23:00
  • Sachkunde für Veranstaltungsrigging nach SQQ2 | Level 1 | Köln

    Donnerstag, 15. Oktober 2026 – Sonntag, 25. Oktober 2026

Letzte Themen

  1. Kölner Oper 8000 Mängel nach Kosten von 1.5 Mrd

    slaytalix
    8. Oktober 2026 um 06:30
  2. IHOS DSP 6.4 / Kingray GPA415 FIR Designer .txt Dateiformat?

    ThomasA
    5. Oktober 2026 um 19:16
  3. Neuer Mixer in Sicht: Behringer FLOWCASTER

    funkbrother
    5. Oktober 2026 um 16:21
  4. VI400/600 - Steuerung Local Rack über Mixing Station und Virtual VI ohne Surface?

    robert müller
    4. Oktober 2026 um 23:18
  5. Leatcon 2026 Forumstreffen

    skyper
    3. Oktober 2026 um 10:00
  6. Eminence Kappa 15 (LF) Bauvorschläge für Bassreflex oder Horn

    soundralf
    2. Oktober 2026 um 12:44
  7. Kleine PA und nur Fragen!!!

    Alex Bundschuh
    1. Oktober 2026 um 18:47
  8. Welche DI-Box/Line-Übertrager für Laptop/Kopfhörerausgang?

    wusel123
    30. September 2026 um 12:29
  9. Ersatzteilversorgung Lautsprecher (speziell Seeburg A3 MKII)

    Hanseat
    29. September 2026 um 18:25
  10. Neues Online-Simulationstool für Treiber / Gehäuse / Leistung / Filter

    Blancblue
    29. September 2026 um 13:16

Benutzer online in diesem Thema

  • 1 Besucher
  1. Datenschutzerklärung
  2. Impressum
Community-Software: WoltLab Suite™