DMX ontvangst met USART

In mijn weinige vrije tijd ben ik hier ook mee bezig, meer toegespitst op het ZENDEN van dmx, maar daar heb je eigenlijk hetzelfde probleem.

Het mooie van de USART is dat je inderdaad niet hoeft te gaan bitbangen. Maar je kunt natuurlijk een mooie tussenoplossing bedenken: detecteer de break "handmatig" en schakel daarna over naar de UART.

Op 19 oktober 2005 14:25:31 schreef Jochem_S:
In mijn weinige vrije tijd ben ik hier ook mee bezig, meer toegespitst op het ZENDEN van dmx, maar daar heb je eigenlijk hetzelfde probleem.

Het mooie van de USART is dat je inderdaad niet hoeft te gaan bitbangen. Maar je kunt natuurlijk een mooie tussenoplossing bedenken: detecteer de break "handmatig" en schakel daarna over naar de UART.

oja natuurlijk! helemaal niet aan gedacht Ga ik even mee aan de slag

Een break is te detecteren als een framing error. Daarna kan je dus de bytes gaan ontvangen. Geen extra pinnetjes nodig.

Op 19 oktober 2005 14:57:00 schreef JoWi:
Een break is te detecteren als een framing error. Daarna kan je dus de bytes gaan ontvangen. Geen extra pinnetjes nodig.

Extra pinnetjes hoeft meestal sowieso niet, omdat de UART gemultiplexed zit met een pinnetje van (bijvoorbeeld) poort C.
Framing error misbruiken klinkt ook wel slim overigens. Ik zou eens met de timing moeten rekenen, maar ik kan me voorstellen dat je dan ook een break detecteert die korter is dan 88uS (een echte error dus). Dus het ligt er een beetje aan hoe fail-safe je toepassing moet zijn.

Op 19 oktober 2005 15:40:02 schreef Jochem_S:
[...]
Extra pinnetjes hoeft meestal sowieso niet, omdat de UART gemultiplexed zit met een pinnetje van (bijvoorbeeld) poort C.
Framing error misbruiken klinkt ook wel slim overigens. Ik zou eens met de timing moeten rekenen, maar ik kan me voorstellen dat je dan ook een break detecteert die korter is dan 88uS (een echte error dus). Dus het ligt er een beetje aan hoe fail-safe je toepassing moet zijn.

Maar bij een BREAK is het signaal laag langer dan de tijd van een compleet byte (en dat is 44 usec). Sommige piccies kunnen dit trouwens herkennen en dan uit slaap gehaald worden, dit zijn de types met een AUSART or EUSART (zoals de 16F688).
Maar DMX is zowiezo zonder foutdetectie dus ik neem aan dat de communicatie foutloos verloopt.

Op 19 oktober 2005 16:00:05 schreef JoWi:
Maar DMX is zowiezo zonder foutdetectie dus ik neem aan dat de communicatie foutloos verloopt.

Hm, maar je hebt natuurlijk niet voor niets start- en stopbits he
Maar in weze heb je gelijk, hoewel de break minimaal 88uS moet duren, zal het voor het ontvangen volstaan om een 'laag' van >44uS te detecteren (framing error).

Voor het verzenden van DMX (waar ik zelf mee bezig ben) is het natuurlijk wel belangrijk om die >88uS aan te houden, maar das een ander verhaal.

Maar je loopt dan wel tegen het volgende probleem aan:

stel de break duurt 100 usec. de eerste 88 komen binnen als twee bytes met framing error. Maar de paar bits die daarna komen worden gezien als de eerste bits van de volgende byte terwijl ze in feite nog bij de break horen?

_____________________||||||||||||

(......)(.......)(.......)(.....)

__ = break  ||| = data    (.....) zijn de bytes zoals de UART ze ziet..

Krijg je dan nu niet een compleet scheve "vangst" ?

Of anders gesteld: Hoe bepaald de UART wanneer hij gaat ontvangen? Wat als de ontvangst begint midden in een byte? Hoe detecteerd een pic dat?

