eLua vs. .net MF

classic Classic list List threaded Threaded
14 messages Options
John Hind John Hind
Reply | Threaded
Open this post in threaded view
|

eLua vs. .net MF

How to put this delicately ...

 

I've noticed a lot of activity with people using FEZ boards (like the Panda) and baseline .NET MF boards like the NetDuino for eLua. What advantages do you see with eLua over using the .NET MF environment they are designed for?

 

I'm afraid that having tried hard to get off the ground with eLua and also with the MBED environment, I bought a FEZ Domino and found the .NET environment (particularly with the GHI Electronics FEZ extensions) very much more capable than either. I'm now actually writing application code rather than trying to get device drivers working! Have you guys run into limitations that are causing you to go with eLua or is it just for the challenge of doing things from scratch?

 

I wish eLua well and hope it will soon get up to the level of functionality offered by FEZ, which I think should serve as a benchmark for what needs to be achieved. I like the following features:

 

1. You can buy single chips with the runtime already loaded and so do not require a JTAG or other specialist development hardware to get going.

 

2. Unlike MBED, it is a genuine single-chip solution using on-chip USB resources for its development link.

 

3. There is a free development system with support for both emulated and target debugging (although I am actually using the paid-for Visual Studio 2010 as I already had that).

 

4. There are libraries / device drivers for all the I/O resources on the chips as well as for TCP/IP using an external chip. This includes more esoteric stuff like CAN and SD Card file systems. There is also full USB, both device and host.

 

5. Multitasking is natively built-in.

 

Set against this, I would prefer the elegant minimalism of Lua to the rather bloated C# and full non-commercial open source would be preferable to the Corporate open source compromise, but for the moment, the other advantages outweigh this.

 


_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
BogdanM BogdanM
Reply | Threaded
Open this post in threaded view
|

Re: eLua vs. .net MF

Hi,

On Wed, May 4, 2011 at 7:04 PM, John Hind <[hidden email]> wrote:

How to put this delicately ...

 

I've noticed a lot of activity with people using FEZ boards (like the Panda) and baseline .NET MF boards like the NetDuino for eLua. What advantages do you see with eLua over using the .NET MF environment they are designed for?

 

I'm afraid that having tried hard to get off the ground with eLua and also with the MBED environment, I bought a FEZ Domino and found the .NET environment (particularly with the GHI Electronics FEZ extensions) very much more capable than either. I'm now actually writing application code rather than trying to get device drivers working! Have you guys run into limitations that are causing you to go with eLua or is it just for the challenge of doing things from scratch?


For me it's mostly the challenge. Plus, strictly as a matter of personal preference, I'd rather write all my programs on a binary keyboard (http://www.virtual-trading-cards.com/2008/02/16/elite-coder-keyboard/) than touch anything related to .NET. That said, I understand your point of view very well.

I wish eLua well and hope it will soon get up to the level of functionality offered by FEZ, which I think should serve as a benchmark for what needs to be achieved. 

I like the following features:

 

1. You can buy single chips with the runtime already loaded and so do not require a JTAG or other specialist development hardware to get going.

 

2. Unlike MBED, it is a genuine single-chip solution using on-chip USB resources for its development link. 

 

3. There is a free development system with support for both emulated and target debugging (although I am actually using the paid-for Visual Studio 2010 as I already had that).

 

4. There are libraries / device drivers for all the I/O resources on the chips as well as for TCP/IP using an external chip. This includes more esoteric stuff like CAN and SD Card file systems. There is also full USB, both device and host.

 

5. Multitasking is natively built-in.

 

Set against this, I would prefer the elegant minimalism of Lua to the rather bloated C# and full non-commercial open source would be preferable to the Corporate open source compromise, but for the moment, the other advantages outweigh this.


I wish you the best time in the world with your new development environment and I hope it will prove to be exactly what you're looking for! And I'm sorry to see you "go", but once again, I fully understand your motives.

Best,
Bogdan


_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
Ronan Paixão-2 Ronan Paixão-2
Reply | Threaded
Open this post in threaded view
|

Re: eLua vs. .net MF

In reply to this post by John Hind
Actually, the problem with eLua not having better device driver
support (which is already very good) is because it's incredibly harder
to make modules which work in a single way for multiple boards.

You see, FEZ can have good device drivers because they have only a
bunch of boards, with the same or very similar chips, which usually
have the same way of doing things.

eLua supports multiple chips, with multiple architectures, each having
multiple peripherals, some that perform the same way, but are
configured differently. That said, the eLua team tries very hard to
make to abstract all that away, in favor of the user. With that, one
can use the same code in different boards. So, if a developer starts
with one board and finds he needs more processing power in the middle
of the application, he won't have to port all of his code, as long as
he used the hardware abstraction layer.

I, myself, prefer to write C code for my projects (haven't had time to
learn to code Lua yet), but I like eLua's idea very much and keep a
look at how things go.

2011/5/4 John Hind <[hidden email]>:

> How to put this delicately ...
>
>
>
> I've noticed a lot of activity with people using FEZ boards (like the Panda)
> and baseline .NET MF boards like the NetDuino for eLua. What advantages do
> you see with eLua over using the .NET MF environment they are designed for?
>
>
>
> I'm afraid that having tried hard to get off the ground with eLua and also
> with the MBED environment, I bought a FEZ Domino and found the .NET
> environment (particularly with the GHI Electronics FEZ extensions) very much
> more capable than either. I'm now actually writing application code rather
> than trying to get device drivers working! Have you guys run into
> limitations that are causing you to go with eLua or is it just for the
> challenge of doing things from scratch?
>
>
>
> I wish eLua well and hope it will soon get up to the level of functionality
> offered by FEZ, which I think should serve as a benchmark for what needs to
> be achieved. I like the following features:
>
>
>
> 1. You can buy single chips with the runtime already loaded and so do not
> require a JTAG or other specialist development hardware to get going.
>
>
>
> 2. Unlike MBED, it is a genuine single-chip solution using on-chip USB
> resources for its development link.
>
>
>
> 3. There is a free development system with support for both emulated and
> target debugging (although I am actually using the paid-for Visual Studio
> 2010 as I already had that).
>
>
>
> 4. There are libraries / device drivers for all the I/O resources on the
> chips as well as for TCP/IP using an external chip. This includes more
> esoteric stuff like CAN and SD Card file systems. There is also full USB,
> both device and host.
>
>
>
> 5. Multitasking is natively built-in.
>
>
>
> Set against this, I would prefer the elegant minimalism of Lua to the rather
> bloated C# and full non-commercial open source would be preferable to the
> Corporate open source compromise, but for the moment, the other advantages
> outweigh this.
>
>
>
> _______________________________________________
> 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
BogdanM BogdanM
Reply | Threaded
Open this post in threaded view
|

Re: eLua vs. .net MF


2011/5/4 Ronan Paixão <[hidden email]>
Actually, the problem with eLua not having better device driver
support (which is already very good) is because it's incredibly harder
to make modules which work in a single way for multiple boards.

You see, FEZ can have good device drivers because they have only a
bunch of boards, with the same or very similar chips, which usually
have the same way of doing things.

Yes. Kind of the difference between Windows and OS X on an incredibly smaller scale :) All joke aside, I sometimes question the decision of making eLua as portable as possible instead of focusing on one or two platforms at most (from a project management perspective, that is). Most of the time I don't though. Going from general to particular is generally easy, the other way around is much harder. 
 
