(05-27-2020, 03:02 PM)VMMainFrame Wrote: I entered the commands you gave me, it failed on "os.mount(flash,'/flash')" with OSError: 1. Attached is the screen from Serial Bluetooth Terminal and a picture of the inside of the watch.
Thanks for all the detail. It helps a lot, especially because this isn't what I was expecting.
You might be able to fix it my formatting the external flash. Normally this happens automatically when there is no filesystem but it doesn't seem to be working for you because you are getting the "wrong" error message. Of course the wrong error message is not expected so they could still be something else causing us trouble... but either way we won't know until we try!
The following sequence of commands is pretty long and might not be fun to type via the Android keyboard. Howver if these commands run without error then they will probably fix the problem (e.g. get it booting properly with manual help):
Code:
from watch import *
flash = FLASH(spi, (Pin('NOR_CS', Pin.OUT, value=1),))
import os
os.VfsLfs2.mkfs(flash)
os.mount(flash,'/flash')
f = open('/flash/main.py', 'w')
f.write('''\
import wasp
wasp.system.run()
''')
f.close()
Good luck!
(05-28-2020, 01:59 AM)lupyuen Wrote: Hi Daniel: wasp-os is really amazing, now that I have seen the code inside [emoji3]
I'm now documenting my attempt to run wasp-os on Mynewt. Maybe this will take off, maybe it won't. But either way it's a fascinating educational look inside wasp-os [emoji3]
I'm quite pleased with how wasp-os is turning out so far althogh I must concede that the most amazing bits I have inherited from MicroPython!
Anyhow I'll be very interested to see how wasp-os on MyNewt comes together. I'd definitely like to see it running on top of a FOSS BLE stack at some point and MyNewt is an interesting way to do that. The number that will really matter is the amount of free memory once wasp-os is running. Micropython systems often live or die based on whether there is enough spare RAM. I'm hopeful that NimBLE (perhaps tuned for a reduced feature set) will have less overhead.
PS On the subject of multi-threading for comms. Micropython has an special execution state that is a little bit like a softirq handler in Linux. In terms of multi-threading I am planning (eventually) to try running wasp-os from that execution context. wasp-os apps are event driven in order to make that possible. Such an approach should leave the regular execution state available to handle BLE comms and/or the REPL.