Whats the recommended workflow for development something on the esp8266 and testing it? Myself, I use the micropython unix port for some testing. Other testing I need to use the board. Sometimes I use ampy.
Guys out there have a better tools/workflow please let me know.
TIA
recommended workflow for development and testing
-
pythoncoder
- Posts: 5956
- Joined: Fri Jul 18, 2014 8:01 am
- Location: UK
- Contact:
Re: recommended workflow for development and testing
This probably needs to be written up as a FAQ, although approaches may vary.
The Unix port is great for testing code which is not hardware dependent and for porting code from CPython. On the ESP8266 I use a USB or serial connection with rshell rather than WebREPL because the latter uses too much RAM for larger programs. If a program is to run on reboot it's best to develop it as a module rather than by modifying main.py. Once debugged, main.py typically becomes a one-liner importing the module.
With larger programs where the ESP8266 can run out of RAM the code is best designed as several modules. Modules which are largely debugged can then be frozen as bytecode allowing you to compile and run the module under development on the device. Or, if pushed, to cross-compile it - this is still much quicker than doing a firmware rebuild with frozen bytecode. In practice I keep each module small enough to compile on-board.
The Unix port is great for testing code which is not hardware dependent and for porting code from CPython. On the ESP8266 I use a USB or serial connection with rshell rather than WebREPL because the latter uses too much RAM for larger programs. If a program is to run on reboot it's best to develop it as a module rather than by modifying main.py. Once debugged, main.py typically becomes a one-liner importing the module.
With larger programs where the ESP8266 can run out of RAM the code is best designed as several modules. Modules which are largely debugged can then be frozen as bytecode allowing you to compile and run the module under development on the device. Or, if pushed, to cross-compile it - this is still much quicker than doing a firmware rebuild with frozen bytecode. In practice I keep each module small enough to compile on-board.
Peter Hinch
Index to my micropython libraries.
Index to my micropython libraries.
Re: recommended workflow for development and testing
Hi,
Thanks for the reply. Thanks for suggesting the rshell approach. Sounds good. I had littered my code with log statements (in some verbose mode). So there is some program running already on the chip. Can rshell connect to the chip (which is running a program) so I can see the output of the logging?
Thanks for the reply. Thanks for suggesting the rshell approach. Sounds good. I had littered my code with log statements (in some verbose mode). So there is some program running already on the chip. Can rshell connect to the chip (which is running a program) so I can see the output of the logging?
Re: recommended workflow for development and testing
rshell has a repl mode, where it acts like a serial terminal (i.e. minicomm, picocomm, putty). But the act of connecting rshell will stop any running program.
The way I test stuff is to connect with rshell, enter the REPL, start the program by importing whatever the main program is, and then you'll see the output. I normally don't have main.py start my program automatically until everything is tested.
The way I test stuff is to connect with rshell, enter the REPL, start the program by importing whatever the main program is, and then you'll see the output. I normally don't have main.py start my program automatically until everything is tested.
Re: recommended workflow for development and testing
There are a lot of sound reasons to develop on the Unix version first, but I have a less rigorous approach, when it comes to the ESP8266. Since my main goal is just to have fun with my projects... I just work directly with the scripts on the device... coding and testing with a graphical application I wrote on top of ampy. It's pretty basic but has enough functionality for my personal use. If a GUI appeals to you, have a look at uPyCraft.
Many ESP8266 modules have 4MB of flash, which I find roomy enough to carry around a bunch of scripts. I have a single, main "device" that I develop everything on, and simply edit the main.py when I want to switch functionality quickly. This is mainly because I use a Wemos D1 Mini which has various shields that can be swapped and stacked very easily. The GUI has a serial connection that provides the REPL and the debug output, so I can run the scripts manually and/or watch the debug messages.
Anyway, it works for me.
Many ESP8266 modules have 4MB of flash, which I find roomy enough to carry around a bunch of scripts. I have a single, main "device" that I develop everything on, and simply edit the main.py when I want to switch functionality quickly. This is mainly because I use a Wemos D1 Mini which has various shields that can be swapped and stacked very easily. The GUI has a serial connection that provides the REPL and the debug output, so I can run the scripts manually and/or watch the debug messages.
Anyway, it works for me.