eLua heading into a product

[Matt Wilbur]

About a year ago I made the pitch to use eLua as a platform for the self-diagnostics software of my employer's next modem.  It'll be going into pre-production soon!

Let me know if you're interested in more details.  I'll provide what I can.

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

[BogdanM]

Hi Matt,

On Mon, Jan 23, 2012 at 2:29 PM, Matt Wilbur <[hidden email]> wrote:
> About a year ago I made the pitch to use eLua as a platform for the
> self-diagnostics software of my employer's next modem.  It'll be going into
> pre-production soon!
>
> Let me know if you're interested in more details.  I'll provide what I can.

Are you kidding me ?! Hit me with all you got! :)

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

[Matt Wilbur]

On Monday, 23 January, 2012 at 7:32 AM, Bogdan Marinescu wrote:

Hi Matt,

On Mon, Jan 23, 2012 at 2:29 PM, Matt Wilbur <[hidden email]> wrote:

About a year ago I made the pitch to use eLua as a platform for the

self-diagnostics software of my employer's next modem.  It'll be going into

pre-production soon!

Let me know if you're interested in more details.  I'll provide what I can.

Are you kidding me ?! Hit me with all you got! :)

First:

Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. 

 

Backstory:

I was tasked with software to help do diagnostics software of an embedded product.  Typically, our products are based on embedded linux, and design-verification test (DVT) and functional test (FT) have all used horrendous bash scripts to test the system.  I mean, the scripts were ugly.  Really ugly.

Additionally, there was no easy way to test low level interfaces (SPI, I2C, etc).  So, one could get an RMA and really have an enormous fault tree to deal with.  Also, lots of NFF boards meant we wanted to try to test the product in situ before it was sent back, if necessary.

Finally, there was a desire to separate the "mission mode" software with the diagnostics and test software.  Updates to "mission mode" software would sometimes cause production test software to break, resulting in an ugly double reflashing of pre-programmed parts during production.

Initially, there was a push to use another linux system for test, but I pushed back on this quite vigourously.  Why incur the overhead a multi-user pre-emptive OS to bit bash pins?  Then u-boot was suggested.  Oy.  So much baggage.

Finally, I proposed eLua.  I had read about it some time ago and wanted a way to use it somewhere in something.  I'm a micro controller nerd at heart.  For better or for worse, others weren't really paying too much attention, said "Ok", and I ran with it.  It was ideal for my needs - interactive, flexible, scriptable, low level, super super easy to extend with C.  However, we are using a Freescale PowerPC microprocessor (er -- Power Architecture, my bad).  So, I had to work on the port from scratch.

What I have now is a series of tests that a run via autorun.lua when eLua starts.  An SPI boot loader, written by me, loads the eLua binary from SPI flash into ram and vectors to eLua.  Then all tests run, optionally dropping to the eLua after the shell.  The tests gradually "walk" out from a SPI flash / SRAM only start (the SPI boot loader, which tests DDR), to eLua which then tests peripherals such as I2C, SPI, local bus, PCIe.  It then talks to an FPGA via the local bus which thens tests its interfaces.  There is an soft-core processor on the FPGA running software.  The messaging lua code is partially generated via a YAML description.

I only have polling-mode drivers, as the OpenPIC used in PPC is not well documented.  Documentation brags about using this "Open" standard.  Try to find a copy.  It's impossible.  Anyhow, I want to go down that road, but don't have time at the moment.  Also, the MMU is always "on" in the processor, and there are at one, usually two, and sometimes three levels of memory translation to get to a peripheral.  It is a pain.  However, I'm pretty sure I understand this better than anyone else in the company now.

What I do have is:

Timers

SPI

I2C

UART

GPIO

RPC works great.  I haven't gotten XMODEM going yet, but I haven't really looked into it yet.  I'd love to use Go@.  I can't use RFS because of no interrupts.  So, I have leveraged RPC for development, effectively using it to upload code.  I put all my functions into a table and create remote objects on the modem, and add references into _G in order to make them "look" local.  It actually works pretty well, as long as I remember not to print.

I also added a raw module (people at my company are addicted to peeks and pokes), but at first opportunity, I remove these uses.  Some of the Freescale peripherals do not play well with the eLua model.  I2C, in particular.  I have never seen a more convoluted peripheral.  I wrote fairly generic-ish drivers, and wrapped them to glue them into eLua.  That way, I could use them for my SPI boot loader.

I built the powerpc-eabi toolchain in a very similar manner to James' ARM methodology, but before I knew about his stuff.  It was a lot of going through ugly shell scripts (no, I don't like shell scripts) but, it allowed me to apply the size optimizations to the C library.  I have started on a MINIX C library port for eLua, but am doing that on my own time to ensure there is no issue releasing it.  However, I have very little of my own time.

It broke my heart when I couldn't fit it all into 256k.  The processor I have can be configured to use 256k of L2 cache as SRAM.  But, I am loading from SPI flash, and can't execute in place, so the whole enchilada must fit, and 32-bit RISC is, apparently, not space efficient.  So, I have to use the DDR2 attached to the processor.  If parallel NOR were an option, I could do that (I did try it), but then was relegated to SPI.

What I really like:

So little baggage.  eLua gives you lua with a nice clean interface to peripherals.  The Platform Interface design was a very very good idea.

I can write my scripts in lua, and if speed is an issue, I can put selected portions in C.  Users are none the wiser.

I just love the C-lua interface.  It is so easy to cross.  Using RO tables is very painless.  I can be as low-level or high-level as I want.  With the interactivity, I can easily test things out, and paste it into a script.  Then, once it is working, just via dofile, I migrate to a module.

I can test program logic on my desktop as long as I have some "fakes" setup.  I'd really like to systematize mocks for the eLua modules to allow for easier desktop development.  I hand craft them right now, but perhaps luaspec or lemock might be useful.

Separation of SConstruct and conf.py is really nice.

What I don't like (not eLua's fault):

Lua's requirement to touch several files to add a new module.

Phew.  That's a lot.  Sorry if there's too much, or not enough specific to eLua.  But I've been slaving away for almost a year in obscurity, and enjoy telling about it.  However, I believe eLua's star is finally rising at my employer and people are able to see the benefit.  For example, I was able to turn a custom load for the Hardware team in < 0.5 a day.  Let's see you do that in linux.  And keep it all to about 256k.

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

[Matt Wilbur]

Oh…I also started on a JTAG module to let eLua be used as 1149.1 master.

On Tuesday, 24 January, 2012 at 6:55 AM, Matt Wilbur wrote:

On Monday, 23 January, 2012 at 7:32 AM, Bogdan Marinescu wrote:

Hi Matt,

On Mon, Jan 23, 2012 at 2:29 PM, Matt Wilbur <[hidden email]> wrote:

About a year ago I made the pitch to use eLua as a platform for the

self-diagnostics software of my employer's next modem.  It'll be going into

pre-production soon!

Let me know if you're interested in more details.  I'll provide what I can.

Are you kidding me ?! Hit me with all you got! :)

First:

Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. 

 

Backstory:

I was tasked with software to help do diagnostics software of an embedded product.  Typically, our products are based on embedded linux, and design-verification test (DVT) and functional test (FT) have all used horrendous bash scripts to test the system.  I mean, the scripts were ugly.  Really ugly.

Additionally, there was no easy way to test low level interfaces (SPI, I2C, etc).  So, one could get an RMA and really have an enormous fault tree to deal with.  Also, lots of NFF boards meant we wanted to try to test the product in situ before it was sent back, if necessary.

Finally, there was a desire to separate the "mission mode" software with the diagnostics and test software.  Updates to "mission mode" software would sometimes cause production test software to break, resulting in an ugly double reflashing of pre-programmed parts during production.

Initially, there was a push to use another linux system for test, but I pushed back on this quite vigourously.  Why incur the overhead a multi-user pre-emptive OS to bit bash pins?  Then u-boot was suggested.  Oy.  So much baggage.

Finally, I proposed eLua.  I had read about it some time ago and wanted a way to use it somewhere in something.  I'm a micro controller nerd at heart.  For better or for worse, others weren't really paying too much attention, said "Ok", and I ran with it.  It was ideal for my needs - interactive, flexible, scriptable, low level, super super easy to extend with C.  However, we are using a Freescale PowerPC microprocessor (er -- Power Architecture, my bad).  So, I had to work on the port from scratch.

What I have now is a series of tests that a run via autorun.lua when eLua starts.  An SPI boot loader, written by me, loads the eLua binary from SPI flash into ram and vectors to eLua.  Then all tests run, optionally dropping to the eLua after the shell.  The tests gradually "walk" out from a SPI flash / SRAM only start (the SPI boot loader, which tests DDR), to eLua which then tests peripherals such as I2C, SPI, local bus, PCIe.  It then talks to an FPGA via the local bus which thens tests its interfaces.  There is an soft-core processor on the FPGA running software.  The messaging lua code is partially generated via a YAML description.

