From owner-freebsd-hardware Sun Apr 14 10:09:17 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA00895 for hardware-outgoing; Sun, 14 Apr 1996 10:09:17 -0700 (PDT) Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id KAA00890 for ; Sun, 14 Apr 1996 10:09:15 -0700 (PDT) Received: from uucp2.UU.NET by relay5.UU.NET with SMTP id QQalku14706; Sun, 14 Apr 1996 13:09:23 -0400 (EDT) Received: from uanet.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Sun, 14 Apr 1996 13:09:15 -0400 Received: by crocodil.monolit.kiev.ua; Sun, 14 Apr 96 20:06:17 +0300 Received: from localhost (dk@localhost) by clipper.cs.kiev.ua (8.6.4) id TAA08085 for freebsd-hardware@freebsd.org; Sun, 14 Apr 1996 19:47:41 +0300 From: dk@clipper.cs.kiev.ua (Dmitry Kohmanyuk) Message-Id: <199604141647.TAA08085@clipper.cs.kiev.ua> Subject: building parallel interface gadget - advice wanted To: freebsd-hardware@freebsd.org Date: Sun, 14 Apr 1996 19:47:41 +0300 (EET DST) X-Motto: Do not believe in miracles - rely on them. Reply-To: dk+@ua.net X-Mailer: ELM [version 2.4 PL22 dk9] Content-Type: text Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk hi gang, I am building (together with a electronics engineer) a device which, when attached to parallel potr, would perform some useful functions for my FreeBSD machines and maybe other devices connected to it. I have thoroughly read all the specs I have get a hold of and an entire lpt.c / lptreg.h in FreeBSD kernel. My only question is: from my understanding, for the data byte t obe output into the (real) printer, it is necessary to assert select, !initialize and strobe bits of control register and then lower the signal on the strobe pin, leaving select and !initialize high. Can it be possible that the same situation unwantedly occurs during system reset (power-on, reset by switch, software-executed reboot, etc.)? We try to follow printer's interface in using the potr to enable general-purpose hardware drivers to operate the device. I therefore want to make sure that by no circumstances a random data would be mistakenly read and accepted, causing unexpected behaviour of the device. thank anyone for reading this. p.s. if you are curious about the device itself, it would implement watchdog timers, power switches, etc. And I am not a company ;-) (we would make only one, or two for ourselves.)