Op 19 oktober 2005 23:36:57 schreef T.Assies:
Maar je loopt dan wel tegen het volgende probleem aan:

stel de break duurt 100 usec. de eerste 88 komen binnen als twee bytes met framing error.

Of anders gesteld: Hoe bepaald de UART wanneer hij gaat ontvangen? Wat als de ontvangst begint midden in een byte? Hoe detecteerd een pic dat?

Nee, dat wordt gezien als één karakter. Een UART bepaalt de start door een hoog->laag flank.
Een UART werkt bijvoorbeeld op de volgende manier:
Hij heeft een interne klok die bijv. 16 * de baudrate is. Na een startflank gaat hij tellen en monstert de waarde op T=8, dan de volgende op T=8+16, dan op T=8+32. Zo leest hij de bits (in het midden van elk bit dus). [Hier zijn variaties op, sommige UARTS samplen meerdere keren per bit]. Maar het gaat erom dat je dus maar 1 keer de startflank ziet, met de break krijg je dus slechts één framing error. Een framing error is het ontbreken van het stopbit (omdat het signaal laag blijft)

Op 20 oktober 2005 09:28:39 schreef JoWi:
[...]Nee, dat wordt gezien als één karakter. Een UART bepaalt de start door een hoog->laag flank.
Een UART werkt bijvoorbeeld op de volgende manier:
Hij heeft een interne klok die bijv. 16 * de baudrate is. Na een startflank gaat hij tellen en monstert de waarde op T=8, dan de volgende op T=8+16, dan op T=8+32. Zo leest hij de bits (in het midden van elk bit dus). [Hier zijn variaties op, sommige UARTS samplen meerdere keren per bit]. Maar het gaat erom dat je dus maar 1 keer de startflank ziet, met de break krijg je dus slechts één framing error. Een framing error is het ontbreken van het stopbit (omdat het signaal laag blijft)

Hmm oke. Ik heb even de usart PDF doorgelezen van microchip dus ik snap hoe het in zijn werk gaat.

