Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How long a simple blynk.run() from examples complete? #32

Closed
kindmartin opened this issue May 3, 2020 · 7 comments
Closed

How long a simple blynk.run() from examples complete? #32

kindmartin opened this issue May 3, 2020 · 7 comments

Comments

@kindmartin
Copy link

Hi all there in this uPy community. I was debugging tons of code ending to test a simple example like terminal at ESP32, https://github.com/blynkkk/lib-python/blob/master/examples/esp32/02_terminal_cli.py.

I just uploaded that script only editing to have an idea of how long run() takes to other things in main loop. Im running at ESP32 standard 2020 FW version.

while True:
LoopStarts = time.time()
blynk.run()
LoopEnds = time.time()
delta = LoopEnds - LoopStarts
print('---->> Delta RunLoop :', delta)

here my results, with fast (0) / slow (~60+ secs) cicles.

All registered pins like this example v2 works in real time, but Im wondering what I m not doing well as we need more than run() timeslots !

Hints ?

  / _  / / // / _ \/  '_/
 /____/_/\_, /_//_/_/\_\
        /___/ for Python v0.2.6

                 Blynk updated

---------->> Delta RunLoop : 0
---------->> Delta RunLoop : 14
---------->> Delta RunLoop : 64
---------->> Delta RunLoop : 0
---------->> Delta RunLoop : 65
---------->> Delta RunLoop : 0
---------->> Delta RunLoop : 63
---------->> Delta RunLoop : 0
---------->> Delta RunLoop : 65
---------->> Delta RunLoop : 0
---------->> Delta RunLoop : 63
---------->> Delta RunLoop : 0
---------->> Delta RunLoop : 65

@kindmartin
Copy link
Author

Adding related to this issue is that using BlynkLib from other source and almost same terminal or any other example like the ones at https://github.com/vshymanskyy/blynk-library-python blynk.run() is as fast is it has only takes 0.1 secs each round.
code between v0.2.6 and this other v0.2.1 (esp32) is not fully compatible and also isa oldes version seems with not new realeases. so I hope Im wrong with something or v0.2.7 provides better performance.

@antohaUa
Copy link
Collaborator

antohaUa commented May 3, 2020

Hi kindmartin!
I am not sure that fully understand what kind of issues do you have:
Scripts allows you to have aka CLI session with ESP32 - do you see timing gaps in communication?
Or you just frustrated with such strange loop values = 60 seconds?

For ESP32 due to memory limitations I suggest check such things:

  • script uploaded without doc headers ( everything until line 36 should be deleted )
  • esp32/esp8266 allows to have compiled and optimized libraries in RAM
    please read "Micropython libraries compiltation" section from this doc
    https://github.com/blynkkk/lib-python/tree/master/examples/esp32
  • after all optimized libs and scripts were loaded better to check available sys RAM
>>> import gc
>>> gc.collect()
>>> gc.mem_free()

Let's check these thing first and then continue investigation.

@kindmartin
Copy link
Author

kindmartin commented May 3, 2020

Thanks antoUa for replying. to explain my self better I just was saying that using this v0.2.6 library even using examples the time consumptions for blynk.run() loops is about one minute. I tried all, using a mpy byte code lib, extract all comments, etc, overclocking the ESP32, etc. ALL.
At the end this quarantine morning I moved back to the other library v0.2.1 from @vshymanskyy and all works perfectly, each loops only consumes 0.1 seconds, including timer.run from BlynkTimer lib. Also, I have a core running a ftp thread in one core and all this other script main.py loop working in background in other thread. now I have access via webrepl, ftp, serail repl working all very responsive (not blocked) plus my script.
I will retry next realease/ thanks/

<M

@antohaUa
Copy link
Collaborator

antohaUa commented May 4, 2020

Kindmartin,
I have double checked behaviour described by you and seems we have only strange time numbers that does not reflect real time. For example I have used not time.time() but time.ticks_us call that shows time in microseconds and have such results:

---->> Delta RunLoop : 5119324
---->> Delta RunLoop : 3070375
---->> Delta RunLoop : 4096995
---->> Delta RunLoop : 5119370
---->> Delta RunLoop : 3071083
---->> Delta RunLoop : 1022475
---->> Delta RunLoop : 1024228
---->> Delta RunLoop : 2047899

But if to measure real time of command response with timer clock it will be less that 1 sec
You can ensure with this just frequently typing 'ls' command in terminal widget - all responses will be within 1sec ( max 2 sec).

Anyway i will try to investigate such strange situation with time displaying.
BTW what time import you have used for script under https://github.com/vshymanskyy/blynk-library-python ?
Can you share the whole test script with me? It may be helpful in scripts compare and further investigations.

@kindmartin
Copy link
Author

I use same time import with the other lib, and blynk.run() just consume ~100ms, including timer.run()

I have two codes. I m learning python so it is not any clean or optimized, full of global variables usages, etc so for that reason I was back to basic examples check.

now im focus the other lib, that have other problem with text input widget updates messages from server to device. but I will like to help/

one coment, if I just use instead time.time() prints just prints like print('PRINTING NOW') I see those prints in the REPL console each minute, so no doubt blynk.run() do not pass fast to next command.
here the almost working code.

main.py.gz

@antohaUa
Copy link
Collaborator

antohaUa commented May 4, 2020

I see the diff in imports import time ( your main.py) vs import utime as time ( terminal example)
If you will have time please double check what will be if for your micropython port you will use
example without utime - just import time call. I think this can be really port specific cause not all micropython systems can support such Cpython imports.

@antohaUa
Copy link
Collaborator

Closed (no reply for a long time). But feel free to re-open

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants