Discussion:
quirk in PCIe parallel port cards "defined"
(too old to reply)
Jon Elson
2017-02-25 19:29:54 UTC
Permalink
Raw Message
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
Gene Heskett
2017-02-25 19:57:00 UTC
Permalink
Raw Message
Post by Jon Elson
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.
Post by Jon Elson
----------------------------------------------------------------------
-------- 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
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>
Jon Elson
2017-02-25 20:10:33 UTC
Permalink
Raw Message
Post by Gene Heskett
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.
That's the beautiful way to do it, but how do you tell which
to do? The only scheme I can come up with is try to
communicate with a board on all 16 addresses over the
parallel port, if no board seems to respond, then try again
with the setting flipped the other way.

Jon
Gene Heskett
2017-02-25 21:01:54 UTC
Permalink
Raw Message
Post by Jon Elson
Post by Gene Heskett
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.
That's the beautiful way to do it, but how do you tell which
to do? The only scheme I can come up with is try to
communicate with a board on all 16 addresses over the
parallel port, if no board seems to respond, then try again
with the setting flipped the other way.
Jon
Ouch. OTOH it only needs to be dome at init time, with the success
recorded in that $configname.var file. At runtime, checking that bit in
memory is, or should be few enough machine cycles that in the longger
view of running a job, is a shrug.

That said Jon, you know chapters and verses about parport hardware that
I'll never know.

All I can now recall was that when I ran into it, probably at least 10
years back up the log, I had to go find a card that did work, and it
worked till I shut it off to replace it with an ARK shoebox that had a
DM525W mobo in it, and the same HD was moved into it and loaded and ran
on that without any excitement. I think the install has been updated to
wheezy since then, and I don't recall any real excitement, other than
udev changing all the net device names, which I have since restored.

That all translates to you having the final say-so, and I'm just one of
those (in)famous frog's, throwing out ideas to see if they'll stick. And
I won't complain if none of my ideas work. :)

What I do know is that putting the problem out there has led to me
solving my own typo's a lot faster than sitting and staring at pages of
code. So this list rarely sees my poorer efforts in broad daylight. :)

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>
Jon Elson
2017-02-26 17:37:02 UTC
Permalink
Raw Message
Post by Jon Elson
Over the years, it has been seen that certain parallel port
chips did not work properly with my hal_ppmc driver.
Hmmm, I was hoping to get more discussion of this. It
concerns a MAJOR overhaul of my hal_ppmc driver.

I can see 3 ways to deal with the problem:

1. Make it automatic, it tries with the "manual" port
direction change off, if no boards can be sensed, turn the
direction change on, and try again.

2. Make it a command line option.

3. Make two versions, hal_ppmc and hal_ppmc_old. Chack
after a year and see if anyone is actually using
hal_ppmc_old, and if not, remove it from LinuxCNC.

I kind of like option 3, as it will have a lot cleaner code,
and also, if it turns out to be a big mistake, we just
remove the new version instead.

One additional concern would be the multi-port option of
hal_ppmc. As far as I know, NO ONE has EVER used this
feature, but it does allow you to have up to 3 parallel
ports in use on the same system. How do you handle it if one
requires the manual direction change, and one doesn't? Ugh,
I really don't want to spend days hacking on code that will
never be used.

Sorry my original message was so long, I wanted to set the
stage for the question.

Any comments?

Thanks,

Jon
dragon
2017-02-26 19:27:41 UTC
Permalink
Raw Message
Jon,

Coming from more of a user integrator person here...
I think that I am with you on liking option 3 the best with number 2
next in line. I would even go so far as marking the 'old' driver as
deprecated and slated for removal on the next release. That warns
everyone that if they want to run the next release they need to get with
the game or they will have to be content with this being the last
release that supports their hardware. I don't like option number 1. It
just begs for a high number of bugs to be introduced that could effect
both camps of users.

My big questions...
- Do we know when this changed occurred to actual products in the
marketplace?

- Are there still cards being sold that ONLY conform to the old behavior
of needing the direction changed?

In your first email you asked, "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?" My response is that even if they could
run a current LCNC release on them, if they are 15 years old anyway
perhaps the question should not be if they could, but if they should.