eLua supports multiple chips, with multiple architectures, each having
multiple peripherals, some that perform the same way, but are
configured differently. That said, the eLua team tries very hard to
make to abstract all that away, in favor of the user. With that, one
can use the same code in different boards. So, if a developer starts
with one board and finds he needs more processing power in the middle
of the application, he won't have to port all of his code, as long as
he used the hardware abstraction layer.

I, myself, prefer to write C code for my projects (haven't had time to
learn to code Lua yet), but I like eLua's idea very much and keep a
look at how things go.


Hopefully you'll be able to work with C code inside eLua much easier in the not-so-distant future.

Best,
Bogdan

2011/5/4 John Hind <[hidden email]>:
> How to put this delicately ...
>
>
>
> I've noticed a lot of activity with people using FEZ boards (like the Panda)
> and baseline .NET MF boards like the NetDuino for eLua. What advantages do
> you see with eLua over using the .NET MF environment they are designed for?
>
>
>
> I'm afraid that having tried hard to get off the ground with eLua and also
> with the MBED environment, I bought a FEZ Domino and found the .NET
> environment (particularly with the GHI Electronics FEZ extensions) very much
> more capable than either. I'm now actually writing application code rather
> than trying to get device drivers working! Have you guys run into
> limitations that are causing you to go with eLua or is it just for the
> challenge of doing things from scratch?
>
>
>
> I wish eLua well and hope it will soon get up to the level of functionality
> offered by FEZ, which I think should serve as a benchmark for what needs to
> be achieved. I like the following features:
>
>
>
> 1. You can buy single chips with the runtime already loaded and so do not
> require a JTAG or other specialist development hardware to get going.
>
>
>
> 2. Unlike MBED, it is a genuine single-chip solution using on-chip USB
> resources for its development link.
>
>
>
> 3. There is a free development system with support for both emulated and
> target debugging (although I am actually using the paid-for Visual Studio
> 2010 as I already had that).
>
>
>
> 4. There are libraries / device drivers for all the I/O resources on the
> chips as well as for TCP/IP using an external chip. This includes more
> esoteric stuff like CAN and SD Card file systems. There is also full USB,
> both device and host.
>
>
>
> 5. Multitasking is natively built-in.
>
>
>
> Set against this, I would prefer the elegant minimalism of Lua to the rather
> bloated C# and full non-commercial open source would be preferable to the
> Corporate open source compromise, but for the moment, the other advantages
> outweigh this.
>
>
>
> _______________________________________________
> 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


_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
jbsnyder jbsnyder
Reply | Threaded
Open this post in threaded view
|

Re: eLua vs. .net MF

In reply to this post by John Hind
On Wed, May 4, 2011 at 11:04 AM, John Hind <[hidden email]> wrote:

> How to put this delicately ...
>
>
>
> I've noticed a lot of activity with people using FEZ boards (like the Panda)
> and baseline .NET MF boards like the NetDuino for eLua. What advantages do
> you see with eLua over using the .NET MF environment they are designed for?
>
>
>
> I'm afraid that having tried hard to get off the ground with eLua and also
> with the MBED environment, I bought a FEZ Domino and found the .NET
> environment (particularly with the GHI Electronics FEZ extensions) very much
> more capable than either. I'm now actually writing application code rather
> than trying to get device drivers working! Have you guys run into
> limitations that are causing you to go with eLua or is it just for the
> challenge of doing things from scratch?

I think it's a bit of both.  To start, when I started working with
eLua things like .NET MF were either not yet available or were just
starting to be discussed and hadn't really materialized.
Unfortunately, we don't have the same sort of plug-and-play GUI IDE
toolchain at this point that an environment like .NET MF might offer,
and for the platforms we support we may not have full peripheral
coverage for every device.  We have these sorts of things as goals,
but we haven't yet reached them.

That said, while it's not perfect, I'm fairly happy with it to use as
a development environment and as a testing tool for a lot of purposes,
and given my familiarity with the guts of it it's fairly easy to
extend, port or fix if there are problems I run into.  I'm also really
not that interested in getting locked into using .NET, when what I've
got is mainly licensed under just about the most permissive license in
existence :-)

>
>
>
> I wish eLua well and hope it will soon get up to the level of functionality
> offered by FEZ, which I think should serve as a benchmark for what needs to
> be achieved. I like the following features:
>
>
>
> 1. You can buy single chips with the runtime already loaded and so do not
> require a JTAG or other specialist development hardware to get going.

This is somewhat inherent to supporting lots of hardware and currently
not having a platform that's shipping with eLua as a "preferred"
development environment.  While there's not anything that is currently
available for order at the moment, there are projects like the Mizar32
that are in progress that will make things like this a lot easier.

mbed is also pretty easy to load eLua on and the filesystem is
supported, but not all the device drivers are fleshed out :-)

>
>
>
> 2. Unlike MBED, it is a genuine single-chip solution using on-chip USB
> resources for its development link.

With the proliferation of support for USB profiles, this is something
that I would like to see in eLua as well.  By supporting CDC on some
platforms we would even get USB<->Serial for free out of the box, and
then we could build on top of that for a fast native link for
transferring data.  I suspect one of the reasons why we haven't really
jumped on this is uneven support on the MCU-side for this type of
interface.  Aside from supporting the obvious CDC link, I'm not sure
what the obvious protocol choice would be.  I suspect we'd pretty much
end up inventing one, or somehow building on top of the multiplexer
work to provide a transparent high speed multiplexing serial link?

Having hacked on some libusb code recently, I actually wouldn't be too
afraid of fiddling with adding some sort of USB link.  It'd be great
to take advantage of some of the built-in features that USB provides
out of the box.

That said, this is generally on a wish list more than a must have list
for me :-)


>
> 3. There is a free development system with support for both emulated and
> target debugging (although I am actually using the paid-for Visual Studio
> 2010 as I already had that).
>

I'm glad to see that there's at least some free/open support for this
platform on it's way through Mono.

I assume you're referring to the Visual Studio Express product however?

>
>
> 4. There are libraries / device drivers for all the I/O resources on the
> chips as well as for TCP/IP using an external chip. This includes more
> esoteric stuff like CAN and SD Card file systems. There is also full USB,
> both device and host.

We're fairly good here (aside from USB) on platforms like LM3S, but
other platforms are more variable.  We do have CAN (on LM3S & STM32)
as well as FatFs on SD cards (via SPI, so any platform that has
working SPI should be able to access SD cards connected to an SPI
peripheral).

>
>
>
> 5. Multitasking is natively built-in.
>

Is this cooperative or preemptive?  Lua certainly has cooperative
multitasking built-in.  eLua also now has the ability to provide some
more primitive preemptive multitasking through the early-stage
interrupt support.

>
>
> Set against this, I would prefer the elegant minimalism of Lua to the rather
> bloated C# and full non-commercial open source would be preferable to the
> Corporate open source compromise, but for the moment, the other advantages
> outweigh this.

Fair enough :-) It's awesome to get a complete solution out of the box
that "just works" and is inexpensive. I certainly really enjoyed the
first time I pulled an Arduino out of the box and found how easy it
was to just plug it in and use any of numerous ready-made examples and
libraries.  I personally don't know enough about the implementation of
the C# microframework to know where it falls down in comparison to Lua
and where it excels aside from what you've mentioned to us.

We're certainly trying to make it a better development tool to make
our own lives easier and so that other people might find it useful as
well.  I think some of the things you've mentioned are certainly on
the roadmap or are things that we'd love to see as well, like some
simple easy to order, load and develop with hardware that doesn't
require a JTAG programmer (though, to be fair quite a number of the
supported platforms either have integrated bootloaders, have
integrated JTAG and/or have simple GUI tools for flashing even if the
integrated flashing interface is JTAG (LM3S/TI for example)).

Also, if you do have gripes or suggestions like this, I think we're
always happy to have discussions about them.  I don't think anyone
here is likely to start a flame war over criticism. Lua is not a
religious language, it's full of compromises and it's a very pragmatic
language.  Likewise, I think a lot of the people on this list are
probably fairly pragmatic as well :-)

>
>
>
> _______________________________________________
> 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
Tim Michals Tim Michals
Reply | Threaded
Open this post in threaded view
|

Re: eLua vs. .net MF

In reply to this post by BogdanM
I've been asked the same question many times over the past few months, Why eLua on a FEZ board? Why? Stupid or something?  Why PIC32 open source port using gcc? ;)

I think the goals for eLua and MicroFramework are the same:
- Support for a high level language with source level debugger
- Easy environment to develop applications. 
- Board support packages for boards

