[instrument-control]

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[instrument-control]

Juan Pablo Carbajal-2
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/octave-dev
Reply | Threaded
Open this post in threaded view
|

Re: [instrument-control]

Juan Pablo Carbajal-2
On Thu, Oct 18, 2012 at 12:31 AM, Juan Pablo Carbajal
<[hidden email]> 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

Testing in Debian Squeeze 2.6.32-5-686 with the same hardware
configuration doesn't show Problem 1
Note that:

- Ubuntu 12.04 uses kernel 3.2.0 and the driver controlling the adapter is
ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver

- Debian Squeeze uses kernel 2.6.32 and
ftdi_sio: v1.5.0:USB FTDI Serial Converters Driver


In Debian the problem observed is the following (opening the port the
same as before)
> srl_write(s,uint8(127)); srl_read(s,1)
ans = 127
> srl_write(s,uint8(128)); srl_read(s,1)
ans = 0

Should it go up to 255?

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/octave-dev
Reply | Threaded
Open this post in threaded view
|

Re: [instrument-control]

Juan Pablo Carbajal-2
On Thu, Oct 18, 2012 at 9:14 AM, Juan Pablo Carbajal
<[hidden email]> wrote:

> On Thu, Oct 18, 2012 at 12:31 AM, Juan Pablo Carbajal
> <[hidden email]> 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
>
> Testing in Debian Squeeze 2.6.32-5-686 with the same hardware
> configuration doesn't show Problem 1
> Note that:
>
> - Ubuntu 12.04 uses kernel 3.2.0 and the driver controlling the adapter is
> ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver
>
> - Debian Squeeze uses kernel 2.6.32 and
> ftdi_sio: v1.5.0:USB FTDI Serial Converters Driver
>
>
> In Debian the problem observed is the following (opening the port the
> same as before)
>> srl_write(s,uint8(127)); srl_read(s,1)
> ans = 127
>> srl_write(s,uint8(128)); srl_read(s,1)
> ans = 0
>
> Should it go up to 255?

Additional update.

Checking the code of srl_write.cc and srl_read.cc I noticed that while
srl_write writes "unsigned char" srl_read reads "char". Is this
intentional?

Additionally there is a C style cast in srl_write line 63. I assume it
should be a static cast and therefore it should be

buf[i] = static_cast<unsigned char>(data(i));

Or is there a reason why to do it the C way?

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/octave-dev
Reply | Threaded
Open this post in threaded view
|

Re: [instrument-control]

Andrius Sutas
In reply to this post by Juan Pablo Carbajal-2


On Wed, Oct 17, 2012 at 11:31 PM, Juan Pablo Carbajal <[hidden email]> 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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/octave-dev
Reply | Threaded
Open this post in threaded view
|

Re: [instrument-control]

Andrius Sutas
In reply to this post by Juan Pablo Carbajal-2
On Thu, Oct 18, 2012 at 8:38 AM, Juan Pablo Carbajal <[hidden email]> wrote:
On Thu, Oct 18, 2012 at 9:14 AM, Juan Pablo Carbajal
<[hidden email]> wrote:
> On Thu, Oct 18, 2012 at 12:31 AM, Juan Pablo Carbajal
> <[hidden email]> 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
>
> Testing in Debian Squeeze 2.6.32-5-686 with the same hardware
> configuration doesn't show Problem 1
> Note that:
>
> - Ubuntu 12.04 uses kernel 3.2.0 and the driver controlling the adapter is
> ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver
>
> - Debian Squeeze uses kernel 2.6.32 and
> ftdi_sio: v1.5.0:USB FTDI Serial Converters Driver
>
>
> In Debian the problem observed is the following (opening the port the
> same as before)
>> srl_write(s,uint8(127)); srl_read(s,1)
> ans = 127
>> srl_write(s,uint8(128)); srl_read(s,1)
> ans = 0
>
> Should it go up to 255?

Additional update.

Checking the code of srl_write.cc and srl_read.cc I noticed that while
srl_write writes "unsigned char" srl_read reads "char". Is this
intentional?

Additionally there is a C style cast in srl_write line 63. I assume it
should be a static cast and therefore it should be

buf[i] = static_cast<unsigned char>(data(i));

Or is there a reason why to do it the C way?

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/octave-dev


Thanks for noting this.

Indeed you are right, fix pushed to the SVN.

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/octave-dev
Reply | Threaded
Open this post in threaded view
|

Re: [instrument-control]

Andrius Sutas
In reply to this post by Juan Pablo Carbajal-2
On Wed, Oct 17, 2012 at 11:31 PM, Juan Pablo Carbajal <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/octave-dev

UPDATE: I did replicate the bug eventually. I can not reproduce it consistently, will look further into this behavior.

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/octave-dev
Reply | Threaded
Open this post in threaded view
|

Re: [instrument-control]

Juan Pablo Carbajal-2
On Sat, Oct 20, 2012 at 3:11 AM, Andrius Sutas <[hidden email]> wrote:

> On Wed, Oct 17, 2012 at 11:31 PM, Juan Pablo Carbajal
> <[hidden email]> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/octave-dev
>
>
> UPDATE: I did replicate the bug eventually. I can not reproduce it
> consistently, will look further into this behavior.

Hi,
Thanks for taking action.

I tested again the following commands (Ubuntu 12.04 Linux
3.2.0-32-generic, FT232RL)

Ring buffer
http://agora.octave.org/snippet/Xd6x/

Read hangs after flush
http://agora.octave.org/snippet/mu7J/

Weird data handling
http://agora.octave.org/snippet/62x8/

Still working unsatisfactorily.

Cheers,

JPi

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/octave-dev
Reply | Threaded
Open this post in threaded view
|

Re: [instrument-control]

Andrius Sutas

On Sat, Oct 20, 2012 at 8:07 PM, Juan Pablo Carbajal <[hidden email]> wrote:
On Sat, Oct 20, 2012 at 3:11 AM, Andrius Sutas <[hidden email]> wrote:
> On Wed, Oct 17, 2012 at 11:31 PM, Juan Pablo Carbajal
> <[hidden email]> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/octave-dev
>
>
> UPDATE: I did replicate the bug eventually. I can not reproduce it
> consistently, will look further into this behavior.

Hi,
Thanks for taking action.

I tested again the following commands (Ubuntu 12.04 Linux
3.2.0-32-generic, FT232RL)

Ring buffer
http://agora.octave.org/snippet/Xd6x/

Read hangs after flush
http://agora.octave.org/snippet/mu7J/

Weird data handling
http://agora.octave.org/snippet/62x8/

Still working unsatisfactorily.

Cheers,

JPi

A few minutes after this email I committed a possible fix, could you please check it again? (don't forget to pkg install !)

Also, "weird data handling" is the same ring buffer problem. I assume "hang after flush" is also related to the same bug. 

I just tested the fix in ubuntu vm with two different adapters multiple times and everything seems works :)

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/octave-dev