Discussion Forums

Uploading python script

#1

How do I upload a script to be run by the Duo on startup? Thanks.

1 Like
#2

Hi @frika, The Duo does not support running a python script for now. Currently only supports REPL (Read Eval Print Loop).

Regards,
guohui

#3

Thanks. Is there an expected use case for the Python functionality currently? Can we expect a future scripting implementation?

#4

We will publish a reference guide(Not applicable for current released python interpreter) for programming the Duo using Python, but only limit to REPL. And we don’t plan to implement running python script, unless the MicroPython support this feature.

#5

MicroPython supports running Python scripts since it’s beginnings. Personally I can confirm that since May 2015. Only the ESP01 device with 512k Flash and the provisional port for Teensy 3.2 has no permanent script storage. They only allow scripts to be embedded in the firmware image. It’s the Duo port that lacks even this feature. Two ways are possible at the moment:
a) Easy: Freeze a script into the firmware image. For instance a call to
exec_frozen_module("main.py")
at the start of loop() in wiring.c would find and execute the module “main.py” in the flash image, which in turn may import other modules, also stored in flash. That can be integrated in the build process by putting the python modules into a subdirectory of duo, e.g. duo/scripts, and call make with
make FROZEN_DIR=scripts
b) Create a file system in the unused part of the external flash. As far as I understand it, there is 768k space available from address 0 on The software is there, “only” the MicroPython code an the firmware code for reading from and writing to the flash has to be matched. Then we’re comparable the level the ESP8266 port has. Stuff like a ftp server can then easily be implemented in python using the great WiFi lib of redbear.

2 Likes
#6

Here’s a link to my repo (the link leads to the subfolder for duo in the duo branch) where I’ve made some changes, I made a fork directly from micropython (and used files from redbear fork) as the redbear one is forked from quite an old revision and the folder structure has changed in the meanwhile.

I’ve been trying to add support for a FAT in the additional flash memory and there’re few issues with it. The stack is too small for the FAT library being able to operate (working_bufs in ../../extmod/vfs_fat.c are 4K) and then there’s still missing USB MSC support from the system FW so you wouldn’t be able to nicely (up/download)load files to/from the flash memory, you’d have to do it through commands in REPL.

The issue with the stack is that even if you change the reserved stack size in linker scripts: ./libs/linker_scripts/gcc/duo the system FW won’t notice, it has to be recompiled. @guohui could you try to tweak it and release yet another FW version?

@robert-hh for the frozen scripts, you should check out the tag frozen-modules and possibly modify lines in wiring.c, I’ve enabled a bunch of micropython’s modules in mpconfigport.h (like floating point arithmetic, mpz long integers, ujson) and it’s far from all so one might to modify this as well, I just want to make a remark that the micropython image now has ~200K so only ~50K are left.

I’ve been trying to make the heap and stack bigger, while I could make the heap somewhat bigger, the stack can’t be made bigger without the system FW recompilation. But still even the heap size can’t be made much bigger unfortunately. The RAM map looks like this:

768B (system_part1) | 75K256 (SRAM) | 48K system_static | 4K stack

So you have some 75K (minus the static variables of your app) for RAM, unfortunately this memory portion is shared with some modules (e.g. for WiFi), I’ve been able to make the micropython’s heap up to ~30K and still maintaining functional pyb.WiFi module.

Final notes for tweakers:
you need to install gcc-arm-none-eabi, head to ports/duo/ and then optionally make clean; make or make flash (the latter requires dfu-util).

#7

Thanks, that looks good. About FAT: The latest release of MicroPython supports also LittleFS, which may be more applicable for this device with small resources. I do not know how easy it is to fit that in.

Robert

#8

I’ve made it! I’ve created new option MICROPY_VFS_FAT_HEAP_BUFFER and I’m allocating working_bufs on the heap (the C’s heap) and after some bugfixes it’s began to work.

You can checkout the tag working-fat. In the meanwhile I’ve reverted the micropython’s heap back to 16K so you might want to find out which size still allows everything working normally.

Hmm can you point me where the support for LittleFS in micropython is? I can’t see it. Nonetheless according to this article, it consumes much more stack than FAT (during normal operations – the working_bufs where used only in the file system creation) so I worry it’d be a bit problematic with that 4K stack.

Right now it would be great to get the USB MSC working alongside the virtual serial port.

#9

Ok, pyexec_file wasn’t still working which I’ve fixed. I’ve made a release.

#10

@frika, @robert-hh

I’ve made some new releases. The duo-v2.3.0-beta release contains a module for transfering files via REPL, you can find a link to the tooling in its description. I wasn’t able to make KeyboardInterrupt to work everywhere, at least I made pyb.delay and pyb.delayMicroseconds interruptible. The binary image is getting close to the 256K limit. It still doesn’t expose the Particle Cloud API which I’d like to add, we’ll see.