On Wed, Oct 17, 2012 at 11:31 PM, Juan Pablo Carbajal <ajuanpi+...@gmail.com
> wrote:

> Hello,
>
> I am observing weird behaviors and I couldn't pin down at which level
> things are going bad. Using instrument-control 0.1.0 from Forge.
> Running Ubuntu 12.04 64 bit
> Linux 3.2.0-32-generic #51-Ubuntu SMP Wed Sep 26 21:33:09 UTC 2012
> x86_64 x86_64 x86_64 GNU/Linux
>
> I am using serial communications. I am testing with a physical
> loopback (RxD connected to TxD) in this USB2Serial adapter
> https://www.sparkfun.com/products/718.
>
> Problem 1 [Ring bufffer?]:
>   s = serial (); # 8-N-1
>   srl_baudrate (s,9600);
>
>   srl_write(s,"hello")
>   ans = 5
>
>   char(srl_read (s,5))
>   ans = hello
>
>   char(srl_read (s,5))
>   ans = hello
>
>   char(srl_read (s,15))
>   ans = hellohellohello
>
>   char(srl_read (s,4))
>   ans = hell
>
>   char(srl_read (s,6))
>   ans = ohello
>
> It looks like as if the buffer is a ring buffer or is really big and
> filled with "hello". Maybe flushing the input after reading will solve
> the problem? Continued from the example before I got this
>
> Problem 2 [Hang after flush]:
>   srl_flush (s, 1)
>
>   char(srl_read (s,5)) # This blocks as expected but ...
>   srl_read: Interrupting...
>   ans =
>
>   srl_write(s,"hello")
>   ans =  5
>
>   char(srl_read (s,5)) # This also blocks!!!!
>   srl_read: Interrupting...
>   ans =
>
> The only way of getting things to work from this point on is to close
> the port and open it again.
>
> Can anybody reproduce this? any suggestions of tests to run to see
> whether the problem is at hardware level?
>
> I also tested with a virtual loopback (command "socat -d -d PTY:
> PTY:", this is simpler than the suggestion in the wiki. I can update
> that), I do not observe Problem 1, but I can't interrupt the second
> call to srl_read
>
> s = serial("/dev/ptmx", 9600);
> srl_write(s,"hello")
> ans =  5
> char(srl_read (s,5))
> ans = hello
> octave:5> char(srl_read (s,5))
> srl_read: Interrupting...
> srl_read: Interrupting...
> srl_read: Interrupting...
> srl_read: Interrupting...
>
>
> Thanks
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> Octave-dev mailing list
> Octave-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>


Hello,

thanks for testing the package! :-)

Unfortunately I was unable to replicate Problem 1 nor Problem 2 on:
Arch linux 3.6.2; Octave 3.6.2 (nice version match)
Adapters: plftdi_sio: v1.6.0; pl2303

see: http://pastebin.com/03X4tzLn

I noticed you are opening /dev/ptmx, it should not be used in such way,
see: http://linux.die.net/man/4/ptmx (notice: grantpt and unlockpt). The
srl_read does indeed block infinitely in such case as behavior is
undefined, but I will rewrite read routines to use "select()" in the
future, which would terminate even in such conditions.

Could you re-test using current development version in SVN? I would suggest
using srl_flush(s) instead of flushing input only.

Also, please do not update the wiki, as the command above is deprecated for
socat  >=1.7 versions, whereas command in wiki works with current and
previous versions.

Another interesting thing I noticed, on ftdi website (
http://www.ftdichip.com/Drivers/VCP.htm ) the newest given version is v1.5,
whereas we both have versions v1.6. Could this be related to
distribution/kernel specific forks of the driver? Any ideas?
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Octave-dev mailing list
Octave-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/octave-dev

Reply via email to