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

  • Kombiseminar Sachkundiger für Anschlagmittel und Traversensysteme (AnschlägerPlus)

    Mittwoch, 23. September 2026 – Freitag, 25. September 2026
  • Kombiseminar Sachkundiger für Anschlagmittel und Traversensysteme (AnschlägerPlus)

    Dienstag, 29. September 2026 – Donnerstag, 1. Oktober 2026
  • Sachkunde für Fliegende Bauten

    Dienstag, 29. September 2026 – Donnerstag, 1. Oktober 2026
  • Virtueller Stammtisch im Chat

    Dienstag, 29. September 2026, 21:00 – 23:00
  • PA-Forum Stammtisch LeatCon

    Dienstag, 6. Oktober 2026, 13:00 – 14:00

Letzte Themen

  1. 17. - 18. November | PA Rigging & Truss Safety mit Tom Greber

    Soundchecker
    23. September 2026 um 10:33
  2. 13. - 14. Oktober | Live Mixing Workshop mit Jörn Müller in Köln

    Soundchecker
    23. September 2026 um 10:30
  3. können das hier (Foto) die original Weichen der KMT CS215 / CM215 sein ?

    phattomatic
    23. September 2026 um 09:12
  4. RCF: "Bass Motion Control" vs. "XBoost" => Ähnliche Funktionalität unter zwei verschiedenen Etiketten oder relevante Unterschiede?

    Hanseat
    21. September 2026 um 22:21
  5. Suche Lichteffekt

    Schreddl
    21. September 2026 um 12:22
  6. QLC+4 in MagicQ Visualsieren - wie richtig einstellen?

    metal-shot
    19. September 2026 um 17:44
  7. Verschiedene Verteiler mit Powercon Anschluss bzw. Ausgang kompatibel?

    tenderboy
    19. September 2026 um 12:22
  8. Suche Optocore Spezialisten - trouble shooting eines SANE Verbunds

    georg.h
    19. September 2026 um 10:21
  9. Quick & dirty reverse engineering - wie gehts weiter?

    phlownd
    19. September 2026 um 10:13
  10. DSP Preset für The Box Pro TP218 MKIII

    dxnny074
    18. September 2026 um 15:16
  1. Datenschutzerklärung
  2. Impressum
Community-Software: WoltLab Suite™