Johny Mattsson 9bbf8f43fb Successfully boot barebones NodeMCU on ESP32 (only).
RTOS driver evicted as it did not play nice with stdio etc.

Implemented a minimal driver to fully support Lua console on UART0. Output
on UART0 done via stdout (provided by the IDF). Input and setup handled
via driver_console/console.c. In addition to the direct input function
console_getc(), the driver also registers in the syscall tables to enable
regular stdio input functions to work (yay!). The Lua VM is still using the
direct interface since it's less overhead, but does also work when going
through stdin/fd 0.

Auto-bauding on the console is not yet functional; revisit when the UART docs
are available.

Module registration/linking/enabling moved over to be Kconfig based. See
updates to base_nodemcu/include/module.h and base_nodemcu/Kconfig for
details.

The sdk-overrides directory/approach is no longer used. The IDF is simply
too different to the old RTOS SDK - we need to adapt our code directly instead.

Everything in app/ is now unused, and will need to be gradually migrated
into components/ though it is probably better to migrate straight from the
latest dev branch.
2016-09-20 13:35:56 +10:00

73 lines
2.7 KiB
C

#ifndef __MODULE_H__
#define __MODULE_H__
#include "lrodefs.h"
#include "sdkconfig.h"
/* Registering a module within NodeMCU is really easy these days!
*
* Most of the work is done by a combination of pre-processor, compiler
* and linker "magic". Gone are the days of needing to update 4+ separate
* files just to register a module!
*
* You will need:
* - to include this header
* - a name for the module
* - a LUA_REG_TYPE module map
* - optionally, an init function
*
* Then simply put a line like this at the bottom of your module file:
*
* NODEMCU_MODULE(MYNAME, "myname", myname_map, luaopen_myname);
*
* or perhaps
*
* NODEMCU_MODULE(MYNAME, "myname", myname_map, NULL);
*
* if you don't need an init function.
*
* When you've done this, you can simply add a Kconfig entry for the module
* to control whether it gets linked in or not. With it linked in, you can
* then within NodeMCU access it with myname.foo(), assuming you have
* a foo function in your module.
*/
#define MODULE_EXPAND_(x) x
#define MODULE_PASTE_(x,y) x##y
#define MODULE_EXPAND_PASTE_(x,y) MODULE_PASTE_(x,y)
#define LOCK_IN_SECTION(s) __attribute__((used,unused,section(s)))
/* For the ROM table, we name the variable according to ( | denotes concat):
* cfgname | _module_selected | CONFIG_LUA_MODULE_##cfgname
* where the CONFIG_LUA_MODULE_XYZ macro is first expanded to yield either
* an empty string (or 1) if the module has been enabled, or the literal
* CONFIG_LUA_MODULE_XYZ in the case it hasn't. Thus, the name of the variable
* ends up looking either like XYZ_module_enabled, or if not enabled,
* XYZ_module_enabledLUA_USE_MODULES_XYZ. This forms the basis for
* letting the build system detect automatically (via nm) which modules need
* to be linked in.
*/
#define NODEMCU_MODULE(cfgname, luaname, map, initfunc) \
const LOCK_IN_SECTION(".lua_libs") \
luaL_Reg MODULE_PASTE_(lua_lib_,cfgname) = { luaname, initfunc }; \
const LOCK_IN_SECTION(".lua_rotable") \
luaR_table MODULE_EXPAND_PASTE_(cfgname,MODULE_EXPAND_PASTE_(_module_selected,MODULE_PASTE_(CONFIG_LUA_MODULE_,cfgname))) \
= { luaname, map }
/* System module registration support, not using CONFIG_LUA_MODULE_XYZ. */
#define BUILTIN_LIB_INIT(name, luaname, initfunc) \
const LOCK_IN_SECTION(".lua_libs") \
luaL_Reg MODULE_PASTE_(lua_lib_,name) = { luaname, initfunc }
#define BUILTIN_LIB(name, luaname, map) \
const LOCK_IN_SECTION(".lua_rotable") \
luaR_table MODULE_PASTE_(lua_rotable_,name) = { luaname, map }
#if !defined(LUA_CROSS_COMPILER) && !(MIN_OPT_LEVEL==2 && LUA_OPTIMIZE_MEMORY==2)
# error "NodeMCU modules must be built with LTR enabled (MIN_OPT_LEVEL=2 and LUA_OPTIMIZE_MEMORY=2)"
#endif
#endif