New v1.20.0 Release candidate v1.20.0.rc7

[combaindeft]

@iwahdan said in New v1.20.0 Release candidate v1.20.0.rc7:

New API in modusocket to get/set DNS servers

usocket.dnsserver(0,'8.8.8.8')
usocket.dnsserver(1,'4.4.4.4')
usocket.dnsserver()
('8.8.8.8', '4.4.4.4')

[catalin]

Hi everyone,

Just added documentation for Pymesh: https://docs.pycom.io/firmwareapi/pycom/network/lora/pymesh.html
FYI, we'll add/update example scripts soon, for now, the previous example won't work We've updated example here: https://docs.pycom.io/tutorials/lora/lora-mesh.html
<Later edit>: moved docs into official docs.pycom.io

[tlanier]

When I try to upgrade a GPy to the latest development release of firmware I get the error "Firmware file has unexpected sha1 checksum".

Does the "Pycom Firmware Update" program automatically download the latest firmware or am I suppose to download the firmware separately? The program does not display a version when run; however, it was installed from "pycom_firmware_update_1.15.1.exe". Does the "sha1 checksum" error imply that the file is corrupt on your server?

[Paul Thornton]

@tlanier Please try using the Beta firmware updater to install the latest RC, Located here: https://forum.pycom.io/topic/3425/new-beta-firmware-updater-1-15-2-b0/1

Will solve the Sha1 hash issue.

[tlanier]

@paul-thornton
That fix it.

Thanks!

[Paul Thornton]

@tlanier Glad to help

[thinginnovations]

@catalin There seems to be differences in the documentation and what is actually implemented in the loramesh.py code, for example https://development.pycom.io/v/development_release/firmware-and-api-reference/pycom/network/lora/pymesh makes reference to the border_router function. This is not present.

Do you have a roadmap for when the rest of the loramesh implementation is to be completed and available?

Thanks

Andrew

[catalin]

hi @thinginnovations, in the development release the method network.LoRa.Mesh.border_router is here, in the code: https://github.com/pycom/pycom-micropython-sigfox/blob/b6dd78344c272002db70c2909a7cd72cff69c5e0/esp32/mods/modmesh.c#L1081

As for roadmap, I am waiting for suggestions :) Of course, meanwhile, working on stability, quicker joining Pymesh, power management...

Meanwhile, by the end of the week I am targeting:

1. example with Border Router (maybe add list and remove method)
2. multi-socket and bind on a specific ipv6 (not for :: as today) for socket

[thinginnovations]

@catalin Thanks , I'll lookout for code updates.

Cheers

Andrew

[tlanier]

At least a 750 msec delay is needed after lte.init(). Would it not make better sense for the init() method to do the delay internally?

Example:

lte = LTE()
lte.init()
sleep_ms(1500)
r = lte.iccid()    # delays less than about 750 msec will return None

[Eric Waai]

@tlanier
If clearly stated i have no problem with adding a manual delay.
there are plenty of case where this time can be used to initialize other stuf. if that already takes 750 ms. there are a 750 ms wasted.

[crumble]

@eric-waai said in New v1.20.0 Release candidate v1.20.0.rc7:

@tlanier
If clearly stated i have no problem with adding a manual delay.
there are plenty of case where this time can be used to initialize other stuf. if that already takes 750 ms. there are a 750 ms wasted.

There is another way to program this. Start each init in an own thread and wait until each one died.

Yes, it shall be optional, 'cause ensure order of execution will not be easy ans overhead maybe too slow. But there are at least two ways to deal with this problem.

If we have to implement the wait time, the min time shall be in the documentation and not in the forum ;)

[tlanier]

Is there any way in Pycom's MicroPython to get some sort of low latency periodic interrupt service routine that can do an I2C transfer?

What I have found is if I use the Timer.Alarm (set to 200 msec periodic interrupt), I get wide variations in the execution of the scheduled callback handler. Some of the code that causes large latency issues include: (1) calling the modem reset method which kills servicing the interrupt routine for seconds, (2) calling the modem initialization method, (3) calling modem AT commands for instance to read signal strength and SMS messages, and (4) calling flash disk i/o methods such as open, read, write, and close.

