Hi, Poul,
I've the datasheet for the uPD7210 in my 1983/84 Nec Microcomputers
Handbook. If you need it, I can scan it for you.
Regards,
Javier
Poul-Henning Kamp wrote:
Are you 100% sure this is a problem on the 5370B ?
I've spent a lot of time with my logic analyzer while implementing
GPI
In message <[EMAIL PROTECTED]>, Takayuki Hosoda writes:
>How do you do. I'm new to time-nuts.
>
>How about take a look on National Instruments'
>NAT7210 Reference manual which is upward
>compatible to NEC uPD7210.
Yes, I have that already, but since I have the orginal uPD7210
chip, that helps me l
How do you do. I'm new to time-nuts.
How about take a look on National Instruments'
NAT7210 Reference manual which is upward
compatible to NEC uPD7210.
http://www.ni.com/support/gpib/reg_prog.htm
http://digital.ni.com/manuals.nsf/websearch/36E3DF121E92D54E86256DB10046D7DB?OpenDocument&node=1270_U
Poul-Henning Kamp wrote:
>In message <[EMAIL PROTECTED]>, Magnus Danielson write
>s:
>
>
>
>>I think I have the uPD7210 datasheet lying around here if you still need it,
>>even for verification.
>>
>>
>
>I would love to. I haven't been able to track one down and ended up
>using a summary co
Poul-Henning Kamp wrote:
>In message <[EMAIL PROTECTED]>, John Ackermann N8UR writes:
>
>
>
>>In theory, the bus is supposed
>>to handshake to avoid that problem, but that's not always reliable on
>>the older instruments -- they will report that they're ready for another
>>command when in fact t
In message <[EMAIL PROTECTED]>, Magnus Danielson write
s:
>I think I have the uPD7210 datasheet lying around here if you still need it,
>even for verification.
I would love to. I haven't been able to track one down and ended up
using a summary condensed into a HP-IB VME card product manual :-(
From: "Poul-Henning Kamp" <[EMAIL PROTECTED]>
Subject: Re: [time-nuts] Off the wall: anyone with experience
programmingHP3456A?
Date: Sat, 10 Sep 2005 20:24:25 +0200
Message-ID: <[EMAIL PROTECTED]>
> In message <[EMAIL PROTECTED]>, John Ackermann N8UR writ
In message <[EMAIL PROTECTED]>, John Ackermann N8UR writes:
>In theory, the bus is supposed
>to handshake to avoid that problem, but that's not always reliable on
>the older instruments -- they will report that they're ready for another
>command when in fact they aren't. In fact, while doing this
John Miles wrote:
>Interesting; I hadn't run across that. The examples in the manuals commonly
>show multiple commands in a single string; maybe the old-school BASIC
>controllers were smart enough to pause briefly after transmitting semicolons
>or string terminators...?
>
>-- john, KE5FX
>
>
Yo
Hi John:
The problem is caused by modern computers being much faster than the
ones available in the late 1970s. With the older computers, after
sending a command the instrument had plenty of time to make a
measurement and format the response.
With today's fast computers if you send a comman
> By the way -- your wait_for_SRQ routine is a bit different than mine in
> that you're testing for 0x800 while I'm calling the board (not the
> device) with the iblines command and looking at 0x2000 to test bit 14,
> the "busSRQ" signal. I'm using the linux-gpib package, which in theory
> mimics
Tom Van Baak wrote:
>>SRQ is definitely a pain, but is hard to do without if you're doing
>>anything with multiple instruments on the bus; my current problem is
>>trying to read frequency from a 5370A and voltage from the 3456A to plot
>>VCO performance. Without the SRQ, I'm getting missing voltme
> SRQ is definitely a pain, but is hard to do without if you're doing
> anything with multiple instruments on the bus; my current problem is
> trying to read frequency from a 5370A and voltage from the 3456A to plot
> VCO performance. Without the SRQ, I'm getting missing voltmeter readings.
Does
13 matches
Mail list logo
