Weshould now have an STM32F4DISCOVERY board with eLua running on it.The debug UART on this board is not made available via theprogramming USB (Mini USB socket at the top of the board). The Luaterminal is supplied as a CDC USB serial device on the applicationport on the Micro USB port at the bottom of the board.
installvirtual comport driver for windows
ttyACM0115200 n 8 1
newlinehandling: "CR" on receive, "CR+LF" on send (someterminal programs won’t give you a choice here).
the basic version is small (to keep the eLuaimage small), but functional.
Allows you to receive from the PC running theterminal emulator program, a Lua file (either source or compiledbytecode) via XMODEM andeither execute it on your board orsave it to a file. To use this feature, youreLuatarget image must be built with support for XMODEM (seebuildingfor details). Also, your terminal emulation program must supportsending files via the XMODEM protocol. Both XMODEM with checksum andXMODEM with CRC are supported, but only XMODEM with 128 byte packetsis allowed (XMODEM with 1K packets won’t work).
To start the transfer, enter recvat the shell prompt. eLua will respond with "Waitingfor file …". At this point you can send the file to the eLuaboard via XMODEM. eLua will receive and execute thefile. Don’t worry when you see Ccharacters suddenly appearing on your terminal after you enter thiscommand, this is how the XMODEM transfer is initiated. Ifyou want to save the data to a file instead of executing it, use recv<filename>instead.
Since XMODEM is a protocol that uses serial lines,this command is not available if you’re running your console overTCP/IP instead of a serial link. If you’d like to send compiledbytecode to eLua instead of source code, pleasecheck thissection first. Examples:
$ recv /wo/temp.lua--保存文件
the advanced shell (new in 0.9)adds file masks, file operations and other goodies to the basicshell. If you have enough flash on your MCU, this is almostcertainly the version that you want. The advanced shell is anextension to the simpleshell. It adds some new features to the simpleshell:
file masks ：Theadvanced shell supports file masks for various file operations (forexample cp). A file mask can match zero, one or more files.In order to match more than one file, it uses two specialcharacters:
?: this matches exactly onecharacter
*: this matches zero ormore characters, non-greedy (it stops at the firstnon-special character). Any ? charactersimmediately following the * will be ignored.
more file operations (rename and move)
recursive operations (for example recursivecopies of directories)
>print(pd.board() .. "/" .. pd.platform() .. "/".. pd.cpu())
>ledpin = pio.PD_13
>pb = pio.PA_0
>print( pio.pin.getval(pb) )
>print( pio.pin.getval(pb) )
You can compile and use more than one file systemin eLua, as listed below:
the ROM filesystem: a very simple, very low footprint read-only file systemthat can be included in the eLua binary image. Check herefor details.
the FAT filesystem: a read-write FAT file system implementation (platformindependent) that can currently be used with SD/MMC memory cards.Check herefor details. (new in 0.7)
the remote filesystem (RFS): a read-write file system that allows eLua to'share' a directory on a PC, effectively accessing its contents asif it was a local file system. Check herefor details. (new in 0.8)
the 'write once file system' (WOFS): avery low footprint, read-write filesystem with a catch: a file canbe written only once, in a single shot. By default, WOFS uses theMCU's internal Flash as storage. Check herefor details. (new in 0.9)
Read-OnlyFS in MCU Flash
TheROM file system
TheROM file system (ROMFS) is a small, read-only file system builtfor eLua<.It is integrated with the C library, so you can use standard POSIXcalls (fopen/fread/fwrite…) to access it. Itis also accessible directly from Lua via the io module.The files in the file system are part of the eLua binaryimage, thus they can’t be modified after the image is built.Forthe same reason, you can’t add/delete files after the image isbuilt. ROMFS doesn’t support directories. ROMFSis integrated with thebuild system formaximum flexibility.
Touse ROMFS,all you have to do is copy the files you need on your eLua imageto the romfs/ directory.The build system will automatically take care of including the filesin romfs/ inyour eLua image.So all that’s left to do is build eLua.As part of the build process, the mkfs scriptwill be called, which will read the contents of the romfs/ directoryand output a C header file that contains a binary description of thefile system.
Touse ROMFS from C code, whevener you want to access a file, prefix itsname with /rom.For example, if you want to open the a.txt filein ROMFS, you should call fopen like this:
Writeonce file system (WOFS)
eLuawrite once file system
(v0.9and above) TheWOFS (Write Once File System) is a read-writefile system designed to use the MCU’sinternal flash as storage.It has an important limitation: afile can be written only once,in a single shot (although there is a mechanism to "overwrite"a file that has already been written, see below for details). Afterthe file is written, it is not possible to append more data to it ormodify its current data. While this limitation might seemprohibitive, WOFS can have quite a few practical uses, including:
receivingfiles and saving them in the internal flash using the recv commandin the eLua shell.
copyinga file from another file system in the internal flash usingthe cp commandin the eLua shell.
savethe history of the code you typed in the interactive Lua shellif linenoise isenabled.
datalogging. Generally a data logger always appends to its log file,just like WOFS.
WOFShas a number of important advantages over a "real"read-write file system:
verylow footprint. WOFS is implemented as a simple extension to the ROMfile system,using an internal file system representation which is very similarto the one ROMFS uses.In fact, both file systems are implement in src/romfs.c.
itis flash-friendly. The WOFS internal file system structure iscompletely linear,thus flash sectors are written in natural order from the first freesector to the last sector in flash. This eliminates the need for aflash wear leveling layer.
itkeeps data in the internal flash and eachfile occupies a single contiguous block of memory.Since the internal flash is directly accesible by the MCU, thisimportant property allows Lua bytecode files in WOFS to takeadvantage of some eLua memoryoptimizations (for example the read-only strings and executingbytecode directly from flash)
itneeds very little RAM. In a fully blown read-write file system, aflash sector would be split into logical "blocks" used bythe files in the filesystem. If the sector must be erased, but someblocks inside it still contain useful information, the file systemimplementation would need to copy the block content in RAM, erasethe sector and write back the useful information in flash from RAM.As some eLua targets have flash sectors which are quitelarge, this operation might fail due to insufficient RAM, mostlikely leaving the file system in an inconsistent state.
EnablingWOFS in eLua
Inorder to enable WOFS, you need to tell the implementation how muchflash the eLua imageuses. This information can be made available at compile time byexporting a linker command file constant namedflash_used_size.The value of this constant must reflect the total size in flash ofthe eLua image,including the code, constants, data section and possibly othersections. For an example of how to define this constant,check lm3s.ld in src/platfrom/lm3s.
Anotherthing that you need to specify is the internal flash structure. Theflash memory is divided into contigous areascalled sectors (a sector isthe smallest erasable unit in a flash memory). The sectororganization can vary greatly amongst various MCUs, but eLua providesa generic mechanism to describe the flash structure:
ifthe flash is divided into equally sized sectors, definethe INTERNAL_FLASH_SECTOR_SIZEmacroto the size of one flash sector.
ifthe flash sectors have different sizes, definethe INTERNAL_FLASH_SECTOR_ARRAY macroas an array that contains the size of each flash sector in turn.
Checkyour MCU datasheet to find which of the above variants you need touse.
Othermacros that you need to define are given in the table below:
Thesize of the internal flash memory, in bytes
Thestart address of the internal flash memory in the MCU addressspace
Theunit size of the Flash write access routine (see below).
Finally,your platform implementation needs to define two functions foraccessing the internal flash. The first one is a flash writefunction, called by WOFS to actually write data in flash. Itssignature is in inc/platform.h:
u32platform_s_flash_write( const void *from, u32 toaddr, u32 size );
Dependingon your platform, the flash write hardware may have differentrequirements. Some MCUs only allow writing the flash in multiples ofa power of 2 (usually 4), at an address which is a multiple of apower of 2, or both. If this is the case for your MCU (check thedatasheet), defineINTERNAL_FLASH_WRITE_UNIT_SIZE tothe required alignment. This way, you can be certain thatyourplatform_s_flash_write functionwill be called only with a destination address (toaddr)that is a multiple ofINTERNAL_FLASH_WRITE_UNIT_SIZE andwith a size (size)that is also a multiple ofINTERNAL_FLASH_WRITE_UNIT_SIZE.
Thesecond flash-related function is used to erase pages from flash (usedonly when "formatting" the WOFS image via wofmt,as already explained). Its signature is also in inc/platform.h:
intplatform_flash_erase_sector( u32 sector_id );
Check thislink formore details about the flash platform interface. If all the aboverequirements are met, justdefine BUILD_WOFS inyour platform_conf.h file,compile and burn your eLua imageand you’ll have a WOFS instance up and running. Check here formore details about the configuration of your eLua image.
eLua hasa very flexible build system that can be used to select thecomponents that are going to be part of the eLua binaryimage and also to set the compile time (static) configuration. To useit, you need to edit a single configuration file (platform_conf.h)located in the platform specific directory(src/platform/<platform_name>/platform_conf.h).The configuration parameters are described in detail in the nextparagraphs.
Enablessupport for the write once file system, check here fordetails. To enable:
Staticconfiguration data dependencies: INTERNAL_FLASH_SIZE,INTERNAL_FLASH_START_ADDRESS, INTERNAL_FLASH_SECTOR_SIZE,INTERNAL_FLASH_SECTOR_ARRAY, INTERNAL_FLASH_WRITE_UNIT_SIZE
查找Staticconfiguration data dependencies:
flash_used_size，ittellsthe implementation how much flash the eLua imageuses. This information can be made available at compile time.
PROVIDE( flash_used_size =SIZEOF(.text) + SIZEOF(.data) + SIZEOF(.ARM.extab) +SIZEOF(.ARM.exidx) );
u32platform_s_flash_write( const void *from, u32 toaddr, u32 size )
intplatform_flash_erase_sector( u32 sector_id )