Maar jij zegt dus dat ik het beste eerst moet wachten op de framing error (de ontvangen byte kan direct gediscard worden, das toch alleen maar laag), en vervolgens wachten op de volgende byte die binnen komt (En dat zal een geldige zijn omdat het signaal eerst hoog wordt voordat de lage startbit komt. Hij begint dus op het moment dat het laag wordt dus dat is in de startbit, dan pakt hij de 8 databits, de 9e bit (1e stopbit bij dmx) en dan de stopbit, vervolgens wordt het signaal weer laag (volgende byte) dus pakt hij die weer..

Ik zal dus inderdaad maar 1 byte met framing error krijgen (break) en daarna geldige bits.. Er zullen dan hooguit problemen onstaan wanneer een echte databyte corrupt aankomt, dan denkt de pic dat het weer een break is. Maar dat is natuurlijk een nadeel van het DMX protocol an sich.. Wat misschien zelfs nog af te vangen is door te kijken of de byte die je ontvangt met de framing error volledig uit nullen bestaat, is dat niet zo heb je te maken met een echte fout.. maar met de refreshrate van dmx moet dat ook geen probleem zijn! Volgens mij heb ik hem door. Bedankt!!

(Zo achteraf lezende was deze post meer een kladblaadje geloof ik )

Op 20 oktober 2005 12:01:21 schreef T.Assies:
[...]

Je MAB is hoog, waardoor je dus altijd je startbit ziet (neergaande flank). Controleer ook altijd netjes op je startcode, als die niet 0 is, negeer dan alle data tot aan de volgende break. Dat moet volgens de standaard (alleen SC 0 is eigenlijk geldig op dit ogenblik, als dimmerdata) en daarmee heb je ook weer een klein stukje meer zekerheid dat je aan het begin van de data zit en geen framing error kreeg omdat er echt fouten op de lijn zaten.

Wil je echt zekerheid, dan controleer je na die framing error op de resterende tijd van die 88uS. Maar in de praktijk zal dat eigenlijk niet nodig zijn hoor, hoe JoWi het beschrijft is gewoon de makkelijkste manier.

Ik heb een dagje zitten programmeren en volgens mij is het helemaal gelukt! Ik heb code geschreven die het DMX-signaal ontrafeld en er 12 PWM kanalen mee uitstuurd.. echte UART kan ik niet simuleren in MPLAB dus dat is nog een beetje hopen maar de startcode detecteren, de kanalen bijhouden etc etc verliep allemaal perfect..

Nu is het wachten tot ik de 16F77 binnenkrijg van Voti.. en dan kan ik het pas echt zeggen..

Ik zou je programma wel eens willen zien als dat mag, aangezien ik, zoals gezegd, ook met dit onderwerp bezig ben!

[Bericht gewijzigd door Jochem op zondag 30 oktober 2005 20:21:54 ]

ik ben ook bezig een DMX ontvanger te maken dus heb ook wel belang bij je programma.
zover als ik begrepen heb, is het signaal in de break hoog en niet laag zoals ik in deze topic las.

BREAK is LAAG
MARK-AFTER-BREAK is HOOG

http://www.euro-pa.be/dmx.html

Hallo,

Ik ben ook bezig met het realiseren van een DMX ontvanger. Dit met een PIC 16f877a maar helaas raak ik er momenteel niet veel aan uit.
Zou het ook mogelijk zijn om dit programma naar me toe te sturen, zo kan ik dat dan eens bekijken wat er moet gebeuren.

Groetjes Boone

haald die pic wel de snelheid van 250 kboud?

ik dacht als oplossing voor probleem: de breaktijd is laag. neem daarvoor dus 88millisec. iedere bit/block laat je 4 millisec duren. dan kan hij alles toch als blokken zien? (dacht ik)

PS, als het werkt dan kan je er wel een schakeling van maken die hier op co kan staan...

Op 15 november 2005 19:20:26 schreef MAH:
haald die pic wel de snelheid van 250 kboud?

Jawel, zie datasheet (deeltal 0 voor een 4 MHz PIC, deeltal 4 bij 20 MHz)

Hallo,
Is het noodzakelijk na een framing error de PIC te resetten? Dit omdat de UART op non actief gaat bij een FERR, of gaat het ontvangen weer verder zodra er valid databytes komen?

Thijs

Op 22 november 2005 19:41:23 schreef T.Assies:
Is het noodzakelijk na een framing error de PIC te resetten? Dit omdat de UART op non actief gaat bij een FERR, of gaat het ontvangen weer verder zodra er valid databytes komen?

Ja dat moet, anders ontvangt hij niks meer (CREN clearen en setten).
edit Weer iets te snel geklopt op het toetsenbord, dat moet bij een overrun, bij een framing error alleen een keer RCREG (het foute karakter) lezen.

[Bericht gewijzigd door JoWi op dinsdag 22 november 2005 19:53:14 ]

Kijk dan is dat denk ik mijn fout geweest... (het project heeft even stil gelegen), in de INThandler kijk ik naar een Ferr, als dat zo is set ik de flag dat er een BREAK is, en vervolgends reset ik de UART. En die reset was ik eerder dus vergeten.. dat verklaard waarom hij bleef hangen bij de break (Had wat controle LEDS ingebouwd)
bedankt en ik hou je op de hoogte.. (kan overmorgen pas weer testen)

EDIT: hmmm... op zoek naar de echte fout dus..!

EDIT2: Ik was na het detecteren van een BREAK vergeten de data uit te lezen. zou dit het zijn?

EDIT3: logisch redenerend denk ik het wel, als bij de break RCREG niet wordt uitgelezen en er wordt meer ontvangen dan komt er een overrun error en loopt de boel vast. Maar daarintegen: stel er wordt een break ontvangen dan is de flag geset, bij de volgende ontvangen byte wordt RCREG keurig uitgelezen omdat er al een break is geweest (je zit dus in de data cyclus) dus dan zou dat toch geen probleem moeten zijn... vraagtekens.. vraagtekens..

[Bericht gewijzigd door T.Assies op dinsdag 22 november 2005 20:02:03 ]

JoWie: wat is jouw visie hierover?