On Saturday 25 February 2017 14:29:54 Jon Elson wrote: > Over the years, it has been seen that certain parallel port > chips did not work properly with my hal_ppmc driver. > Some of these chips were just admittedly broken in EPP > mode. It all seemed to settle down by 2010 or so, and I > thought the bad chips were a thing of the past. I > recommended SIIG PCI cards with Oxford chips, and all was > good. Then, I found that, to my horror, SIIG PCIe cards did > not work! That was a confusing nightmare, to tell people to > get SIIG PCI cards, but avoid their PCIe cards. I did > identify ***ONE*** PCIe chip that worked. Not good to be > sole-source. > > Kumar Bhatia of Axxon in Canada had communicated with me a > long time ago about making their own industrial-grade > parport cards. He apparently is also involved in qualifying > other cards for industrial use and is very up on EPP mode. > I sent him a text description of the sequence of inb/outb > commands that my driver used, and what (incorrect) behavior > the EPP card gave. He noticed that all the newer chips do > NOT require the program to switch the parport bus direction, > the read or write request to the PCI register does it > automatically. Well, I tried this on my diagnostic, and it > WORKS! > So, at least on the Siig card with the OXPCIe952 chip, this > switching of the direction in the control register actually > BREAKS the EPP read operation. I have one other PCIe card > and some PCI cards that are known to not work, I will test > the rest of those this weekend to see if the same > interference is the cause. > > Now, in the long distant past of ISA-bus multi-IO chips and > maybe some early PCI parport chips, the program DID have to > change the bus direction bit in the control register when > switching between read and write operations on the EPP bus. > So, my hal_ppmc driver does this, and it works on a number > of PCI chips, both of the on-motherboard and plug-in card > type. It also works fine on MCS9900 and MCS9901 chips. > > So, now, the quandary is what to do with the hal_ppmc > driver? If I take this command out of the driver, it will > only affect new versions. Are all the parport chips that > NEED the "manual" direction changing so far back in history > that nobody could ever run a current LinuxCNC on those > motherboards and parport cards? > > Any comments will be very welcome! > > Jon
I'd have an urge to, at init time, test the hdwe it finds, and set a flag to hit or skip that instruction sequence at runtime. Then the nagging question remains, did the testing leave it in a non-functional state? In that event I'd save a state flag in $configname.var and ask the user to do a cold reboot to re-enable the hardware, and if the bit is set in the *.var file on the restart, set the skip it bit (a different bit) and never touch it again. This could wind up with some odd pranks in your code, similar to the knots we've had to tie in the flow control code (and wiring up of pins) around an SY6551 UART/ACIA to make it work with a true 7wire protocol. That was a Pain in the ass as many of the users didn't know which end of a soldering iron gets hot, so make it as bulletproof OOTB as you can, Jon. > ---------------------------------------------------------------------- >-------- Check out the vibrant tech community on one of the world's > most engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