I only have polling-mode drivers, as the OpenPIC used in PPC is not well documented.  Documentation brags about using this "Open" standard.  Try to find a copy.  It's impossible.  Anyhow, I want to go down that road, but don't have time at the moment.  Also, the MMU is always "on" in the processor, and there are at one, usually two, and sometimes three levels of memory translation to get to a peripheral.  It is a pain.  However, I'm pretty sure I understand this better than anyone else in the company now.

What I do have is:

Timers

SPI

I2C

UART

GPIO

RPC works great.  I haven't gotten XMODEM going yet, but I haven't really looked into it yet.  I'd love to use Go@.  I can't use RFS because of no interrupts.  So, I have leveraged RPC for development, effectively using it to upload code.  I put all my functions into a table and create remote objects on the modem, and add references into _G in order to make them "look" local.  It actually works pretty well, as long as I remember not to print.

I also added a raw module (people at my company are addicted to peeks and pokes), but at first opportunity, I remove these uses.  Some of the Freescale peripherals do not play well with the eLua model.  I2C, in particular.  I have never seen a more convoluted peripheral.  I wrote fairly generic-ish drivers, and wrapped them to glue them into eLua.  That way, I could use them for my SPI boot loader.

I built the powerpc-eabi toolchain in a very similar manner to James' ARM methodology, but before I knew about his stuff.  It was a lot of going through ugly shell scripts (no, I don't like shell scripts) but, it allowed me to apply the size optimizations to the C library.  I have started on a MINIX C library port for eLua, but am doing that on my own time to ensure there is no issue releasing it.  However, I have very little of my own time.

It broke my heart when I couldn't fit it all into 256k.  The processor I have can be configured to use 256k of L2 cache as SRAM.  But, I am loading from SPI flash, and can't execute in place, so the whole enchilada must fit, and 32-bit RISC is, apparently, not space efficient.  So, I have to use the DDR2 attached to the processor.  If parallel NOR were an option, I could do that (I did try it), but then was relegated to SPI.

What I really like:

So little baggage.  eLua gives you lua with a nice clean interface to peripherals.  The Platform Interface design was a very very good idea.

I can write my scripts in lua, and if speed is an issue, I can put selected portions in C.  Users are none the wiser.

I just love the C-lua interface.  It is so easy to cross.  Using RO tables is very painless.  I can be as low-level or high-level as I want.  With the interactivity, I can easily test things out, and paste it into a script.  Then, once it is working, just via dofile, I migrate to a module.

I can test program logic on my desktop as long as I have some "fakes" setup.  I'd really like to systematize mocks for the eLua modules to allow for easier desktop development.  I hand craft them right now, but perhaps luaspec or lemock might be useful.

Separation of SConstruct and conf.py is really nice.

What I don't like (not eLua's fault):

Lua's requirement to touch several files to add a new module.

Phew.  That's a lot.  Sorry if there's too much, or not enough specific to eLua.  But I've been slaving away for almost a year in obscurity, and enjoy telling about it.  However, I believe eLua's star is finally rising at my employer and people are able to see the benefit.  For example, I was able to turn a custom load for the Hardware team in < 0.5 a day.  Let's see you do that in linux.  And keep it all to about 256k.

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

[Heinz]

Hi Matt,

thank you so much for the description. I guess most on the list will just like it.
I couldn't stop reading ;-)
It pretty much explains the heart of eLUA as I see it as well.
Supporting a layerd  modular structure where LUA acts as a
(pretty good!) glue code with fast round trips.

And since in testing scripts are used often, LUA ist just perfect there.
I use LUA within an embedded linux box for this purpose as well.

So you are running eLUA on the same device the linux is normally running on.
But you are focusing on 'testing hardware behaviour'. Right? That
would be a pretty neat setup for HW-guys and for the purpose of bridging
hw to sw on the proess of development.

Or is eLUA acting as a Testsystem and simulating the environment for the SUT (system under test)?

Heinz


Am 24.01.2012 12:55, schrieb Matt Wilbur:

On Monday, 23 January, 2012 at 7:32 AM, Bogdan Marinescu wrote:

Hi Matt,

On Mon, Jan 23, 2012 at 2:29 PM, Matt Wilbur <[hidden email]> wrote:

About a year ago I made the pitch to use eLua as a platform for the

self-diagnostics software of my employer's next modem.  It'll be going into

pre-production soon!

Let me know if you're interested in more details.  I'll provide what I can.

Are you kidding me ?! Hit me with all you got! :)

First:

Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. 

 

Backstory:

I was tasked with software to help do diagnostics software of an embedded product.  Typically, our products are based on embedded linux, and design-verification test (DVT) and functional test (FT) have all used horrendous bash scripts to test the system.  I mean, the scripts were ugly.  Really ugly.

Additionally, there was no easy way to test low level interfaces (SPI, I2C, etc).  So, one could get an RMA and really have an enormous fault tree to deal with.  Also, lots of NFF boards meant we wanted to try to test the product in situ before it was sent back, if necessary.

Finally, there was a desire to separate the "mission mode" software with the diagnostics and test software.  Updates to "mission mode" software would sometimes cause production test software to break, resulting in an ugly double reflashing of pre-programmed parts during production.

Initially, there was a push to use another linux system for test, but I pushed back on this quite vigourously.  Why incur the overhead a multi-user pre-emptive OS to bit bash pins?  Then u-boot was suggested.  Oy.  So much baggage.

Finally, I proposed eLua.  I had read about it some time ago and wanted a way to use it somewhere in something.  I'm a micro controller nerd at heart.  For better or for worse, others weren't really paying too much attention, said "Ok", and I ran with it.  It was ideal for my needs - interactive, flexible, scriptable, low level, super super easy to extend with C.  However, we are using a Freescale PowerPC microprocessor (er -- Power Architecture, my bad).  So, I had to work on the port from scratch.

What I have now is a series of tests that a run via autorun.lua when eLua starts.  An SPI boot loader, written by me, loads the eLua binary from SPI flash into ram and vectors to eLua.  Then all tests run, optionally dropping to the eLua after the shell.  The tests gradually "walk" out from a SPI flash / SRAM only start (the SPI boot loader, which tests DDR), to eLua which then tests peripherals such as I2C, SPI, local bus, PCIe.  It then talks to an FPGA via the local bus which thens tests its interfaces.  There is an soft-core processor on the FPGA running software.  The messaging lua code is partially generated via a YAML description.

I only have polling-mode drivers, as the OpenPIC used in PPC is not well documented.  Documentation brags about using this "Open" standard.  Try to find a copy.  It's impossible.  Anyhow, I want to go down that road, but don't have time at the moment.  Also, the MMU is always "on" in the processor, and there are at one, usually two, and sometimes three levels of memory translation to get to a peripheral.  It is a pain.  However, I'm pretty sure I understand this better than anyone else in the company now.

What I do have is:

Timers

SPI

I2C

UART

GPIO

RPC works great.  I haven't gotten XMODEM going yet, but I haven't really looked into it yet.  I'd love to use Go@.  I can't use RFS because of no interrupts.  So, I have leveraged RPC for development, effectively using it to upload code.  I put all my functions into a table and create remote objects on the modem, and add references into _G in order to make them "look" local.  It actually works pretty well, as long as I remember not to print.

I also added a raw module (people at my company are addicted to peeks and pokes), but at first opportunity, I remove these uses.  Some of the Freescale peripherals do not play well with the eLua model.  I2C, in particular.  I have never seen a more convoluted peripheral.  I wrote fairly generic-ish drivers, and wrapped them to glue them into eLua.  That way, I could use them for my SPI boot loader.

I built the powerpc-eabi toolchain in a very similar manner to James' ARM methodology, but before I knew about his stuff.  It was a lot of going through ugly shell scripts (no, I don't like shell scripts) but, it allowed me to apply the size optimizations to the C library.  I have started on a MINIX C library port for eLua, but am doing that on my own time to ensure there is no issue releasing it.  However, I have very little of my own time.

It broke my heart when I couldn't fit it all into 256k.  The processor I have can be configured to use 256k of L2 cache as SRAM.  But, I am loading from SPI flash, and can't execute in place, so the whole enchilada must fit, and 32-bit RISC is, apparently, not space efficient.  So, I have to use the DDR2 attached to the processor.  If parallel NOR were an option, I could do that (I did try it), but then was relegated to SPI.

What I really like:

So little baggage.  eLua gives you lua with a nice clean interface to peripherals.  The Platform Interface design was a very very good idea.

I can write my scripts in lua, and if speed is an issue, I can put selected portions in C.  Users are none the wiser.

