Raspberry Pi Pico W I2C/Piicodev Bug [Solved]

Hi Bob,
That is the same device I have been playing with. Assume you are using Arduino and C++.
To show numbers (ie integers) you would convert them to a string first. Depending on the library it may need to be sent one character at a time.

Haven’t looked at the Arduino libraries, but if you want me to investigate happy to do that, should be fun.

Cheers
Jim

2 Likes

Hi James

Tried that. The device simply seems reluctant to produce anything that is not in Quotes(“”). It does however produce rubbish almost as if it is using the wrong ASCII table.(that bit of info is from memory as it was a fair while ago)

If I get a chance I will try the experiment with the other library which I use for that I2C backpack device and post results here hopefully before this thread gets too old.
Cheers Bob
Just looked it up, that library which works with the backpack device is
<LiquidCrystal_PCF8574.h>

2 Likes

Hi Bob,

Looking at the datasheets for the PCF8574 backpack and the AiP31068 (chip used in the RGB LCD) the library’s would not be compatible. The programming for each is very different.

The PCF8574 is a much simpler device converting I2C data stream into parallel port data.

The AiP31068 has character generator memory and display memory which are set up to show the characters you want to display. It is quite a powerful device. The Waveshare driver does not use it to its full potential.

The character generator allows for different language characters to be setup and displayed such as Chinese or Japanese. There are 3 versions with different character sets built in. I believe it would be possible to setup your own character set if you wanted.

The Waveshare drivers do not have checking for valid characters, whatever is sent is displayed. It would explain why you get a random display with weird characters. The device tries to match the data in display memory with a character in the character generator memory. Unsure what out of range characters would display.

Anyway, I am going to create a post related to the RGB LCD with the changes I made to the Waveshare driver and an explanation. I will also use that post to look at the Arduino driver and how to use it. In a way it is a little better than the Micropython driver, C++ allows lower level control of the micro.

cheers
Jim

3 Likes

Hi James
Thanks for that. Saves me the trouble in finding out it does not work.
I will keep watch for your analysis and fixes.
Does not alter my opinion about a product that was purchased and using the Waveshare library for Arduino would not get far past the “Waveshare Hello World” demo. Strings Yes. Numbers no. Numbers converted to strings no. Disappointing.
Will look forward to your post.
Thanks again. Cheers Bob

3 Likes

Latest fw still doesn’t support BME280 -

from machine import Pin
from PiicoDev_BME280 import PiicoDev_BME280

sensor = PiicoDev_BME280(sda=Pin(8), scl=Pin(9))

tempC, presPa, humRH = sensor.values() # read all data from the sensor
pres_hPa = presPa / 100 # convert air pressurr Pascals -> hPa (or mbar, if you prefer)
tp = "{:4.1f}".format(tempC)
pr = "{:3.0f}".format(pres_hPa)
hu = " {:4.1f}".format(humRH)

print( '\n' + \
    tp + "    " + \
    pr + "    " + \
    hu + "\n"\
)

%Run -c $EDITOR_CONTENT
PiicoDev could not communicate with module at address 0x77, check wiring
Traceback (most recent call last):
File “”, line 4, in
File “PiicoDev_BME280.py”, line 32, in init
File “PiicoDev_BME280.py”, line 29, in init
File “PiicoDev_BME280.py”, line 64, in _read16
OSError: [Errno 5] EIO

@Peter212355 I am unable to duplicate the error you are experiencing.

Pico W loaded rp2-pico-w-20221014-unstable-v1.19.1-544-g89b320737.uf2

Copied to Pico W from Core Electronics GitHub using Thonny the following files.

PiicoDev_Unified.py 
PiicoDev_BME280.py 
main.py

Ran ok as per web page screen shot.

Copied your code to Pico W, produced temp pressure and humidity values.

I think Core have updated the Piicodev files based on the post from @Michael.

Regards
Jim

2 Likes

That’s correct - ensure you are using the latest PiicoDev_Unified.py (right-click, save-as)
I released a PicoW-fixing update recently.

4 Likes