The idea to schedule the callback on a new thread which can run any Python code without restriction is nice, but it seems that the long latency issues make that technique prohibitive in some cases. Some of the Python commands block the interrupt handlers from being able to run for long periods. For instance in my case I need to sample an analog signal periodically at a rate of 200 msec. I can't afford to have the sample be 200 msec plus or minus 50-5000 msecs. I could live with plus or minus maybe 20-30 msecs.

Would it be possible to have two types of timers? Type #1 timers would schedule the handler to run in the future as it does now. Type #2 timers would allow executing restricted code immediately at the time of the interrupt.

Here's documentation from the MicroPython site:

Writing Interrupt Handlers

Any ideas on how this problem can be accomplished with Pycom's implementation of MicroPython without adding another micro-controller to the design just to do the analog sampling?

[protean]

@tlanier said in New v1.20.0 Release candidate v1.20.0.rc7:

lte = LTE()
lte.init()

Why init twice?

Either way, there is a method in the C source for the LTE code called: lte_check_init(). Seems like it would be trivial to expose that to the public class and then you can call it lte.is_init() and use it just like is_connected or is_attached

[tlanier]

@protean
In my production code the object instantiation lte = LTE() line is executed once at startup. The following code is executed whenever an error occurs that may require reinitializing the modem.

lte.reset()
LTE.reconnect_uart()
lte.init()
sleep_ms(1500)

That's what I have found to work with experimentation.

The problem I have discovered are many of the python commands are blocking other tasks from running for relatively long periods of time. For instance the lte.reset() command seems to block tasks for up to 5 secs. Unless Pycom provides some way to execute code when a timer interrupt occurs, I believe that all python commands should be rewritten to have some maximum time of execution (maybe 1-2 msecs) before they return to allow multitasking to run smoothly. For instance instead of lte.reset(), we would need lte.reset_start() and lte.reset_iscompleted() commands.

I would love for someone with more knowledge of this subject to jump in and explain how Pycom expects programmers to do any type of real-time code in the existing environment. Is work being done to solve this problem? Is there something I am missing which currently solves the problem?

One possibility is to rebuild the software from source as described on Github and to add new python commands to implement a true interrupt service routine using the Espressif ESP32 IDF to do the work required. A second possibility is to add another micro-controller to the design to do the real-time work. Neither option is appealing.

[tlanier]

Bug Report

machine.reset() does not zero the utime.ticks_ms() counter.

An actual button press reset does.

[3sotweb]

This post is deleted!

[robert-hh]

@tlanier said in New v1.20.0 Release candidate v1.20.0.rc7:

machine.reset() does not zero the utime.ticks_ms() counter.

That does not really matter, since utime.ticks_ms(), utime.tick_us() and utime.ticks_cpu() are not intended as absolute time stamps, but only intended as to be used for time differences in combination with utime.ticks_diff(). These counters overflow anyhow after a while.

[tlanier]

@robert-hh
My bigger concern was that the machine.reset() is not equivalent to pressing the reset button as the manual suggest. There are definite differences. One difference is the utime.ticks_ms() is not zero'ed. Another difference I discovered by accident. In our design we were having trouble with an occasional I2C bus error which was later resolved by adjusting the pull-up resistor values on the I2C bus. What was more concerning is that after the I2C bus error occurred, there seemed to be nothing I could do in software, including doing a machine.reset(), that would resolve the problem. Only a press of the reset button would allow the I2C bus to function normally again.

The question now is what else is different between a machine.reset() and a reset button press? Is there reason to believe that we should have an external watchdog that pulses the reset line of the processor to be assured that everything is properly reset after a problem occurs?

Incidentally, there are valid reasons to want the ticks_ms timer to be zero'ed after reset. If you know the program will be restarted before the timer overflows and if the timer is zero'ed after reset as you would expect, a simple subtraction would work for measuring time differences.

[robert-hh]

@tlanier I agree that machine.reset() is different from pushing the reset button, and pushing the reset button is different to a power cycle. There are obviously states which are not reset by the code running after machine.reset(). I do not know whether this can be fixed. In any case I would use an external watchdog if long term unsupported operation is needed. There are error states where the internal watchdog also fails.