I just love the C-lua interface.  It is so easy to cross.  Using RO tables is very painless.  I can be as low-level or high-level as I want.  With the interactivity, I can easily test things out, and paste it into a script.  Then, once it is working, just via dofile, I migrate to a module.

I can test program logic on my desktop as long as I have some "fakes" setup.  I'd really like to systematize mocks for the eLua modules to allow for easier desktop development.  I hand craft them right now, but perhaps luaspec or lemock might be useful.

Separation of SConstruct and conf.py is really nice.

What I don't like (not eLua's fault):

Lua's requirement to touch several files to add a new module.

Phew.  That's a lot.  Sorry if there's too much, or not enough specific to eLua.  But I've been slaving away for almost a year in obscurity, and enjoy telling about it.  However, I believe eLua's star is finally rising at my employer and people are able to see the benefit.  For example, I was able to turn a custom load for the Hardware team in < 0.5 a day.  Let's see you do that in linux.  And keep it all to about 256k.

_______________________________________________
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

[Patrick Mc(avery]

Hi Matt

Thanks very much for sharing your story. I think this project has a
bright future and with pioneers like you trailblazing we'll all get
there faster-Patrick
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[jbsnyder]

On Tue, Jan 24, 2012 at 5:55 AM, Matt Wilbur <[hidden email]> wrote:

>
> On Monday, 23 January, 2012 at 7:32 AM, Bogdan Marinescu wrote:
>
> Hi Matt,
>
> On Mon, Jan 23, 2012 at 2:29 PM, Matt Wilbur <[hidden email]> wrote:
>
> About a year ago I made the pitch to use eLua as a platform for the
> self-diagnostics software of my employer's next modem.  It'll be going into
> pre-production soon!
>
> Let me know if you're interested in more details.  I'll provide what I can.
>
>
> Are you kidding me ?! Hit me with all you got! :)
>
> First:
>
> Any views or opinions presented in this email are solely those of the author
> and do not necessarily represent those of the company.
>
> Backstory:
>
> I was tasked with software to help do diagnostics software of an embedded
> product.  Typically, our products are based on embedded linux, and
> design-verification test (DVT) and functional test (FT) have all used
> horrendous bash scripts to test the system.  I mean, the scripts were ugly.
>  Really ugly.
>
> Additionally, there was no easy way to test low level interfaces (SPI, I2C,
> etc).  So, one could get an RMA and really have an enormous fault tree to
> deal with.  Also, lots of NFF boards meant we wanted to try to test the
> product in situ before it was sent back, if necessary.
>
> Finally, there was a desire to separate the "mission mode" software with the
> diagnostics and test software.  Updates to "mission mode" software would
> sometimes cause production test software to break, resulting in an ugly
> double reflashing of pre-programmed parts during production.
>
> Initially, there was a push to use another linux system for test, but I
> pushed back on this quite vigourously.  Why incur the overhead a multi-user
> pre-emptive OS to bit bash pins?  Then u-boot was suggested.  Oy.  So much
> baggage.
>
> Finally, I proposed eLua.  I had read about it some time ago and wanted a
> way to use it somewhere in something.  I'm a micro controller nerd at heart.
>  For better or for worse, others weren't really paying too much attention,
> said "Ok", and I ran with it.  It was ideal for my needs - interactive,
> flexible, scriptable, low level, super super easy to extend with C.
>  However, we are using a Freescale PowerPC microprocessor (er -- Power
> Architecture, my bad).  So, I had to work on the port from scratch.

Generally I think many would look at Power as being a bit on the large
side for eLua (might be one of the reasons we don't officially have a
port), but this points out a very nice use case for these slightly
larger embedded platforms where one can cram a fairly flexible
environment and use it as an (nearly) instant-on testing environment
that can be crammed into a fairly small space.

>
> What I have now is a series of tests that a run via autorun.lua when eLua
> starts.  An SPI boot loader, written by me, loads the eLua binary from SPI
> flash into ram and vectors to eLua.  Then all tests run, optionally dropping
> to the eLua after the shell.  The tests gradually "walk" out from a SPI
> flash / SRAM only start (the SPI boot loader, which tests DDR), to eLua
> which then tests peripherals such as I2C, SPI, local bus, PCIe.  It then
> talks to an FPGA via the local bus which thens tests its interfaces.  There
> is an soft-core processor on the FPGA running software.  The messaging lua
> code is partially generated via a YAML description.
>
> I only have polling-mode drivers, as the OpenPIC used in PPC is not well
> documented.  Documentation brags about using this "Open" standard.  Try to
> find a copy.  It's impossible.  Anyhow, I want to go down that road, but
> don't have time at the moment.

No need.  The words "standard" and "open" have had innumerable
meanings over the years, many of which sound like complete opposites
to what one might think those words mean.

>  Also, the MMU is always "on" in the
> processor, and there are at one, usually two, and sometimes three levels of
> memory translation to get to a peripheral.  It is a pain.  However, I'm
> pretty sure I understand this better than anyone else in the company now.

While I've never worked things at that low of a level on that
platform, that does bring to mind a Torvalds quote:
"The memory management on the PowerPC can be used to frighten small children"

>
> What I do have is:
>
> Timers
> SPI
> I2C
> UART
> GPIO
>
> RPC works great.  I haven't gotten XMODEM going yet, but I haven't really
> looked into it yet.  I'd love to use Go@.  I can't use RFS because of no
> interrupts.  So, I have leveraged RPC for development, effectively using it
> to upload code.  I put all my functions into a table and create remote
> objects on the modem, and add references into _G in order to make them
> "look" local.  It actually works pretty well, as long as I remember not to
> print.

Glad to hear it :-)

>
> I also added a raw module (people at my company are addicted to peeks and
> pokes), but at first opportunity, I remove these uses.  Some of the
> Freescale peripherals do not play well with the eLua model.

There are some functions like this in the CPU module:
http://www.eluaproject.net/doc/v0.8/en_refman_gen_cpu.html

I'm not sure if you're using integer or floating point, is this
related to not being able to store enough precision in the mantissa of
a floating point number?

>  I2C, in
> particular.  I have never seen a more convoluted peripheral.  I wrote fairly
> generic-ish drivers, and wrapped them to glue them into eLua.  That way, I
> could use them for my SPI boot loader.
>
> I built the powerpc-eabi toolchain in a very similar manner to James' ARM
> methodology, but before I knew about his stuff.  It was a lot of going
> through ugly shell scripts (no, I don't like shell scripts) but, it allowed
> me to apply the size optimizations to the C library.  I have started on a
> MINIX C library port for eLua, but am doing that on my own time to ensure
> there is no issue releasing it.  However, I have very little of my own time.

We'd certainly welcome any contributions on that front.  Having looked
around some, I'd love to have a clean, as simple as possible,
permissively licensed, ANSI C implementation of the standard C
library.  Nothing I've found so far seems to fit all of that at the
same time, but the minix libc seems to be commonly discussed as a good
starting point.

>
> It broke my heart when I couldn't fit it all into 256k.  The processor I
> have can be configured to use 256k of L2 cache as SRAM.  But, I am loading
> from SPI flash, and can't execute in place, so the whole enchilada must fit,
> and 32-bit RISC is, apparently, not space efficient.  So, I have to use the
> DDR2 attached to the processor.  If parallel NOR were an option, I could do
> that (I did try it), but then was relegated to SPI.

It is possible to save some space by compiling an integer-only version
of the project, ripping out functionality and modules, pre-compiling
or "compressing" scripts if you're using ROMFS, and a few other
things.  The Mizar32 port and related discussions probably provide
some of the most extensive examples on this front.

>
> What I really like:
>
> So little baggage.  eLua gives you lua with a nice clean interface to
> peripherals.  The Platform Interface design was a very very good idea.
> I can write my scripts in lua, and if speed is an issue, I can put selected
> portions in C.  Users are none the wiser.
> I just love the C-lua interface.  It is so easy to cross.  Using RO tables
> is very painless.  I can be as low-level or high-level as I want.  With the
> interactivity, I can easily test things out, and paste it into a script.
>  Then, once it is working, just via dofile, I migrate to a module.

This certainly echoes a number of things I like about Lua and eLua.
The Lua C API is a nice example of how the the implementation manages
to balance pragmatism, simplicity and elegance.  I think this is one
of the things that makes the language so popular for embedding within
other programs.

>
> I can test program logic on my desktop as long as I have some "fakes" setup.
>  I'd really like to systematize mocks for the eLua modules to allow for
> easier desktop development.  I hand craft them right now, but perhaps
> luaspec or lemock might be useful.
>
> Separation of SConstruct and conf.py is really nice.
>
> What I don't like (not eLua's fault):
>
> Lua's requirement to touch several files to add a new module.

This could certainly be improved a bit.  One way to handle it would be
to transfer some of the load to the build system.

>
> Phew.  That's a lot.  Sorry if there's too much, or not enough specific to
> eLua.  But I've been slaving away for almost a year in obscurity, and enjoy
> telling about it.  However, I believe eLua's star is finally rising at my
> employer and people are able to see the benefit.  For example, I was able to
> turn a custom load for the Hardware team in < 0.5 a day.  Let's see you do
> that in linux.  And keep it all to about 256k.

Thanks very much, I certainly enjoyed reading through your
description. It's also great to hear that it's working out well for
you and your employer.

As always, feel free to let us know if you need any help with
something in the future, have comments/notice any bugs or just want to
share something you've been working on :-)

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

[Martin Guy]

Hi Matt. Great story and a tribute to how easy eLua makes it to
implement this kind of thing.
We shipped the first of our Mizar32 products yesterday, and it is
valuable for us to know the kind of uses that people might put this
kind of solution to, so many thanks for sharing.

> It broke my heart when I couldn't fit it all into 256k.

Our original design had 128KB of flash with 120K available for eLua
and, like you, we found it was a bit tight for full eLua. However,
during the months in which I was trying to fit the best of eLua into
120K I did a lot of size optimizations. Now we decided also to make
256K and 512K models which alleviate this pressure and let us provide
eLua proper with them. However, it seemed a shame to waste all that
hackery so I used those patches to produce the 128K model's firmware.
Some are too ugly to put in mainline eLua but they are all visible on
the Mizar32 branch of the eLua repository; that may help to give you
the extra space you need.

> Some of the Freescale peripherals do not play well with the eLua model.  I2C, in particular.

We had the same problem in the AVR32 hardware, which needs complete
I2C messages and cannot work at the start-stop level. There was a
proposal to add a higher-level I2C interface to get round this but it
turned out that some existing eLua code relied on being able to regain
control in the middle of a sending a message to be able to achieve
certain optimizations, so in the end we implemented it by bit-banging
two GPIO pins. You could probably lift that implementation from
src/platform/avr32/i2c.c

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

[Nuccio Raciti]

Il 24/01/2012 12:55, Matt Wilbur ha scritto:

>
> On Monday, 23 January, 2012 at 7:32 AM, Bogdan Marinescu wrote:
>
>> Hi Matt,
>>
>> On Mon, Jan 23, 2012 at 2:29 PM, Matt Wilbur <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>> About a year ago I made the pitch to use eLua as a platform for the
>>> self-diagnostics software of my employer's next modem.  It'll be
>>> going into
>>> pre-production soon!
>>>
>>> Let me know if you're interested in more details.  I'll provide what
>>> I can.
>>
>> Are you kidding me ?! Hit me with all you got! :)
> First:
>
> Any views or opinions presented in this email are solely those of the
> author and do not necessarily represent those of the company.
> Backstory:
>
> I was tasked with software to help do diagnostics software of an
> embedded product.  Typically, our products are based on embedded
> linux, and design-verification test (DVT) and functional test (FT)
> have all used horrendous bash scripts to test the system.  I mean, the
> scripts were ugly.  Really ugly.
>
> Additionally, there was no easy way to test low level interfaces (SPI,
> I2C, etc).  So, one could get an RMA and really have an enormous fault
> tree to deal with.  Also, lots of NFF boards meant we wanted to try to
> test the product in situ before it was sent back, if necessary.
>
> Finally, there was a desire to separate the "mission mode" software
> with the diagnostics and test software.  Updates to "mission mode"
> software would sometimes cause production test software to break,
> resulting in an ugly double reflashing of pre-programmed parts during
> production.
>
> Initially, there was a push to use another linux system for test, but
> I pushed back on this quite vigourously.  Why incur the overhead a
> multi-user pre-emptive OS to bit bash pins?  Then u-boot was
> suggested.  Oy.  So much baggage.
>
> Finally, I proposed eLua.  I had read about it some time ago and
> wanted a way to use it somewhere in something.  I'm a micro controller
> nerd at heart.  For better or for worse, others weren't really paying
> too much attention, said "Ok", and I ran with it.  It was ideal for my
> needs - interactive, flexible, scriptable, low level, super super easy
> to extend with C.  However, we are using a Freescale PowerPC
> microprocessor (er -- Power Architecture, my bad).  So, I had to work
> on the port from scratch.
>
> What I have now is a series of tests that a run via autorun.lua when
> eLua starts.  An SPI boot loader, written by me, loads the eLua binary
> from SPI flash into ram and vectors to eLua.  Then all tests run,
> optionally dropping to the eLua after the shell.  The tests gradually
> "walk" out from a SPI flash / SRAM only start (the SPI boot loader,
> which tests DDR), to eLua which then tests peripherals such as I2C,
> SPI, local bus, PCIe.  It then talks to an FPGA via the local bus
> which thens tests its interfaces.  There is an soft-core processor on
> the FPGA running software.  The messaging lua code is partially
> generated via a YAML description.
>
> I only have polling-mode drivers, as the OpenPIC used in PPC is not
> well documented.  Documentation brags about using this "Open"
> standard.  Try to find a copy.  It's impossible.  Anyhow, I want to go
> down that road, but don't have time at the moment.  Also, the MMU is
> always "on" in the processor, and there are at one, usually two, and
> sometimes three levels of memory translation to get to a peripheral.
>  It is a pain.  However, I'm pretty sure I understand this better than
> anyone else in the company now.
>
> What I do have is:
>
> Timers
> SPI
> I2C
> UART
> GPIO
>
> RPC works great.  I haven't gotten XMODEM going yet, but I haven't
> really looked into it yet.  I'd love to use Go@.  I can't use RFS
> because of no interrupts.  So, I have leveraged RPC for development,
> effectively using it to upload code.  I put all my functions into a
> table and create remote objects on the modem, and add references into
> _G in order to make them "look" local.  It actually works pretty well,
> as long as I remember not to print.
>
> I also added a raw module (people at my company are addicted to peeks
> and pokes), but at first opportunity, I remove these uses.  Some of
> the Freescale peripherals do not play well with the eLua model.  I2C,
> in particular.  I have never seen a more convoluted peripheral.  I
> wrote fairly generic-ish drivers, and wrapped them to glue them into
> eLua.  That way, I could use them for my SPI boot loader.
>
> I built the powerpc-eabi toolchain in a very similar manner to James'
> ARM methodology, but before I knew about his stuff.  It was a lot of
> going through ugly shell scripts (no, I don't like shell scripts) but,
> it allowed me to apply the size optimizations to the C library.  I
> have started on a MINIX C library port for eLua, but am doing that on
> my own time to ensure there is no issue releasing it.  However, I have
> very little of my own time.
>
> It broke my heart when I couldn't fit it all into 256k.  The processor
> I have can be configured to use 256k of L2 cache as SRAM.  But, I am
> loading from SPI flash, and can't execute in place, so the whole
> enchilada must fit, and 32-bit RISC is, apparently, not space
> efficient.  So, I have to use the DDR2 attached to the processor.  If
> parallel NOR were an option, I could do that (I did try it), but then
> was relegated to SPI.
>
> What I really like:
>
> So little baggage.  eLua gives you lua with a nice clean interface to
> peripherals.  The Platform Interface design was a very very good idea.
> I can write my scripts in lua, and if speed is an issue, I can put
> selected portions in C.  Users are none the wiser.
> I just love the C-lua interface.  It is so easy to cross.  Using RO
> tables is very painless.  I can be as low-level or high-level as I
> want.  With the interactivity, I can easily test things out, and paste
> it into a script.  Then, once it is working, just via dofile, I
> migrate to a module.
>
> I can test program logic on my desktop as long as I have some "fakes"
> setup.  I'd really like to systematize mocks for the eLua modules to
> allow for easier desktop development.  I hand craft them right now,
> but perhaps luaspec or lemock might be useful.
>
> Separation of SConstruct and conf.py is really nice.
>
> What I don't like (not eLua's fault):
>
> Lua's requirement to touch several files to add a new module.
>
> Phew.  That's a lot.  Sorry if there's too much, or not enough
> specific to eLua.  But I've been slaving away for almost a year in
> obscurity, and enjoy telling about it.  However, I believe eLua's star
> is finally rising at my employer and people are able to see the
> benefit.  For example, I was able to turn a custom load for the
> Hardware team in < 0.5 a day.  Let's see you do that in linux.  And
> keep it all to about 256k.
>
>
>
>
>
>
> _______________________________________________
> eLua-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/elua-dev

Hi Matt,

thanks for sharing this great story, I would be flattered if you will
use the Goat IDE...
so please feel free to send me suggestions about it.

Cheers,
Nuccio








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