Hal,

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
      begin;
        Debugform.Console.WriteString('Port has been opened'+#13+#10);
        Qccom32.Flush;
        sendstring:='++auto 0'+#13+#10;
        sendflag:=true;
        autoenabled:=False;
        repeat
          sleep(10);
          application.ProcessMessages;
        until sendflag=false;
        debugform.Console.WriteString('Send ++auto 0 command'+#13+#10);
        sendstring:='++ver'+#13+#10;
        sendflag:=true;
        repeat
          sleep(10);
          application.ProcessMessages;
        until sendflag=false;
        debugform.Console.WriteString('Send ++ver command'+#13+#10);
        j:=0;
        repeat
          inc(j);
          sleep(100);
        until dataavailable or (j>=10);
        if dataavailable then
        begin;
          PLfound:=(pos('GPIB-USB',Valuebuffer)<>0);
          DataAvailable:=False;
        end;

Best regards
Ulrich Bangert

> -----Ursprüngliche Nachricht-----
> Von: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] 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 
> conjunction 
> > 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 
> obvious.)
> 
> 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@febo.com 
> https://www.febo.com/cgi-> bin/mailman/listinfo/time-nuts
> 


_______________________________________________
time-nuts mailing list
time-nuts@febo.com
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts

Reply via email to