* This is an edge case which happens if a file is written to the flash storage
immediately after the first boot and before a reset causing the host to corrupt
the selftests.py script.
* The selftests.py is now executed before USB MSC is enabled to avoid
corrupting the filesystem when selftests.py is removed.
* If the selftests.py fails, the USB MSC is enabled to allow the host to read the error log.
* Now OpenMV Cam's can be discovered in the wild by OpenMV IDE without
hardcoding the OpenMV Cam WiFi IP address and port.
* The firmware reads settings from OpenMV IDE for STA and AP mode.
* Boradcast in both modes works and OpenMV IDE can find the cam.
* AP mode works (albeit the driver needs help).
* Station mode sometimes connects every now and then. There's a bug in
the WiFi module that prevents this from working right. The same code
executes on the cam and in the IDE for both modes but station mode has
issues...
All the notes about how to implement wifi programming are in the code.
Steps:
1. Get wifi_apply_settings() working first and make sure you can turn
the wifi shield on in the right mode. Then add the necessary hooks into
the network code to make it such that previous user wifi code still
works. Also, make sure to handle start and shutdown gracefully.
Basically, get all the lifecycle code working first before moving to the
next step so notning gets in a weird state and bugs creep in...
2. Get the beacon method working. Once this works OpenMV IDE should see
the camera when you hit the connect button.
3. Do the code to turn off the regular usbdbg interface and swtich to
having the data come from wifi_dbg. This isn't a lot of code... but,
will be tricky since you no longer will have USB frames to work with.
All bytes are just going to come randomly and in bursts so you have to
handle the serial stream yourself... (Kwabena can help writing a
statemachine for dealing with this type of stuff if you want. I do it
all the time).
OpenMV IDE includes an ini file generator which will let you set board
settings easily from the IDE. Currently, the IDE has support for setting
the WiFi shield up along with adding a REPL Uart.
Anyway, this commit adds support for the OpenMV Cam to parse an ini file
on startup to configure things before starting main.py. WiFi support is
not yet implmented. However, we now have the ability to turn the UART
and put the REPL terminal on it on startup given a setting in the ini
file.
(Why not use boot.py like normal MP? While that is more flxible it's
much harder for the IDE to easily write out settings for you which is
what most users will want to do versus coding this up).
...
The movitation for adding REPL UART support in particular is so that the
OpenMV Cam can be used as a slave processor to IoT type processors like
the ESP32/ESP8266/ParticlePhoton/ElectricImp. In particular, a processor
like the ParticlePhoton can control the OpenMV Cam's reset wire. Wake
the camera up by releasing reset, then send a script to it after it
powers on over the UART. The camera will then run the script, do
computer vision, and report results back over the UART to the
ParticlePhoton. Users can then push new scripts to the OpenMV Cam from
the cloud allowing for semi-flexible firmware fixes for the OpenMV Cam
over low data rate networks.
By setting this feature up the need for OpenMV to offer a WiFi IoT
system is reduced as we can now just be the best camera for everything.
...
Due to... I don't know... ctrl-c doesn't work on the duplicated UART.
https://github.com/micropython/micropython/issues/1568
Not sure how to handle this. I don't want to fix it since it needs to be
fixed by MP upstream. Right now the work around is for the mastering MCU
to just reset the OpenMV Cam when it's done with the system.
That said, this does mean that once you start a script using the Open
Terminal command line system you won't be able to stop the script.