Aller Anfang ist schwer. -> DMX

Hi,

hey, danke Ihr beiden! Ist ja echt klasse wie das hier vorangeht. Wenn das so weitergeht dann gehen die ersten Prototyp Platinen innerhalb 14 Tagen noch in die Produktion.

Mal ne vieleicht etwas freche Frage. Da Pesi das mit dem Senden gut vorkauen könnte und Günter in Bascom bestimmt wesentlich fitter ist als ich, könntet Ihr da nicht irgendwie.....naja.....etwas Code zusammenraten?!? An meinen Mega644p muss ich den ja dann eh noch anpassen, aber so ne grobe Richtung wäre cool.

Gruß, Benny.

Hallo Benny,

$regfile = "m8def.dat"
$crystal = 16000000
$baud = 250000


Config Com1 = Dummy , Synchrone = 0 , Parity = None , Stopbits = 2 , Databits = 8, Clockpol = 1


Dim Puffer(512) As Byte
Usart_tx Alias Portd.1
Config Usart_tx = Output


Do
Ucsrb.txen = 0 'Usart ausschalten
Usart_tx = 0 'Reset abfallende Flanke
Waitus 88 'minimale Länge des Resets
Usart_tx= 1 'Reset aufsteigende Flanke
Ucsrb.txen = 1 'Usart einschalten
Waitus 16 'MARK zw. RESET und Startbyte min. 8us
Printbin Puffer(1) ; 512 'jetzt die Daten
Waitms 10 'laaaangsaaaam
Loop

Ein Schuß aus der Hüfte, ungeprüft....

Guenter, vielen Dank!

....ich hoffe, Du hältst mich nicht für nen "Miesmacher" oder so, weil ich so oft "dagegenrede", aber nur mal zum Verständnis: Diese Routine läuft ja nicht in nem Interrupt, da ist der µC ja *nur* mit senden beschäftigt...?

oder heisst das "Printbin Puffer(1) ; 512", dass er die 512 Bytes "automatisch im Hintergrund" verschickt...? das wäre natürlich ne geniale Funktion bei Bascom! - würde dann mein Gelaber von oben mit dem Tx complete Interrupt überflüssig machen, den wertet da anscheinend Bascom selbst aus und macht das so...? - Also da kann man sich ja dann echt sparen, das so extra zu programmieren (was man in asm ja machen muss)...

Würde mich dann interessieren (bitte nicht falsch verstehen, ist als ernste Frage gemeint aus Neugier), wo man dann da den Code unterbringt, den der µC währenddessen macht..? - direkt nach dieser Zeile...? - und woher weiß man dann, wann er mit der Übertragung fertig ist...?

Falls diese Zeile jedoch bewirkt, dass er die 512 Bytes rausschickt und währendessen nix anderes macht, dann bleibt natürlich 0 Zeit für andere Sachen übrig...

ansonsten mal von mir ein Versuch, das oben beschriebene in Bascom umzusetzen:

$regfile = "m8def.dat"
$crystal = 16000000
$baud = 250000


Config Com1 = Dummy , Synchrone = 0 , Parity = None , Stopbits = 2 , Databits = 8, Clockpol = 1


Dim Puffer(512) As Byte
Kanal = 513


On tx complete DMX_Senden ' k.A. ob das so heisst, es soll halt diese Routine bei einem Tx Complete Interrupt aufgerufen werden....


Enable Interrupts


Printbin 0 ' einfach mal ein Nullbyte senden, damit danach der Interrupt aufgerufen wird (gibt ja dann nen Tx Complete Interrupt, wenn das Byte durch ist...


'die eigentliche Routine:


DMX_Senden:


If Kanal = 513 then    ' 513 heisst "alle Kanäle durch" (bei weniger Kanälen halt die entsprechende Zahl eintragen, z.B. "13", wenn man nur 12 Kanäle senden möchte...), also ist als nächstes der Reset dran
   $baud = 96000  ' Baudrate runter
   Printbin 0    ' und ein Nullbyte senden, erzeugt den Reset (hier länger als 88 µs, macht ja nix...) - der Mark zwischen Reset und Startbyte besteht dann aus den 2 Stop-Bits dieses Bytes, das sind auch mehr als 8 µs
   $baud = 250000  ' Baudrate wieder hoch für die nächsten ("normalen") Bytes
   Kanal = 0  ' Als nächstes kommt das Startbyte
   Return  ' das war's erst mal
