Re: Controlling Holiday Lights

[sylvan butler <ZsdbUse1+noZs_0610@xxxxxxxxxxxxxxxxxxxxx>]

On Mon, 23 Oct 2006 11:49:44 -0400, Marc_F_Hult <MFHult@xxxxxxxxxxxxxxxxxxxxx> wrote:
> In bygone days, the LPTs were convenient because they were supported by the
> OS

Or mostly as standard hardware that was easy to access both on the SW
and hardware side.  (though a simple design change by IBM in the
original to swap the addresses of the status and control ports would
have made high speed much easier!)  A SW example:  port write to 0x378
switches 8 lines simultaneously.  0x37a does four lines.  On anything
faster than a 4.77mhz 8088, the cycle time is limited by wait states on
the ISA bus.  (PCI (and microchannel) reduce or eliminate most of the
CPU wait states.)  This means that the slowest PC you can buy today can
set the state of 8 lines hundreds of thousands of times per second.
Compare that with an 8255 solution which takes multiple port writes to
set the state of any set of the 24 output lines.  If it takes two
writes, you just cut your maximum rate in half.  Three writes == 1/3.
Etc.  Even the parallel port multiplexing solutions which take five or
six writes are way faster than my 1000hz target (which only requires
2000 writes per second on a standard parallel port).

> As Si implies above, attempting to control multiple LTP's in real time
> deterministically at 1000hz with a PC without a real- time operating system

The 1000hz is the design target.  And modern PCs are fast enough that an
ancient 386/20 laptop running linux has worked great for simple testing.
It has worked so well, I may even change my stuff to be a kernel driver.
The ancient PC speaker driver would produce full sound effects using
1bit PWM under linux.  As long as you kept the sounds from about 1000hz
to 12,000hz and didn't mind a bit of jumpiness on the keyboard.  :)
Given that, I expect I could run fades on 8 lights (one parallel port)
from this 386/20 without needing any "real time" anything.

In reality, not all bits on all ports will need to be toggling that
fast.  Mostof the time, no bits will be toggling.  When a light is
full-on or full-off the system is idle.  It is only while fading or
maintaining a dim level that any toggling will need to happen.

> would cause one to see many more flashes and other glitches owing to OS and
> software timing problems in the PC than anything caused by the hardware.

Again, the PC is mostly a SW development and prototyping platform.
There is no OS involved.  It boots DOS and loads my code which takes
over the entire system.  Or another way of saying it, I've written the
OS.  Even the really little, cheap pics can do 4 channels (bits aka
loads).  That's what's in many of the remotable dimmers.

> I presume that sylvan gets his "1000hz" requirement from 120 zero-crossings
> per second * 8 positions  per zero crossing = OFF + 8 other intensity values.

Not even close.

> Pretty crude. Not sure why he would go this route.

I'm not.

> Conventional dimmers do
> much better than that -- eg DMX512 nominally has 255 intensity values, some

Think of it as me building a DMX512 or X10 dimmer.  How does it actually
create the varying intensities?  By turning on and off the light many
times per second.  That's what I'm doing.

sdb
--
Wanted:  Omnibook 800 & accessories, cheap, working or not
sdbuse1 on mailhost bigfoot.com