Hi Rui,
As you wrote on page 11 (MicroPython_Programming with ESP32….) “Your feedback is very important so that we can improve….” here some points/questions:
1st question:
It’s not quite clear from the course material how I have to see using filenames for my code. Your explanation suggests only ‘boot.py’ and ‘main.py’.
But it can not be true that I have to use for all my different programs only these 2 names, I thought. As to prevent overwriting former files (or I should maintain a complex administration with subdirs for every boot.py/main.py couple).
So I named my exercising programs with the names of the GITHUB-filenames as you gave them. And this works! (realize that the boot.py is at start of this book and chapters actually an empty file).
With MODULE 4, the webserver, my approach was not good anymore. I had to fill the boot.py and the main.py. Otherwise the main.py was not executed.
But what if I want to maintain and save different version of webserver-programs?!
I cannot believe that we are urged to call them every time boot.py and main.py and to overwrite content of previous programs. Very user unfriendly.
What’s the idea behind file/codenaming in MicroPython?
2nd question:
import:
In the code for your deep_sleep-example (p. 135 and on) I see this:
import machine from machine import Pin from time import sleep
I thought you explained somewhere that “from”-clause is used to limit importing to just the needed routines form a library. As to save on memory use.
“import machine” is importing the whole library, isn’t it? So also the object Pin? ( I thought).
BUT I cannot leave out this second line “from machine import Pin” as I won’t work.
Please some explanation about the “why”. It looks so not logical. Certainly where Python is so elegant and simple.
3th question:
In your C++ course for ESP using a button makes it necessary to circumvent this with debouncing-code.
Not in MicroPython (but it works good). Is this debouncing implemented in the object in the library for buttons. So we can count on stable situations?
If so, this makes write code much more pleasant.
Thanx,
Jop
Hi Rui,
In follow-up of my 1st question above I’ve noticed now that you can mark a filename in Device-section (left at top) as Default Run. Its name will (sometimes?!) be colored red. It seems that this is the program that will be executed, also when pressing EN-button on board.
But the interface is not very transparent. Sometimes you really don’t know what you are doing. Can this be the reason that users complain about uPyCraft is not functioning?
The interaction between the buttons at the right side (iMac version – it seems to be at top for Windows-version) and the files at left and in the Edit-window is not very transparent.
The online Help-tutorial is also very limited in its explanations. This guys that developed uPyCraft should hire you to write a proper manual – better, to design an understandable interface. Creating good and transparent interfaces is one of the most difficult tasks in IT.
Maybe you should pay some attention to this all in your course “MicroPython_Programming with ESP32….”.
Kind regards,
Jop
Hi Jop.
You are right. I agree with you that the interface is not very user friendly. When we started programming with MicroPython. uPyCraft IDE was the most user-friendly IDE we found. Later on, we found Thonny IDE, which I think is more user-friendly and easier to upload files and to connect to your board.
Have you tried it yet? If not, you should, and then see which IDE you like the most.
You need to save your files as boot.py and main.py on your board, otherwise the files won’t run. But, if you use Thonny IDE, you can give your files whatever name you want. Then, there is an option to upload your file as main.py or boot.py. So, it is easier to organize your files.
2nd question:
when you use:
from machine import Pin
You declare a Pin object as follows:
led = Pin(2, Pin.OUT)
if you import the whole machine module, you need to specify from which module the Pin object is from:
led = machine.Pin(2, OUT)
Thanks for pointing that out, because in the deep sleep mode, we can simply import deepsleep() from the machine module:
from machine import Pin, deepsleep
Later, in the code you can use:
deepsleep(10000)
instead of
machine.deepsleep(10000)
I’ll fix that in the code, in the next update.
3rd question
That’s a great question.
I also noticed that you don’t need a debounce code. But I’m not sure what’s the reason. (that’s probably the Pin object that handles all of that)
Thank you for your feedback.
Regards,
Sara