Support for D-light

ErnieHorning said:
I’ll look around, I have the pin definitions for the D-light board somewhere...
Click to expand...
Here are the pin definitions.

rjmcnay said:
Ok, what do I need to do to get new micro's.
Click to expand...
You can get up to 3 free sample on Microchip.com.

rjmcnay said:
What Software and hardware.
Click to expand...
There’s a free development IDE tool called MPLAB that you can use to write assembly as is. You can also attach third party tools if you want to write in a different language.

You’ll also need a programmer. I use MPLAB IDC2, though there are cheaper programmers. You compile and program through MPLAB.
 

Attachments

  • DLight Board Pinouts.pdf
    502.2 KB · Views: 56
That pinout description helps a lot, enough for someone to get started. There are still some open questions (polarity of the signals, what is the zero-crossing output for, etc), but those could all be resolved with a board, software and either a scope or a little bit of trial and error.

It's not on my project list for now, though.
 
ErnieHorning said:
Here are the pin definitions.

You can get up to 3 free sample on Microchip.com.

There’s a free development IDE tool called MPLAB that you can use to write assembly as is. You can also attach third party tools if you want to write in a different language.

You’ll also need a programmer. I use MPLAB IDC2, though there are cheaper programmers. You compile and program through MPLAB.
Click to expand...

Yeah, that is a handy picture.
I wonder what the A and B zero cross signal are.

I thought the design was op amp based (I remember the discussion on Planet Christmas and thought these were the result of those discussions).

I wonder what the Crystal frequency is.

Tony M.

P.S. I am enclosing the 2004 design I got off of PC back then when we were discussing open light controls.
 

Attachments

  • Pic_Serial_dim_ver9.jpg
    Pic_Serial_dim_ver9.jpg
    96.3 KB · Views: 48
A Marchini said:
I wonder what the A and B zero cross signal are.
Click to expand...
The guy’s with the D-Light boards my have to do some foot work here, depending on how bad they want this.

Looking the board in the picture, pin 2 goes through a 10K resistor and then to the transformer output. I can’t tell where the other side of the transformer goes. Maybe they’re using the A/D and generating an interrupt when it goes non-zero. Maybe they’re only looking at halfwave.

Pin 5 goes through another 10K resistor and a diode. Maybe this is a fall back to halfwave it the A/D didn’t work.
 
This is richard's son in law again,

Reading back over the posts, Richards posts make him seem angry and that is not true. It's not intentional, but he translates online as mad :oops:. Anyway, I am more than willing to do any legwork. Most of this is over my head but I feel I can help map out the board as far as I can without an oscilloscope. Are we still thinking that loading a modified Renard firmware will allow us to use vixen? Or would it be easier to write an output plug-in for vixen?

We've downloaded MPLAB and played around with it. Let me see if I have this right we will load the renard firmware into mplab, make the changes corresponding to channels, zero a/b, and occ? Does anyone have a link to a primer on some of this stuff, not the assembly but the terms as concepts for the firmware? As in why is a zero necessary? is it watching the frequency of the transformer?

Anyway Thank you all for responding and keeping our hope alive!
Andy
 
ErnieHorning said:
Looking the board in the picture, pin 2 goes through a 10K resistor and then to the transformer output. I can’t tell where the other side of the transformer goes. Maybe they’re using the A/D and generating an interrupt when it goes non-zero. Maybe they’re only looking at halfwave.
Click to expand...

I believe I remember in those old discussions of taking the AC and connecting direct to the comparator on a PIC as well. So perhaps that is what they are doing, using a comparator input as zero cross detect.

Tony M.
 
I bet that if whoever writes the code just contacts Darryl, he’d be willing to help. I believe that he’s mentioned that he’d like Vixen support over on his message board.
 
I asked the question to Darryl and this is his response.

We don't currently support Vixen.
The ACx16 does use a PIC18F2420 with a 10Mhz resonator.
I *definitely* recommended doing your testing with a "non D-Light provided PIC".
The zero cross is comparator based.

I did not plan on using the PIC in the D-Light board.
So I need to know what PIC I need to get and anything else that I will need.
I am more then willing to do the testing and do anything else that needs to be done.
 
