GIRS driver sending extra space to serial

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

GIRS driver sending extra space to serial

Helen Foster
In 0.9.4pre1 when starting mode2 with the GIRS driver, it makes 10
attempts at sending " \r" (space-return), which the AGirs firmware
rejects with "ERROR". Then mode2 gives up with "Cannot initiate
device".

IrScrutinizer begins a connection by sending "\r" (return without the
space), and AGirs replies "OK".

When I modified AGirs to accept a space as a blank command, mode2
worked with that version.

Regards,
Helen

------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
Reply | Threaded
Open this post in threaded view
|

Re: GIRS driver sending extra space to serial

Bengt Martensson-2
Hi Helen,

On 03/28/16 00:18, Helen Foster wrote:
> In 0.9.4pre1 when starting mode2 with the GIRS driver, it makes 10
> attempts at sending " \r" (space-return), which the AGirs firmware
> rejects with "ERROR". Then mode2 gives up with "Cannot initiate
> device".

 From the source of the driver, it appears as "this cannot happen". Can
you provide a more extensive log?

> IrScrutinizer begins a connection by sending "\r" (return without the
> space), and AGirs replies "OK".
>
> When I modified AGirs to accept a space as a blank command, mode2
> worked with that version.

Thanx for the "suggestion". I have checked in a fix to AGirs,
https://github.com/bengtmartensson/AGirs/commit/8c9bb321f69b2d3714c2be1044bd8ad031c78661

Greetz,

Bengt

------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
Reply | Threaded
Open this post in threaded view
|

Re: GIRS driver sending extra space to serial

Helen Foster
On 3/28/16, Bengt Martensson <[hidden email]> wrote:
>> In 0.9.4pre1 when starting mode2 with the GIRS driver, it makes 10
>> attempts at sending " \r" (space-return), which the AGirs firmware
>> rejects with "ERROR". Then mode2 gives up with "Cannot initiate
>> device".
>
>  From the source of the driver, it appears as "this cannot happen". Can
> you provide a more extensive log?
>

Here are some mode2 logs. Have checked that I didn't accidentally
modify any of the LIRC source code before building it. I had also
extracted and built it independently on the OpenPandora, which gives
the same behaviour.

http://pastebin.com/i55WFSjS

I am not sure what is happening with the lock files. There are
definitely no other LIRC processes running. If some other process was
using the serial port, that could cause errors; but in any case mode2
agrees it is sending the " " command itself.

------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
Reply | Threaded
Open this post in threaded view
|

Re: GIRS driver sending extra space to serial

Bengt Martensson-2
On 03/28/16 15:58, Helen Foster wrote:

> On 3/28/16, Bengt Martensson <[hidden email]> wrote:
>>> In 0.9.4pre1 when starting mode2 with the GIRS driver, it makes 10
>>> attempts at sending " \r" (space-return), which the AGirs firmware
>>> rejects with "ERROR". Then mode2 gives up with "Cannot initiate
>>> device".
>>
>>   From the source of the driver, it appears as "this cannot happen". Can
>> you provide a more extensive log?
>>
>
> Here are some mode2 logs. Have checked that I didn't accidentally
> modify any of the LIRC source code before building it. I had also
> extracted and built it independently on the OpenPandora, which gives
> the same behaviour.

Try this. I have not tested extensively, but it is definitely a step in
the right direction.

diff --git a/plugins/girs.c b/plugins/girs.c
index 684b5a2..ab93087 100644
--- a/plugins/girs.c
+++ b/plugins/girs.c
@@ -483,7 +483,7 @@ static int syncronize(void)
         int i;

         for (i = 0; i < NO_SYNCRONIZE_ATTEMPTS; i++) {
-           int res = sendcommand_ok(" ");
+         int res = sendcommand_ok("");
                 //if (res == -1)
                         //return 0;
                 if (res == 1) {
@@ -769,7 +769,7 @@ static int init(void)
         rec_buffer_init();
         send_buffer_init();
         readflush();
-   return dev.receive ? enable_receive() : 1;
+ return 1;
  }

  // Almost the default open


> I am not sure what is happening with the lock files. There are
> definitely no other LIRC processes running. If some other process was
> using the serial port, that could cause errors; but in any case mode2
> agrees it is sending the " " command itself.

That does not seem to be a major problem, since lircd reaps the lock
files it considers wrong. Does the problem persist if you end lircd
properly?

------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
Reply | Threaded
Open this post in threaded view
|

Re: GIRS driver sending extra space to serial

Helen Foster
On 3/28/16, Bengt Martensson <[hidden email]> wrote:

> Try this. I have not tested extensively, but it is definitely a step in
> the right direction.
>
> diff --git a/plugins/girs.c b/plugins/girs.c
> index 684b5a2..ab93087 100644
> --- a/plugins/girs.c
> +++ b/plugins/girs.c
> @@ -483,7 +483,7 @@ static int syncronize(void)
>          int i;
>
>          for (i = 0; i < NO_SYNCRONIZE_ATTEMPTS; i++) {
> -           int res = sendcommand_ok(" ");
> +         int res = sendcommand_ok("");

The above change fixes receiving on the old AGirs firmware.

There also seems to be a problem with sending, but I have not looked
into that much yet.

> @@ -769,7 +769,7 @@ static int init(void)
>          rec_buffer_init();
>          send_buffer_init();
>          readflush();
> -   return dev.receive ? enable_receive() : 1;
> + return 1;
>   }
>

The above change breaks irw.

>
>> I am not sure what is happening with the lock files.
>> ...
> That does not seem to be a major problem, since lircd reaps the lock
> files it considers wrong. Does the problem persist if you end lircd
> properly?

With the girs driver, lircd cleans up the lock file when ended
properly, but mode2 is always leaving it.

With the irtoy driver, lircd and mode2 are both leaving the lock file.

------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
Reply | Threaded
Open this post in threaded view
|

Re: GIRS driver sending extra space to serial

Bengt Martensson-2
On 03/31/16 23:26, Helen Foster wrote:
> On 3/28/16, Bengt Martensson <[hidden email]> wrote:
>> Try this. I have not tested extensively, but it is definitely a step in
>> the right direction.
>>
...
>
> The above change breaks irw.

Try this:
https://sourceforge.net/u/bengtmartensson/lirc/ci/2752ccf169c25120981746159083464516f9ecea/tree/plugins/girs.c

together with the latest Git sources for AGirs
(https://github.com/bengtmartensson/AGirs.git)

Sorry for the inconvenience.

>>> I am not sure what is happening with the lock files.
>>> ...
>> That does not seem to be a major problem, since lircd reaps the lock
>> files it considers wrong. Does the problem persist if you end lircd
>> properly?
>
> With the girs driver, lircd cleans up the lock file when ended
> properly, but mode2 is always leaving it.
>
> With the irtoy driver, lircd and mode2 are both leaving the lock file.

I conclude that lircd & the girs driver does the right thing, the others
not. If you care, you can try this patch for the irtoy driver:

diff --git a/plugins/irtoy.c b/plugins/irtoy.c
index f6e81d7..30bbce6 100644
--- a/plugins/irtoy.c
+++ b/plugins/irtoy.c
@@ -114,7 +114,7 @@ const struct driver hw_usbirtoy = {
         .init_func      = init,
         .deinit_func    = deinit,
         .open_func      = default_open,
-       .close_func     = default_close,
+       .close_func     = deinit,
         .send_func      = send,
         .rec_func       = receive,
         .decode_func    = decode,



------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
Reply | Threaded
Open this post in threaded view
|

Re: GIRS driver sending extra space to serial

Helen Foster
On 4/3/16, Bengt Martensson <[hidden email]> wrote:
> Try this:
> https://sourceforge.net/u/bengtmartensson/lirc/ci/2752ccf169c25120981746159083464516f9ecea/tree/plugins/girs.c
>
> together with the latest Git sources for AGirs
> (https://github.com/bengtmartensson/AGirs.git)
>
> Sorry for the inconvenience.
>

Sending seems to be working now. Unfortunately, it is not receiving anything.

mode2: Info: girs: receive module found
mode2: Info: Version "MyGirs2 2016-04-03"
mode2: Trace: girs: flushing the input
mode2: Trace1: girs: written command "receive"
mode2: Trace1: girs: written command "
"
mode2: Trace: girs: flushing the input
mode2: Trace1: girs readdata, timeout = 0
(and that is the end of the log)


>> With the girs driver, lircd cleans up the lock file when ended
>> properly, but mode2 is always leaving it.
>>
>> With the irtoy driver, lircd and mode2 are both leaving the lock file.
>
> I conclude that lircd & the girs driver does the right thing, the others
> not. If you care, you can try this patch for the irtoy driver:
>
> diff --git a/plugins/irtoy.c b/plugins/irtoy.c
> index f6e81d7..30bbce6 100644
> --- a/plugins/irtoy.c
> +++ b/plugins/irtoy.c
> @@ -114,7 +114,7 @@ const struct driver hw_usbirtoy = {
>          .init_func      = init,
>          .deinit_func    = deinit,
>          .open_func      = default_open,
> -       .close_func     = default_close,
> +       .close_func     = deinit,
>          .send_func      = send,
>          .rec_func       = receive,
>          .decode_func    = decode,

With this change, the lock file is removed but lircd segfaults after
"caught signal" (strange when deleting the lock file is the last thing
the deinit function does).
But as you said, leaving the lock file is not a major problem.

------------------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|

Re: GIRS driver sending extra space to serial

Bengt Martensson-2
On 04/07/16 20:38, Helen Foster wrote:

> On 4/3/16, Bengt Martensson <[hidden email]> wrote:
>> Try this:
>> https://sourceforge.net/u/bengtmartensson/lirc/ci/2752ccf169c25120981746159083464516f9ecea/tree/plugins/girs.c
>>
>> together with the latest Git sources for AGirs
>> (https://github.com/bengtmartensson/AGirs.git)
>>
>> Sorry for the inconvenience.
>>
>
> Sending seems to be working now. Unfortunately, it is not receiving anything.
>
> mode2: Info: girs: receive module found
> mode2: Info: Version "MyGirs2 2016-04-03"
> mode2: Trace: girs: flushing the input
> mode2: Trace1: girs: written command "receive"
> mode2: Trace1: girs: written command "
> "
> mode2: Trace: girs: flushing the input
> mode2: Trace1: girs readdata, timeout = 0
> (and that is the end of the log)

Appears that the Arduino is not responding to the receive command.
Possibly because no signal was detected?
Please try it using a terminal program, see
http://harctoolbox.org/arduino_nano_part2.html#Testing+the+firmware

>>> With the girs driver, lircd cleans up the lock file when ended
>>> properly, but mode2 is always leaving it.
>>>
>>> With the irtoy driver, lircd and mode2 are both leaving the lock file.
>>
>> I conclude that lircd & the girs driver does the right thing, the others
>> not. If you care, you can try this patch for the irtoy driver:
>>
>> diff --git a/plugins/irtoy.c b/plugins/irtoy.c
>> index f6e81d7..30bbce6 100644
>> --- a/plugins/irtoy.c
>> +++ b/plugins/irtoy.c
>> @@ -114,7 +114,7 @@ const struct driver hw_usbirtoy = {
>>           .init_func      = init,
>>           .deinit_func    = deinit,
>>           .open_func      = default_open,
>> -       .close_func     = default_close,
>> +       .close_func     = deinit,
>>           .send_func      = send,
>>           .rec_func       = receive,
>>           .decode_func    = decode,
>
> With this change, the lock file is removed but lircd segfaults after
> "caught signal" (strange when deleting the lock file is the last thing
> the deinit function does).


With the amount of detail you provide, I cannot say more than "It works
for me, and I cannot reproduce." It is a problem with lircd proper
and/or your system.

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/
gampad/clk?id=1444514301&iu=/ca-pub-7940484522588532
Reply | Threaded
Open this post in threaded view
|

Re: GIRS driver sending extra space to serial

Helen Foster
On 4/9/16, Bengt Martensson <[hidden email]> wrote:
> Appears that the Arduino is not responding to the receive command.
> Possibly because no signal was detected?
> Please try it using a terminal program, see
> http://harctoolbox.org/arduino_nano_part2.html#Testing+the+firmware

Sorry, that was my fault. The latest update works for me - thanks!

At that link, the Girs language documentation needs updating. "Testing
the firmware" says "GirsLite supports the commands modules, version,
transmit, analyze, receive, and led". The Lirc Girs driver is using
the "send" command. The full Girs Command Language page does not
mention "send" or "led".

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/
gampad/clk?id=1444514301&iu=/ca-pub-7940484522588532
Reply | Threaded
Open this post in threaded view
|

Re: GIRS driver sending extra space to serial

Bengt Martensson-2
On 04/09/16 18:35, Helen Foster wrote:
> On 4/9/16, Bengt Martensson <[hidden email]> wrote:
>> Appears that the Arduino is not responding to the receive command.
>> Possibly because no signal was detected?
>> Please try it using a terminal program, see
>> http://harctoolbox.org/arduino_nano_part2.html#Testing+the+firmware
>
> Sorry, that was my fault. The latest update works for me - thanks!

Nice to hear that! Your future feedback of course also welcome.

> At that link, the Girs language documentation needs updating. "Testing
> the firmware" says "GirsLite supports the commands modules, version,
> transmit, analyze, receive, and led". The Lirc Girs driver is using
> the "send" command. The full Girs Command Language page does not
> mention "send" or "led".

Yes, that needs some updating. Technically, the module "transmit"
implements a command, that somehow was transmogrified from "transmit" to
"send". The command/module "led" not contained in "Girs", neither is "lcd".



------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/
gampad/clk?id=1444514301&iu=/ca-pub-7940484522588532