Raspberry Pi as comprehensive eLua solution ?

[jbsnyder]

--
James Snyder
Biomedical Engineering
Northwestern University
http://fanplastic.org/key.txt
ph: [phone]



On Thursday, May 17, 2012 at 1:23 AM, Bogdan Marinescu wrote:

> Hi,
>
> On Wed, May 16, 2012 at 4:06 PM, Patrick <[hidden email] (mailto:[hidden email])> wrote:
> > Hi Bogdan
> >
> > I am feeling silly about my post now. Of course eLua runs on bare metal and
> > not under an OS, DUH!
> >
> > What I should have said, is "could eLua run under an OS" but having thought
> > this through a little more, this is equally stupid. Why take a complex,
> > feature rich code base and rip out features until your left with what... the
> > ability to control 8 GPIO pins, an LED and maybe a TCP/IP stack? not an
> > intelligent use of time...
>
>
>
> This is exactly my problem too. Especially when it comes to
> networking, when Linux has a full stack which is light years better
> than what eLua can do at the moment.
>
> >
> > So would this be sensible...
> >
> > Assuming that these boards(Olimex/BeagleBoard/Raspberry PI etc) have C
> > libraries for their limited peripherals, would it be sensible to write Lua
> > bindings for them?
>
>
>
> It does, yes. Except you won't be writing bindings for them directly,
> you'd write bindings for whatever driver the kernel uses for them.
> Fortunately, the kernel driver base is very good, although the way
> they choose to expose some I/O functionality (for example via files in
> /dev) can sometimes feel unnatural (at least to me).
>
> >
> > It could be a totally different code base but retain the same API, a sort of
> > eLua-Lite.
>
>
>
> You won't be able to retain the same API, unfortunately. For example,
> everything that has to do with interrupts will go away instantly,
> since that is handled by the kernel. Many other functions in various
> libraries will have to change too.

This is true to some extent.  The model for "eLua interrupts" doesn't necessarily need to be entirely redone though, since it's basically just a mechanism for queueing and executing code based on events that happen outside of the interpreter.

That said, for some of this, one might be best served by sitting on top of libevent or libev to provide some of that type of functionality in a flexible manner.

Likewise, as available, one could sit on top of libraries that provide some cross-platform compatibility, especially if what one could do is use existing Lua libraries like LuaSocket that are well tested.

>
> >
> > Here is a bit of my workflow and logic(if it's okay to call it that!).
> >
> > Using WebBuilder and CuteCom, I've written some simple blink like programs.
> > I am sure WebBuilder can do much more then this and it's just my limited
> > time that's the issue.....
> >
> > I sometimes download other people's .BIN files. When I do, I have to copy
> > them to a USB key, go downstairs, Boot up a Windoze 2000 machine and use the
> > piece-o-sh*t, proprietary Luminary program to flash my board.
>
>
>
> Yes, I know how that feels ... There are ways to flash even those
> boards from Linux though, you just have to dig on the net a bit (I
> don't have a link right now, otherwise I would've given it to you).

If you'll mention again what board you're using, I can try and update our guides a little bit.  I basically just have some shell scripts and a load script that I've been using on LM3S w/ built-in JTAG and OpenOCD for ages that has worked well for me.  I've also got variations for using different targets and JTAG interfaces.

 

>
> >
> > I have a JTAG pod on it's way and I hope to set up a cross compiler soon but
> > so far in the limited time I have been able to spend on the project flashing
> > has been an issue and adding C code to a project looks like it will take
> > some time.
>
>
>
> Why would you need to setup a cross compiler yourself? Just use
> CodeSourcery's (now Mentor Graphics) lite edition cross compiler
> packages and you can cross an item from your TODO list.

I heartily agree with this.  G++ Lite is excellent, tested and precompiled for Linux & Windows.
 

>
> >
> > I was thinking that if eLua-Lite was as easy as installing a deb package or
> > downloading from a repository, then someone could have an LED blinking in
> > under a minute as eLua-Lite is already running on the target. Other features
> > such as a cross compiler could be included as well.
>
>
>
> What you say makes a lot of sense, but mainly in the form of standard
> Lua C modules used with stock Lua. There's really no need to use eLua
> for this stuff as far as I can see. BTW, this would be a very nice
> project. The Raspberry Pi was designed (amongst other things) to be a
> Python development machine, but I have a very strong feeling that it
> would be much better used as a Lua development machine. I'd start this
> project myself if I had the time ...
>
> >
> > Someone could play with the eLua like features and then start flashing a
> > real target via JTAG right from the first board and then pretty soon just
> > dump eLua-Lite and use the real thing.
>
>
>
> Sadly, I can't see this happening, as we can't provide a fully
> compatible API (as explained).
>
> >
> > The only benefit I see here is a lower barrier to entry but I think that is
> > still worth something.
> >
> > More logical? or should I get back to my crack pipe? :)
>
> I believed I covered the "logical" part. As for your crack pipe ...
> you know what they say, sharing is good for your soul :D
>
> Best,
> Bogdan
>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On 12-05-14 05:11 AM, Bogdan Marinescu wrote:
> > >
> > > Hi Patrick,
> > >
> > > On Sun, May 13, 2012 at 12:54 AM, Patrick
> > > <[hidden email] (mailto:[hidden email])> wrote:
> > > >
> > > > Hi Guys
> > > >
> > > > The past few months have been difficult. It looks like daughter is also
> > > > about to be diagnosed with Autism.
> > >
> > >
> > >
> > > Sorry to hear that :( I wish the best of luck to you and your daughter.
> > >
> > > > The project I have been working on for my
> > > > Son looked easier as a desktop solution, so I've ignored everything
> > > > embedded. Now it looks viable as embedded and i am back again. i need to
> > > > follow along with what is best for my kids and my business, i haven't
> > > > been
> > > > able to do anything just for my own interest.
> > > >
> > > > I hope to resume the screencast tutorials I started(or barely
> > > > started)earlier in the year, sorry about the interruption.
> > > >
> > > >
> > > > So enough rambling....I am planning on buying a Raspberry Pi for my son's
> > > > project and it got me thinking about eLua.
> > >
> > >
> > >
> > > I got a Raspberry coming my way too :)
> > >
> > > > This device boots a full Linux desktop(LDXE). I was thinking that if I(or
> > > > we) could rework a distro so that it ships with eLua, Nuccio's text
> > > > editor,
> > > > GCC, OpenOCD and any other useful tools, then it would provide a native
> > > > build environment for many of the boards the project targets, GCC on arm
> > > > is
> > > > not a cross compiler!
> > >
> > >
> > >
> > > You can't have a distribution with both eLua and GCC/OpenOCD. GCC
> > > needs an OS (like Linux) to run on, eLua is itself a
> > > mini-and-extremely-basic-OS (and you certainly won't be able to run
> > > GCC on top of eLua :) ). You could probably find a virtualization
> > > setup suitable for this task, but where's the fun in that? GCC on ARM
> > > is indeed not a cross-compiler, but this isn't an issue at all. Cross
> > > compilers make as good of a job as native compilers do.
> > >
> > > > With a jtag programmer preconfigured via OpenOCD and it could also make
> > > > for
> > > > an easy environment to flash lighter weight ARM boards from.
> > >
> > >
> > >
> > > This would be indeed an interesting project, but again, it would have
> > > to run under Linux. While it's probably possible to make OpenOCD run
> > > on bare metal, I can't see an advantage to this.
> > >
> > > > If it had SSH and/or NFS installed then it could also be used in tandem
> > > > with
> > > > a full power desktop. People could open remote directories for editing in
> > > > their desktop computers and initiate commands via SSH(like gcc).
> > > >
> > > > This device also has 8 GPIO pins and could provide something to play with
> > > > without the user having to be concerned about flashing at all.
> > >
> > >
> > >
> > > And that's the main problem with this category of devices. They are
> > > built around CPUs, not MCUs, so you loose the convenience of using
> > > on-chip peripherals (like PWM, UARTs and so on) from the start. Sure,
> > > you can add everything you need over USB and other interfaces, but at
> > > that point it really doesn't make much sense to use the board as a
> > > bare metal platform (working an USB drivers alone is a huge PITA). On
> > > a somewhat related topic, don't even get me started on their extremely
> > > bizarre NDA policy (I'm really struggling to keep a polite tone right
> > > now). I refuse to work with manufacturers who release a CPU/MCU and
> > > refuse to make the documentation public, as if you could do anything
> > > at all with that chip without documentation (and actually getting the
> > > documentation involves a lot of time, effort and maybe even lawyers)).
> > > This simply doesn't make any sense at all in my engineerish mind and
> > > thus I choose to not have anything to do with it.
> > >
> > > > I have a couple of concerns.
> > > >
> > > > One the board is in short supply.
> > > >
> > > > Two, just because it's a Debian/Fedora ARM build environment might not
> > > > make
> > > > it suitable for all ARM targets. I don't know how much the various ARMs
> > > > differ?
> > >
> > >
> > >
> > > You needn't worry about that. Cross compilers are available on all
> > > Linux distros that I know of and they are very good at their job. The
> > > ARMs can differ quite a bit, but that's for the compiler to worry
> > > about (most of the time :) ).
> > > All in all, I'd second Martin's oppinion: get a Mizar32 (or other
> > > board that supports eLua), you're likely to get a much more pleasant
> > > experience as far as eLua is concerned.
> > >
> > > Best,
> > > Bogdan
> > >
> > > > Any thoughts on this on this project-Patrick
> > > > _______________________________________________
> > > > eLua-dev mailing list
> > > > [hidden email] (mailto:[hidden email])
> > > > https://lists.berlios.de/mailman/listinfo/elua-dev
> > >
> > >
> > >
> > > _______________________________________________
> > > eLua-dev mailing list
> > > [hidden email] (mailto:[hidden email])
> > > https://lists.berlios.de/mailman/listinfo/elua-dev
> >
> >
> >
> > _______________________________________________
> > eLua-dev mailing list
> > [hidden email] (mailto:[hidden email])
> > https://lists.berlios.de/mailman/listinfo/elua-dev
>
>
> _______________________________________________
> eLua-dev mailing list
> [hidden email] (mailto:[hidden email])
> https://lists.berlios.de/mailman/listinfo/elua-dev

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

[Patrick Mc(avery]

If you'll mention again what board you're using, I can try and update
our guides a little bit.  I basically just have some shell scripts and a
load script that I've been using on LM3S w/ built-in JTAG and OpenOCD
for ages that has worked well for me.  I've also got variations for
using different targets and JTAG interfaces.

Hi James

I have a LM3S8962 board. The JTAG POD is shipping via post from the US,
so it might not be here for another week or so.

One of these days, i will  get back to my screencast tutorials. I plan
on doing a JTAG one so I will pass along whatever I can when I am able
to do them again.

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