Curt, My memory of the 8255 is slightly different (sorry if this has been resolved, I'm a little behind in my mail): The 8255 does starts up with all pins as inputs. This high-impedence state coupled with pull-up resistors will be detected as inactive outputs as long as the system design considers outputs as active low. The problem arises at the moment you change the I/O direction of a port. You are not allowed to change the state of the output latches prior to setting the direction. And those output latches were set to zero on power up. Therefore, you have to set the direction and immediately AFTER set the outputs to all 1's. This leaves a glitchy microsecond-or-so turn on of all those outputs. Yuck. This is not usually a problem when activating indicator lights or solenoids or relays or motors. In fact, if you have a typical set of solid states relays connected to the real world, they might even absorb the glitch. It's been a long time since I worried about propagation time. If they are connected to another computer, or a motor controller, or communication line or any other device that can detect that short pulse, you could have a problem. Rufus _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

Hi Rufus The problem I was seeing was that when interfacing with TTL the hi impedence state on startup turned the ttl inputs on. This was on powerup before you had a driver loaded to change anything. By switching to the darlington array drivers, this high impedence state shouldn't turn the drivers on as they should require the 8255 to source current. It may still require pull downs to ensure that the drivers are inactive until the pins are configured as outputs and we are in control. I will be testing this Monday. Using pulldowns is a balancing act to ensure the pins are held low until programmed as outputs yet have adequate drive for the darlingtons without exceeding the IOH specs for the 8255. That is why I want to test this before releasing it. I may need to adjust some resistor values. I want the highest pull down value that will guarantee the low state to allow as much current as possible to drive the optoisolator. The current transfer ratio on these is spec'ed rather broadly so I want more current than I absolutely need to ensure performance over temperature and individual device variations. Fortunately these darlingtons have swamping resistors to set a definate threshold and the current though these will allow higher value pulldown resistors. Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

> The problem I was seeing was that when interfacing with TTL the > hi impedence state on startup turned the ttl inputs on. This was > on powerup before you had a driver loaded to change anything. > By switching to the darlington array drivers, this high impedence > state shouldn't turn the drivers on as they should require the > 8255 to source current. It may still require pull downs to ensure > that the drivers are inactive until the pins are configured as > outputs and we are in control. I will be testing this Monday. Why not use cheap old buffers or inverters? The cost and board space would be minimal and you won't be wasting power fighting pullups and pulldowns. > Using pulldowns is a balancing act to ensure the pins are held low > until programmed as outputs yet have adequate drive for the > darlingtons without exceeding the IOH specs for the 8255. That Especially if they need to keep their state over temp and time. Regards, Andrew _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

Hi Andrew Andrew Kohlsmith wrote: > > > The problem I was seeing was that when interfacing with TTL the > > hi impedence state on startup turned the ttl inputs on. This was > > on powerup before you had a driver loaded to change anything. > > By switching to the darlington array drivers, this high impedence > > state shouldn't turn the drivers on as they should require the > > 8255 to source current. It may still require pull downs to ensure > > that the drivers are inactive until the pins are configured as > > outputs and we are in control. I will be testing this Monday. > > Why not use cheap old buffers or inverters? The cost and board space would > be minimal and you won't be wasting power fighting pullups and pulldowns. I think I've got it solved with the minimum parts count. Each output cell uses two quad optoisolators and 1 octal darlington sink driver. The sink driver can be replaced with a source driver if desired. The pulldowns aren't that big a problem as they go on the DIO48 card. The opto's are $ 1.00 and the drivers are $.50. The boards are about 5"x6.5" already. I was going to use some hex inverters but since we need the optoisolators anyway, just setting them up as sinking loads for the 8255 should solve what I was seeing. I am about halfway done with a version without optoisolators for applications where we don't have to deal with multiple power systems. Will be smaller and cheaper. I'll post in and out schematics a little later. The glitch Rufus was talking about might be still be a problem but I think we can set the direction and write zeroes before anything drastic happens. Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

Hi All, As promised, the schematics for the inputs and outputs. I am writing documentation and putzing with the non-isolated version trying to learn all the features of pcb. Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

Someone asked, in a private e-mail what the schematic format is. I've deleted the private part as I will with all private communications unless told it's ok to publish them. Curt Wuollet wrote: > > Hi all > > Format is standard PostScript, can be viewed in ghostview, > Image Magick, XV, Electric Eyes, etc. or simply dumped to > a Postscript printer. All free and standard in Linux. > The tool I use for schematics is xcircuit, a dedicated > schematic editor that is one of the few tools I've seen > that uses standard Postscript directly for it's file format. > It saves a file that is printable without conversion. It is > also really fast and easy for schematics, flowcharts, and > other typical engineering needs. It is not in many Linux > distributions but it should be. It is also free and OSS but > I doubt it is available for non-unix platforms. > > No proprietary software was used (harmed :^)) in the production > of the board. For the sake of completeness, the board layout > was done in pcb, a free, OSS layout tool and the illustrations > not done in xcircuit are being done in xfig, another free OSS > standard on *nix platforms. Typesetting, if any, will be in > one of the flavors of TeX the free and OSS program used > extensively for Linux documentation. Mechanical drawings are > done with QCAD a lightweight, free, and OSS CAD package. > > For the standards challanged, Ghostscript is available for > Windows from the standard freeware download sites. If there > is need, I will post a jpg, but, jpg's are typically not > easily editable. I will not use Gif as they use patented > technology which is being used to shake down websites for > money, after the fact. > > I would suggest that these be standard for our project as > they put the poorest student ( or old UNIX hacker ) on an > equal footing with everyone else and everyone in the project > can get them at no cost. I am open to alternatives, especially > to TeX as it requires quite an investment of time but produces > beautiful results. I won't ask anyone to learn troff, groff and > the like, but I think we shuold use OSS tools Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc