I built NodeMCU firmware with module enduser_setup, but when using it in Arduino IDE the compilation stops with this error:
enter code here test_:35: error: 'enduser_setup' was not declared in this scope`
Do I need to include something else?
There seems to be a fundamental misunderstanding. There are two choices but you mixed and matched them.
If you want to program the Arduino way then you don't need the NodeMCU firmware. You have to be prepared to compile and upload the entire binary to the device every time you change a single bit in your program.
If you want to program in Lua, a scripting language not too different from JavaScript, then you need to flash the NodeMCU firmware first. After that you simply upload your Lua script(s) and (re)start the execution or invoke the new functions you just uploaded. You won't need the Arduino IDE at all for this.
Disclaimer: I'm a member of the NodeMCU firmware team and thus I can't deny being slightly biased as to which approach I prefer.
Related
I'm hoping to find a way to update to the next NodeMCU version OTA as many of my devices are rather difficult to access.
To do this (if I'm headed in the right direction) I'd need a way to add binary C functions at runtime. I'm picturing using LUA to upload a binary file containing some C functions to call the system flash operations. Then using those in an LUA OTA update program based on the Arduino version of the firmware Update class.
I believe this would mean loading binaries into RAM or pointing to a binary file in SPIFFS.
My question is, are the necessary functions needed to manipulate the LUA function table to add C functions available in LUA at runtime? Can they be pointed to wherever I put the binaries? Is the C compiler output relocatable?
I would love to be able to update my NodeMCU ESP8266-01 OTA, since they're located in awkward spots. I'm by no means an expert regarding the ESP or NodeMCU, but I haven't been able to find anything recent about OTA updates. I found some discussions about it going back to 2015, but it never seems to have been implemented.
I use my ESP with NodeMCU to control a PWM dimmer. I upload a precompiled version of NodeMCU with the NodeMCU Firmware FLasher, and then use ESPlorer to upload a custom lua file called 'init.lua'. I'm not even sure if this is the proper way to do stuff, but it works.
So the main question: Has OTA updating been implemented, or is it possible in some way?
Just to clarify, I don't think I want to update the firmware. As I understand it, firmware is what you build yourself, or on a website like https://nodemcu-build.com. I want to update the lua files that run on the ESP, that you normally upload through a program like ESPlorer.
I found some discussions about it going back to 2015, but it never seems to have been implemented.
Indeed, firmware OTA is not available yet. However, as you probably know, the need for firmware OTA is much lower with the NodeMCU firmware than e.g. with the Arduino platform. I'd argue that you're much less likely in need to replace/upgrade/extend the firmware with its built-in modules than the application code that runs on top of it.
Fortunately, it's quite simple to replace one or several Lua scripts (compiled or uncompiled) on the device and reboot it. All the web and cloud IDEs listed at https://frightanic.com/iot/tools-ides-nodemcu/ offer this. There's even a pending PR that'll bring FTP support to NodeMCU.
For a complete Lua provisioning system take a look at what #TerryE provided at https://github.com/nodemcu/nodemcu-firmware/tree/master/lua_examples/luaOTA
I've attempted to use the two Web IDEs listed in the link provided in Marcel Stör's answer, but I honestly failed to understand how to use either IDE. they also seemed like they weren't exactly what I was looking for, and required a server to connect to, or an extra program, which I wanted to avoid.
Edit: Apparently, I did end up using one of the two Web IDEs in the list. Since it's been a while since I did all this, it's a bit fuzzy in my head.
I eventually stumbled upon this GitHub page, which seemed to provide exactly what I was looking for: The ability to access the Lua files on the ESP through a webbrowser. I have personally changed the ide.lua file around completely, since I needed to call functions from it in the init.lua script. However, I think you can just upload the ide.lua script to the ESP, and add a line containing dofile("ide.lua") to your init.lua file.
If anyone is interested in my changes to, or my implementation of the ide.lua script, you can take a look at my repo Timmiej93 / QuinLED / Program code.
In fact there's a class for that to implement OTA i the NodeMCU its called the ESPhttpUpdate you can refer to ESPhttpUpdate for further details.
I don't know if his is the correct topic to ask this but here it goes:
I have a NodeMCU devkit 0.9 and I'm am able to use ESPlorer to upload basic code like the web server with some buttons that turn on and off LEDs on the board.
I was trying to interface NodeMCU with a load cell amplifier (HX711), which I saw has libraries for NodeMCU. How can I "include" hx711.c in my .lua file for it to recognize the functions inside hx711.c?
The error that appears when I try to send to ESP is
LUA interpreter error detected
stdin:1: attempt to index global 'hx711' (a nil value)..."
Best regards.
You need to build a NodeMCU firmware that includes the HX711 module. Then you need to flash the new firmware to your devkit.
I'm working with ESP8266 and I don't want to use Lua for the whole project, I just want to run a few snippets of Lua code, received from wifi/sd card. I'd need to start a Lua environment and run the scripts, which would then eventually call some native functions for low level tasks. In other words, I just want to use Lua as simple scripting language (as it's intended to be) to implement some dynamic behavior. Is it possible? Is there any build of lualib for arduino?
Thanks in advance!
You can simply embed Lua in a extlibs/ folder for example and link to it when compiling your program.
There is existing Lua binaries but building it yourself is easy and better (as it's multiplatform).
OK, I know both answers told me I can just embed the code into my project, however, I found out I need to make some small changes. I made an example working project available here and the following list of changes had to be made:
The flags LUA_32BITS and LUA_USE_LONGJMP (C exception handling) were enabled
The following libraries were excluded: io, os, package, coroutine
The following functions were removed from C API: luaL_fileresult, luaL_execresult, luaL_loadfile, luaL_loadfilex, luaL_dofile, luaB_loadfile, luaB_dofile
Lua output messages are redirected to the Serial interface, check tinylua.h, tinylua.cpp and lauxlib.h to change this behavior
Hope this helps!
The ESP8266 has up to 4MB of program storage. Theoretically you can get up to 16MB as the datasheet specifies.
As I remember, compiling an amalgamated version of Lua (all sources in one file), occupies less than 100kb.
So, you can compile the Lua library and use it as needed on esp8266, even using Arduino IDE.
But you will get NAKED Lua if you do so... No nifty libraries to control Wifi, serial, SD, ports... You would have to provide that in C, or use NodeMCU code as you need.
You can try LuaJIT and access C code directly from Lua, cutting out the need for writing libraries. I have no idea of how you would compile it to Esp8266, or if anyone have tried this before, but you can do it "for science" and tell us how it turned out.
So here is the problem: Recently someone bought a new PC for server to replace an older dating from before 1985 (i wonder how it is possible to work daily from then) .
He wants to put there the old COBOL software and he isnt willing in any means to rewrite it to something better..
So is there any compiler for 1985 cobol? For nowadays red hat linux? Googling it found opencobol and other few but all converted the code to c... Seems too compilacted too me..
UPDATE AS REQUESTED
AIX was the old system
What's the problem with converting the COBOL to C and then compiling? As long as it works. Early C++ environments were implemented in the same way: they converted the C++ to C, and then invoked the C compiler.
Converting the COBOL to C allows them to use high-level abstractions that implement the COBOL equivalents in C. They can leverage the standard C libraries, and also convert the COBOL data access code into calls to widely available databases like MySQL. Finally, converting to C and then compiling leverages the vast amount of development effort that went into code generation. Were they to try compiling directly to object code, they'd have to generate the intermediate code expected by the GNU compiler subsystem, or they'd have to go directly to object code. Either one of those would be much more complicated than converting to C, meaning that the likelihood of bugs in the COBOL compiler would be much higher.
From where I sit, I'd say OpenCOBOL is worth looking into. Note that they say they implement "a substantial part of the COBOL 85 and COBOL 2002 standards." You probably want to make sure that they implement the parts that you need.
I would also suggest that you look into TinyCOBOL.
You don't mention when the application, or AIX was last updated. If these were updated in the last few years, you may be able to port the application, without re-compiling. You should check to see what COBOL compiler was used originally, e.g IBM, RM/COBOL, AcuCOBOL, etc. It might be possible to buy a run-time only version (will execute, but not compile), which would be cheaper than buying a compiler.
A company called Micro Focus make a cobol compiler for Windows but I can assure you it is not cheap at all!
Standard method for doing this is called migrating and involves a number of steps including converting source file to a textfile format or a filetype compatible with the target computer, using an approved method of converting to a file and writing to magtape with compatible recording method of Phase encoding or to disk or other data medium possibly in the ASN.xx mode, transferring to the new computer to then read in the file (through ASN.yy) and store it in a native or import file format, then either use a utility to convert it to the sourcefile format or by running the program development environment to access the native text file or import file and saving the content as a native sourcefile. Perform manual checks and amendments to the source or script code and then compile the program and repeat alterations until a working version is achieved. Create test data files on the new computer and create a new jobfile or macro to run the job in the development environment. When fully tested the program can be run live using data files and live macros or jobfiles migrated over from the old system or newly created in more or less the same way as bringing over the source code. An important point is that the live data must be read into a specialized data takeon or loading program to achieve a populated database before any new transactions occur in the case of a structured datafile being necessary. When moving from AIX or other versions of Unix to an entirely different operating system the characters for end of line and linefeed and end of record may need specific conversion if they are not handled by a file format convertor or exporter utility.