eLua is a a pure open source embedded project:
Code: 
     - Core code.  Kernel, makefile system, etc.
     - Good documentation on the code base
     - BSP(Board Support Package), drivers,  libraries (TCP/IP, USB, crypto(SSL), etc.     

Packaging eLua:
     - Having eLua already loaded on hardware to allows the end user to start writing applications out of the box, no porting, no creating a BSP. No issues with voiding support or warranty if loading different binary, etc.  eLua is already on the board, why load anything else?  ;)
     - Upgrade firmware with web, or simple interface
    
Just image if  .NET Micro Framework did not run on the FEZ boards?
What if mbed, just had simple examples? No web development tool to compile apps, no drivers, no framework, etc.  Would it sell? 
Why does microchip do so well? Offers a complete package, drivers, source, boards and chips.

FYI, Microsoft stopped support for .NET Micro Framework. It is hard sell Micro-framework for $5 a board, when the board is only $5.  But package  .NET Microframe work with hardware, it is a good combination, great out of the box experience.  Same holds for Arduino, great HW with development tools, i.e. GUI, libraries etc. 

I think having eLua run on FEZ boards will offer .NET Micro framework developers a new tool to help develop applications. Does it compete with C#? It offers a different way to program.  Just like using Python instead of C#, both are programming languages but offer different ways of doing it. 

It will take time to have complete package. 
I've got my work cut out to deliver a  complete FEZ port, documentation, loader etc.  eLua has a place holder on the GHI web site at http://wiki.tinyclr.com/index.php?title=ELua

Hope this email makes more sense than some of my others as of late....


From: Bogdan Marinescu <[hidden email]>
To: eLua Users and Development List (www.eluaproject.net) <[hidden email]>
Sent: Wednesday, May 4, 2011 2:35 PM
Subject: Re: [eLua-dev] eLua vs. .net MF


2011/5/4 Ronan Paixão <[hidden email]>
Actually, the problem with eLua not having better device driver
support (which is already very good) is because it's incredibly harder
to make modules which work in a single way for multiple boards.

You see, FEZ can have good device drivers because they have only a
bunch of boards, with the same or very similar chips, which usually
have the same way of doing things.

Yes. Kind of the difference between Windows and OS X on an incredibly smaller scale :) All joke aside, I sometimes question the decision of making eLua as portable as possible instead of focusing on one or two platforms at most (from a project management perspective, that is). Most of the time I don't though. Going from general to particular is generally easy, the other way around is much harder. 
 
eLua supports multiple chips, with multiple architectures, each having
multiple peripherals, some that perform the same way, but are
configured differently. That said, the eLua team tries very hard to
make to abstract all that away, in favor of the user. With that, one
can use the same code in different boards. So, if a developer starts
with one board and finds he needs more processing power in the middle
of the application, he won't have to port all of his code, as long as
he used the hardware abstraction layer.

I, myself, prefer to write C code for my projects (haven't had time to
learn to code Lua yet), but I like eLua's idea very much and keep a
look at how things go.


Hopefully you'll be able to work with C code inside eLua much easier in the not-so-distant future.

Best,
Bogdan

2011/5/4 John Hind <[hidden email]>:
> How to put this delicately ...
>
>
>
> I've noticed a lot of activity with people using FEZ boards (like the Panda)
> and baseline .NET MF boards like the NetDuino for eLua. What advantages do
> you see with eLua over using the .NET MF environment they are designed for?
>
>
>
> I'm afraid that having tried hard to get off the ground with eLua and also
> with the MBED environment, I bought a FEZ Domino and found the .NET
> environment (particularly with the GHI Electronics FEZ extensions) very much
> more capable than either. I'm now actually writing application code rather
> than trying to get device drivers working! Have you guys run into
> limitations that are causing you to go with eLua or is it just for the
> challenge of doing things from scratch?
>
>
>
> I wish eLua well and hope it will soon get up to the level of functionality
> offered by FEZ, which I think should serve as a benchmark for what needs to
> be achieved. I like the following features:
>
>
>
> 1. You can buy single chips with the runtime already loaded and so do not
> require a JTAG or other specialist development hardware to get going.
>
>
>
> 2. Unlike MBED, it is a genuine single-chip solution using on-chip USB
> resources for its development link.
>
>
>
> 3. There is a free development system with support for both emulated and
> target debugging (although I am actually using the paid-for Visual Studio
> 2010 as I already had that).
>
>
>
> 4. There are libraries / device drivers for all the I/O resources on the
> chips as well as for TCP/IP using an external chip. This includes more
> esoteric stuff like CAN and SD Card file systems. There is also full USB,
> both device and host.
>
>
>
> 5. Multitasking is natively built-in.
>
>
>
> Set against this, I would prefer the elegant minimalism of Lua to the rather
> bloated C# and full non-commercial open source would be preferable to the
> Corporate open source compromise, but for the moment, the other advantages
> outweigh this.
>
>
>
> _______________________________________________
> 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


_______________________________________________
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
sweetlilmre sweetlilmre
Reply | Threaded
Open this post in threaded view
|

Re: eLua vs. .net MF

Hi,

Having used .NETMF extensively one of its main issues for me has been interop performance.

When needing to bitbang pins for LED matrix displays etc. it has been necessary to extend the firmware see NetDuino BitBanger

eLua seems to perform better for this kind of application and seems more easily extensible.