Else
   If Kanal = 0  ' Startbyte kommt als nächstes
      Printbin 0  ' Nullbyte senden
      Incr Kanal  ' beim nächsten Aufruf ist Kanal dann "1", heisst "Datenbyte senden"
      Return ' und raus, beim nächsten Aufruf wird gesendet
   Else
      Printbin Puffer(Kanal) ' jetzt werden die Datenbytes gesendet, da "Kanal" größer als 0 ist, aber kleiner als 513...
      Incr Kanal ' hochzählen für nächstes Byte, wenn alle 512 durch sind, hat "Kanal" den Wert 513, also wird beim nächsten Aufruf der ISR wieder der Reset erzeugt und das Ganze von vorne...
   Endif
Endif
Return

k.A., ob Bascom da schnell genug ist mit dem ganzen If-Zeug...? - aber wie schon gesagt, zwischen 2 Bytes bleiben ca. 880 Takte, da sollte auch bei einer etwas längeren ISR genug über bleiben für den Rest - ansonsten könnte man den "Kern" dieser Routine ja auch noch in asm machen...

Und diese ganze If-Abfragerei erzeugt ja eine gewisse Verzögerung, d.H. es kommt sowieso nicht Byte an Byte ohne kleine Pause, was ja ganz gut so ist, eine zusätzliche Verzögerung ist hier wohl nicht nötig....

Hallo Pesi,

wie gesagt, der Code ist ungeprüft. Die Zeit für eigenen Code habe ich für das Ende der Schleife angedacht. Dort ist ja gerade "Mark zwischen den Paketen" der eine Sekunde lang sein darf.

Übrigends, den Kanal 0 habe ich noch nicht berücksichtigt außerdem muß noch Config Printbin = extended eingefügt werden sonst können nur 255 Bytes verschickt werden.

Für das Senden aller 512 Kanäle ist der ATMega 7680 Takte lang beschäftigt. Das kann man natürlich auf die nötigen Kanäle beschränken.

$regfile = "m8def.dat"
$crystal = 16000000
$baud = 250000


Config Com1 = Dummy , Synchrone = 0 , Parity = None , Stopbits = 2 , Databits = 8, Clockpol = 1


Dim Puffer(512) As Byte
dim Null_byte(1) as Byte
Usart_tx Alias Portd.1
Config Usart_tx = Output
Config Printbin = extended


Do
Ucsrb.txen = 0 'Usart ausschalten
Usart_tx = 0 'Reset abfallende Flanke
Waitus 88 'minimale Länge des Resets
Usart_tx= 1 'Reset aufsteigende Flanke
Ucsrb.txen = 1 'Usart einschalten
Waitus 16 'MARK zw. RESET und Startbyte min. 8us
Printbin Null_byte(1); 1; Puffer(1) ; 512 'jetzt die Daten
Waitms 10 'laaaangsaaaam
Loop

Hallo NG,

so jetzt hab ichs getestet:

Mit Bascom gehen maximal 255 Kanäle in einem Array mit Printbin. Es gibt zwar den Highlevelbefehl Config Printbin = extended, mit dem Arrays > 255 gesendet werden können, jedoch dauert dann das Senden zu lange. Deshalb habe ich die 512 Kanäle auf 3 Arrays verteilt. Wer nicht alle 512 Kanäle senden will, kann sich das natürlich sparen. Mal sehen, ob das noch ein bisschen hübscher geht...

Hier der vorläufige Code

$regfile = "m8def.dat"
$crystal = 16000000
$baud = 250000


Config Com1 = Dummy , Synchrone = 0 , Parity = None , Stopbits = 2 , Databits = 8 , Clockpol = 1


Dim Puffer1(255) As Byte
Dim Puffer2(255) As Byte
Dim Puffer3(2) As Byte
Dim Null_byte(1) As Byte


Usart_tx Alias Portd.1
Config Usart_tx = Output


Do
Ucsrb.txen = 0                                          'Usart ausschalten
Usart_tx = 0                                            'Reset abfallende Flanke
Waitus 200                                              'minimale Länge des Resets
Usart_tx = 1                                            'Reset aufsteigende Flanke
Ucsrb.txen = 1                                          'Usart einschalten
Waitus 16                                               'MARK zw. RESET und Startbyte min. 8us
Printbin Null_byte(1) ; 1 ; Puffer1(1) ; 255            	'jetzt die Daten
Printbin Puffer2(1) ; 255
Printbin Puffer3(1) ; 2
'Hier dein genialer Code rein...
Loop

Günter

Hi Günter,

vielen Dank für den Code, ich werde den dann nächste Woche testen sobald ich die Prototypplatine habe. Das mit den Kanälen ist für mich kein Problem da ich den DMX-Sende-Code ja nur für die Master-Slave Funktion missbrauche und eine Verbindungsart wollte die einfach Standard ist. Da ist DMX einfach perfekt.

Das einzige was mir nun noch fehlt wäre eine galvanische Trennung. Ich frage mich ob ich das über Optokoppler lösen könnte und ob da einer einen Tipp für mich hat. Macht der Einsatz eines Optokopplers beim Sender auch einen Sinn? Dachte eigentlich das das nur bei den Empfängern gemacht wird?

Gruß, Benny.

Zitat von guenter

jedoch dauert dann das Senden zu lange.

warum habe ich mir sowas irgendwie schon gedacht...?

Ist hier aber egal, der Benny muss ja nur 4 Kanäle senden, nämlich die Werte seiner 4 Ausgänge, da reicht ja ein Array locker... ich kann mir auch kaum vorstellen, dass es irgendeine in Bascom programmierte Anwendung gibt, die es schafft, 512 Kanäle zu generieren (512-Kanal-Lichtpult, 512-Kanal-Fader, -Matrixsteuerung, wasauchimmer), also sollte man generell mit einem Array leicht zurecht kommen....

Trotzdem ist das irgendwie ne seltsame Art zu programmieren....

Zitat von guenter

Die Zeit für eigenen Code habe ich für das Ende der Schleife angedacht. Dort ist ja gerade "Mark zwischen den Paketen" der eine Sekunde lang sein darf.

Ja, darf er - was das dann aber für die Wiederholrate ausmacht, kannst Du Dir ja selbst ausrechnen

irgendwie ist Deine Routine sowas für "Pakete senden, wenn sich was geändert hat"... der "geniale" Code ändert was, die Routine schickt's dann anschliessend raus... aber DMX sendet halt normalerweise kontinuierlich, deswegen wird's ja normal in nem Interrupt gemacht...

natürlich, de facto, meinem (und auch Deinem) Receiver ist's egal, wenn das nächste Paket kommt, dann kommt es halt, egal ob direkt im Anschluss oder erst in 5 Sekunden - aber es gibt durchaus auch Geräte, die da komplett aussteigen wenn die Zeit zwischen 2 Paketen zu lange ist...

Mir ist echt nicht klar, wie das alles timingmäßig so laufen soll... - angenommen, der "geniale Code" steckt gerade in nem Menue und wartet da auf ne Eingabe, dann werden solange keine Daten weitergeschickt, bis das Menue beendet ist... jetzt läuft aber z.B. das Faden beim Benny in nem Timer-Interrupt, also geht das munter weiter, die geänderten Daten werden aber nicht rausgeschickt...

also ganz generell, *wo* soll das Ding dann hin/aufgerufen werden (wenn's ne Subroutine wäre)...? nach jeder Tastenabfrage...? oder beim Faden in den Timer-Interrupt mit rein...? - dafür ist's dann aber definitiv zu lang...

mal ganz blöd gesagt, wenn der Benny z.B. *ganz einfach* seinen kompletten Code wie er ist an die von Dir vorgesehene Stelle einsetzt, dann schickt Deine Routine einmal Daten raus (ganz am Anfang), anschliessend läuft nur noch der Code vom Benny - also muss er Deine Sende-Routine als Subroutine machen, und diese "gelegentlich" aufrufen.. da ist halt die Frage, wo....?

an manchen Stellen wird's nicht gehen, weil das dann ne zu große Unterbrechung wäre, es muss/müssen aber schon ne Stelle/Stellen sein, an denen sie regelmäßig drankommt, sonst stockt die Übertragung - daher ja auch üblicherweise ne kurze ISR, die nur ein Byte weiterschickt, sobald das vorherige durch ist....

k.A. warum Du Dich so dagegen sträubst, das auf die ganz normale, bewährte, übliche Methode zu machen, das senden in ne ISR zu packen und damit quasi "gleichzeitig" laufen zu lassen... - in Deiner Empfangsroutine machst Du das ja richtigerweise auch so*, da rufst Du ja auch nicht alle 512 Kanäle in einer "Warte"-Schleife ab und verarbeitest die *dann anschliessend*.... da läuft das Empfangen ja auch in nem Interrupt "nebenbei"...

*EDIT: und bei Deiner asm-Sende-Routine ja auch, die läuft ja auch in nem Interrupt....

aber naja, mir ist's wurscht - der Benny wird schon wissen, wo er das Ding dann mit reinbaut..

EDIT: Benny, was Du noch als "Kompromiß" machen könntest: Du nimmst die Sende-Routine vom guenter, aber *nur für 4 Kanäle* (!) und rufst die in nem Timer-Interrupt 40x in der Sekunde auf - dann hast Du auch ne übliche DMX-Refreshrate, und das Dings läuft trotzdem "im Hintergrund" - wie stark der Prozessor dann damit belastet ist, kann ich jetzt nicht sagen (bin kein "Bascom-Profi"), aber zumindest treten die Wartezeiten regelmäßig auf... aber, Problem, Du hast ja keinen Timer mehr frei, oder....?

Und mach' Dir doch keinen solchen Kopf wegen der galvanischen Trennung! - die ist hier echt nicht nötig und macht das Ding nur noch teurer! - Wenn, dann brauchst Du 2 Optokoppler zwischen dem MAX485 und dem AVR, einen für senden und einen für empfangen - und natürlich nen DC/DC-Wandler, weil die Versorgung für den MAX485 ja auch getrennt sein muss - wenn, dann geht's nur so, Du kannst nicht beim Empfangen den Optokoppler einbauen und beim Senden nicht, weil wenn's irgendwo verbunden ist, dann ist es verbunden....

Mann, ich hätte echt die Schnauze halten sollen mit dieser galvanischen Trennung! - spar's Dir einfach, das muss echt nicht sein!

eine Norm gibt's dafür übrigens nicht, nur eine Empfehlung, dass es getrennt sein "sollte" - ob bei Empfänger oder Sender ist nicht festgelegt, bei dem uDMX-Interface vom Waechter z.B. ist die Trennung ja am Sender...

Hallo Pesi,

ja, das Ding kann in nen Interrupt, der von einem Timer angestoßen wird. Theoretisch könnte man auf das Senden ganz verzichten solange sich keine Werte ändern. Auch hier wollte ich den Code auf das nötigste Beschränken.

Der Highlevelbefehl Printbin ist für diese Aufgabe zu universell. Er kann alle möglichen Variablen aufteilen und verschicken, das macht ihn im Extended Modus halt langsam. "Hier wäre ein Stückchen ASM schön"

Ein Paket enthält 512 Kanäle. Das heißt es werden erst alle Kanäle gesendet, dann wird der geniale Code ausgeführt.

Zur Timingfrage: Bis auf ganz wenige Dinge macht ein ATMega garnichts im "Hintergrund". Auch einen Interrupt nicht. Hier wird der Hauptcode gestoppt, die Interruptroutine ausgeführt und an der Stelle im Hauptcode weitergemacht an der er unterbrochen wurde. Deswegen werden timingkritische Routinen gerne in Interrupts gelegt, da sie dort nicht unterbrochen werden können. Der DMX-Code in der Hauptschleife mit der Hardware USART ist aber nicht timingkritisch, da das Byte, das im Register steht, tatsächlich im Hintergrund verschickt wird. Das nächste Byte kommt dann halt etwas später (normkonform) im Register an, wenn der Interrupt abgearbeitet ist. Das kann man positiv und negativ sehen: Negativ weil das DMX-Signal je nach Stresslage dann unterschiedlich lang wird, positiv weil man mehr Zeit hat anderes zu tun. Läge der DMX im Interrupt, muß der Rest warten bis alle 512 Kanäle durch sind. Das mit dem "faden" ist ein gutes Beispiel: 2 Interruptroutinen. Wenn gedmxt wird kann nicht gefadet werden und umgekehrt. Wenn alle 512 Kanäle gesendet werden ist der DMX Interrupt sehr lange, das kann Probleme geben.

Also: das DMX eher in der Hauptschleife lassen, die Interrupts möglichst kurz halten (wie immer), den genialen Code auf 16000000 Takte beschränken und du wirst doch nicht den ATMega wegen einer Eingabe hinhalten

Übrigends: die ASM-Senderoutine ist (sehr) timingkritisch

Wegen der galvanischen Trennung hat Pesi völlig recht. Wenns aber sein soll...

Optokoppler: 6N137
DCDC-Wandler: Reichelt SIM1-0505S DIL8

Günter

Hi,

also für mich stellt das alles gaaaaar kein Problem dar mit dem Timing, zumindest bisher von der Theorie her. Mal sehen was mir wieder alles dazwischenfunkt.

Bisher ist mein Programm so aufgebaut das alles über die Hauptloop abgefragt wird. Als erstes wird die Tastermatrix abgefragt, wenn da nix passiert ist gehts einfach weiter. Dann wird das Menu abgefragt, wenn kein Taster gedrückt würde bzw. kein RC5 Code empfangen wurde dann wird auch das übersprungen. Wenn im Menu was passiert ist wird anschliessend ins Menu-Show Unterprogramm gesprungen und das Display aktualisiert. Dann wird erst das eigentliche LED-Programm abgefragt und ausgeführt. Und erst jetzt würde ich, wenn DMX-Senden aktiv ist, den DMX Sende Code in ein Unterprogramm packen und dieses bei Bedarf schnell ausführen.
Also meines erachtens bremst sich da kaum irgendwas aus wenn überhaupt. Wenn ich z.B. auf der Fernbedienung auf einer Taste bleibe dann zählt der z.B. auch schnell die Werte hoch. So wie mein Programm aufgebaut sagt mir das das es sehr schnell durch die Main-Loop läuft.

Gruß, Benny.

Zitat von benkly

also für mich stellt das alles gaaaaar kein Problem dar mit dem Timing, zumindest bisher von der Theorie her.

jaja, Theorie und Praxis...

Zitat von guenter

ja, das Ding kann in nen Interrupt, der von einem Timer angestoßen wird.

Aber dann bitte nicht bei 512 Kanälen, da macht der µC sonst gar nix mehr... - das war nur ein Kompromißvorschlag für Bennys 4 Kanäle, normal macht man sowas nicht in nem Timer-Interrupt....

Zitat von guenter

Theoretisch könnte man auf das Senden ganz verzichten solange sich keine Werte ändern.

Klar - wie oben schon geschildert... nur wäre es dann kein korrektes DMX-Signal mehr, und manche Empfänger haben damit Probleme... ich würde als Entwickler eines solchen Gerätes schon drauf achten, dass da ein halbwegs vernünftiges DMX-Signal rauskommt...

Zitat von guenter

Der Highlevelbefehl Printbin ist für diese Aufgabe zu universell. Er kann alle möglichen Variablen aufteilen und verschicken, das macht ihn im Extended Modus halt langsam.

"Highlevel", "Extended Modus"... k.A. von diesen Bascom-internen Sachen, ich sage dem Ding halt immer *Takt für Takt genau was es da machen soll*

Zitat von guenter

"Hier wäre ein Stückchen ASM schön"

Kann ich mal machen - ich weiß nur nicht, wie man den RAM-Bereich rausfindet, in den Bascom dann das Zeug aus dem Array reinlegt, und ob/wie man sich da Register reservieren kann - müsste man mal den Neni fragen, der kennt sich gut aus mit asm-Schnipseln in Bascom....

Zitat von guenter

Ein Paket enthält 512 Kanäle. Das heißt es werden erst alle Kanäle gesendet, dann wird der geniale Code ausgeführt.

Ist das denn so...? - Habe ich noch keine genauen Infos gefunden... das würde dann Deiner Aussage weiter unten widersprechen... und eben nen Haufen Rechenzeit verschwenden!

Erst kommt Deine Sendeschleife, die schickt 512 Byte raus (+ Startbyte + Reset), macht ca. 23 ms, also ca. 368.000 Takte, die der µC *nur mit dieser Senderoutine beschäftigt ist!* Bzw. die meiste Zeit davon wartet er nur sinnlos ab... während dieser Zeit steckt er in der Senderoutine fest, kann also nix anderes machen!

In der selben Zeit würde die ISR-Senderoutine 514x aufgerufen, je ca. 10-20 Takte (k.A., wieviel bei Bascom), also max. ca. 10.280 Takte für das Senden, die restlichen 357.720 Takte könnte er *während dem Versenden* dieser 512 Kanäle "nebenbei" was anderes machen!

Dann kommt der "geniale Code", von dem man nicht weiß, wie lange er braucht - und hier (in der Zeit, die dieser Code läuft) wird kein DMX-Signal generiert! - also gibt es mehr oder weniger lange Pausen zwischen zwei DMX-Datenblöcken - die man durch das Senden in ner ISR ganz einfach vermeiden kann... und auch hier wieder ein Beispiel: machst Du das z.B. so, dass der "geniale Code" nur 10.000 Takte braucht, bevor wieder die Senderoutine dran ist, dann heisst das unterm Strich, dass der µC zu 97% mit dem DMX Senden beschäftigt ist! - also, als "gut programmiert" würde ich persönlich das nicht empfinden...

Zitat von guenter

Zur Timingfrage: Bis auf ganz wenige Dinge macht ein ATMega garnichts im "Hintergrund".

Ja - aber das Senden per USART *eben schon*, der schickt das Byte völlig unabhängig von der CPU raus, und *das* ist das entscheidende! - die asm-Senderoutine braucht ca. 10-20 Takte, dann macht der USART den Rest alleine! - ein Byte ca. 44 µs, also (bei 16 MHz) ca. 704 Takte zwischen zwei Aufrufen - der µC ist also nur zu ca. 1,4 - 2,8% mit DMX senden ausgelastet, *obwohl* das *kontinuierlich* läuft!

K.A. für Bascom, sagen wir mal, da braucht die Senderoutine satte 300 Takte (gegenüber 20 in asm), dann wären das trotzdem "nur" 42,6% für's DMX senden... Wenn der "Printbin" aber *auch bei einem Byte schon* wartet bis das durch ist, dann ist natürlich auch meine oben geschilderte Bascom-Senderoutine sinnlos, weil da dann auch die meiste Zeit nur gewartet wird... dann müsste man das wirklich mit nem Schnipsel asm machen...

Und sagen wir mal, Du packst Deine Routine in nen Timer-Interrupt, der 10x in der Sekunde aufgerufen wird, dann ist der µC immer noch zu mind. 23% nur mit DMX Senden beschäftigt, aber die Refresh-Rate beträgt nur noch 10 Hz statt 44 Hz! Das ist wohl nicht besonders effektiv, die zehnfache Prozessorbelastung für die viertelte Refreshrate...

Wie schon gesagt, beim Benny würde das als Kompromiß gehen (wenn er noch nen Timer frei hat), ca. (eher *mindestens*) 5.000 Takte für die Routine, alle 400.000 Takte aufgerufen (bei 40 Hz Refresh), macht ca. 1,3% Auslastung, ist doch super! - aber *grundsätzlich* gilt das oben gesagte, 512 Kanäle auf die Methode verschicken ist absoluter Humbug!

Zitat von guenter

Auch einen Interrupt nicht. Hier wird der Hauptcode gestoppt, die Interruptroutine ausgeführt und an der Stelle im Hauptcode weitergemacht an der er unterbrochen wurde.

Oh, sorry, das wusste ich nicht, wie das mit den Interrupts funktioniert - ich dachte immer, da spaltet sich der Prozessor in 2 Kerne auf und macht das parallel! - Spaß beiseite, wie schon erwähnt ist der Knackpunkt der, dass der USART das Byte *selbsttätig* verschickt und die CPU *in der Zeit* was anderes machen kann - aber anscheinend wohl nicht bei Bascom, weil da wohl die CPU in ner Warteschleife hängt, bis das Byte durch ist...?

Zitat von guenter

Das mit dem "faden" ist ein gutes Beispiel: 2 Interruptroutinen. Wenn gedmxt wird kann nicht gefadet werden und umgekehrt.

Und das ist eben auch ein gutes Beispiel für das, was ich mit "im Hintergrund" meine: Die Routinen wechseln sich ab, für den (menschlichen) Betrachter laufen jedoch beide Dinge (DMX senden und faden) *gleichzeitig*! - und unabhängig von dem, was der µC in der Hauptschleife macht, eben "im Hintergrund"...

Zitat von guenter

Wenn alle 512 Kanäle gesendet werden ist der DMX Interrupt sehr lange, das kann Probleme geben.

Ja! - drum sage ich auch schon seit 2 Beiträgen, dass es Nonsense ist, die 512 Kanäle in einem Interrupt zu senden! - Sondern *ein Interrupt pro Byte*! - so wie in meinem Beispielcode ja auch gemacht! - dann bremst das in keinster Weise die Fade-Routine aus!

Zitat von guenter

Der DMX-Code in der Hauptschleife mit der Hardware USART ist aber nicht timingkritisch, da das Byte, das im Register steht, tatsächlich im Hintergrund verschickt wird.

Und hier widersprichst Du Dir! - natürlich, *der USART* sendet das im Hintergrund, aber wenn das *so ist wie oben beschrieben*, wartet Bascom darauf, dass das Byte durch ist und macht *dann* erst weiter - und das ist das Problem! Weil der Prozessor eben während des Sendens der 512 Byte völlig "blockiert" ist!

*Sollte* es anders sein (dass Bascom das eben selbst in nem Interrupt "im Hintergrund" managed, hat denn jemand hier gesicherte Infos dazu, wie das läuft..?!?), dann hast Du ein ganz anderes Problem: woher weisst Du, wann die 512 Byte durch sind...? - Wenn der "geniale Code" z.B. sehr kurz ist (naja, muss gar nicht "sehr", also kürzer als ca. 368.000 Takte reicht schon), dann kommt als nächstes gleich wieder die Senderoutine und macht erst Mal nen Reset, auch wenn evtl. gerade mal 5 Kanäle durch sind...

*Wenn* also Bascom dazu fähig ist, etwas anderes zu machen *während die 512 Byte verschickt werden*, dann hast Du genau das umgekehrte Problem: Du musst den "genialen Code" *sicher* mind. 368.000 Takte irgendwas machen lassen, sonst "zerschiesst" sich Deine Senderoutine selbst!

Zitat von guenter

Also: das DMX eher in der Hauptschleife lassen, die Interrupts möglichst kurz halten (wie immer), den genialen Code auf 16000000 Takte beschränken

Umgekehrt wird ein Schuh draus: Das DMX-Senden in ner ISR erledigen, den Rest in der Hauptroutine - dann läuft das Senden nämlich kontinuierlich "im Hintergrund" (Du weisst, was ich meine), und Du musst Dir keine Gedanken machen, wann und wo Du die Senderoutine aufrufst... Du *könntest* Dir sogar den Luxus erlauben, irgendwo auf ne Eingabe zu warten, und *trotzdem* wird das DMX-Signal weiter kontinuierlich gesendet, und das auch noch ohne Pause zwischen den Paketen!

Zitat von guenter

und du wirst doch nicht den ATMega wegen einer Eingabe hinhalten

Ja - ich nicht, aber das hier:

Zitat von benkly

Wenn im Menu was passiert ist wird anschliessend ins Menu-Show Unterprogramm gesprungen und das Display aktualisiert.

Habe ich schon so aufgefasst, wie wenn der µC da in der Menue-Routine bleibt, bis die Bearbeitung fertig ist...

Zitat von guenter

Übrigends: die ASM-Senderoutine ist (sehr) timingkritisch

*Deine* meinst Du aber jetzt, oder....? Das hatten wir ja schon besprochen, dass die hier völlig ungeeignet ist - die "normale/gängige" (die ein Byte im Interrupt rausschickt, sobald das vorherige durch ist) ist auch absolut unkritisch...

Hallo Pesi,

du hast natürlich vollkommen recht.Das byteweise Senden ist schöner. Ob das Eine oder Andere bei 4 Kanälen eingesetzt wird, hängt daran, ob ein Timer frei ist um den Interrupt zu versorgen. Eigentlich wollte ich noch ausprobieren, ob sich der Printbin-Befehl durch einen Interrupt mitten beim Senden des Arrays unterbrechen lässt. Ich gehe zwar davon aus, wenn nicht wäre das natürlich Rossmist. Wenn doch, dann kann der ATMega seine anderen Interrupts ja abarbeiten und ist nicht ganz tatenlos.

Zum Menü kann ich die Statemachine http://www.roboternetz.de/wiss…Bascom_State_Machine_Menu empfehlen. Damit gelingen auch große Menüstrukturen und flott ist es auch.

Gerade ist nix mehr mit DMX zur Reparatur da. Deswegen kann ich deinen Code nicht am lebenden Objekt testen, kann aber nicht lange dauern...

Günter

Hallo,
ich denke das es sich da wohl um mein uDMX Interface handelt,Du mußt bevor Du DMXC startest das Plugin also die beiden .dll Dateien des uDMX ins Hauptverzeichnis von DMXC kopieren," NICHT in den Plugin Ordner " dann sollte es funktionieren.

Tausche doch Einfach mal DMX+ und DMX- am Empfänger danach sollte die Led Konstant an sein ,wärend der Empfänger Daten Empfängt sollte sich die Led nicht ändern.

P.S.Hättest blos was sagen mußen ich habe hier noch einige DMX Empfänger rumliegen.( Pesis normale oder die SMD Variante oder aber auch mein Favorit den Aufbau von Hendrik Hölscher

Mit der Startadresse hast Du recht, das kann man aber auch in DMXC rausfinden in dem Du ein Gerät einbindest und dort wird dann auch eine Dipreihe dargestellt mit Schalterstellung.
Aber ob das IC noch zu gebrauchen ist mußt Du ausprobieren.Ich hoffe Du hast Dir nicht blos Bauteile für einen Empfänger gekauft den 75176 kann man öfter gebrauchen.

***************
Wenn Du es heute Zeitlich nicht mehr schaffst einen neuen 75176 zu kaufen ist hier im Forum bestimmt jemand bereit Dir mit einem auszuhelfen !

Also normal scheind mir das aber nicht.
Hast Du Deinem DMX Dimmer im Gerätemanger des DMXC angemeldet? dann soltest Du die ersten 5 Kanäle in der Kanalübersicht verstellen können - Kanal 1 -3 = Rot,Grün,Blau - Kanal 4= Dimmer und Kanal 5= Strobe
Als DDF kannst Du ja dieses was ich angehängt habe nehmen und kopierst das ohne .txt nach " DMXControl\Devices "