The sample code, blink.py, works. But, time.sleep() dose not work. Runnning the code below, I get "AttributeError: 'module' object has no attribute 'sleep'".
Found this just via Google:
" time.sleep(seconds )ΒΆ
Sleep for the given number of seconds. Some boards may accept seconds as a floating-point number to sleep for a fractional number of seconds. Note that other boards may not accept a floating-point argument, for compatibility with them use sleep_ms() and sleep_us() functions."
So, it means:
on some boards time.sleep() is supported as integer or as floating point number
instead, use time.sleep_ms() - as what you see working
try to provide for time.sleep(seconds) - the seconds as real floating point number, e.g. 1.0 (not just 1 - it can mean integer 1 instead of floating point 1.0 - therefore it fails)
It might be just the issue to use 1.0 instead of 1 for the seconds (floating vs. integer format value).
I am sorry,
not using MicroPython really (just regular Python on Host PC and following the Internet help pages for MicroPython).
No idea. I am sorry.
As software engineer I would argue: "why do you care when another approach is working?"
Nothing is perfect and never consistent with (online) help provided.
All what works is fine. You can complain and argue against a "company" - but it will not solve your current problem. All what is working is fine, all what is badly documented or wrongly mentioned... - what can you do? (hard enough to figure out which info in Internet is "wrong").
Personally, I do not trust any SW/FW when I cannot see the source code. I do not believe anymore in documentation on web sites: often, they talk about features or "how to use" which is out of date, not true, not working. All what matters for me is: "provide source code to have a look myself" (real Open Source to go with).
And to be honest:
"MicroPython" - even it works, it is actually "strange": I prefer to send my data from MCU to a host and than use host Python scripts to process.
I cannot imagine that MicroPython is complete, the latest Python version or would do the same processing as I could do on a host. It can never be the same Python as on a host PC!
I do not like to use a high-level HW-abstract coding language like "Python", when the resulting code is not really platform independent (and re-usable).
So, my approach:
my MCU board is a "data aggregation board", a sensor board (for sensors, data input I do not have on PCs).
It should send me the sensor data (I use ETH network) to host PC. Host PC can get it (Network in Python on host PC is easy, even Matlab can get my sensor data, all tools possible...).
It is much more powerfull.
MicroPython is just slow data processing with limited features (not all Python libs and features).
And: "unpredictable real-time": I do not like to run a sub-system like MicroPhython which makes my MCU as "sensor data aggregation" board unpredictable.
Writing Python scripts running on a MCU platform, with limited speed, limited memory capacity, not full access to (all) Python libs (e.g. matplotlib) - does not make any sense to me.
Extend a PC platform with full access to all SW features with MCU based sensor boards - sending their sensor data via standardized interfaces (such as ETH IP/TCP/UPD).
And all the rest on host PC (real Python is much better as "MicroPython").
Why do you use "MicroPython" when it does not do what it "should do:?
Send your MCU (sensor) data to a host PC running a "real Python".
Any MCU is not a host PC substitution: it should augment, extend, help, but not "promise" to do the same (like running "any" Python) as you could do on a host PC.
LOL
I do not like this "MicroPython" approach. For what?
I like more the Matlab approach: connect an MCU to a host PC running Matlab: Matlab can see and talk to MCU, use as HW aggregation (sensor data).
Matlab is so "cool": when I connect my Portenta H7 - it sees it, even I do not have any FW running related to Matlab.
But it tells me:
Matlab is able to see my external "HW extension", use it and Matlab can also generate code for this MCU. It makes much more sense to "split" the tasks between host PC (Matlab) and MCU (real-time, sensor data) and to combine both into a system.
But what should an MCU running "MicroPython" do in such a system, e.g. when host PC can run
"real" Python?
A "strange" (system) approach for me.