RigTigThe controller code for interpreting GCODE lines works fine on my desktop (using ZeroBrane). The lua code even loads onto the NodeMCU on an ESP12F, but it complains about not enough memory to run.
After some research and careful reading of NodeMCU documentation, it seems I am asking too much of the ESP12F/NodeMCU combination. The device really is an ideal IoT terminal node, but not really capable of parsing the GCODE and performing all the related tasks.
Oh well, looks like back to using an Arduino Nano clone and just using the ESP12F as the WiFi interface. I want to keep the Arduino serial IO for monitoring, etc. So, I now need to look at the best way to communicate between Arduino and ESP12F other than serial, then rewrite the Arduino code for the GCODE parser and WiFi interface.
At least, I've learnt lots about the ESP8266 and the ESP12 in particular, plus got a non-trivial Lua program to work (if only in simulation mode).
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
@matseng, you are correct. It just doesn't sound right. The problem is not the MCU; it is the toolset. Essentially, NodeMCU takes up a large chunk of the codespace on ESP12 before any user code gets to be added. And the user code just gobbles up codespace at a great rate, because of the complex stuff that can be done. I cut down the code I was loading to almost half and the ESP12 complained it still did not have enough resources to run. I do not know how to tune NodeMCU and its Lua code to get it to do what I want and leave out all the stuff I do not need, but it strikes me that I was using a sledge hammer to do a job really requiring a tack hammer. GCODE interpreters are not that hard. There are dozens (hundreds?) of desktop 3D printer designs using Arduinos of various sizes, including the UNO. My first working version of this printer used an Arduino Nano.
The STM8S103F has only 1K ram and 8K flash. The Forth engine I am using takes (currently) 4953 bytes of the flash, and the very basic GCODE interpreter takes about 3500 bytes (still a work-in-progress), so I'm getting close to the limit. Of course there are many compromises to get the code this small, but that is part of the challenge and it is fun. The outcome is that these limited resources are enough to get the job done, and even I am amazed.
So, to summarise, it is not the hardware that is the key to solving this (or any other problem). It is the total package of hardware and software tools, plus the knowledge to properly use those resources.
Are you sure? yes | no
It must be something I don't understand with this particular problem.
You're saying that a 8-bit MCU running at 16MHz with 2K ram and 32k flash is better at processing GCODE than a 32-bits MCU (with floating point hardware) running at 80/160MHz with 96k data ram and 1024k flash for code?
That really doesn't sound right to me...
Are you sure? yes | no