The problem is that I have a D1306 OLED display in the chain. When I remove that it works,
with it in the chain if fails with those errors.

1 Like

Hang on! I retested to see if the order of the devices mattered. So far it worked in the reverse order,
then worked in the original order but with these messages from time to time (multiple ^C’s will stop the run eventually, but the “Thonny” stop button has no effect) -

21.92 °C  988.4939 hPa  63.48242 %RH
21.91 °C  988.4752 hPa  63.48242 %RH
21.91 °C  988.4697 hPa  63.49219 %RH

Device is busy or does not respond. Your options:

  - wait until it completes current work;
  - use Ctrl+C to interrupt current work;
  - reset the device and try again;
  - check connection properties;
  - make sure the device has suitable MicroPython / CircuitPython / firmware;
  - make sure the device is not in bootloader mode.

21.91 °C  988.4593 hPa  63.51465 %RH
21.91 °C  988.4626 hPa  63.51465 %RH
21.91 °C  988.497 hPa  63.50293 %RH
1 Like

Hi Peter,

If you add a sleep function to your loop you ought to find some more success (try a 0.5 second delay) the SSD1306 commands send a few packets back to back vs few for the BME280, plus any temperature pressure or humidity data shouldn’t change too much over 5 seconds let alone a few minutes in a large room

2 Likes

Experienced this too. If the RP2040 is in a tight loop it will miss the messages from Thonny.
Also happen when using asyncio tasks, if the main running code does not have a small delay the asyncio task will not get processor time. Delays can be a little as 100ms.

The Micropython software is NOT an operating system. In devices like the Pi Zero and Pi 4B the OS schedules time for each task so this sort of thing does not happen. The Pico, Micropython and Thonny are still amazing creations and so easy to use.

Cheers
Jim

1 Like

I did not state that in an attempt to go back to the simplest situation, I had reverted to the original sample code “main.py” provided by Core Electronics (my apologies). It has a 100ms delay on each cycle of the loop.

This morning, with Thonny running, I plugged in the USB cable and the code started running by itself.
It did respond to the “Stop” button, however on subsequent starts under the control of Thonny, the error messages started appearing again, and the Thonny stop button had no effect. Control-C did stop the run though.

Peter.

I’ve tried specifying the “freq”, 400000 then 100000. I Couldn’t say that it had significant effect.

However, I can say that the reproducible behaviour is that on the 1st hit on the Thonny “stop” I get -

PiicoDev could not communicate with module at address 0x77, check wiring
nan °C nan hPa nan %RH
PiicoDev could not communicate with module at address 0x77, check wiring
nan °C nan hPa nan %RH
PiicoDev could not communicate with module at address 0x77, check wiring
nan °C nan hPa nan %RH
19.87 °C 986.0364 hPa 76.1084 %RH
19.86 °C 986.044 hPa 76.08691 %RH
19.86 °C 986.0402 hPa 76.1084 %RH
19.86 °C 986.0559 hPa 76.09668 %RH
19.86 °C 986.0553 hPa 76.09668 %RH
19.85 °C 986.0139 hPa 76.0752 %RH
19.86 °C 986.0505 hPa 76.08594 %RH
19.86 °C 986.0406 hPa 76.08594 %RH
19.86 °C 986.0357 hPa 76.08594 %RH
19.86 °C 986.0341 hPa 76.08594 %RH
19.86 °C 986.0586 hPa 76.08594 %RH

Device is busy or does not respond. Your options:

  • wait until it completes current work;
  • use Ctrl+C to interrupt current work;
  • reset the device and try again;
  • check connection properties;
  • make sure the device has suitable MicroPython / CircuitPython / firmware;
  • make sure the device is not in bootloader mode.

19.86 °C 986.0323 hPa 76.06348 %RH
19.86 °C 986.0193 hPa 76.09668 %RH
19.86 °C 986.0128 hPa 76.08594 %RH

Subsequent "stop"s sometimes work, Control-C’s always work. "Stop"s after the 1st one that don’t work produce the “your options” message only.

Peter.

Success!

A 200ms delay (as apposed to 100ms in the sample code) in the loop cycle works reliably.

1 Like