<ul><li>port setup: 115200 baud (38400 for <ahref="installing_str7.html">STR7)</a>, 8N1(8 data bits, no parity, one stop bit). </li><li>hardware flow control: none</li><li>newline handling: "CR" on receive, "CR+LF" on send (some terminal programs won't give you a choice here). </li></ul>
<li>make sure you know the address of your board. If you enabled static IPs (see <ahref="building.html">building</a>) remember what you chose for the static IP; if DHCP
(the default) is used instead, your
DHCP server should've added the address of the <b>eLua</b> board to your DNS. The board name is always "elua"
in our code examples too, so if you execute "ping elua" from a shell you should see that the board is
<aname="pc"><h3>Using standalone eLua on PC</h3></a>
<p>If you build <b>eLua</b> for the i386 platform, you can boot your PC directly in <b>eLua</b>! No underlying OS, nothing but plain <b>eLua</b>. It won't have any actual peripherals to
<p>No matter what's your physical connection (serial, TCP/IP or you PC's monitor after booting <b>eLua</b>), after you setup the PC-<b>eLua</b> board connection and press
the "RESET" button on your board or simply press ENTER if you're using the serial connection, you should see the <b>eLua</b> shell prompt (if you enabled the shell in your build, as described <ahref="building.html">here</a>). The shell is a simple
<p>Print the version of the <b>eLua</b> image installed on the board. Currently, the version only increments for official releases, so if there's inter-release code in the
development tree, this isn't reflected in the version number.</p>
If you want to execute a file from the <ahref="arch_romfs.html">ROM file system</a> (or from another file system), remember to prefix it with <i>/rom</i>. For example, to execute <b>hello.lua</b>, do this:
<p>Copies a file to another file. This command can be used to copy files between different file systems (for example between the MMC file system and the RFS file system).</p>
<p>Exits the shell. This only makes sense if <b>eLua</b> is compiled with terminal support over TCP/IP , as it closes the telnet session to the <b>eLua</b> board. Otherwise it just
<p>In order to use cross-compilation, the two Lua targets (in this case your desktop PC and your <b>eLua</b> board) must be compatible
(they should have the same data types, with the same size and the same memory
representation). This isn't true all the time. For example, some gcc toolchains for ARM targets use a very specific representation for double precision numbers (called FPA
format) by default, which makes bytecode files generated on the PC with the regular Lua compiler useless on
<p>You should get a file called <i>luac</i> in the same directory after this. It's almost the same as the regular Lua compiler, but it has a few arguments that deal with differences between different targets (shown below in bold):</p>
<td><code>./luac -ccn int 32 -cce big -o <script.luac> -s <script.lua></code></td>
</tr>
</tbody>
</table>
<p>(note that if for some reason you want to cross-compile <b>eLua</b> for the x86 target you can use the regular Lua compiler).<br>
You can omit the <i>-s</i> (strip) parameter from compilation, but this will result in larger bytecode files (as the debug information is not stripped if you don't use <i>-s</i>).</p>
<p>You can use your bytecode file in two ways:</p>
<p><i>Remote procedure calls</i> (RPC) allow one program to communicate with another and call functions or subroutines within the second program. For example one might want to programmatically control an array of LEDs connected to an eLua embedded device from a desktop Lua state. A simple implementation might be a protocol that would allow one to send numeric or text-based commands that would cause code to be executed in eLua that would change the state of the LEDs. As one needs new commands to change these LEDs, one would need to upload a new Lua program to handle changing functionality. In contrast to this ad-hoc method for remote calls, LuaRPC provides a more general way to manipulate the state and execution of a remote Lua environment.</p>
<p>You should get a file called <i>luarpc</i> in the same directory which, when started, should give you a normal Lua interpreter with a built-in rpc module.</p>
<p>See <ahref="building.html">building</a> for details and requirements for the building process. In order to boot into RPC mode, the RPC <ahref="building.html#components">component</a> will need to be enabled, and appropriate <ahref="building.html#static">static configuration data</a> need to be set. To build <b>eLua</b> to boot into RPC mode, include
<b>boot=luarpc</b> in the <ahref="building.html#buildoptions">build options</a>.</p>
<p>In terms of the LED example from the beginning of this section, one could directly call pio module functions from the desktop side, experimenting with responses. If the experimentation developed into a program this could be tested both on the desktop side and on the microcontroller by making aliases to eLua modules in local Lua state. Such aliasing can be done as follows:</p>
<pre><code>-- open connection from Linux host serial port to eLua
slave,err = rpc.connect("/dev/ttyUSB0")
-- make a local helper pointing to pio module in eLua
pio = slave.pio
-- define function to set direction and value of port B
function set_port_val(val)
pio.port.setdir( pio.OUTPUT, pio.PB )
pio.port.setval( val, pio.PB )
end
set_port_val(23)</pre></code>
<p>When we run this locally, calling and indexing helpers are translated into appropriate actions on the server. If we were done with modifications to the above function and wanted it to execute in eLua rather than using local aliases, which will result in a great deal of RPC traffic every time the function is called, we can send the function to the remote side:</p>
<pre><code>-- cross-compile local chunk for function and send to server
slave.set_port_val = set_port_val
-- call function on server device
slave.set_port_val(23)</pre></code>
<p>In addition to functions, we can also copy most other Lua types from client to server using simple assignment. Due to Lua's internal workings the opposite operation of copying Lua types from server to client requires an additional metamethod:</p>
<pre><code>-- make table on remote server
slave.remote_table = {}
-- put data in table
slave.remote_table.rval = 42
-- get data back from server, print
local_table = slave.remote_table:get()
print(local_table.rval)</pre></code>
<p>While these examples are trivial, they serve to illustrate a compelling development paradigm that gives one a great deal of flexibility for development and testing with an embedded target.</p>
<h2>Serializable Lua Types</h2>
<p>Most Lua types can be transferred between the client and server states. The following list indicates which ones can be transferred, and where there are known exceptions:</p>
