Propeller-based Lighting Control System

gmichael225

Hi, I'm totally new to the propeller platform, I've previously used Arduino boards and became interested in the propeller for the simultaneous processing.

I'm working on a final-year school project, a control desk for lighting systems, see here and here for the sort of thing I'm thinking of.

These devices have very simple video displays (using monospace characters), up to a couple of hundred input buttons or potentiometers, LEDs for feedback and usually some further auxiliary displays (which may be as simple as an LED matrix).

I've (nearly) successfully made an Arduino-based 8-channel light controller by reading potentiometer values, mapping them to within the range of the master potentiometer, mapping that to within the range of the DMX protocol (0-255), which is the most popular lighting control protocol currently used. If you're unfamiliar with it, there's a good explanation here. The protocol is based on RS-485 and as such msot projects use a Maxim MAX485 Chip to send DMX data (I'm using this chip with the Arduino). So far, the output of the Arduino should be working, but causes the light it's hooked up to to flicker. I'm planning on buying a digital oscilloscope to find out what's going wrong.

My current idea of how to use the propeller would be to use one cog to scan inputs for changes and trigger the appropriate response on other cogs, have another cog constantly transmitting DMX data from some kind of shared memory that other cogs can update. The remaining 6 cogs would handle events and video display.

As I said, I'm unfamiliar with the platform so I don't know how much of this is practical or whether it's the most sensible way to do it.

Any constructive comments are very welcome.

Thanks, Michael

Nick McClick

For hardware you can use something like the DMX IO module. that has XLR jacks for in and out, 4 output channels, some DIP switch inputs and there are open pins for adding other controls like pots, switches, sensors, etc.

For the software, you can take a look at Jon Williams' Spin zone column on DMX (here, pdf). There's also sample code here.

I'm pretty sure his code only uses one cog for the DMX portion, that gives you plenty of horsepower for the rest of your project.

gmichael225

Thanks Nick, that board resembles the design I'm hoping to use except for the receiving capability (although I may use this for RDM later on). The other two links are extremely helpful, thanks

I noticed that the code reads the dmx into a buffer... I'm hoping to do this with analog inputs and for the dmx output. What would be the best way to store 512 8-bit integers, in order, on the propeller? It would need to be accessible to all cogs.

M

JonnyMac

A couple of us -- as Nick has pointed out -- have written DMX receivers and transmitters (I just completed programming this weekend for a commercial DMX lighting fixture for an EFX-TEK client).

If you use my DMX transmitter object (jm_dmxout.spin) then the 512-byte buffer is built right in and you don't have to worry about creating your own buffer. You can read a pot or some other input, massage it as desired, and then write it to the buffer for the channel you want (using the .write() method). If the DMX output has been enabled it will be broadcast in the next cycle.

Since you desire multi-cog access you would want to use the .address() method which provides the hub location of the buffer. You can use this to provide access (read or write) from any cog.

BTW... I am Iron Man Jon Williams

gmichael225

That's fantastic, thanks! My propeller chip should be arriving today, so I'll try it out when I get home. I'll make sure to credit you in the documentation. :-)

M

JonnyMac

Just a note on Spin programming: If the other cogs you launch are Spin, you can use the methods from the DMX object just the way your main program does. I do this all the time with "debugging" code, that is, I declare a serial object and then launch a Spin cog to continuously spit out data to a terminal where I can monitor it as desired.

If you're want a PASM cog to read from or write to the DMX buffer then you will need to pass the address of the buffer to that cog.

Brian Fairchild

I did a "quick and dirty" DMX desk a few months ago to try out a few concepts. In general your concept is fine in splitting the task across multiple cogs. For testing you can get away with SPIN but once you start to do real things you'll need to move to PASM. A simple operation like scaling every output by the value of the master fader needs a multiply per output which soon gobbles cpu cycles.

I had...

2 x input scanning cogs
1 x DMX output cog
2 x video driver cogs
1 x video display cog
2 x DMX 'engine' cogs

The 'engine' cogs took data from the input buffers and filled the output buffers.
The 'display' cog took data from the input and output buffers and formatted them for display.

For fun I wrote my own DMX output routine which generates 8 DMX streams in a single COG.

gmichael225

Thanks for that, that's a huge help! Do you think it's worth having a coprocessor for math?

M

Brian Fairchild

gmichael225 wrote: »

Thanks for that, that's a huge help! Do you think it's worth having a coprocessor for math?

That's kind of what my 'engines' did. The 'beauty' of DMX is that you always know what you are going to do next, ie either the next output or the start of a new frame, as so you can easily interleave operations. For instance, if you didn't want a VGA display you could take those cogs and use then as engines, interleaving them 4 ways.

In fact my ultimate plan was to split the whole thing across 2 propellers with one handling the user interface and one doing the hard work using 1 cog as input from the UI, 6 cogs running as engines and the last cog outputting 8 DMX streams.

My prototype...

gmichael225

Thanks, I'm also drawn tot he idea of a two-prop system...one thing I'm not sure of, though, is what you mean by interleaving in this context? Any explanations welcome.

Brian Fairchild

Interleaving (4-way)...

1st cycle...

Engine 1 is transferring the result of its work to the output buffer position for DMX slot 1 while engine 2 is working on the second half of DMX slot 2 while engine 3 is working on the first half of slot 3 and engine 4 is collecting data from the inputs to work on slot 4.

Next cycle...

Engine 2 is transferring the result of its work to the output buffer position for DMX slot 2 while engine 3 is working on the second half of DMX slot 3 while engine 4 is working on the first half of slot 4 and engine 1 is collecting data from the inputs to work on slot 5.

So engine 1 works on slots 1,5,9,13...; engine 2 on slots 2,6,10,14.... etc etc