Also as a language, Lua is significantly easier to learn (for newbies) and I find this attractive for teaching purposes.

Still both are very interesting and have their place. A really nice debugging interface over serial akin to the VS debugger for .NETMF would be fantastic for eLua.

My 2c
-(e)
jbsnyder jbsnyder
Reply | Threaded
Open this post in threaded view
|

Re: eLua vs. .net MF

On Thu, May 5, 2011 at 2:37 AM, sweetlilmre <[hidden email]> wrote:

> Hi,
>
> Having used .NETMF extensively one of its main issues for me has been
> interop performance.
>
> When needing to bitbang pins for LED matrix displays etc. it has been
> necessary to extend the firmware see
> http://forums.netduino.com/index.php?/topic/272-bitbanger-driver/page__p__1778__hl__bitbanger__fromsearch__1#entry1778
> NetDuino BitBanger
>
> eLua seems to perform better for this kind of application and seems more
> easily extensible.

I didn't want to jump to conclusions, but I was somewhat presuming
that both of these might be the case.  I figured that the .NET VM
would still end up being somewhat slower than Lua's, and I was curious
about whether or not they had managed to come up with some way to make
it as simply extensible with C modules.

> Also as a language, Lua is significantly easier to learn (for newbies) and I
> find this attractive for teaching purposes.

I can't speak to this directly (since I haven't written anything of
great length or significance in C#), but I would figure that the
syntax and a primarily functional language like Lua + the REPL might
be easier to teach with.

>
> Still both are very interesting and have their place. A really nice
> debugging interface over serial akin to the VS debugger for .NETMF would be
> fantastic for eLua.

This is something I'm not sure if anyone (including myself) on the dev
team is familiar with.  Is there a demo of this somewhere to show how
this works without getting the hardware?  If you look at the roadmap
on the site you'll note there's a "Lua debugging (remote/on target)"
item, and while I think  we know we have some of the components we
might need for such a tool, I'm not sure we've decided what it will
look like (aside from not OpenOCD+gdb ;-) ).

>
> My 2c
> -(e)
>
> --
> View this message in context: http://elua-development.2368040.n2.nabble.com/eLua-vs-net-MF-tp6331487p6333433.html
> Sent from the eLua Development mailing list archive at Nabble.com.
> _______________________________________________
> 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
BogdanM BogdanM
Reply | Threaded
Open this post in threaded view
|

Re: eLua vs. .net MF



On Thu, May 5, 2011 at 11:21 AM, James Snyder <[hidden email]> wrote:
On Thu, May 5, 2011 at 2:37 AM, sweetlilmre <[hidden email]> wrote:
> Hi,
>
> Having used .NETMF extensively one of its main issues for me has been
> interop performance.
>
> When needing to bitbang pins for LED matrix displays etc. it has been
> necessary to extend the firmware see
> http://forums.netduino.com/index.php?/topic/272-bitbanger-driver/page__p__1778__hl__bitbanger__fromsearch__1#entry1778
> NetDuino BitBanger
>
> eLua seems to perform better for this kind of application and seems more
> easily extensible.

I didn't want to jump to conclusions, but I was somewhat presuming
that both of these might be the case.  I figured that the .NET VM
would still end up being somewhat slower than Lua's, and I was curious
about whether or not they had managed to come up with some way to make
it as simply extensible with C modules.

> Also as a language, Lua is significantly easier to learn (for newbies) and I
> find this attractive for teaching purposes.

I can't speak to this directly (since I haven't written anything of
great length or significance in C#), but I would figure that the
syntax and a primarily functional language like Lua + the REPL might
be easier to teach with.

>
> Still both are very interesting and have their place. A really nice
> debugging interface over serial akin to the VS debugger for .NETMF would be
> fantastic for eLua.

This is something I'm not sure if anyone (including myself) on the dev
team is familiar with.  Is there a demo of this somewhere to show how
this works without getting the hardware?  If you look at the roadmap
on the site you'll note there's a "Lua debugging (remote/on target)"
item, and while I think  we know we have some of the components we
might need for such a tool, I'm not sure we've decided what it will
look like (aside from not OpenOCD+gdb ;-) ).

I think the OP was talking about high level debugging (debugging Lua code), not the very low level stuff one can do with OpenOCD+gdb. This isn't hard in itself:

(there are other examples out there. A simple Lua debugger is almost trivial to write using the "debug" library).

The main issue here is presentation. What most people have come to expect when they hear about debuggers is something integrated with a GUI where they can easily do stuff like breakpoint management, variable tracing, program control (on/off/step) and so on. A command line debugger is easy to write, not that easy to use. Without such a GUI and giving the dynamic nature of eLua I believe it's actually more efficient to simply add couple of "print" statements around the code and interpret the output. 
On the other hand, I believe the GUI debugger should be a simple UI over the command line debugger (just like gdb+associated GUIs) so we'll have to do the command line version anyway.

Best,
Bogdan
 

>
> My 2c
> -(e)
>
> --
> View this message in context: http://elua-development.2368040.n2.nabble.com/eLua-vs-net-MF-tp6331487p6333433.html
> Sent from the eLua Development mailing list archive at Nabble.com.
> _______________________________________________
> 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


_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
John Hind John Hind
Reply | Threaded
Open this post in threaded view
|

Re: eLua vs. .net MF

