PDA

View Full Version : DMX & PicBasic coding problem



magicmarty
- 20th September 2004, 03:09
Hi All,

I'm trying to make a small DMX (lighting) test box, and i was going to create the dmx signal by using a combination of "pulsout" and "pauseus" commands to meet the timing standard of DMX.

My problem is that my pic 'F877 running at 20Mhz has some form of of delay between my commands.
I completely stripped my code down, and experimented wiht only the folling snippet of code :

************************************************** *
INCLUDE "modedefs.bas"
DEFINE OSC 20

dmxdata VAR PORTA.0 'variable dmx to portA bit0.

TRISA=0 'set port A as OUTPUTS

start:
pulsout dmxdata,1 ( pic @ 20Mhz will make this 2uS)
pulsout dmx data,1
goto start
**************************************************


When i look at the signal on my oscilloscope, i see a clean 2uS pulse, then almost 10uS delay until the follwing pulse of 2uS is generated.

I want to know WHY is there almost 10uS between my 'pulsout' commands?


According to the picbasic pro book, if i run a pic at 20Mhz, the MINIMUM delay achievable is 3uS
So, my above example, i was expecting to see at least 3uS between my 2 pulsout commands, and not something as large as 10uS.

I prefer BASIC since it's easier for me, but if i HAVE TO add some asm bits within my BASIC code, then so be it ;-(
(asm...endasm)

Is there soemthing i've completely overlooked on a picf877?

Thanx in advance,
Marty.

magicmarty
- 20th September 2004, 03:22
Sorry, i've been so busy with F877's that i forgot i was actually trying this dmx code on a 16F84A (20mhz).

Marty.

Melanie
- 20th September 2004, 15:35
The PULSOUT routine is not a straightforward "shoot from the hip". You're specifying a duration, which for starters takes the routine time to figure what you want and set-up, then the PULSOUT routine is being called from your program, that's a subroutine jump to and a return from. Add-in all these little odds and ends and it takes a while BEFORE the PULSOUT is executed, and it takes a while to recover AFTER as well. That's why you're seeing that delay between adjacent pulses. You can always do it the long way... add in @ NOP's to time 1uS (at 4MHz) or 200nS (at 20MHz)... Here's Two 1 us Pulses, separated by 2uS the long-way (based on 20MHz PIC)...

High dmxdata
@ NOP
@ NOP
@ NOP
@ NOP
@ NOP
Low dmxdata
@ NOP
@ NOP
@ NOP
@ NOP
@ NOP
@ NOP
@ NOP
@ NOP
@ NOP
@ NOP
High dmxdata
@ NOP
@ NOP
@ NOP
@ NOP
@ NOP
Low dmxdata

Naturally you can incorporate them (pulses and delays) into subroutines if you remember to factor-in the subroutine calls and returns and any other fiddly bits you're doing into the calculation.