I also see this as making a large number of cards available for use. I
hate having to dig for a source of one specific item that may not even
still be in production. If I have a card die in an old system, I would
much rather be able to look for one of many options to replace it in
exchange for being stuck on an older software release so I can keep
using my antiquated hardware.

I am of the opinion that if legacy machines are working... leave them
alone! If it makes parts reliably everyday, why do you want to be
messing with newer versions of LCNC. If a parport card dies on a 15 year
old system, you should probably look at upgrading the whole computer as
other items might not be far behind. In that case, move up to a newer
version of LCNC while you are at it.

Significantly increasing your development workload just so that a
relatively few users can run ancient hardware in combination with a new
release is not worth it in my opinion. Having an expectation that users
upgrade their hardware once a decade in order to be able to run the
latest software release is perfectly acceptable. Heck, 5 years should be
acceptable. If you wanted to run the latest software (not to be confused
with maintaining your current software) from any of the proprietary
control system companies on 15 year old hardware they would laugh at you.

Just my thoughts.
Post by Jon Elson
Post by Jon Elson
Over the years, it has been seen that certain parallel port
chips did not work properly with my hal_ppmc driver.
Hmmm, I was hoping to get more discussion of this. It
concerns a MAJOR overhaul of my hal_ppmc driver.
1. Make it automatic, it tries with the "manual" port
direction change off, if no boards can be sensed, turn the
direction change on, and try again.
2. Make it a command line option.
3. Make two versions, hal_ppmc and hal_ppmc_old. Chack
after a year and see if anyone is actually using
hal_ppmc_old, and if not, remove it from LinuxCNC.
I kind of like option 3, as it will have a lot cleaner code,
and also, if it turns out to be a big mistake, we just
remove the new version instead.
One additional concern would be the multi-port option of
hal_ppmc. As far as I know, NO ONE has EVER used this
feature, but it does allow you to have up to 3 parallel
ports in use on the same system. How do you handle it if one
requires the manual direction change, and one doesn't? Ugh,
I really don't want to spend days hacking on code that will
never be used.
Sorry my original message was so long, I wanted to set the
stage for the question.
Any comments?
Thanks,
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
https://lists.sourceforge.net/lists/listinfo/emc-developers
Jon Elson
2017-02-26 20:51:31 UTC
Permalink
Raw Message
Post by dragon
Jon,
Coming from more of a user integrator person here...
I think that I am with you on liking option 3 the best with number 2
next in line. I would even go so far as marking the 'old' driver as
deprecated and slated for removal on the next release. That warns
everyone that if they want to run the next release they need to get with
the game or they will have to be content with this being the last
release that supports their hardware. I don't like option number 1.
Actually, I thought option 1 was the "best", but required a
bit more code and more testing.
Since I've discovered the offending line occurs in ONE and
only one place in the whole driver (I think),
then conditional compilation of one copy of the source seems
like a workable solution.
Post by dragon
My big questions...
- Do we know when this changed occurred to actual products in the
marketplace?
NO! That's what makes this decision a bit hard. I know
some old ISA-bus multi-IO chips needed this, in the DISTANT
past. I started this project in 2001, to give you some
context! And, once it worked, I have no idea when it might
have no longer been needed! And, even WORSE, I have no idea
if any CURRENT parport chips still require this. I did
check that none of the ones HERE do, but that is not conclusive.
Post by dragon
I also see this as making a large number of cards available for use. I
hate having to dig for a source of one specific item that may not even
still be in production.
Yes, indeed! I was at the point of having a SOLE SOURCE of
PCIe chip that worked! That was NOT a good feeling.
Post by dragon
If I have a card die in an old system, I would
much rather be able to look for one of many options to replace it in
exchange for being stuck on an older software release so I can keep
using my antiquated hardware.
I am of the opinion that if legacy machines are working... leave them
alone! If it makes parts reliably everyday, why do you want to be
messing with newer versions of LCNC.
Yes, but there are great improvements in GUIs, trajectory
planners, and such that could make life easier.
But, a major update, as from 2.4 to 2.7 will almost
certainly require updating the PC hardware.