If you can provide a company mailing address, you can get 3 samples from Microchip for free; I don’t believe they’ll take a home address. The part that you’re looking for is PIC18F2420-I/SP. If they’re out, you could also take PIC18LF2420-I/SP; it just also works at lower voltage, which you won’t care about.

You can also buy them from Microchip or Mouser.
 
P. Short said:
Are you planning on using or losing the d-light boot loader?
Click to expand...

Phil:

That's a very good question seeing how I do not know what the boot loader does. Will you please explain what a boot loader does or used for, and make a recommendation on what I should do. All the help is greatly appreciated.

Thanks.
 
My understanding is that the code in the d-light is divided into two pieces. The first piece, which I call the boot loader, is always present in the controller and is never over-written or updated. The purpose of this code is to start up the processor, perhaps do some sanity checks, jumpe into the operational firmware, and on occasion download new operational firmware. The second piece of code is the operational firmware, which does everything associated with dimming, is designed to be updated from time to time as enhancements and changes are introduced and bugs are fixed. The usual reason for dividing the code into two pieces is to make sure that there is always code in the device that is capable of starting up the processor and receiving a new operational firmware download, even after a previous download/update failed due to a power glitch or other problem.

The Renard firmware is currently designed as one single blob of code, since the PIC16F688 doesn't provide any mechanism for the firmware to update itself. What I was thinking is that you would probably want to write a new version of the operational firmware that still works with the original d-light boot-loader. This assumes that you can make the new firmware interface to that boot-loader as needed, and that the PC program for downloading new operational firmware does not prove to be a problem.

Of course, I'm hoping that Daryl will chime in (either in public or privately) if I'm totally off-base.
 
We use boot loaders at work. Here are a couple of reasons this is desirable.

One is that no special hardware or programmer is needed. You just use the same method to communicate as you normally would. Second is that you can use any protocol you want, from simple to complex. We sent a few carriage returns out and measured the bit widths and adjusted the master clock frequency until the bit width measured correctly.

You can also ignore the UART and use two pins and use a clocking method that allows you to go as fast as the slowest hardware will go. We used an Atmel processor and found that it was four times quicker to program a boot loader and have the processor clock in the rest of the code.

With a boot loader, on some processors, you can also load test code into RAM and execute out of RAM. This allows you to run this code once and once power is removed, so is the code. You could write a boot loader that moves itself to RAM and then can program all of the flash.
 
I would recommend that you remove the D-Light supplied PIC and replace it with a blank PIC. You will not be able to use our bootloader. However, they are a "nice to have"!
 
I certainly have interest in it being done.

d-Light would eliminate this totally if he would just add DMX control to the programming like LOR has done on their controllers. Granted DMX would not let one to use the fancy features of the product but it would allow it to be used in many other environments including Vixen. :)
 
Macrosill said:
What features would be lost if the DMX protocol was to run a D-light board?
Click to expand...

DMX is basically a ON/OFF/Dimmable function protocol.

The Twinkle and other similar fancy functions would be suppressed.

However those functions can be simulated in software and are planned to be included in some commercial packages.

LOR allready supports DMX on its line of controllers. The board senses whether it is being controlled by DMX or the LOR/d-Light protocol. Physically the connections remain the same to the units. DMX is the protocol used by the professional stage lighting community. Many spot lights, lasers, motor controls and other specialty items use DMX to control their features.

By having DMX support you can use software like Vixen to control the LOR protocol controllers.

Tom
 
One thought that comes to my mind would be to create a daughterboard that would plug into the PIC slots (as long as they are removable) to adapt/change them to the Renard Spec. I would draw something like this up - but - don't have a board to test with.

As I look at the boards - it appears that they use 18F pics for each of the 8 channels.

Of course, if someone wrote an dlight (lor) plugin for vixen.... that would also solve the issue!
 
Last edited:
MrChristmas2000 said:
DMX is basically a ON/OFF/Dimmable function protocol.

The Twinkle and other similar fancy functions would be suppressed.

.......

Tom
Click to expand...

So the Twinkle and other fancy effects are stored in an ic on the board and not controlled by the D-Light software, its name escapes me right now?

Vixen already has Twinkle and other fancy functions as well.
 
You must log in or register to reply here.
Back
Top