Re: eLua-dev Digest, Vol 35, Issue 31

[raman]

On Sun, Jun 12, 2011 at 12:00 PM, <[hidden email]> wrote:

Send eLua-dev mailing list submissions to
       [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
       https://lists.berlios.de/mailman/listinfo/elua-dev
or, via email, send a message with subject or body 'help' to
       [hidden email]

You can reach the person managing the list at
       [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of eLua-dev digest..."


Today's Topics:

  1. Problems with LuaRPC module (Raman Gopalan)
  2. Re: Redefining the I2C Lua interface (was: I2C for LM3S
     devices) (Martin Guy)
  3. RPC_PROTOCOL_VERSION (Raman Gopalan)
  4. Re: Problems with LuaRPC module (James Snyder)
  5. Re: RPC_PROTOCOL_VERSION (James Snyder)


----------------------------------------------------------------------

Message: 1
Date: Sat, 11 Jun 2011 16:30:10 +0530
From: Raman Gopalan <[hidden email]>
To: [hidden email]
Subject: [eLua-dev] Problems with LuaRPC module
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="iso-8859-1"

Hello,

I seem to have problems with LuaRPC module. Just by running Elua on the
target,
a sample snippet such as slave, err = rpc.connect ("COM11") throws
me the error "MY ERROR: no data received when attempting to read". (slave =
nil)

System configuration:
Windows-7 + All the tools needed to burn the .bin file.
(Have also tested it on Gnu/Linux, Ubuntu 10.04)

Elua cross-compiled for:
CPU: LM3S8962
Micro-controller dev board: Luminary Micro, ARM Cortex M3

I did however read through the source code to understand the protocol used
while
communicating with RPC.

The files I have used for this problem definition:
src/main.c, src/luarpc_elua_uart.c, src/modules/luarpc.c

As mentioned earlier, just by cross compiling Elua for LM3S8962, the
luarpc.exe
throws me the error: "MY ERROR: no data received when attempting to read" on
my PC console.

luarpc.c:

static int rpc_connect( lua_State *L ):

   transport_write_u8( &handle->tpt, RPC_CMD_CON );
   client_negotiate( &handle->tpt );

At this point, we can expect the handshake between the micro and
the PC through the luarpc.exe instance running on the PC.

During the client_negotiate( &handle->tpt ), it is supposed to send out the
header "LRPC(3)(default client config)" ('3', for the RPC_PROTOCOL_VERSION,
defined as an enum).

I tweaked the boot_rpc() in src/main.c to check if the micro is receiving
the header. I added the functions transport_read_buffer() and
transport_write_buffer(). The micro receives junk values, a stream of '#'.
Nonetheless, The UART module of the micro-controller works flawlessly.

I have narrowed down on the source of the problem. I suspect that the
luarpc.exe instance running on the PC isn't responsive.

How do I proceed with the bug ? Please share your thoughts and give me a few
suggestions.

Also, it is given on the website that rpc.connect() returns a HANDLE to the
slave. In the C definition of the same function, it returns an 'int'. Have I
understood it correctly ?

Raman, Student.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.berlios.de/pipermail/elua-dev/attachments/20110611/40fc205f/attachment-0001.html>

------------------------------

Message: 2
Date: Sat, 11 Jun 2011 18:57:04 +0200
From: Martin Guy <[hidden email]>
To: "eLua Users and Development List (www.eluaproject.net)"
       <[hidden email]>
Subject: Re: [eLua-dev] Redefining the I2C Lua interface (was: I2C for
       LM3S    devices)
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=ISO-8859-1

On 11 June 2011 11:37, Laurent Dufrechou <[hidden email]> wrote:
> So we end with address inside write and read funtions??
> i2c.setspeed(id, speed)
> i2c.write(id, address, data)
> i2c.read(id, address, maxbytes)
>
> For repeated start case, I think there is no issue with such device, because
> repeated start is a trick to avoid to send a stop and thus permit to? keep
> the control in case of multiple master.

No, that was just an idea for discussion (which never took place), and
may be wrong.
I don't understand I2C yet, so these ideas may be based on gross
misunderstanding of I2C.

In particular, I don't have an answer to the question "Is repeated
start an optional feature of an I2C impementation?"
The specification certainly doesn't say so.

As was suggested (thanks!) I am now working from the I2C specification
and it turns out that the Wikipedia entry is easier to understand
because it is incomplete and imprecise.

As yet, it is quite unclear to me what is needed. At present (to
condense my long email) it seems to be a choice between something that
is as simplistic as the rest of eLua but can't do I2C, or something
that does I2C but is too complex for beginners to understand.  There
may be some middle ground that satisfies both needs, but "what" is not
clear to me yet.

If you are in a hurry and want to get started, you could try
implementing the above scheme in a Git fork and let us know how the
attempt goes. Unfortunately, I need to understand things before I
implement them, and I don't understand the problem well enough yet.

   M


------------------------------

Message: 3
Date: Sat, 11 Jun 2011 20:38:59 +0200
From: Raman Gopalan <[hidden email]>
To: [hidden email]
Subject: [eLua-dev] RPC_PROTOCOL_VERSION
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="iso-8859-1"

Hello,

I was going through the source code for LuaRPC. The function
client_negotiate() defined in luarpc.c,
uses RPC_PROTOCOL_VERSION which is defined in an enumeration. char header[ 8
] (defined in the same
function) holds this value to check for header validity before it can
indicate e.errnum = ERR_HEADER; There
is also no possible way to typecast this directly. The
RPC_PROTOCOL_VERSIONcan be changed to a character.

Please let me know if my observation is correct or if there's something I am
overlooking.

Raman, Student.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.berlios.de/pipermail/elua-dev/attachments/20110611/4b223b10/attachment-0001.html>

------------------------------

Message: 4
Date: Sat, 11 Jun 2011 15:29:59 -0500
From: James Snyder <[hidden email]>
To: "eLua Users and Development List (www.eluaproject.net)"
       <[hidden email]>
Subject: Re: [eLua-dev] Problems with LuaRPC module
Message-ID: <BANLkTi=[hidden email]>
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Jun 11, 2011 at 6:00 AM, Raman Gopalan <[hidden email]> wrote:
>
> Hello,
>
> I seem to have problems with LuaRPC module. Just by running Elua on the
> target,
> a sample snippet such as slave, err = rpc.connect ("COM11") throws
> me the error "MY ERROR: no data received when attempting to read". (slave =
> nil)
>
> System configuration:
> Windows-7 + All the tools needed to burn the .bin file.
> (Have also tested it on Gnu/Linux, Ubuntu 10.04)
>
> Elua cross-compiled for:
> CPU: LM3S8962
> Micro-controller dev board: Luminary Micro, ARM Cortex M3

Are you sure that you started the rpc server on eLua's side of the
connection?  The simplest way to do this is to use the boot=luarpc
build option, however you can also start lua on the mcu, then run
rpc.server(<timer_id>,<uart_id>) and then disconnect and connect to
the server using luarpc.  If the server isn't explicitly started using
one of these methods LuaRPC on the desktop side is going to try and
talk to the eLua "shell".

Hello,

Thanks for your reply.

Yes, the RPC server is running and the boot=luarpc is enabled at build.
I even tried starting the server with rpc.server() but it takes me to an
infinite waiting state. It does not respond.

>
> I did however read through the source code to understand the protocol used
> while
> communicating with RPC.
>
> The files I have used for this problem definition:
> src/main.c, src/luarpc_elua_uart.c, src/modules/luarpc.c
>
> As mentioned earlier, just by cross compiling Elua for LM3S8962, the
> luarpc.exe
> throws me the error: "MY ERROR: no data received when attempting to read" on
> my PC console.
>
> luarpc.c:
>
> static int rpc_connect( lua_State *L ):
>
> ??? transport_write_u8( &handle->tpt, RPC_CMD_CON );
> ??? client_negotiate( &handle->tpt );
>
> At this point, we can expect the handshake between the micro and
> the PC through the luarpc.exe instance running on the PC.
>
> During the client_negotiate( &handle->tpt ), it is supposed to send out the
> header "LRPC(3)(default client config)" ('3', for the RPC_PROTOCOL_VERSION,
> defined as an enum).
>
> I tweaked the boot_rpc() in src/main.c to check if the micro is receiving
> the header. I added the functions transport_read_buffer() and
> transport_write_buffer(). The micro receives junk values, a stream of '#'.
> Nonetheless, The UART module of the micro-controller works flawlessly.

Here it sounds like you are using the rpc boot mode, which has worked
for me on Mac OS X, Win XP and Linux. I'm not sure why you would
receive a stream of "#" values.

Did you change any other parameters?  What compilers are you using,
etc..?  I assume you're not using the multiplexer (mux) or anything
like that and that you haven't modified the baud rates?

 

No. I haven't changed any parameters. I am running them on the default
parameters. I am using the codesourcery toolchain to cross compile
elua. The baud rate is set to 115200.

>
> I have narrowed down on the source of the problem. I suspect that the
> luarpc.exe instance running on the PC isn't responsive.
>
> How do I proceed with the bug ? Please share your thoughts and give me a few
> suggestions.

I suspect that maybe there's a configuration problem if you're having
the issue on multiple platforms?  It's hard to know without knowing
if/what you have or might have configured or adjusted.  To my
knowledge the current code should work with boot=luarpc with proper
platform configuration and compilation and if the desktop client
builds correctly.  Knowing which build environment you're using on the
desktop and perhaps any adjustments you've made might help.  One
shortcoming of the way the desktop client works with serial
connections is that it doesn't take a baud parameter and therefore
just assumes that the connection will be at 115200, so if you've
changed that it certainly won't pick it up.

I am using MinGW to build my desktop Lua, RPC enabled. I haven't modified
the configuration.

Are you using the built-in FTDI-based virtual com port interface that
the LM3S board provides?

Yes, I am using the FDTI based virtual com port interface provided in
the disk that came along with the LM3S8962 dev-board. I have also
checked the com port settings. It is configured to a baud of 115200
with 8 data bits, no parity, 1 stop bit and no flow control.
Is there anything else I must set in the FTDI setting ?
 
Awaiting your response.

>
> Also, it is given on the website that rpc.connect() returns a HANDLE to the
> slave. In the C definition of the same function, it returns an 'int'. Have I
> understood it correctly ?

Yes, the way the Lua API works is that you push values on the stack
which you wish to return to the user and you return to the VM the
number of results that are on the stack for it.

>
> Raman, Student.
>
> _______________________________________________
> eLua-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>


------------------------------

Message: 5
Date: Sat, 11 Jun 2011 16:01:07 -0500
From: James Snyder <[hidden email]>
To: "eLua Users and Development List (www.eluaproject.net)"
       <[hidden email]>
Subject: Re: [eLua-dev] RPC_PROTOCOL_VERSION
Message-ID: <BANLkTikFGgCpP-f7uQ=[hidden email]>
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Jun 11, 2011 at 1:38 PM, Raman Gopalan <[hidden email]> wrote:
>
> Hello,
>
> I was going through the source code for LuaRPC. The function
> client_negotiate() defined in luarpc.c,
> uses RPC_PROTOCOL_VERSION which is defined in an enumeration. char header[ 8
> ] (defined in the same
> function) holds this value to check for header validity before it can
> indicate e.errnum = ERR_HEADER; There
> is also no possible way to typecast this directly. The RPC_PROTOCOL_VERSION
> can be changed to a character.
>
> Please let me know if my observation is correct or if there's something I am
> overlooking.

There's nothing special about char that prevents something that isn't
a character from being stored in it that's a value between 0 and 255.

>From the C89 spec (not much different in C99):
"An object declared as type char is large enough to store any member
of the basic execution character set.  If a member of the required
source character set enumerated in $2.2.1 is stored in a char object,
its value is guaranteed to be positive.  If other quantities are
stored in a char object, the behavior is implementation-defined: the
values are treated as either signed or nonnegative integers."

Enumerated types are just integer constant values.

Generally, I suppose, many platforms treat it as an unsigned 8-bit
integer, so the enumerated value of 3 is perfectly small enough to fit
within the range that would be large enough to store a member of the
basic execution character set.

Now, I suppose that it might not be a bad idea to make the cast
explicit here to char for all of the parameters that are set in that
function, but I'm not sure if I would consider the existing version
broken or the source of the difficulties you're currently experiencing
(unless the compiler you're using is behaving differently than the
ones we've used previously :-) ).

The LuaRPC headers actually bear some resemblance to the Lua headers
used for compiled Lua files, and since that header generation code
does include explicit casts, I'll probably add this on my next pass
through the code since it's generally better to be explicit.

Lua's ldump.c DumpHeader, 259:
https://github.com/elua/elua/blob/master/src/lua/ldump.c

Sure, thanks for the reply.

Best.

-jsnyder

>
> Raman, Student.
>
>
>
> _______________________________________________
> eLua-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>


------------------------------

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev


End of eLua-dev Digest, Vol 35, Issue 31
****************************************

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[jbsnyder]

On Tue, Jun 14, 2011 at 6:01 AM, Raman Gopalan <[hidden email]> wrote:

> Hello,
>
> Thanks for your reply.
>
> Yes, the RPC server is running and the boot=luarpc is enabled at build.
> I even tried starting the server with rpc.server() but it takes me to an
> infinite waiting state. It does not respond.

rpc.server is intended to "take over" and not do anything other than
handle RPC requests after invokation.  There's another model writing
servers that intermingle with other running Lua code, but given some
platform limitations and the way LuaRPC is currently written use of
that approach is problematic on the MCU.  We should have this
supported in an upcoming release.

> Awaiting your response.

OK, so I've done some additional testing and what I'm currently
finding is that while STM32 seems to work fine on Windows, Mac & Linux
for me, I pulled out an LM3S6965 that I've got and while that works
with a desktop OS X client, it doesn't appear to work with Windows.
So, you have indeed found a bug, and one that I'm not quite sure why
is manifesting in this way (working configurations/platforms vs
non-working ones).

I don't believe the problem is related to virtual com ports since the
STM32 platform is also using one.  I'm guessing it may have something
to do with the differences in behavior between the Win and POSIX
serial implementations and perhaps timing and how that might vary
between platforms?

I know some enhancements were made to the rfs/mux serial
implementation for Windows that prevent some problematic conditions
for that platform.  I have tried updating the serial code being used
by LuaRPC to use similar checks on setup reading and writing and that
doesn't seem to fix the issue.

 I'll send an update as soon as I've narrowed down what might be
causing this issue.

-jsnyder
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev