[time-nuts] Linux code for Prologix GPIB/USB
df6jb at ulrich-bangert.de
Tue Feb 27 11:14:46 EST 2007
no matter whether you use my stuff or not: The very first thing you
should do after opening the serial port is to transmit a ++auto 0 to
hinder the interface from sending something own its own. My own internal
stuff reads as follows:
if QCCom32.Opened then
Debugform.Console.WriteString('Port has been opened'+#13+#10);
debugform.Console.WriteString('Send ++auto 0 command'+#13+#10);
debugform.Console.WriteString('Send ++ver command'+#13+#10);
until dataavailable or (j>=10);
if dataavailable then
> -----Ursprüngliche Nachricht-----
> Von: time-nuts-bounces at febo.com
> [mailto:time-nuts-bounces at febo.com] Im Auftrag von Hal Murray
> Gesendet: Dienstag, 27. Februar 2007 04:32
> An: Discussion of precise time and frequency measurement
> Betreff: Re: [time-nuts] Linux code for Prologix GPIB/USB
> > At the end of the USB cable there is a FTDI chip that (in
> > with the appropiate driver) emulates a serial port. This
> serial port
> > in turn is connected to the serial port of an AVR type of
> > microcontroller. Because this microcontroller expects a certain
> > setting of serial transmission parameters you have to set them
> > correct, otherwise it will not understand your commands.
> Thanks. Makes sense, I guess. I was assuming they had
> reprogrammed the FTDI
> chip rather than adding another CPU. (I'm not sure why. The
> AVR is pretty
> There is a layer of stuff I haven't sorted out yet. It's all
> tangled up in
> the GPIB device being at the far end of a serial (USB or
> RS-232) string. The
> Prologix defaults to automagiclly reading data when it
> becomes available and
> sending it up to the kernel rather than waiting for you to
> explicitly poll it.
> I see two cases where that might get confusing. One is when
> you send it a
> command at about the time it sends you something. You can't
> tell if the data
> you get arrived before or after your command.
> My normal command sequence is running in single cycle mode so
> it's easy to
> stay in lock step once you get started. So far, I haven't
> had any troubles
> getting through initialization, but I'll bet my code would
> screwup if it got
> delayed for long enough in the right places.
> The other case is if you are talking to several devices.
> Again, there is a
> race as you switch devices. You can't tell if the string
> arrived before or
> after you switched. I think this case can be avoided by
> switching to a
> device that doesn't exist, checking for input, then switching
> to the new
> device. It probably requires some pauses in the right place.
> > I have only very limited Linux experience and even less
> with Windows
> > emulation under Linux.
> You probably know more about Linux than I do about Windows.
> I was just looking for a subroutine package rather than a GUI/IDE.
> These are my opinions, not necessarily my employer's. I hate spam.
> time-nuts mailing list
> time-nuts at febo.com
> https://www.febo.com/cgi-> bin/mailman/listinfo/time-nuts
More information about the time-nuts