Hi Everyone, hopefully someone might know what the issue is.
I finished a simple script to test the python on a Arduino Nano BLE Sense.
Successfully followed the instructions here and wrote my own, all tested perfectly for the sensors: Getting started with OpenMV | Arduino Documentation | Arduino Documentation
However the option to save to the device is grey and cannot be selected in the tools menu.
Is this feature available yet?
No, at the time that port was made the nrf port didnât have any filesystem support.
Thank you for the confirmation. So are only the portenta and RP2040 supported in that regard?
Yes thatâs right for now.
It looks like supporting file system.
MicroPython v1.19.1-216-g45ab801c3 on 2022-07-27; Arduino Nano 33 BLE Sense with NRF52840
Hi all -
Just to add my own experiences with this (and I am only just starting to experiment with OpenMV, and specifically targetting the nano 33 BLE, so apologies if I am missing any additional context).
In the current nano firmware for OpenMV there does seem to be embedded filesystem support, in that I can use scripts (import os) to create directories and files on the nano, and these are non-volatile (survive power down etc.). But the OpenMV IDE options to save to the embedded filesystem are indeed greyed out. I tried using the pyboard.py script as a workaround but it fails, throwing âcould not enter raw replâ. Trying to communicate with the board directly via a serial terminal (either using the terminal interface in OpenMV IDE or a standalone terminal program) shows some very erratic and unpredictable behaviour: characters not echoed consistently or lost completely. Iâm not sure, but this seems suggestive of a problem in the embedded code for handling ânativeâ serial-over-USB in the version of the MicroPython nrf port currently included in OpenMV. I tried flashing the most recent upstream MicroPython port for nrf (per link in the message above) directly to the board. This âworksâ in that the communication in a serial terminal is now as expected, and pyboard.py actually works to (e.g.) copy files into the nano file system. However ⌠OpenMV IDE itself can no longer connect directly to the board (presumably because the firmware is now lacking relevant additional OpenMV support). A next step might be to try to merge the most recent MicroPython (including this updated nrf port) into OpenMV: however, that is beyond my own immediate skills. So Iâm wondering is there any merging/syncing of OpenMV with MicroPython on an ongoing basis? In order words, is it reasonable to expect that this problem might just âresolve itselfâ if I wait for a future OpenMV release?
@iabdalkader - Ibrahim might know more but we arenât supporting a file system on that board right now so itâs usability is just at demo level.
Thanks for the response. Obviously full filesystem support via OpenMV on the nano 33 BLE and other nrf based boards would be ideal for me (and some others, I guess). But I do get that these are not a core target for OpenMV (though that is perhaps not quite the message being conveyed here?). Even short of full filesystem support in OpenMV IDE, the issue with serial communication is presumably a problem in itself, even for âdemo levelâ usability as it could affect virtually any use of serial port interfacing to a nano 33 BLE running the OpenMV MicroPython. And it specifically prevents even the workaround of pyboard.py for doing remote filesystem management outside of OpenMV IDE.
But in any case, my ultimate question was really just whether OpenMV MicroPython is generally expected/intended to track upstream developments in MicroPython? I guess that would not be guaranteed to at least fix this serial communication issue, but there has to be a reasonable chance that it mightâŚ
But the OpenMV IDE options to save to the embedded filesystem are indeed greyed out.
That port does not (and very likely, will not) have mass storage support. Itâs just not very popular upstream, and gets a lot of resistance, so youâll have to use whatever command line tools MicroPython provides, once that serial issue is resolved.
So Iâm wondering is there any merging/syncing of OpenMV with MicroPython on an ongoing basis? In order words, is it reasonable to expect that this problem might just âresolve itselfâ if I wait for a future OpenMV release?
Yes, after every stable MicroPython release I update/sync our fork, sometimes it takes a lot of work, so it may take a while to get around to, but eventually we catch up. Note, right now weâre only one release behind 1.18, just saying weâre kinda up to date, but at the same time I acknowledge one release is a lot of fixes. And yes the issue will resolve itself if it was fixed in that release (I think that was an issue with MicroPythonâs tinyusb CDC driver implementations that affected multiple ports).
But I do get that these are not a core target for OpenMV (though that is perhaps not quite the message being conveyed here?).
We maintain support for Arduino boards, they get the same updates, bug fixes etc⌠Iâve also added support for a number of boards upstream, so you now have another option if you donât need OpenMV firmware features.
Thatâs great @iabdalkader - many thanks. I really do appreciate both the timely answer and the overall OpenMV effort which is really extremely impressive.
Update: I see that the latest OpenMV Development Release has now incorporated MicroPython 1-19 - yay! I have just installed the updated firmware on my nano-33-BLE and pyboard.py now seems to work successfully. I did need to use the âno-soft-reset switch on pyboard.py but with that, the commands to access the nano 33 filesystem all seemed to work as expected.
Thanks again to @iabdalkader and all involved with this release!
bmcm,
thank you for discovering this! Would you help me further please? I have questions on what you did as Iâm trying to save a python script on my nano 33.
I believe I have downloaded and installed firmware.bin from the development release by following the steps in the Arduino getting started guide (uploading updateBLandSoftDevice with Arduino IDE, running it, updating firmware with openMV). However Iâm still unable to save the code to the nano, it is still greyed out.
What do you mean you needed to use the -no-soft-reset switch on pyboard.py?
What steps did you take to use -no-soft-reset switch on pyboard.py?
Did you install pyboard.py on the nano? Isnât that to be used in a terminal on the pc side to interact with the board?
Would you point me in the right direction as to tutorial on how to use pyboard.py with the nano?
Please help, Thank you
Hi @cfink.cals -
Sorry for delayed response.
To clarify: you will still not be able to use the OpenMV IDE to access the filesystem (âsave python codeâ) on the nano 33. I donât know if that will ever be available on this board (Iâm not sure of the underlying implementation or what would be necessary to make it work).
For now, the only somewhat practical way to access the nano 33 filesystem from your development/host machine (the laptop etc. with the physical USB connection to the nano 33) seems to be via running the pyboard.py standalone python script on the host machine.
Although this script is made available as part of the OpenMV project, it is used completely separately from the OpenMV IDE.
To run pyboard.py you will need to have a python environment installed on your host machine (this is separate from installing OpenMV IDE on your host, or installing MicroPython firmware on the nano 33 - the latter allows to run python code on the nano 33, but not on the host system). The details on this will vary depending on your particular host platform. Iâm running MS Windows 10 and have installed the âminimalâ version of the anaconda python package manager called miniconda. But there are many other ways of installing python on Windows so you can choose your own preference.
Assuming you have python installed on the host, you will need to open a command line shell (with the miniconda installation on Windows, this is called âAnaconda promptâ). You will likely need to manually install the python pyserial package (which pyboard.py depends on); if using anaconda/minicoda, the shell command âconda install pyserialâ should work; otherwise try âpip install pyserialâ.
Next, within the shell, navigate (normally using the cd command to âchange directoryâ) to wherever you have downloaded the pyboard.py script . You should then be able to invoke/execute the script, using the various options/switched detailed in its documentation. Try âpyboard.py --helpâ first just to see that the script execution works at all (i.e., that you have python available, and pyserial installed etc.). You may need to explicitly specify âpythonâ before the script name, thus: âpython pyboard.py --helpâ.
You will need to know what serial port the nano 33 is connected on (and then specify it with the -d option to pyboard.py). If you donât already know, but you can successfully connect to the board with OpenMV IDE then you should be able to see the correct port there; but remember to close, or at least disconnect, OpenMV IDE before then trying to run pyboard.py.
As described in my previous post, in my own testing, I always had to include the -no-soft-reset switch/option with pyboard.py to order to get successful communcation with the nano 33; this option does not seem to be documented, but I found it by examining the script itself.
Once you have pyboard.py working and successfully communicating with the nano 33 you can try using --filesystem and its various subcommands to access/modify the remote nano 33 filesystem.
Hope that clarifies/helps: but in essence, you will need some level of comfort/experience in using a command line shell on your host system, and specifically in running python scripts within such a shell, in order to use this approach.
Thank you very much for your reply. It has helped a lot. I have some experience working with the termial and from your reply I have been able to access the filesystem on the nano 33! Wooh! I made a directory, removed it, and tried a few other filesystem operations, and I even got a script to run on the nano 33 (blininkg LEDs) and saved it. The -no-soft-reset worked. Here is what I ran in the Anaconda prompt (Miniconda3):
python pyboard.py -d COM8 -w 100 --no-soft-reset -f cp blinky.py :
BUT I still have the original problem for me, which is: I cannot get the script to run just by saving it onto the nano 33 in its filesystem. I want to be able to save the script onto the board so that as long as the board is powered I can run python on it but without the need of a computer, like a remote datalogger. So, my question is this: Were you able to accomplish running a python on your nano 33 without the need for a computer or terminal connection? (just powering it via a battery or other source?)
Thank you again for your reply
You can also use mpremote ? I think pyboard.py is obsolete, not sure why it still exists⌠Btw I can probably fix that -no-soft-reset issue, if you report a bug on github will look into it.
Note to save a script that will on power-on, save it as main.py
Thank you for your reply @iabdalkader and to @bmcm for the explanation above.
I think mpremote would work but I have a new problem now. I was able to save the code onto the nano33 as main.py and by pressing reset the board does indeed run it.
The new problem: I cannot access the filesystem anymore on the board. When I run the command to access the filesystem I get âfailed to access COM8â. It doesnât show up in device manager either. I retried to upload the bootloader too but once the bootloader was installed it started running the main.py script and I got the same message. The script is simple too, just blinking the blue LED.
Any reason why the nano 33 wouldnât be connecting to the pc via a COM port after saving the main.py script and running it?
I think this issue is fixed, test again with the development release ?
Ok, I tried again:
From the latest development release, I downloaded the firmware_NANO33.zip, extracted it, and used OpenMV IDE to Run Bootloader (load firmware). This installs succesfully on the board. However, my board is still not recognizeable by my windows pc; âUsb not recognizedâ notification appears.
Also, this latest firmware is the same size as the previous at 600KB, is this correct? Do I need to build the firmware from source instead of just downloading the NANO33.zip?
Thank you
So ⌠I have just run into the same problem. Or at least I think so. Hard to be sure: because I can no longer access REPL, I canât check the filesystem; but I think I did accidentally manage to leave a main.py that is now impossible to get rid of.
(I am running OpenMV IDE 2.9.7 to reflash the firmware: but this doesnât seem to clear the FS - despite the tickbox suggesting it canâŚ)
I guess maybe there should be a way (via BOSSAC?) to forcibly zero out the flash area allocated for the filesystem: but it seems quite convoluted/obscure to figure out exactly what the start and end addresses are. Any other advice or ideas would be appreciated!
Just to say that, ideally, there would be a general purpose way to trigger a microPython reboot into âsafe modeâ (no main.py or boot.py execution). Not all that easy to suggest a suitable trigger on the nano 33 BLE: but maybe triple tap on the reset button (double tap already triggers bootloader mode)?