New firmware release, version 1.6.0.b1

livius

unable to run the onewire / ds1820b code any longer

you point me in direction to dig first why my working code in 1.5.0 not work in current firmware
i suppose that OSError: [Errno 104] ECONNRESET is because i got None from onewire instead of value - but i can check this in the evening

livius

I still have objection to pycom did not you inform on your website which is already implemented and what still needs to be improved before buying.
As I have once wrote - people will buy your product but do not expect that everything is fine and dandy and beautifully.
as you can see that another criticise post from new user @crankshaft.

Informing that the device consumes this much power in a deep sleep, or so and so enabled wifi it seems to me also pure guesswork until deep sleep mode will not be available. You can indicate that the promises esp so be it.

Additional - issue tracker - github is not very good for that - could you use something like jira -
e.g. Firebird use free version of it
http://tracker.firebirdsql.org/secure/Dashboard.jspa

but summarize this
i believe in pycom team i see many, many progress but without first point you loose more and more.

Pete

@crankshaft said in New firmware release, version 1.6.0.b1:

My patience is now wearing very thin and I am now forced to consider switching to another platform, because as far as I can tell, the issues preventing me from using these devices in a real live environment are still many, many months away.

I know what you mean. I bought WiPys because I need to quickly simulate a large piece of equipment we won't have our hands on for a couple of months. I had been waiting for some specs from its supplier before I got stuck into implementation (just received them this morning), but the few things I tried already and many of the posts I'm reading have me worried that the WiPy won't be stable during our tests in the field, when we'll be relying on it working all day while we debug our actual product and can't easily do resets and suchlike on the WiPy.

If it had been advertised as an alpha/beta product I'd have approached it differently, keeping an eye on it as an interesting future possibility but not building our test plan on it.

Fortunately I'm sufficiently cynical as to have also ordered a different brand of WiFi IoT module as a backup. This one runs a full Linux which is more complexity than I really wanted (serial -> Python -> UDP-over-Wifi and nothing more, as promised by the WiPy, was ideal) but at this point I'm rather glad I have them on the shelf as well.

I'm going to stick with WiPy for now in case our simple use-case happens to dodge round all the bugs, but posts like Livius's on this thread saying that WiFi station mode (which is what we need to use) is not stable, are not encouraging.

Pete

daniel

Hello,

Apologies for the bugs introduced on the latest release. There were 2:

pin.value() was not working correctly for OPEN_DRAIN pins, and this broke the one-wire library.
Bluetooth callbacks were not being called for characteristic read/write events.

Both are fixed now. We just published firmware 1.6.1.b1 with the following changes:

esp32/mods/modbt.c: Protect against writing chars value over 20 bytes long.
esp32/util: Increase callbacks stack size to 5K.
tools: Make the certification script compatible with US915 too.
esp32/mods/modbt.c: Mark the is_char field as true on characteristics.
This ensures that the read and write callbacks are actually called.
esp32/mods: Fix bug introduced when reading the value of an output pin.

Simply run the updater tool again and the new firmware will be flashed on your boards.

Cheers,
Daniel

livius

@daniel
i can confirm that problem was not with wifi
only pin.value() mentioned by you

i also fix my software to prevent such situation like None returned instead of value (maybe never happen again but...)
None value was send by wipy by wifi and i automatically drop connection on server side because of wrong packets sended and i then i see OSError: [Errno 104] ECONNRESET which was ok

now after your fixes may software work back ok
@Pete you can test now - it looks promising :)

after few minutes of testing i see only one thing not work
but all others are fixed - i see if it will be working tomorrow through night :)

@daniel can you test my sample from post below with getNTPTime
it still doesn't work

Neo

I am working with my colleagues on these products since 2 month almost... and I reinforce what @cranshaft is saying above.

Definitely, the products are not ready for real deployments... and we tried to slope between issues getting FRUSTRATION TO MAXIMUM.

The fact that from release to release, the basic issues are not resolved ... and more regressions are coming... going to an worse situation. I don't know what to say, might be pressure on workload/qualified manpower ... or we are dealing with a bad product development management that is focusing on new features

Here is a brief:

1.6.1b1 release, if yourscript is big (eats memory) the system is hanging on gc.collect()/gc.mem_free() .. huh this is CRITICAL
There is no way to compile modules as frozen byte - and this is solving the memory limitation
Release 1.30 - the OneWire code that was functional ... from 1.5.x is not working anymore.
I2C with some devices (like BMP180 or ADC1115) is not working. Please note that SAME devices are working with Arduino/PI/OrangePI/MCU
DHT22 can not be implemented due to sleep ms issue. You need to go at C level to make it work... not a chance on mpython.

... and more others that we got if you expose the product on low temp, or run it over days etc.

Guys, my advice is to take a breath from this race and focus on basic stuff .. then go and develop other new features. Take it slow and focus on QUALITY.... doing a lot of stress tests.

A bad reputation or negative web article, will not push you between champions. Doesn't matter if you have SiPy, LoPy or whatever Py ... if the reputation of the products are bad.

livius

@Neo
I do not want to defend PYCOM but you mentioned inoperative few things
which work for me in current firmware (1.6.1):

Onewire work for me - i read 3 x ds18b20 at the same time
BM180 work also for me (but i have some problems previously and do not test if i still must read first something from i2c e.g. light sensor)
I have many others sensors working but
I forgot about this sensor(DHT11) - because it was so inaccurate - but yes there are problems with timing - you remind me about it - I have to go back to it ;-) and when succed i will try dht22
I fight with color tft (some progress but..) but i wait until pycom merge github with official micropython

daniel

@Neo, thanks for your feedback. Let's go one by one:

Can you share a minimal example that reproduces this issue? Or is it only with big scripts?
Adding this option to MicroPython is easy. Then we have to write a guideline on how to do it for the ESP32 port. We have been working on this but is not finished yet.
One-wire is working on the latest release as @livius just confirmed. Are you sure it still doesn't work for you with 1.6.1.b1?
Are these devices I2C devices (BMP180 or ADC1115) requiring a really fast clock? Exactly what happens on the I2C bus? Are you getting exceptions somewhere?
If sleep_ms is not accurate enough, could it be done with sleep_us. If you really need this in C, share with us a C driver, and we can make it part of the C firmware and expose a Python API. Would that work?

Cheers,
Daniel

daniel

@livius I have reproduced your issue with NTP and I have fixed it just now. The problem was caused by the wlan.ifconfig() line. It turns out that Espressif fixed the issue with setting the DNS server that we have been working around for months. This is good but it made our work around break internet connectivity. I have tested the patch in 2 different ways:

Setting the static IP after connecting to the AP:

if not wlan.isconnected():
    wlan.connect('my-ap', auth=(None, '123456abc'), timeout=5000)
    while not wlan.isconnected():
        machine.idle() 
    print('WLAN connection to the router succeeded!')
    wlan.ifconfig(config=('172.20.10.8', '255.255.255.240', '172.20.10.1', '8.8.8.8'))

and Setting the static IP before connecting to the AP:

if not wlan.isconnected():
    wlan.ifconfig(config=('172.20.10.8', '255.255.255.240', '172.20.10.1', '8.8.8.8'))
    wlan.connect('my-ap', auth=(None, '123456abc'), timeout=5000)
    while not wlan.isconnected():
        machine.idle()
    print('WLAN connection to the router succeeded!')

In both cases setting the static IP works and there's internet connectivity. We'll release this along with other fixes tomorrow.

Cheers,
Daniel

crankshaft

@daniel - I have just upgraded again and onewire is now working, but I am still getting the same wlan error mesaages:

W (240989) wifi: post pm rx bcn failed
W (240990) wifi: post pm rx bcn failed

Questions:

How can I disable these debug messages as they fill up my screen so quickly and I am unable to read my own debug data as it gets pushed off the top of the screen by all of the wlan 'bcn failed' messages
[ Add parameter to enable/disable WLAN power save mode ] - How can I disable / enable wlan power saving, what is the parameter ??

Thanks

robert-hh

About frozen bytecode: I managed to enable it with the following steps, copied from the eps8266 build:

In mpconfigport.h of the ESP32 directory, goto the line

#define MICROPY_MODULE_FROZEN (0)

and change it to the four lines:

#define MICROPY_PERSISTENT_CODE_LOAD (1)
#define MICROPY_MODULE_FROZEN (1)
#define MICROPY_MODULE_FROZEN_MPY (1)
#define MICROPY_QSTR_EXTRA_POOL mp_qstr_frozen_const_pool

Then, put your python code like before into the directory modules and run:
make FROZEN_MPY_DIR=modules BOARD=LOPY
The first line added allows you to run crosscompiled code from the file system (.mpy files), which are generated by mpy-cross.
You have to build mpy-cross before in the mpy-cross directory.

That worked for my sample files, totalling to 750 loc, but @shaun had problems to replictate these steps. Maybe his code was too large and he would have had to adapt the linker map.

daniel

@crankshaft Power save is disabled by default now, and it's controlled by an extra parameter in the init/constructor:

https://docs.pycom.io/pycom_esp32/library/network.WLAN.html#network.wlan.init

How can I disable these debug messages as they fill up my screen so quickly and I am unable to read my own debug data as it gets pushed off the top of the screen by all of the wlan 'bcn failed' messages

This needs to be disabled internally in the IDF. Before there was not a way to do it, but now it's possible. We'll try to do it today.

Cheers,
Daniel

livius

@daniel said in New firmware release, version 1.6.0.b1:

This needs to be disabled internally in the IDF. Before there was not a way to do it, but now it's possible. We'll try to do it today.

Will be good to have possibiliti to turn it on
e.g. if we encounter some problem with wifi it can be usefull to look at it
and e.g. send it to you

jmarcelino

I suspect what's being discussed is setting the CONSOLE_UART=None which is a compile time-only option so I agree with @livius until the system stabilises (especially IDF) the messages are very important for our own debugging and should stay.

I guess you can send your own debug messages to the second UART perhaps?

Neo

@livius Looking to your posts, somehow you are a defender, or probably working/part of pycom team... but this actually doesn't matter.

Here I am proudly part of a team of people, experts in micro&electronics, C/C++ RTOS and other related stuff, implementing dozens of IOT systems, running real product deployments.

The onewire that we are using is from micropython git repo, module written and tested by many people. Can you point me the onewire DS1B20 that you are using?
That module was working with 1.3.0 LopY... now is not working anymore (LoPy ). That's the point: if your work is going to be continuously impacted by regression means, frustration, waste of time and finally money.
Have you checked your sketch with only one DS1B20 sensor running on LoPy 1.6.x (p23) ? If not ... please do it and then post your results. Have you put BMP180 and read simply the SN ... with LopY/Wipy this is raising I2C errors. With Arduino/PI this is working.

Have you performed stress tests on your pyboard? Running complex scripts for hours in lab and outside at bad conditions (eq temperature), in transmission mode (frequently Wifi up then down, Lora up then down) loading modules progressively, gc collect, running with free memory around 8-10k ?

That is a big difference between real IOT stuff and running a sketch with 1-2 sensors on it... where probably Wifi is always ON and the board is running on wall power and not battery/solar.

Colateral

@robert-hh Thanks. We will try it.

Colateral

@Neo I understand your frustration, but let's keep our faith that pycom product development manager is proactive on the enumerated issues.

livius

@Neo

Looking to your posts, somehow you are a defender, or probably working/part of pycom team... but this actually doesn't matter.

no i am not from pycom team if you look at history you can find much more criticize post by me ;-)
https://forum.pycom.io/post/2245
but i try to change attitude ;-)
Because much more working now then previously was even possible...
UPDATE
I change also attitude because @daniel describe how situation looks like - that they are affected by ESP-IDF development

about onewire i use this:
https://github.com/pycom/pycom-libraries/tree/master/examples/onewire
and it work for me on version 1.5.0 and it write data to direcly connected sdcard (without expansion board) many days
it is stable. On version 1.6.0.b1 it was broken but day after @daniel fix it and release 1.6.1
which work continously for me since yesterday and write data throught wifi to my server throught tcp/ip socket

I can not test on Lopy because i have only 2x Wipy2.0
First is with 1.5.0 firmware second with 1.6.1

Have you performed stress tests on your pyboard? Running complex scripts for hours in lab and outside at bad conditions (eq temperature), in transmission mode (frequently Wifi up then down, Lora up then down) loading modules progressively, gc collect, running with free memory around 8-10k ?

now memory is to limited to me to write main concept.
and until more memory will be avaiable i only play with sensers
Current working scenario is lilke this
first Wipy retrive data from sensors store it to sdcard and connect to second Wipy (master) and send data packet
Second Wipy have same sensors and store data but is as master and get data from first.
After whole packet retrive it change from AP to STA mode and connect to server and send whole data.
After sended all data it go back to AP.
And this work for me.
I try playing with STA+AP mode but without success
but not played much ..

Neo

@daniel Hello.

Yes. The code was taken from micropython. You can download from here: https://drive.google.com/open?id=0B2FyGVkp3y9ZZ2plTHNFUFF2WW8
This we tried.We compiled mpy-cross and generated binary... but that is not working.
Yes. 1.6.1b1 LoPy.
Most probably requires fast clock... same fast clock issue we believe is also with DHT22 (not I2C). On the terminal we "I2C bus error" message comming from pycom framework.
I need to check this with our management.

livius

@Neo
"I2C bus error"

@livius BM180 work also for me (but i have some problems previously and do not test if i still must read first something from i2c e.g. light sensor)

I suppose than that problem presists
i fix this by first read light sensor (it fix something for me) i do not dig enaught because @daniel say that I2C is still software not hardware.

@daniel is this still true I2C still software?

Explore Pybytes | Official Documentation | Report a Firmware Bug/Issue | GitHub

New firmware release, version 1.6.0.b1

Pycom on Twitter