I would not personally emphasise the language, the debugger or even the absolute performance as the key issues. Other things being equal, these would be important. However at this stage of the game, for me, the important thing is being able to write a real, useful microcontroller application in a single chip. So the key things are:

 

1. All the hardware I/O features of the chip should be accessible to the high-level language and well documented.

 

2. There should be support for multitasking and event response in the high-level language.

 

3. Memory use (RAM and EPROM) must be frugal enough so you can fit real applications in on-chip memory.

 

I accept eLua has a difficult challenge due to trying to support lots of different chips and boards, but is that the right decision? Microcontrollers are a chip-per-application proposition, so we can afford to buy the chip that supports the software rather than trying to make the software support all the available chips.

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Bogdan Marinescu
Sent: 05 May 2011 09:35
To: eLua Users and Development List (www.eluaproject.net)
Subject: Re: [eLua-dev] eLua vs. .net MF

 

 

On Thu, May 5, 2011 at 11:21 AM, James Snyder <[hidden email]> wrote:

On Thu, May 5, 2011 at 2:37 AM, sweetlilmre <[hidden email]> wrote:


> Hi,
>
> Having used .NETMF extensively one of its main issues for me has been
> interop performance.
>
> When needing to bitbang pins for LED matrix displays etc. it has been
> necessary to extend the firmware see
> http://forums.netduino.com/index.php?/topic/272-bitbanger-driver/page__p__1778__hl__bitbanger__fromsearch__1#entry1778
> NetDuino BitBanger
>
> eLua seems to perform better for this kind of application and seems more
> easily extensible.

I didn't want to jump to conclusions, but I was somewhat presuming

that both of these might be the case.  I figured that the .NET VM
would still end up being somewhat slower than Lua's, and I was curious
about whether or not they had managed to come up with some way to make
it as simply extensible with C modules.


> Also as a language, Lua is significantly easier to learn (for newbies) and I
> find this attractive for teaching purposes.

I can't speak to this directly (since I haven't written anything of
great length or significance in C#), but I would figure that the
syntax and a primarily functional language like Lua + the REPL might
be easier to teach with.


>
> Still both are very interesting and have their place. A really nice
> debugging interface over serial akin to the VS debugger for .NETMF would be
> fantastic for eLua.

This is something I'm not sure if anyone (including myself) on the dev
team is familiar with.  Is there a demo of this somewhere to show how
this works without getting the hardware?  If you look at the roadmap
on the site you'll note there's a "Lua debugging (remote/on target)"
item, and while I think  we know we have some of the components we
might need for such a tool, I'm not sure we've decided what it will
look like (aside from not OpenOCD+gdb ;-) ).

 

I think the OP was talking about high level debugging (debugging Lua code), not the very low level stuff one can do with OpenOCD+gdb. This isn't hard in itself:

 

(there are other examples out there. A simple Lua debugger is almost trivial to write using the "debug" library).

 

The main issue here is presentation. What most people have come to expect when they hear about debuggers is something integrated with a GUI where they can easily do stuff like breakpoint management, variable tracing, program control (on/off/step) and so on. A command line debugger is easy to write, not that easy to use. Without such a GUI and giving the dynamic nature of eLua I believe it's actually more efficient to simply add couple of "print" statements around the code and interpret the output. 

On the other hand, I believe the GUI debugger should be a simple UI over the command line debugger (just like gdb+associated GUIs) so we'll have to do the command line version anyway.

 

Best,

Bogdan

 


>
> My 2c
> -(e)
>
> --
> View this message in context: http://elua-development.2368040.n2.nabble.com/eLua-vs-net-MF-tp6331487p6333433.html
> Sent from the eLua Development mailing list archive at Nabble.com.
> _______________________________________________
> 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

 


_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
sweetlilmre sweetlilmre
Reply | Threaded
Open this post in threaded view
|

Re: eLua vs. .net MF

In reply to this post by jbsnyder
jbsnyder wrote
I didn't want to jump to conclusions, but I was somewhat presuming
that both of these might be the case.  I figured that the .NET VM
would still end up being somewhat slower than Lua's, and I was curious
about whether or not they had managed to come up with some way to make
it as simply extensible with C modules.
Interesting you mention that, I saw this today:

Native code interop

jbsnyder wrote
This is something I'm not sure if anyone (including myself) on the dev
team is familiar with.  Is there a demo of this somewhere to show how
this works without getting the hardware?  If you look at the roadmap
on the site you'll note there's a "Lua debugging (remote/on target)"
item, and while I think  we know we have some of the components we
might need for such a tool, I'm not sure we've decided what it will
look like (aside from not OpenOCD+gdb ;-) ).
Basically its the debugger integration into the VS IDE that is so awesome.
Putting a breakpoint on C# code and hitting F5, then breaking on that line in the device is a world class experience.

I imagine this can be similarly achieved with eLua as Bogdan mentions in his email. Maybe one day when I feel bored and have an immense amount of time available I'll try a VS plugin :)

I would suggest that you spend the $35 or so if you have it and get a NetDuino... Its a really interesting bit of kit.

Thanks
-(e)
BogdanM BogdanM
Reply | Threaded
Open this post in threaded view
|

Re: eLua vs. .net MF

In reply to this post by BogdanM

On Thu, May 5, 2011 at 1:00 PM, John Hind <[hidden email]> wrote:

I would not personally emphasise the language, the debugger or even the absolute performance as the key issues. Other things being equal, these would be important. However at this stage of the game, for me, the important thing is being able to write a real, useful microcontroller application in a single chip. So the key things are:

 

1. All the hardware I/O features of the chip should be accessible to the high-level language and well documented.

 

2. There should be support for multitasking and event response in the high-level language.

 

3. Memory use (RAM and EPROM) must be frugal enough so you can fit real applications in on-chip memory.

 

I accept eLua has a difficult challenge due to trying to support lots of different chips and boards, but is that the right decision?


I don't believe there is a single right decision here. The original plan was to offer Lua on embedded _targets_, not a specific target. In other words, I didn't intend to provide a hardware-software combo like Arduio, Netduino and alike, but a software platform which is as portable and flexible as possible.  Cross-platform compatibility was also an initial goal. In retrospect, I believe that was a good decision. Hardware with resources more appropriate to eLua's needs (mostly RAM) is just starting to emerge. Also, if we decide to go with an "officially supported eLua development board" (yes, there have been some discussions about this) all we have to do is implement a complete platform interface layer in order to have access to all its power (and probably extend the platform interface, but the idea is the same). I strongly believe eLua has the right architecture for the job and this is obviously extremely important. And we still consider an "official eLua hardware" approach.
 

Microcontrollers are a chip-per-application proposition, so we can afford to buy the chip that supports the software rather than trying to make the software support all the available chips.


Absolutely correct.

Best,
Bogdan

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Bogdan Marinescu
Sent: 05 May 2011 09:35


To: eLua Users and Development List (www.eluaproject.net)
Subject: Re: [eLua-dev] eLua vs. .net MF

 

 

On Thu, May 5, 2011 at 11:21 AM, James Snyder <[hidden email]> wrote:

On Thu, May 5, 2011 at 2:37 AM, sweetlilmre <[hidden email]> wrote:
> Hi,
>
> Having used .NETMF extensively one of its main issues for me has been
> interop performance.
>
> When needing to bitbang pins for LED matrix displays etc. it has been
> necessary to extend the firmware see
> http://forums.netduino.com/index.php?/topic/272-bitbanger-driver/page__p__1778__hl__bitbanger__fromsearch__1#entry1778
> NetDuino BitBanger
>
> eLua seems to perform better for this kind of application and seems more
> easily extensible.

I didn't want to jump to conclusions, but I was somewhat presuming
that both of these might be the case.  I figured that the .NET VM
would still end up being somewhat slower than Lua's, and I was curious
about whether or not they had managed to come up with some way to make
it as simply extensible with C modules.


> Also as a language, Lua is significantly easier to learn (for newbies) and I
> find this attractive for teaching purposes.

I can't speak to this directly (since I haven't written anything of
great length or significance in C#), but I would figure that the
syntax and a primarily functional language like Lua + the REPL might
be easier to teach with.


>
> Still both are very interesting and have their place. A really nice
> debugging interface over serial akin to the VS debugger for .NETMF would be
> fantastic for eLua.

This is something I'm not sure if anyone (including myself) on the dev
team is familiar with.  Is there a demo of this somewhere to show how
this works without getting the hardware?  If you look at the roadmap
on the site you'll note there's a "Lua debugging (remote/on target)"
item, and while I think  we know we have some of the components we
might need for such a tool, I'm not sure we've decided what it will
look like (aside from not OpenOCD+gdb ;-) ).

 

I think the OP was talking about high level debugging (debugging Lua code), not the very low level stuff one can do with OpenOCD+gdb. This isn't hard in itself:

 

(there are other examples out there. A simple Lua debugger is almost trivial to write using the "debug" library).

 

The main issue here is presentation. What most people have come to expect when they hear about debuggers is something integrated with a GUI where they can easily do stuff like breakpoint management, variable tracing, program control (on/off/step) and so on. A command line debugger is easy to write, not that easy to use. Without such a GUI and giving the dynamic nature of eLua I believe it's actually more efficient to simply add couple of "print" statements around the code and interpret the output. 

On the other hand, I believe the GUI debugger should be a simple UI over the command line debugger (just like gdb+associated GUIs) so we'll have to do the command line version anyway.

 

Best,

Bogdan

 


>
> My 2c
> -(e)
>
> --
> View this message in context: http://elua-development.2368040.n2.nabble.com/eLua-vs-net-MF-tp6331487p6333433.html
> Sent from the eLua Development mailing list archive at Nabble.com.
> _______________________________________________
> 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

 


_______________________________________________
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
Tim Michals Tim Michals
Reply | Threaded
Open this post in threaded view
|

Re: eLua vs. .net MF

In reply to this post by BogdanM
I'm currently using debugger.lua from luaforge for debugging Lua scripts on a PC.  It acts just like a command line debugger.  The only issue is adding a require("debugger") and a pause function. 
For example:
-- echo command line arguments
require("debugger")

pause("enter debugger")

for i=0,table.getn(arg) do
 print(i,arg[i])
end

LinuxHost:~/projects/lua/lua-5.1.4/test$ lua echo.lua 1212
Lua Debugger
Paused at file echo.lua line 6 (0)
Message: enter debugger
Type 'help' for commands
[DEBUG]> dump table.getn
table.getn = function: 0x25a1f70;
[DEBUG]> dump arg
arg = {  -- table: 0x25a7f50
  [1] = "1212";
  [-1] = "lua";
  [0] = "echo.lua";
};
[DEBUG]>
[DEBUG]>

