This shares the */home/user/work/fs* directory on port /dev/ttyUSB0 at baud 115200. +
Once the RFS server is in place, you can use it from eLua just like you'd use any other file system. For the previous example, if you have a file
named */home/user/work/fs/test.lua* and you want to run in eLua, you just need to do this from the eLua shell:
-----------------------
elua# lua /rfs/test.lua
-----------------------
Notes
~~~~~
Some things you should consider when using the RFS:
- the code is still in beta. It works well most of the time, but sometimes it simply crashes. If this happens, please consider submitting a bug report.
- using hardware flow control is strongly encouraged. To do this:
1. make sure that your eLua board has support for hardware flow control (see link:refman_gen_uart.html#platform_uart_set_flow_control[here] for details).
2. specify the correct *RFS_FLOW_TYPE* value at build time (it should be *PLATFORM_UART_FLOW_RTS | PLATFORM_UART_FLOW_CTS*).
3. make sure that the serial cable connecting the PC and the eLua board also supports flow control. Some simple serial connection cables have only the RX, TX and GND wires.
RTS/CTS flow control requires at least RX, TX, RTS, CTS and GND wires arranged in a null-modem configuration.
4. start *rfs_server* specifying _rtscts_ as part of the _<transport>_ parameter (see above).
- eLua has a global filename size limit of 30 characters, so don't put files with longer names in the shared directory, it might lead to unexpec ted
behaviour.
- the file sharing "protocol" is an extremely simple one, it doesn't make provisions for error correction and has only very basic error detection.
So, if there are serial communication problems on the connection used by RFS, you might encounter RFS errors (timeouts, invalid operations and so on).
If the errors persist, simply restart *rfs_server* and reset the eLua board.
- try not to share directories on devices that might go to sleep unexpectedly, such as an USB HDD attached to the PC, or a network storage device
with a HDD that might also go to sleep. If you try to make an operation on such a shared directory and the device is asleep, it will take a while
until it wakes up and during this time RFS will most likely time out (see *RFS_TIMEOUT* macro above). This, in turn, might confuse RFS completely and
give strange errors, like being unable to list the contents of the directory on the eLua board. If this happens, restart *rfs_server*, reset the
eLua board and try again.
- for reasons similar to the above, if you're running your server on a
hosted virtual machine (ex: Virtualbox, VMWare, ...), make sure the VM
host has a steady clock and does not keep entering and leaving some
energy-saving mode that changes the clock speed. If you work on this
configuration (usually on laptops), just go to your energy-savings
preferences and chose one that will not change the clock during the serial
transfers. This is not mandatory for all scenarios. Just keep this in mind
if you have some issues and change it only if needed.
- the larger *RFS_BUFFER_SIZE* is, the better the performance, but obviously RAM consumption also increases.
- some serial ports built around USB to RS232 adapters seem to confuse *rfs_server* sometimes. If RFS won't work after you tried all the above
instructions, or if *rfs_server* terminates unexpectedly, unplugging and plugging the USB cable of the RS232 adapter and restarting *rfs_server*
will most likely solve your problem.
- if you find a bug in the RFS server and wish to report it, try to reproduce the problem again, but this time run *rfs_server* with *-v* (verbose).
The resulting logs may help us identify the problem.
IMPORTANT: If you like the RFS, but dislike the idea of having to connect your eLua board to the PC with two serial connections (one for the console and another
