Re: [Linux-gpib-general] hpdrive changes: dac holdoff

[Ansgar K. <an...@hp...>]

Hi Dave,

this is fine from my side. Even in case we still can't take changes over 
into the main stream, patching new releases for the use with HPDrive 
will become way easier if most others changes are included.

-Ansgar

On 2021-05-07 14:24, dave penkler wrote:
> HI Frank and Ansgar,
> It would be great to get hpdrive working with the stock package,
> especially for users who could then benefit from this functionality
> via the distro's that ship linux-gpib.
> We certainly don't want to break anything so I am all for working
> through the issues one by one until we get down to a minimal set of
> absolutely necessary hpdrive conflicts with the current (standard)
> behaviour.
> Then we can try to find a good way to package them to avoid affecting
> existing applications. If you agree, may I suggest we start with the
> tnt4882 driver with which I can test both my t&m and hpdrive use
> cases.
> 
> -Dave
> 
> On Thu, 6 May 2021 at 08:29, Ansgar Kueckes <an...@hp...> wrote:
> 
>> Frank,
>> 
>> thanks for the open words.
>> 
>> For me it looks like linux-gpib is mostly designed after NI's ni488
>> API,
>> which is proven for most GPIB applications and probably covers 99.9%
>> of
>> all use cases. Which is mostly data exchange with measuring
>> equipment.
>> That approach seems to be quite desirable, also because porting
>> existing
>> application code to Linux is pretty easy to achieve, since ni488
>> represents some kind of industry standard and has been adopted by a
>> large number of other chip vendors. My own tools all work out of the
>> box
>> with linux-gpib, HPDrive is the single exception. So the cool thing
>> with
>> linux-gpib is that all that is available for Linux, too. Which opens
>> up
>> a new world for open applications. I understand this is the main
>> outcome
>> of your great work.
>> 
>> HPDrive and the other HP tools step into another history of GPIB,
>> that
>> of HP, the inventor of the GPIB. They go a bit deeper into what HP
>> itself achieved with HP-IB, but the challenges are similar,
>> implementing
>> the diverse mechanisms with as many chip designs as possible. I
>> think
>> the general question is, stay at ni488 level, or go beyond and
>> implement
>> the full IEEE standard, or even support special chip features. I
>> cannot
>> answer that question, this is the primary task of the maintainers,
>> who
>> define the scope of the project. There are different approaches, CEC
>> for
>> instance simply added a general register access function in their
>> (ni488
>> based) API. HPDrive uses that function to add the functionality
>> which is
>> not provided by ni488 and works fine. But I am not sure whether this
>> is
>> the way to go for security reasons.
>> 
>> I see your concerns (1) to (3) and I fully agree. I'd suggest to go
>> with
>> you and Dave through those points where existing code will be
>> affected,
>> and see whether there is a good way for a standard behavior which
>> fits
>> all use cases. In no way should existing applications be affected.
>> If
>> that is not possible, we may think about a fork or leave it as it is
>> 
>> (create patches for new releases). Although the use of GPIB is still
>> 
>> quite spread, I feel we more and more also have to take into account
>> the
>> historic relevance of HP-IB and GPIB. And think about adding the
>> historic computing to the uses cases of linux-gpib, not just limited
>> to
>> data exchange with vintage measuring & control equipment. And there
>> is
>> growing base for this. The story would not be complete without what
>> HP's
>> engineering  did with HP-IB/GPIB during the 70s and 80s.
>> 
>> HPDrive in fact is one of the key enabler for everyone who is
>> dealing
>> with vintage HP systems. Without it you would be restricted to the
>> real
>> mass storage hardware, which is going to fade away. For me
>> linux-gpib is
>> a true gift, because most HPDrive users are on Windows and I have a
>> personal interest for changing this or at least offering an
>> alternative.
>> And of course it would be comfortable not to have to step through
>> all
>> changes coming with every new linux-gpib release and do all the
>> testing,
>> but it is a quite normal procedure. Whether refactoring is affecting
>> the
>> extensions, is probably mainly a matter of documentation.
>> 
>> -Ansgar
>> 
>>> Ok, and the dac holdoff requirement seems to come from AMIGO's
>> need to
>>> change the parallel poll response synchronously with reception of
>>> certain command bytes.
>>> 
>>> One of the more disturbing aspects of the hpdrive patches is they
>>> change the behavior of data read/writes on some of the boards,
>> such as
>>> the conditions under which they are interrupted and return early.
>>> There may or may not be good motivation for this, however:
>>> 1) know it WILL break people's existing code
>>> 2) there should be a clear and defensible rationale for the
>> change,
>>> and specification of exactly what the required behavior now is
>>> 3) if the behavior of data reads and writes is to be changed, it
>>> should be changed consistently for all boards
>>> 
>>> Whether the patches are merged is up to Dave, as I am not the
>> primary
>>> maintainer of linux-gpib any more.  However, I feel I should fully
>>> disclose what my position on all this is.  I don't particularly
>> care
>>> about HPDRIVE or AMIGO, etc.  The patches in their current state
>>> introduce finely-tuned behavior in scattered locations for no
>> clear
>>> reason other than they are apparently required to make hpdrive
>> work.
>>> That makes linux-gpib support for hpdrive likely to be broken by
>>> anyone refactoring the code, especially anyone who doesn't have a
>>> strong interest and knowledge of hpdrive and associate protocols,
>> such
>>> as myself.  There are parts of the patches which are just general
>>> improvements and could be cherry picked out, but if all the
>> patches
>>> are merged in anything like their current state, my response will
>> be
>>> to abandon main line linux-gpib completely, and just make a
>> minimally
>>> maintained pre-merge fork for use in my own work.  Maybe this is
>> fine
>>> though, as I haven't done much development on linux-gpib for a
>> long
>>> time, except when I needed to fix something for work.
>>> 
>>> On Wed, May 5, 2021 at 2:21 PM Ansgar Kueckes <an...@hp...>
>> wrote:
>>>> See the files attached.
>>>> 
>>>> The Identify command was some kind of extension to the HP-IB
>> standard.
>>>> HP realized that the HP-IB standard lacked a device
>> identification
>>>> mechanism (comparable to the PCI Device Id). So they implemented
>> a
>>>> special circuit in their HP-IB controllers which worked similar
>> to a
>>>> poll where the addressed device's controller replied with a
>> defined
>>>> two-byte ID. It works by sending an UNT followed by the primary
>> address
>>>> of the queried device as secondary address. However, the
>> mechanism never
>>>> became part of the IEEE standard and was implemented in HP's own
>> HP-IB
>>>> controller chips only.
>>>> 
>>>> The only other chip that can detect and handle the Identify is a
>> nec7210
>>>> by activating secondary addressing and using the UNT as TALK to
>> address
>>>> 31. Which normally is an invalid address, but the nec7210 is
>> implemented
>>>> entering talker state when being configured to 31 as second
>> primary
>>>> address when in dual extended addressing mode. Actually this is a
>> flaw
>>>> in the nec7210 design, but for the sake of compatibility all 7210
>>>> implementations also implement that special behavior.
>>>> 
>>>> -Ansgar
>>>> 
>>>>> Where can I find a description of the AMIGO or CS/80 protocols?
>> Some
>>>>> blurb I found sounded like the AMIGO identify command is UNT
>> followed
>>>>> by MTA, but then said it was implemented by setting the
>> secondary
>>>>> address of a nec7210 to UNT, which would suggest MTA followed by
>> UNT?
>>>>> Anyways I'd like a specific problematic protocol example.
>>>>> 
>>> 
>> 
>> _______________________________________________
>> Linux-gpib-general mailing list
>> Lin...@li...
>> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general