Some GUI tools use this as the front end to a debugger.  It is like the remdebug but it is like using gdb.  Plus you can add it to your scripts, to stop them and allows you to get the DEBUG prompt.

From: Bogdan Marinescu <[hidden email]>
To: eLua Users and Development List (www.eluaproject.net) <[hidden email]>
Sent: Thursday, May 5, 2011 3:34 AM
Subject: Re: [eLua-dev] eLua vs. .net MF



On Thu, May 5, 2011 at 11:21 AM, James Snyder <[hidden email]> wrote:
On Thu, May 5, 2011 at 2:37 AM, sweetlilmre <[hidden email]> wrote:
> Hi,
>
> Having used .NETMF extensively one of its main issues for me has been
> interop performance.
>
> When needing to bitbang pins for LED matrix displays etc. it has been
> necessary to extend the firmware see
> http://forums.netduino.com/index.php?/topic/272-bitbanger-driver/page__p__1778__hl__bitbanger__fromsearch__1#entry1778
> NetDuino BitBanger
>
> eLua seems to perform better for this kind of application and seems more
> easily extensible.

I didn't want to jump to conclusions, but I was somewhat presuming
that both of these might be the case.  I figured that the .NET VM
would still end up being somewhat slower than Lua's, and I was curious
about whether or not they had managed to come up with some way to make
it as simply extensible with C modules.

> Also as a language, Lua is significantly easier to learn (for newbies) and I
> find this attractive for teaching purposes.

I can't speak to this directly (since I haven't written anything of
great length or significance in C#), but I would figure that the
syntax and a primarily functional language like Lua + the REPL might
be easier to teach with.

>
> Still both are very interesting and have their place. A really nice
> debugging interface over serial akin to the VS debugger for .NETMF would be
> fantastic for eLua.

This is something I'm not sure if anyone (including myself) on the dev
team is familiar with.  Is there a demo of this somewhere to show how
this works without getting the hardware?  If you look at the roadmap
on the site you'll note there's a "Lua debugging (remote/on target)"
item, and while I think  we know we have some of the components we
might need for such a tool, I'm not sure we've decided what it will
look like (aside from not OpenOCD+gdb ;-) ).

I think the OP was talking about high level debugging (debugging Lua code), not the very low level stuff one can do with OpenOCD+gdb. This isn't hard in itself:

(there are other examples out there. A simple Lua debugger is almost trivial to write using the "debug" library).

The main issue here is presentation. What most people have come to expect when they hear about debuggers is something integrated with a GUI where they can easily do stuff like breakpoint management, variable tracing, program control (on/off/step) and so on. A command line debugger is easy to write, not that easy to use. Without such a GUI and giving the dynamic nature of eLua I believe it's actually more efficient to simply add couple of "print" statements around the code and interpret the output. 
On the other hand, I believe the GUI debugger should be a simple UI over the command line debugger (just like gdb+associated GUIs) so we'll have to do the command line version anyway.

Best,
Bogdan
 

>
> My 2c
> -(e)
>
> --
> View this message in context: http://elua-development.2368040.n2.nabble.com/eLua-vs-net-MF-tp6331487p6333433.html
> Sent from the eLua Development mailing list archive at Nabble.com.
> _______________________________________________
> 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


_______________________________________________
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
Tony-12 Tony-12
Reply | Threaded
Open this post in threaded view
|

Re: eLua vs. .net MF

In reply to this post by John Hind
I don't think .NET MF is comparable to eLua.  Although I haven't used the Micro Framework, I have used both .NET (mostly VB.NET) and interpretive languages (a Python/VB6 combo) extensively, with many machines using both approaches in the field.  The real .NET comparable to Lua isn't C#,it's Boo, IronPython, or IronRuby.

If I had to choose between VisualStudio and its debugger or a high level interactive language (such as Python or Lua) with no IDE, I'd choose the latter.  Using an interactive system is a great way to both learn new hardware and to debug; my Python/VB6 code is setup so I can access all the Python objects via the interpreter, and thus I can interactively test, look at the results, try something, check out the new results, and so on.

The comparable for VisualStudio also isn't eLua, but other IDEs such as Eclipse, Netbeans, Code Composer Studio (based on Eclipse) and MPLAB X (based on Netbeans).  I don't think VS is any better than those -- and many of these are now cross platform.  JTAG isn't such a big deal now; stand-alone JTAG interfaces are pretty reasonable for many architectures (heck, TI has open sourced the XDS 100), and are included on most development kits.

I think the eLua cross-platform approach is correct; for example, the selection of .NET MF chips and boards available from GHI and Netduino is quite limited.  The NXP (GHI) and Atmel (Netduino) chips are nice, but are missing some pretty cool peripherals available on the eLua supported STM32 and Stellaris.  BTW, GHI's pricing for their chips is reasonable; a USBizi100 is $16.95; the LPC2387 is $13.44.

However, although most modern MCUs are supplied with a lot of software (e.g. StellarisWare), I can see why the .NET MF is a good choose for some situations: I'm quite sure it's much simpler to get started in VisualStudio + C# + GHI/Netduino than IDE (Eclipse,etc) + C/C++ + assorted supplied and open source libraries.

BTW, at first I confused the FEZ Panda board with the PandaBoard ( pandaboard.org ); they're quite different animals.

--Tony

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