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

[raman]

On Wed, Jun 15, 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. Re: eLua-dev Digest, Vol 35, Issue 31 (James Snyder)
  2. Help with a Port (free hardware on offer) (Iain@HotSolder)
  3. Re: Help with a Port (free hardware on offer) (Bogdan Marinescu)


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

Message: 1
Date: Tue, 14 Jun 2011 19:01:56 -0500
From: James Snyder <[hidden email]>
To: "eLua Users and Development List (www.eluaproject.net)"
       <[hidden email]>
Subject: Re: [eLua-dev] eLua-dev Digest, Vol 35, Issue 31
Message-ID: <BANLkTi=[hidden email]>
Content-Type: text/plain; charset=ISO-8859-1

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

Hello,

Thanks for your reply. Now that I know for sure that the bug has nothing
to do with my platform setup, I will try to build up test cases to corner the
bug. I will keep the posix vs win serial implementation in mind. If I stumble
upon something interesting, I will certainly keep the community posted.

Awaiting your update.

Raman

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

Message: 2
Date: Wed, 15 Jun 2011 01:04:15 -0700 (PDT)
From: "Iain@HotSolder" <[hidden email]>
To: [hidden email]
Subject: [eLua-dev] Help with a Port (free hardware on offer)
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=us-ascii

Hello,

I have been watching eLUA website for about a year watching it grow, at the
same time I have developed a small Arduino shaped platform based on a
LM39D92 from TI/Luminary. ( http://www.solderCore.com
http://www.solderCore.com ). Website is completely out of date, so not all
the statement are still relevant.
The board has been designed to support a BASIC interpreter from Rowley
Associates which has some similar characteristics to eLUA. I would also like
to this board to support eLUA, preferably when we launch July/August.

I was going to try and port over eLUA myself, as I kind of enjoy that type
of stuff, however, it would take me while as no matter how hard I try, I'm
essentially a hardware guy. I don't think the port would be that difficult
as the LM3S9D92 is very similar to the LM3S9B92, it has twice as much Flash,
and I believe the peripheral set is pretty much identical.

I have a board or two that I don't mind giving away to anybody who could
port this code. If anyone is interested please let me know and I can send
over more information.

Thanks

Iain



--
View this message in context: http://elua-development.2368040.n2.nabble.com/Help-with-a-Port-free-hardware-on-offer-tp6477750p6477750.html
Sent from the eLua Development mailing list archive at Nabble.com.


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

Message: 3
Date: Wed, 15 Jun 2011 12:06:16 +0300
From: Bogdan Marinescu <[hidden email]>
To: "eLua Users and Development List (www.eluaproject.net)"
       <[hidden email]>
Subject: Re: [eLua-dev] Help with a Port (free hardware on offer)
Message-ID: <BANLkTi=JnG=_6jZQgc_dPPSHBiyr=[hidden email]>
Content-Type: text/plain; charset="iso-8859-1"

Hi,

On Wed, Jun 15, 2011 at 11:04 AM, Iain@HotSolder <
[hidden email]> wrote:

> Hello,
>
> I have been watching eLUA


eLua :)


> website for about a year watching it grow, at the
> same time I have developed a small Arduino shaped platform based on a
> LM39D92 from TI/Luminary. ( http://www.solderCore.com
> http://www.solderCore.com ). Website is completely out of date, so not all
> the statement are still relevant.
> The board has been designed to support a BASIC interpreter from Rowley
> Associates which has some similar characteristics to eLUA. I would also
> like
> to this board to support eLUA, preferably when we launch July/August.
>
> I was going to try and port over eLUA myself, as I kind of enjoy that type
> of stuff, however, it would take me while as no matter how hard I try, I'm
> essentially a hardware guy. I don't think the port would be that difficult
> as the LM3S9D92


Is this chip in pre-production with private specs or something similar? I
couldn't find anything related to 9D92 on ti.com or luminarymicro.com, thus
it's a bit hard to estimate the porting effort :)


> is very similar to the LM3S9B92, it has twice as much Flash,
> and I believe the peripheral set is pretty much identical.
>

Then the port should be extremely straightforward.


> I have a board or two that I don't mind giving away to anybody who could
> port this code. If anyone is interested please let me know and I can send
> over more information.
>

I'll hold off on this until I find out more about that chip :) Although I
don't really expect surprises, it's highly unlikely that the overall core
changed too much.

Best,
Bogdan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.berlios.de/pipermail/elua-dev/attachments/20110615/fece43ea/attachment-0001.html>

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

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


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

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

[jbsnyder]

On Wed, Jun 15, 2011 at 5:32 AM, Raman Gopalan <[hidden email]> wrote:

> Thanks for your reply. Now that I know for sure that the bug has nothing
> to do with my platform setup, I will try to build up test cases to corner
> the
> bug. I will keep the posix vs win serial implementation in mind. If I
> stumble
> upon something interesting, I will certainly keep the community posted.
>
> Awaiting your update.
>
> Raman

What's odd here is that I did hook up a scope to both Rx and Tx lines
and at least at the MCU it appears to be sending back the initial
handshake reply.  What I can't figure out is why it never appears in
the buffer in Windows.  There's plenty of buffer space allocated
beforehand.  One difference I notice in timing between POSIX and
Windows is that it seems to send the connection request byte and
header as one "packet" whereas with windows there is a couple
millisecond delay between the sending of the connection request byte
and the 8 header bytes.  Additionally, there appears to be a longer
delay in responding to the single 9 byte POSIX send vs the separated
Windows 1 + 2ms + 8 byte send.  I haven't looked at timing on an STM32
platform yet to see how it differs if at all but I wonder if this
might be related to timing?

It has definitely worked in the past on this platform.  I may start
trying to find the last working version and then use git bisect to
find what change caused the current problem.
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev