Hi,
I tried hard to understand the elua build system and activate a prog action to my build to run the genprog function to strip a binary from the elf file. I didn't get it working yet. Below you can see my conf.lua, I expect that the line tools.bonfire.prog_flist = { output .. ".bin"} will create a dependency to build the bin file. But it is not working. What am I missing?

-- Configuration file for the RV32IM on bonfire Platform
-- Intended to run standalone


if comp.cpu:lower()=="bonfire_arty_10" then
  specific_files = sf( "start.S platform.c stubs.c uart.c systimer.c console.c platform_int.c mod_riscv.c xil_etherlite.c", comp.cpu:lower() )
else
   specific_files = sf( "start.S platform.c stubs.c uart.c systimer.c console.c platform_int.c mod_riscv.c", comp.cpu:lower() )
end
--local ldscript = "src/platform/bonfire/riscv_local.ld"
local ldscript = sf( "src/platform/%s/%s", platform, "riscv_local.ld" )

-- Override default optimize settings
delcf{ "-Os", "-fomit-frame-pointer" }
addcf{"-g", "-O2","-fomit-frame-pointer"}

-- Prepend with path
specific_files = utils.prepend_path( specific_files, sf( "src/platform/%s", platform ) )


-- Standard GCC flags

addcf{ '-march=rv32im' ,'-mabi=ilp32' }
addcf{ '-ffunction-sections', '-fdata-sections', '-fno-strict-aliasing', '-Wall'}
addlf{ '-nostartfiles', '-nostdlib', '-T', ldscript, '-Wl,--gc-sections', '-Wl,--allow-multiple-definition' }
addlib{ 'c','gcc','m' }



local gcc_version=utils.exec_capture(comp.CC.." -dumpversion")
print(string.format("Found %s version %s",comp.CC, gcc_version))
if gcc_version:sub(1,1)>="7" then -- For RISCV gcc version >= 7
  print("Configuring for gcc Version >= 7")
  addcf{'-mstrict-align','-mbranch-cost=6'}
else
  print("Configuring for gcc Version < 7")
end


-- Also tell the builder that we don't need dependency checks for assembler files
--builder:set_asm_dep_cmd( false )

-- Toolset data
tools.bonfire = {}
tools.bonfire.prog_flist = { output .. ".bin"}

-- Programming function for i386 (not needed, empty function)
--tools.bonfire.progfunc = function( target, deps )
  --print "bonfire.progfunc"
  --return 0
--end

-- Add the programming function explicitly for this target
--tools.bonfire.pre_build = function()
  --local t = builder:target( "#phony:prog", { exetarget }, tools.bonfire.progfunc )
  --builder:add_target( t, "build eLua firmware image", { "prog" } )
--end

I believe there is a memory leak in the code.

Within the file lparser.c in the function static void block, the variable pbl is dynamically allocated. This is obviously an optimization to decrease the memory usage, unfortunately I believe it is not the optimal solution.

The function block can throw an exception (LUAI_THROW in luaD_throw) which will be handled from luaD_rawrununprotected. The consequence is that this function is "jumped" and the deallocation of pbl with it.

This happens when there is a malformed piece of code e.g.:
"""
prog = [[
do
function foo();
return
end
end
]]

do
pcall(loadstring(prog))
end
"""

On STM32F4 Discovery I can't no longer send lua scripts via xModem using recv command.
In previous version of lua (0.6?) when the shell was accessible via UART, sending files through XMODEM was working perfectly.
Now, in version 0.9 where shell is accessible via virtual com USB, I can't send file anymore.

Problem reproduction:

• I connect with eLua shell via terminal and write: recv
• Shell: Waiting for file ... CCCC
• I select file
• Now communication becomes silent and terminal shows the dialog with progressbar and "Sending file via xModem... 0%" message for about 10s. (independent from file size)
• After this freezed situation, I receive "\0x06XMODEM error"
  And I can use eLua shell again but nothing more happened, especially lua script didn't start.

(Tested on kUbuntu 13.04 with minicom and cutecom)

I tried to run eLue 0.9 for i386 on old PC I found. It is i486SX33, 24MB of RAM.
I was able to run memtest 86+ 4.10 on this machine.
When I tried to boot eLua, there was an error, "interrupt 6" printed again and again. I am not sure about the number but i think it was 6...

Maybe it is because 486SX has no FPU... Is FPU mandatory for eLua?

Please consider in main.c supporting the wofs for autorun. Something like:

char *boot_order[] = {

if defined(BUILD_MMCFS)

"/mmc/autorun.lua",
"/mmc/autorun.lc",

endif

if defined(BUILD_WOFS)

"/wo/autorun.lua",
"/wo/autorun.lc",

endif

if defined(BUILD_ROMFS)

"/rom/autorun.lua",
"/rom/autorun.lc",

endif

};

Hi everyone,

i am currently working on an system where we have a small POSIX like operating system. We included the Lua variant from eLua because of the LTR patch.
I have quite some lua code as modules in the fashion:

local mod = {}
..
..
return mod

I put different modules pre compiled as bytecode into the romfs. When i require them in Lua via:

x = require "mod"

the ram consumption raises by 2-10kB depending on the size of the module. I check these via collectgarbage('count') before and after the require and also run collectgargage('collect') in between.

So maybe i do and/or understand something wrong but i thought that eLua is able to execute bytecode directly from the romfs. So i expect the ram consumption raises just a little but in kBytes.

Is there a way to test if the lua code is executed from flash ?

Thanks in advance for any help,
Hans

"\x1b[0G" sequence is not supported by vt100
probably it will be better use "\r" instead (tested in minicom in Ubuntu)

diff --git a/src/linenoise.c b/src/linenoise.c
index fb41583..77c9e1f 100644
--- a/src/linenoise.c
+++ b/src/linenoise.c
@@ -131,7 +131,7 @@ static void refreshLine(const char *prompt, char *buf, size_t len, size_t pos, s
     }

     /* Cursor to left edge */
-    snprintf(seq,MAX_SEQ_LEN,"\x1b[0G");
+    snprintf(seq,MAX_SEQ_LEN,"\r");
     term_putstr( seq, strlen( seq ) );
     /* Write the prompt and the current buffer content */
     term_putstr( prompt, strlen( prompt ) );
@@ -140,7 +140,7 @@ static void refreshLine(const char *prompt, char *buf, size_t len, size_t pos, s
     snprintf(seq,MAX_SEQ_LEN,"\x1b[0K");
     term_putstr( seq, strlen( seq ) );
     /* Move cursor to original position. */
-    snprintf(seq,MAX_SEQ_LEN,"\x1b[0G\x1b[%dC", (int)(pos+plen));
+    snprintf(seq,MAX_SEQ_LEN,"\r\x1b[%dC", (int)(pos+plen));
     term_putstr( seq, strlen( seq ) );
 }

Use of LTR __metatable docs are thin, and I'm doing my best to work from the source code.

First, I'm surprised that the metatable map returned is always self, rather than the one I'm pointing at via an LRO_ROVAL.

Given:

const LUA_REG_TYPE mymodule_metatable_map[] = {
  { LSTRKEY("__call")  , LFUNCVAL(myCallMetamethodHandler) },
  { LNILKEY, LNILVAL }
};

const LUA_REG_TYPE mymodule_map[] = {
  { LSTRKEY("__metatable"), LRO_ROVAL(mymodule_metatable_map) },
  { LNILKEY, LNILVAL }
};

It seems to ignore the metatable and registers a metatable of self:

m = require 'mymodule'
print(m)
romtable: 0x805c9b8

for k,v in pairs(m) do print(k,v) end
__metatable     romtable: 0x805c9b8

print(getmetatable(m))
romtable: 0x805c9b8

for k,v in pairs(m) do print(k,v) end
__metatable     romtable: 0x805c9b8

So given that, I went back to a single consolidated romtable that uses itself as a metatable:

const LUA_REG_TYPE mymodule_map[] = {
  { LSTRKEY("__call") , LFUNCVAL (myCallMetamethodHandler) },
  { LSTRKEY("__metatable"), LRO_ROVAL(mymodule_map) },
  { LNILKEY, LNILVAL }
};

And __call seems to get ignored:

> m('foo')
stdin:1: attempt to call global 'm' (a romtable value)

lua 5.2.4

$ export PATH=$PATH:/Users/znouza/gcc-arm-none-eabi-4_9-2015q3/bin && ./build_elua.lua board=stm32f4discovery
[CONFIG] Found board description file at boards/known/stm32f4discovery.lua
[CONFIG] Generated board header file at boards/headers/board_stm32f4discovery.h
Unable to find an usable toolchain in your path.
List of accepted toolchains (for STM32F407VG): arm-gcc,codesourcery,devkitarm,arm-eabi-gcc

with that simple change

$ export PATH=$PATH:/Users/znouza/gcc-arm-none-eabi-4_9-2015q3/bin && ./build_elua.lua board=stm32f4discovery
[CONFIG] Found board description file at boards/known/stm32f4discovery.lua
[CONFIG] Generated board header file at boards/headers/board_stm32f4discovery.h
WARNING: unable to determine version from repository

*********************************
Compiling eLua ...
CPU:                STM32F407VG
Board:              stm32f4discovery
Platform:           stm32f4
Allocator:          multiple
Boot Mode:          standard
Target:             lua
Toolchain:          codesourcery
ROMFS mode:         verbatim
Version:            unknown
*********************************

fixed in #76

Hi, I am a committer on the nodeMCU implementation and we've found a hole in the EGC fixes, see issue issue nodemcu/nodemcu-firmware#795 and the fix PR nodemcu/nodemcu-firmware#812. I've traced this omission back to the EGC patch. At a patch level this should be directly applicable to eLua

Sorry for not giving this as a native eLua patch, but I don't have a test-bed for standard eLua, just esp8266 modules.

Regards Terry

CC3200 use ARM Cortex-M4, and eLua also supported Cortex-M3. Is it possible to use the toolchain cortexm? If I create new port from Cortex-M3 boad, is it more easy?

I got trouble building eLua:

$ cd /tmp/elua/ ; ./build_elua.lua board=sim
[CONFIG] Found board description file at boards/known/sim.lua
[CONFIG] Generated board header file at boards/headers/board_sim.h
WARNING: unable to determine version from repository

---

Compiling eLua ...
CPU: LINUX
Board: sim
Platform: sim
Allocator: newlib
Boot Mode: standard
Target: lua
Toolchain: i686-gcc
ROMFS mode: verbatim
Version: unknown

---

[builder] Forcing rebuild due to configuration change.
[PHONY] #phony:romfs
Building ROM file system ...
Done, total size is 1 bytes
[COMPILE] .build/sim/src__buf.o
In file included from inc/platform.h:6:0,
from inc/platform_conf.h:9,
from src/buf.c:3:
inc/newlib/devman.h:7:19: fatal error: reent.h: No such file or directory
#include <reent.h>
^
compilation terminated.
[builder] Error building target
[builder] Last executed command was:
i586-alt-linux-gcc -DELUA_CPU_HEADER=""cpu_linux.h"" -DELUA_BOARD_HEADER=""board_sim.h"" -DELUA_CPU=LINUX -DELUA_BOARD=SIM -DELUA_PLATFORM=SIM -D__BUFSIZ__=128 -DELUA_CPU_LINUX -DELUA_BOARD_SIM -DELUA_PLATFORM_SIM -DLUA_PACK_VALUE -DELUA_ENDIAN_LITTLE -DELUA_SIMULATOR -DELUA_SIM_LINUX -DLUA_OPTIMIZE_MEMORY=2 -Iboards/headers -Iinc -Iinc/newlib -Iinc/remotefs -Isrc/platform -Isrc/lua -Isrc/modules -Isrc/platform/sim -Isrc/platform/sim/cpus -Isrc/uip -Isrc/fatfs -O0 -g -ffunction-sections -fdata-sections -fno-strict-aliasing -Wall -march=i386 -mfpmath=387 -m32 -fno-builtin -fno-stack-protector -c -MD -MF .build/sim/src__buf.d -o .build/sim/src__buf.o src/buf.c

I suggest that the header from newlib is missing.

This probably is cortex-m4-wide problem. See logs on http://pastebin.com/HXFqbLNh. My toolchain is created by Gentoos crossdev -S -t arm-none-eabi. stm32f1xx based boards compile fine.

$ arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/arm-none-eabi/gcc-bin/4.7.3/arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/arm-none-eabi/4.7.3/lto-wrapper
Target: arm-none-eabi
Configured with: /var/tmp/portage/cross-arm-none-eabi/gcc-4.7.3-r1/work/gcc-4.7.3/configure --host=x86_64-pc-linux-gnu --target=arm-none-eabi --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/arm-none-eabi/gcc-bin/4.7.3 --includedir=/usr/lib/gcc/arm-none-eabi/4.7.3/include --datadir=/usr/share/gcc-data/arm-none-eabi/4.7.3 --mandir=/usr/share/gcc-data/arm-none-eabi/4.7.3/man --infodir=/usr/share/gcc-data/arm-none-eabi/4.7.3/info --with-gxx-include-dir=/usr/lib/gcc/arm-none-eabi/4.7.3/include/g++-v4 --with-python-dir=/share/gcc-data/arm-none-eabi/4.7.3/python --enable-languages=c --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.7.3-r1 p1.4, pie-0.5.5' --disable-build-with-cxx --disable-build-poststage1-with-cxx --enable-poison-system-directories --disable-shared --disable-threads --without-headers --disable-bootstrap --with-newlib --enable-multilib --disable-altivec --disable-fixed-point --disable-libgcj --disable-libgomp --disable-libmudflap --disable-libssp --disable-libquadmath --enable-lto --without-cloog --without-ppl
Thread model: single
gcc version 4.7.3 (Gentoo 4.7.3-r1 p1.4, pie-0.5.5)

I've just built an image from master for MBED and the 'mbed' module are not available.

I am thinking the buffer size needs looked at in the stm32f4discovery board file.

cdc = { buf_size = 64 },

This doesn't work for me with the shell recv command. Changing to 128 resolved my xmodem receive issue.

cdc = { buf_size = 128 },

Thank you.

It may be a feature, but then I would like to understand why it must behave like this.

If the garbage collector is stopped, a call of collectgarbage("collect") will be ignored. This deviates from the original lua and (although I have not analyzed much further) it does not make sense to me.

Could somebody comment on that?

Thanks in advance,
Emilio

Would it be feasible to add support for the Teensy 3.1/3.2 boards?

Teensy 3 is an Arduino compatible development board. Arduino cor

ARM Cortex-M4, 72 MHz standard, 96 MHz overclocked
64kB RAM
256kB flash
2kB EEPROM
USB, Serial, SPI, I2C, CAN, I2S, GPIO
3.3V, most pins are 5V tolerant (a few exceptions)
RTC if optional clock crystal and backup battery is added.

I2S "soundcard" is available in the pjrc store, so is a 320x240 color display.

• Specs overview
• Datasheets
• Schematics
• Teensy 3.2 - PJRC store - $19.80
• Teensy 3 Arduino core code
• Better SPI Bus Design in 3 Steps by Paul Stoffregen (just for for further reference)

I have a little experience with C/C++ from a few Arduino projects, but otherwise not too much experience with the language. My main programming language is Python, and I know a fair bit of Lua from playing with the ComputerCraft Minecraft mod. My goal would be to create something similar to ComputerCraft with real hardware.
I would be able to do some work on the porting to Teensy3, but I currently have little experience with C/C++, and no experience with eLua. No experience with bare-metal programming of ARM chips (or other microcontrollers).
I can however donate a Teensy 3.2 to someone who have good understanding of the internal workings of eLua, that would like to help with the porting and testing.

Oddstr13

Hi, its not exactly an eLua issue, the berlios.de seems to be offline, so it is not possible to post to the mailing list. I was able to register on the link at nabble.com, but it says that it needs berlios.de to publish the message.

It has "193.168.1.10" for the address and "192.168.1.1" for the gateway, which can never work.

diff --git a/boards/known/mizar32a.lua b/boards/known/mizar32a.lua
index 6d16849..5a3f7b3 100644
--- a/boards/known/mizar32a.lua
+++ b/boards/known/mizar32a.lua
@@ -7,7 +7,7 @@ return {
     mmcfs = { spi = 4, cs_port = 0, cs_pin = "SD_MMC_SPI_NPCS_PIN" },
     adc = { buf_size = 2 },
     term = { lines = 25, cols = 80 },
-    tcpip = { ip = "193.168.1.10", netmask = "255.255.255.0", gw = "192.168.1.1"
+    tcpip = { ip = "192.168.1.10", netmask = "255.255.255.0", gw = "192.168.1.1"
     dhcp = true,
     dns = true,
     cints = true,
diff --git a/boards/known/mizar32b.lua b/boards/known/mizar32b.lua
index 7ff381c..b98ed40 100644
--- a/boards/known/mizar32b.lua
+++ b/boards/known/mizar32b.lua
@@ -7,7 +7,7 @@ return {
     mmcfs = { spi = 4, cs_port = 0, cs_pin = "SD_MMC_SPI_NPCS_PIN" },
     adc = { buf_size = 2 },
     term = { lines = 25, cols = 80 },
-    tcpip = { ip = "193.168.1.10", netmask = "255.255.255.0", gw = "192.168.1.1"
+    tcpip = { ip = "192.168.1.10", netmask = "255.255.255.0", gw = "192.168.1.1"
     dhcp = true,
     dns = true,
     cints = true,

A user has reported:
I've just moved to a new development machine and reinstalled all the tools I need to build eLua, including the latest version of scons (2.3.0). I've noticed that the output file being generated now has a .exe extension rather than .elf. Downgrading back to scons 2.2.0 fixes the problem.

a minor issue. Raised in #108

Merge this port: https://github.com/jsnyder/elua/tree/SiM3U1xx_port

This requires some work to strip out some platform-specific code, and some changes to the Lua core code.

Running build_elua.lua using Lua 5.3 produces the following error:

$ ./build_elua.lua 
lua: ./utils/build.lua:3: attempt to call a nil value (global 'module')
stack traceback:
	./utils/build.lua:3: in main chunk
	[C]: in function 'require'
	./build_elua.lua:21: in main chunk
	[C]: in ?

What version of Lua should be used? 5.1.x?

If i use WHILE (1), waiting for the serial port data will cause blocking, how to solve this problem?

Attached code:
while(1)
do

str = uart.getchar( 0 )

if(str == '\a')
then
break
else
uart.write( 0, str)
end

end

I'm struggling to integrate the lua-url module. Although my luaopen_url_parse() function gets called, it doesn't seem to register a module if it doesn't return a table.

I've set up a test environment here:

https://github.com/drauschenbach/elua/tree/url-parse

Steps to reproduce:

$ git clone https://github.com/drauschenbach/elua elua-1
$ cd elua-1
$ git checkout lua-url
$ make
docker run -v `pwd`:/export -it elua
'elua_lua_stm3210e-eval.bin' -> '/export/elua_lua_stm3210e-eval.bin'
'elua_lua_stm3210e-eval.elf' -> '/export/elua_lua_stm3210e-eval.elf'
'elua_lua_stm3210e-eval.hex' -> '/export/elua_lua_stm3210e-eval.hex'

This works:

> require 'lauxhlib'

But this doesn't:

> require 'url.parse'
stdin:1: module 'url.parse' not found:
        no field package.preload['url.parse']
        no file '/mmc/url/parse.lua'
        no file '/mmc/url/parse.lc'
        no file '/wo/url/parse.lua'
        no file '/wo/url/parse.lc'
        no file '/rom/url/parse.lua'
        no file '/rom/url/parse.lc'
        no file '/semi/url/parse.lua'
        no file '/semi/url/parse.lc'
stack traceback:
        [C]: in function 'require'
        stdin:1: in main chunk
        [C]: ?

Hello. I'm trying to find info on what version of lua language is implemented in elua. As I know, theree are some differences in Lua 5.0, 5.1, 5.2 versions (e.g. in module loading and handling, even in semantics, deprecating module function) and it would be good to have it somewhere in docs or in wiki. Unfortunately, I cannot find it.

Platform adc clock setup uses period & prescaler (platform_adc_set_clock) (as does PWM setup), main timer clock setting has a fixed period. platform_timer_get_clock doesn't include the period in its calculation and so will return incorrect results if either the adc or pwm clock setting functions have been used.

lparser.c uses a number of calls to malloc that longjump exception handling (as when partial lines are entered or syntax errors are made at the REPL) can cause these to result memory leaks

romfs is currently a write-once filesystem that will allow incremental adding to the fs, and "deletion" of files, but this currently does not reclaim space.

A repacking algorithm could be implemented in order to manually or automatically minimize the amount of space needed for the FS and free up unused flash. A branch currently exists for this, but the implementation has not been sufficiently tested for mainlining.

The default configuration for LuaRPC shares the default stdout/stderr with RPC. When software other than LuaRPC attempt to print to this, protocol errors will occur that are not recovered from well.

Possible resolutions:

1. Redirect printed messages to be properly carried over the protocol
2. Make default configuration to not share stdout/stderr with RPC
3. Disable or reroute stdout/stderr to another UART by default.

The first option would be most desirable, but as implemented there is a strict protocol with a state machine on either side of the link controlling reads or writes. Messages printed when one side or the other would be waiting for data should be simple (add another type of RPC message), but those sent while the state machine is currently expecting other data may be complicated. Perhaps messages could be buffered or queued, or some sort of framing could be used?

The link doesn't work. I'm just starting on the eLua Bluemod+s42 road and feel it might be useful.
regards

and your program runs in a wide varied of (sometimes radically different) platforms

s/varied/variety/

(no PR filed because i dislike the typo fixer crowd)

When a table is constructed from a multivalued entity (like a function call returning multiple values, or '...'), all values should be put into the resulting table; with eLua, only the first value is stored.

Vanilla Lua 5.1.4:

> =#{(function() return 1,2 end)()}
2
> (function(...) print(#{...}) end)(1,2)
2

eLua:

> =#{(function() return 1,2 end)()}
1
> (function(...) print(#{...}) end)(1,2)
1

It seems like the implementation of the SETLIST opcode is affected. As it is largely unchanged from the vanilla implementation, I would figure there's something wrong with functions that are called from there (e.g. the resizing functions, as they have been changed).

In lrotable.c

1. if luaR_next is called with data == NULL (by mistake for example),
2. keypos will not be set in luaR_findentry.
3. Since keypos is unitialized the call luaR_next_helper is called with garbage input.

It is not so important, but I just wanted to help.

When I build an eLua image for ek-lm3s8962 from master, enabling any of the modules lm3s_disp or lm3s_pio, I'm getting the error below when I enter on lua interpreter:

lua: attemp to call a string value

I've built with CodeSourcery and GNU Tools for ARM, same error.

[]s

Mauricio

Please see

The code which swaps the upper and lower dwords allocates char* temp[4]; as the temp buffer.
Each element in the temp array will be as wide as the memory bus.. whereas it only needs to be of length sizeof(double)/2.

Allow the VM to run while sitting at the lua REPL so that eLua interrupts can be handled.

A simple implementation of this exists in the SiM3 port: https://github.com/jsnyder/elua/blob/SiM3U1xx_port/src/lua/lua.c#L234

However this could be a bit nicer/cleaner before brining it into the master branch.

The Lua function get_platform_modules() should include a check for XMC4500-HEXAGON-SDRAM for platform modules.

R

How can I build i386 PC firmware in Ubuntu 16.04? Thx!

Hi,

I have a STM32F429I-DISCO board here, which seems pretty similar from the board stm32f4discovery supported in the tree.

This board has a STM32F429ZI mcu and a qvga lcd display :
http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/PF259090

I wasn't able to get up to connect to the CDC USB port, which worked on the my other stm32f4discovery board sporting a stm32f407 chip.

Kinda new to the embedded world, but based on naming I was under the impression that STM32F429I-DISCO would work out of the box.

Hi,
I wonder, whether somebody port uip also to other arm platforms as LM3?
Most LM3 boards are not available anymore and only other board with uip is avr32. May be it's about time to use more update platform for uip (such as nucleo 144) or bring some other ip lowlevel devices such slip example in to the source. Did anybody consider porting uip on other arm platforms ?

Regards
Roman

Not sure where to file this, but the eluaproject.net website has been down since yesterday. I noticed yesterday that it was down for a few hours and then came back up.

Is there an alternative to the web-based Builder that I can run locally from the sources?

stm32f4 support should be merged from https://github.com/jsnyder/elua/tree/bikeNomad-master

The stm32f2 support could be stripped out for now since I don't have that platform to test with. f4 port is in good shape.

#74 refers.

Lua Compact Debug (LCD). What this patch does is to eliminate 90% of the overhead of using lua source execution rather than stripped binary luac.cross files. It's also stable on nodeMCU.

Read the whitepaper for the full description, but whatthis patch does is to allow the developer to trim (at compile time) what debug information is retained. At the normal level(2) only lineinfo is retained so tracebacks still work. The difference is that instead of the overhead being ~ 4N where N is the number of instructions, it's roughly 1M where M in the number of non-blank source lines. What this means in effect that the debug "overhead" drops to roughly 5% of what its is for an unmodified RTS. The runtime impact is negligible for normal code.

This is working stably on the nodemcu fork, but it seems to me that this would be of wider elua interest.

how to compile my c file into elua source code?

I am a fresh man ,I want to compile my .c file with elua source code,but the compile break out error when I using command
"lua build_elua board=stm32f4discovery prog".the error is :

[COMPILE] .build/stm32f4discovery/src__main.o
In file included from src/main.c:70:0:
src/platform/stm32f4/custom/myprintf.h:6:13: warning: 'uart_intix' used but never defined
static void uart_intix();
^
[LINK] ./elua_lua_stm32f4discovery.elf
.build/stm32f4discovery/src__main.o: In function main': /home/huangwei/luaOrg/src/main.c:84: undefined reference to uart_intix'
collect2: error: ld returned 1 exit status
[builder] Error building target
[builder] Last executed command was:

It seems that the compiler can not find function "uart_intix", but I have already defined it in"./src/platform/stm32f4/custom/myprintf.c".
and the "myprintf.h" also at the same path.

I modefied the "conf.lua" file as belowing.

addi( sf( 'src/platform/%s/FWLib/USB/VCP/inc', platform ) )
--my function path !
addi( sf( 'src/platform/%s/custom/',platform) )

but the compiler can not work! what should i do I want to add my code into elua source ? forgive my poor English!
by the way,in main.c file ,i have already included the head file "myprintf.h".
thanks a lot!

Is it possible to build eLua as a library. I would like to incorporate eLua into an embedded app (on a microcontroller) so that app can launch eLua to run user scripts.

Any suggestions as to how to do this would be greatly appreciated

#130 didn't modify the shell help command properly. At the moment, help shows the help text even for the shell commands that are not used.

Bogdan, I see that you are still maintaining eLua so I thought that you should be aware of this gremlim that has been causing subtle but repeated crashes of our NodeMCU fork. See PR nodemcu/nodemcu-firmware#2320 and the underpinning issue, nodemcu/nodemcu-firmware#2311. You should consider applying this patch to eLua as well because your builds will be suffering from the same bug. 😄

Does anyone have a Dockerfile for a reference Linux build env? I'm struggling to achieve a build.

Using:

FROM ubuntu:16.04

# ============================================================
# Install package prerequisites
# ============================================================
RUN apt-get -y update && apt-get -y install software-properties-common
RUN add-apt-repository ppa:team-gcc-arm-embedded/ppa
RUN apt-get -y update && apt-get -y install \
  build-essential \
  gcc-arm-embedded \
  git \
  libreadline-dev \
  ncurses-dev \
  wget \
  unzip

# Lua 5.1
RUN wget -q http://www.lua.org/ftp/lua-5.1.4.tar.gz \
  && tar zxvf lua-5.1.4.tar.gz \
  && cd lua-5.1.4 \
  && make linux \
  && make install

# LuaRocks
ARG LUAROCKS_VERSION=2.3.0
RUN wget -q http://luarocks.github.io/luarocks/releases/luarocks-$LUAROCKS_VERSION.tar.gz \     
  && tar zxvf luarocks-$LUAROCKS_VERSION.tar.gz \
  && cd luarocks-$LUAROCKS_VERSION \
  && ./configure \
  && make \
  && make install

# eLua build script dependencies
RUN luarocks install luafilesystem \
  && luarocks install lpack \
  && luarocks install md5

# ============================================================
# Download eLua sources, and checkout a stable tag
# ============================================================
RUN git clone https://github.com/elua/elua.git /elua
WORKDIR /elua
ARG ELUA_GIT_VERSION=2e6a3af
RUN git checkout $ELUA_GIT_VERSION

# ============================================================
# Build eLua
# ============================================================
ARG BOARD=STM3210E-EVAL
RUN lua build_elua.lua board=$BOARD

When run:

$ docker build -t elua .
Step 14/15 : ARG BOARD=STM3210E-EVAL
 ---> Running in 102b03003924
 ---> 81c8a95ad2ef
Removing intermediate container 102b03003924
Step 15/15 : RUN lua build_elua.lua board=$BOARD
 ---> Running in cd5a0750e0e3
[CONFIG] Found board description file at boards/known/stm3210e-eval.lua
[CONFIG] Generated board header file at boards/headers/board_stm3210e-eval.h
In file included from src/modules/luarpc.c:43:0:
inc/luarpc_rpc.h:4:2: warning: #warning Not sure which of the two serial.h this should include [-Wcpp]
 #warning Not sure which of the two serial.h this should include
  ^~~~~~~
In file included from src/luarpc_elua_uart.c:6:0:
inc/luarpc_rpc.h:4:2: warning: #warning Not sure which of the two serial.h this should include [-Wcpp]
 #warning Not sure which of the two serial.h this should include
  ^~~~~~~
src/fatfs/ff.c:288:9: error: conflicting types for 'sync'
 FRESULT sync ( /* FR_OK: successful, FR_DISK_ERR: failed */
         ^~~~
In file included from /usr/arm-none-eabi/include/sys/reent.h:13:0,
                 from /usr/arm-none-eabi/include/reent.h:93,
                 from inc/newlib/devman.h:7,
                 from src/fatfs/ffconf.h:14,
                 from src/fatfs/ff.h:20,
                 from src/fatfs/ff.c:79:
/usr/arm-none-eabi/include/sys/unistd.h:289:9: note: previous declaration of 'sync' was here
 void    _EXFUN(sync, (void));
         ^

*********************************
Compiling eLua ...
CPU:            	STM32F103ZE
Board:          	stm3210e-eval
Platform:       	stm32
Allocator:      	newlib
Boot Mode:      	standard
Target:         	lua
Toolchain:      	codesourcery
ROMFS mode:     	verbatim
Version:        	v0.9-349-g2e6a3af
*********************************

[PHONY] #phony:romfs
Building ROM file system ...
Done, total size is 1 bytes
[COMPILE] .build/stm3210e-eval/src__semifs.o
[COMPILE] .build/stm3210e-eval/src__common.o
[COMPILE] .build/stm3210e-eval/src__modules__uart.o
[COMPILE] .build/stm3210e-eval/src__modules__net.o
[COMPILE] .build/stm3210e-eval/src__modules__bit.o
[COMPILE] .build/stm3210e-eval/src__modules__pwm.o
[COMPILE] .build/stm3210e-eval/src__modules__pd.o
[COMPILE] .build/stm3210e-eval/src__modules__can.o
[COMPILE] .build/stm3210e-eval/src__modules__bitarray.o
[COMPILE] .build/stm3210e-eval/src__modules__adc.o
[COMPILE] .build/stm3210e-eval/src__modules__luarpc.o
[COMPILE] .build/stm3210e-eval/src__modules__elua.o
[COMPILE] .build/stm3210e-eval/src__modules__pio.o
[COMPILE] .build/stm3210e-eval/src__modules__lpack.o
[COMPILE] .build/stm3210e-eval/src__modules__cpu.o
[COMPILE] .build/stm3210e-eval/src__modules__tmr.o
[COMPILE] .build/stm3210e-eval/src__modules__term.o
[COMPILE] .build/stm3210e-eval/src__modules__i2c.o
[COMPILE] .build/stm3210e-eval/src__modules__spi.o
[COMPILE] .build/stm3210e-eval/src__elua_mmc.o
[COMPILE] .build/stm3210e-eval/src__buf.o
[COMPILE] .build/stm3210e-eval/src__luarpc_elua_uart.o
[COMPILE] .build/stm3210e-eval/src__romfs.o
[COMPILE] .build/stm3210e-eval/src__common_fs.o
[COMPILE] .build/stm3210e-eval/src__common_uart.o
[COMPILE] .build/stm3210e-eval/src__main.o
[COMPILE] .build/stm3210e-eval/src__elua_uip.o
[COMPILE] .build/stm3210e-eval/src__common_tmr.o
[COMPILE] .build/stm3210e-eval/src__eluarpc.o
[COMPILE] .build/stm3210e-eval/src__dlmalloc.o
[COMPILE] .build/stm3210e-eval/src__elua_mmc_sim.o
[COMPILE] .build/stm3210e-eval/src__xmodem.o
[COMPILE] .build/stm3210e-eval/src__shell__shell_adv_rm.o
[COMPILE] .build/stm3210e-eval/src__shell__shell_ls.o
[COMPILE] .build/stm3210e-eval/src__shell__shell_mkdir.o
[COMPILE] .build/stm3210e-eval/src__shell__shell_adv_cp_mv.o
[COMPILE] .build/stm3210e-eval/src__shell__shell_help.o
[COMPILE] .build/stm3210e-eval/src__shell__shell_ver.o
[COMPILE] .build/stm3210e-eval/src__shell__shell_lua.o
[COMPILE] .build/stm3210e-eval/src__shell__shell_cat.o
[COMPILE] .build/stm3210e-eval/src__shell__shell_recv.o
[COMPILE] .build/stm3210e-eval/src__shell__shell_wofmt.o
[COMPILE] .build/stm3210e-eval/src__shell__shell.o
[COMPILE] .build/stm3210e-eval/src__elua_adc.o
[COMPILE] .build/stm3210e-eval/src__fatfs__ccsbcs.o
[COMPILE] .build/stm3210e-eval/src__fatfs__ff.o
[builder] Error building target
[builder] Last executed command was: 
arm-none-eabi-gcc -DELUA_CPU_HEADER="\"cpu_stm32f103ze.h\"" -DELUA_BOARD_HEADER="\"board_stm3210e-eval.h\"" -DUSE_GIT_REVISION -DELUA_CPU=STM32F103ZE -DELUA_BOARD=STM3210E-EVAL -DELUA_PLATFORM=STM32 -D__BUFSIZ__=128 -DELUA_CPU_STM32F103ZE -DELUA_BOARD_STM3210EEVAL -DELUA_PLATFORM_STM32 -DLUA_PACK_VALUE -DELUA_ENDIAN_LITTLE -DLUA_OPTIMIZE_MEMORY=2 -DFORSTM32F103ZE -DFORSTM3210EEVAL -Dgcc -DCORTEX_M3 -Iboards/headers -Iinc -Iinc/newlib -Iinc/remotefs -Isrc/platform -Isrc/lua -Isrc/modules -Isrc/platform/stm32 -Isrc/platform/stm32/cpus -Isrc/uip -Isrc/fatfs -Isrc/platform/stm32/FWLib/library/inc -Os -fomit-frame-pointer -ffunction-sections -fdata-sections -fno-strict-aliasing -Wall -mcpu=cortex-m3 -mthumb -mlittle-endian -c -MD -MF .build/stm3210e-eval/src__fatfs__ff.d -o .build/stm3210e-eval/src__fatfs__ff.o src/fatfs/ff.c
The command '/bin/sh -c lua build_elua.lua board=$BOARD' returned a non-zero code: 1

In the UNPACKSTRING macro within lpack.c, the sum "i+m+l" is compared to "len" without checking that "i+m+l" does not overflow. A bad encoding could easily produce such overflow.

I would also suggest to rise an error instead of the current behavior of just "goto done"