eLua vs. .net MF
Locked
|
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 |
|
|
Hi,
On Wed, May 4, 2011 at 7:04 PM, John Hind <[hidden email]> wrote:
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 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 |
|
|
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 |
|
|
2011/5/4 Ronan Paixão <[hidden email]> Actually, the problem with eLua not having better device driver 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 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]>: _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
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 |
|
|
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? ;) - 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 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 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]>: _______________________________________________ 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 |
|
|
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) |
|
|
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 |
|
|
On Thu, May 5, 2011 at 11:21 AM, James Snyder <[hidden email]> wrote:
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
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
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 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 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.
I can't speak to this directly (since I haven't written anything of
This is something I'm not sure if anyone (including myself) on the dev 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
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by jbsnyder
Interesting you mention that, I saw this today: Native code interop 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) |
|
|
In reply to this post by BogdanM
On Thu, May 5, 2011 at 1:00 PM, John Hind <[hidden email]> wrote:
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.
Absolutely correct. Best, Bogdan
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
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:
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
_______________________________________________ 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 |
|
|
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 |
| Free forum by Nabble | Edit this page |