Jon
John Kasunich
2017-02-27 15:42:54 UTC
Permalink
Raw Message
Post by Jon Elson
Actually, I thought option 1 was the "best", but required a
bit more code and more testing.
Since I've discovered the offending line occurs in ONE and
only one place in the whole driver (I think),
then conditional compilation of one copy of the source seems
like a workable solution.
Option 1 seems complex, and you really don't want to be twiddling parport bits on every LinuxCNC startup, who knows what is connected to those bits.

I prefer option 2. If there are tweaks needed to help the driver adapt to the hardware, the logical thing to do is to tell the driver about those tweaks at load time.

I'm not a big fan of option 3, but I suppose it works. But imagine if you later find another idiosyncrasy that requires the driver to do some other thing differently? Do you make "hal_ppmc", and "hal_ppmc_old" and "hal_ppmc_not_so_old"?

Better to have command line args with meaningful names like "change_dir=1" for the old behavior, and "change_dir=0" for the new behavior. The default should be the old behavior, and the manual page should say to try the alternate if the default doesn't work.
--
John Kasunich
***@fastmail.fm
Jon Elson
2017-02-27 16:52:28 UTC
Permalink
Raw Message
Post by John Kasunich
Post by Jon Elson
Actually, I thought option 1 was the "best", but required a
bit more code and more testing.
Since I've discovered the offending line occurs in ONE and
only one place in the whole driver (I think),
then conditional compilation of one copy of the source seems
like a workable solution.
Option 1 seems complex, and you really don't want to be twiddling parport bits on every LinuxCNC startup, who knows what is connected to those bits.
Well, the driver certainly twiddles some bits as it scans
the bus to see what PPMC devices are out there. If you
don't have one of the Pico Systems boards attached, you'd
have no reason to invoke the ppmc driver. I'm not
contemplating touching the generic parport driver, only
hal_ppmc.
Post by John Kasunich
I prefer option 2. If there are tweaks needed to help the driver adapt to the hardware, the logical thing to do is to tell the driver about those tweaks at load time.
Yes, this may actually be easier, as it doesn't require
major mucking around in the Makefiles to produce two
versions of hal_ppmc. I'm now leaning more toward this. I
think I will make the default setting to be the "new way",
so existing configs won't have to be changed to use it.
Post by John Kasunich
I'm not a big fan of option 3, but I suppose it works. But imagine if you later find another idiosyncrasy that requires the driver to do some other thing differently? Do you make "hal_ppmc", and "hal_ppmc_old" and "hal_ppmc_not_so_old"?
Better to have command line args with meaningful names like "change_dir=1" for the old behavior, and "change_dir=0" for the new behavior. The default should be the old behavior, and the manual page should say to try the alternate if the default doesn't work.
OK, I'll think about your parameter name, and unless I come
up with a better one, that will be it.
No, I don't want the default to be the old behavior, as that
has been PROVEN to break on at least a couple parport
chips. I am not, at present, able to find any parport chip
that fails with the new method. (Still digging in boxes for
some older PCI cards to try.)


Thanks much, John!

Jon
dragon
2017-02-27 17:00:33 UTC
Permalink
Raw Message
For what it's worth... I would second the notion that the new behavior
be the default. Much higher likelihood that it would "just work."
Post by Jon Elson
Post by John Kasunich
Post by Jon Elson
Actually, I thought option 1 was the "best", but required a
bit more code and more testing.
Since I've discovered the offending line occurs in ONE and
only one place in the whole driver (I think),
then conditional compilation of one copy of the source seems
like a workable solution.
Option 1 seems complex, and you really don't want to be twiddling parport bits on every LinuxCNC startup, who knows what is connected to those bits.
Well, the driver certainly twiddles some bits as it scans
the bus to see what PPMC devices are out there. If you
don't have one of the Pico Systems boards attached, you'd
have no reason to invoke the ppmc driver. I'm not
contemplating touching the generic parport driver, only
hal_ppmc.
Post by John Kasunich
I prefer option 2. If there are tweaks needed to help the driver adapt to the hardware, the logical thing to do is to tell the driver about those tweaks at load time.
Yes, this may actually be easier, as it doesn't require
major mucking around in the Makefiles to produce two
versions of hal_ppmc. I'm now leaning more toward this. I
think I will make the default setting to be the "new way",
so existing configs won't have to be changed to use it.
Post by John Kasunich
I'm not a big fan of option 3, but I suppose it works. But imagine if you later find another idiosyncrasy that requires the driver to do some other thing differently? Do you make "hal_ppmc", and "hal_ppmc_old" and "hal_ppmc_not_so_old"?
Better to have command line args with meaningful names like "change_dir=1" for the old behavior, and "change_dir=0" for the new behavior. The default should be the old behavior, and the manual page should say to try the alternate if the default doesn't work.
OK, I'll think about your parameter name, and unless I come
up with a better one, that will be it.
No, I don't want the default to be the old behavior, as that
has been PROVEN to break on at least a couple parport
chips. I am not, at present, able to find any parport chip
that fails with the new method. (Still digging in boxes for
some older PCI cards to try.)
Thanks much, John!
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
https://lists.sourceforge.net/lists/listinfo/emc-developers
Gene Heskett
2017-02-26 20:32:53 UTC
Permalink
Raw Message
Post by Jon Elson
Post by Jon Elson
Over the years, it has been seen that certain parallel port
chips did not work properly with my hal_ppmc driver.
Hmmm, I was hoping to get more discussion of this. It
concerns a MAJOR overhaul of my hal_ppmc driver.
1. Make it automatic, it tries with the "manual" port
direction change off, if no boards can be sensed, turn the
direction change on, and try again.
2. Make it a command line option.
3. Make two versions, hal_ppmc and hal_ppmc_old. Chack
after a year and see if anyone is actually using
hal_ppmc_old, and if not, remove it from LinuxCNC.
I kind of like option 3, as it will have a lot cleaner code,
and also, if it turns out to be a big mistake, we just
remove the new version instead.
One additional concern would be the multi-port option of
hal_ppmc. As far as I know, NO ONE has EVER used this
feature, but it does allow you to have up to 3 parallel
ports in use on the same system. How do you handle it if one
requires the manual direction change, and one doesn't? Ugh,
I really don't want to spend days hacking on code that will
never be used.
Sorry my original message was so long, I wanted to set the
stage for the question.
Any comments?
Thanks,
Jon
Parport cards aren't THAT expensive if someone gets caught out by option
3. And if that warning that the old one will be expunged on such and
such a date, is right in the manpage for it, and at that point it gets
renamed to -old, the only fix would be in the users halfiles loadrt
line. So the problem is a bit vaporous if they can do the edit needed.

Option 3 has it covered IMO Jon.

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>
Jon Elson
2017-02-26 20:57:31 UTC
Permalink
Raw Message
Post by Gene Heskett
Parport cards aren't THAT expensive if someone gets caught
out by option 3. And if that warning that the old one will
be expunged on such and such a date, is right in the
manpage for it, and at that point it gets renamed to -old,
the only fix would be in the users halfiles loadrt line.
So the problem is a bit vaporous if they can do the edit
needed. Option 3 has it covered IMO Jon.
I was hoping that some of the main developers would chime in
with a "smell test" on our logic. Yes, option 3 is great,
as the changes to the code are TINY. To get it to compile
two versions with a #define requires some hacking on the
make system, which is always a big hassle. I think I'm
going to need some help with that, as I seem to recall there
has been a bit of reorganization of the whole make system
since I last added a module, which has been a LONG time.

Thanks,

Jon
Jon Elson
2017-02-26 17:49:02 UTC
Permalink
Raw Message
Post by Jon Elson
Over the years, it has been seen that certain parallel port
chips did not work properly with my hal_ppmc driver.
And, another question :

I have a development system that was built at Tx/Rx Labs in
Houston with help from Jeff Epler.
It uses the :

3.2.0-4-rt-686-pae #1 SMP PREEMPT RT Debian 3.2.82-1 i686

kernel, but the LinuxCNC version is a BIT dated. Is this
kernel OK to pull and build a source
git repo for updating this driver? I know there have been a
LOT of changes in LinuxCNC since
I had this local repo current.

Thanks,

Jon
Loading...