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

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

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