Re: [Emc-developers] quirk in PCIe parallel port cards "defined"

2017-02-27 Thread dragon 
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."

On 02/27/2017 10:52 AM, Jon Elson wrote:
> On 02/27/2017 09:42 AM, John Kasunich wrote:
>>
>> On Sun, Feb 26, 2017, at 03:51 PM, Jon Elson wrote:
>>> 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.
>> 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.
>> 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
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
> 



signature.asc
Description: OpenPGP digital signature
--
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

Re: [Emc-developers] quirk in PCIe parallel port cards "defined"

2017-02-27 Thread Jon Elson 
On 02/27/2017 09:42 AM, John Kasunich wrote:
>
> On Sun, Feb 26, 2017, at 03:51 PM, Jon Elson wrote:
>> 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.
> 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.
> 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
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] quirk in PCIe parallel port cards "defined"

2017-02-27 Thread John Kasunich 


On Sun, Feb 26, 2017, at 03:51 PM, Jon Elson wrote:
> 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
  jmkasun...@fastmail.fm

--
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

Re: [Emc-developers] quirk in PCIe parallel port cards "defined"

2017-02-26 Thread Jon Elson 
On 02/26/2017 02:32 PM, Gene Heskett wrote:
> 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

--
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

Re: [Emc-developers] quirk in PCIe parallel port cards "defined"

2017-02-26 Thread Jon Elson 
On 02/26/2017 01:27 PM, dragon wrote:
> 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.
> 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.
>
> 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.
>   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

--
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

Re: [Emc-developers] quirk in PCIe parallel port cards "defined"

2017-02-26 Thread Gene Heskett 
On Sunday 26 February 2017 12:37:02 Jon Elson wrote:

> On 02/25/2017 01:29 PM, Jon Elson wrote:
> > 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

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 

--
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

Re: [Emc-developers] quirk in PCIe parallel port cards "defined"

2017-02-26 Thread 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. 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.


On 02/26/2017 11:37 AM, Jon Elson wrote:
> On 02/25/2017 01:29 PM, Jon Elson wrote:
>> 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
> 
> --
> 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
> 



signature.asc
Description: OpenPGP digital signature
--
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

Re: [Emc-developers] quirk in PCIe parallel port cards "defined"

2017-02-26 Thread Jon Elson 
On 02/25/2017 01:29 PM, Jon Elson wrote:
> 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

--
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

Re: [Emc-developers] quirk in PCIe parallel port cards "defined"

2017-02-26 Thread Jon Elson 
On 02/25/2017 01:29 PM, Jon Elson wrote:
> 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

--
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

Re: [Emc-developers] quirk in PCIe parallel port cards "defined"

2017-02-25 Thread Gene Heskett 
On Saturday 25 February 2017 15:10:33 Jon Elson wrote:

> On 02/25/2017 01:57 PM, Gene Heskett wrote:
> > 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 

--
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

Re: [Emc-developers] quirk in PCIe parallel port cards "defined"

2017-02-25 Thread Jon Elson 
On 02/25/2017 01:57 PM, Gene Heskett wrote:
> 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

--
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

Re: [Emc-developers] quirk in PCIe parallel port cards "defined"

2017-02-25 Thread Gene Heskett 
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 

--
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