Hi there I’m hoping this is not a stupid question, but has anyone been able to establish communication with I2C modules. Namely the OLED display using a Pico-W and MicroPython?
I am getting a hardware error in the Thonny shell when I try to run the sample applications from the Core page.
I have tried this on two Pico-W boards with the same result and have checked my solder joints and confirmed I have continuity on the data pins. The same code runs flawlessly on a non wireless Pico.
My Pico-W boards have the correct UF2 file and run the demo webserver programs without issue?
Any ideas on what I am missing here, would be greatly appreciated.
1 Like
Welcome David!
I’ve run examples on the OLED no worries, were you using the same default pins 8/9 for I2C?
If you run an I2C scan do you get any addresses back?
Hi Liam
thanks for your reply, I am using the PiicoDev Expansion board which uses the default pins I had previously checked this for continuity to ensure I hadn’t dry jointed a pin on either board.
I had no idea of the i2c scan, but a quick google search found me some code which I’ve since run. The i2c scan of the Pico W correctly reports the connected devices at 0x3c and 0x3d, which is what I current have plugged up.
The demo code runs happily on a Pico but same code on on the Pico W delivers the error “PiicoDev could not communicate with module at address 0x3C, check wiring”.
Thanks for the clues, I’ll keep looking to see why this is occurring.
Regards
David.
1 Like
Does this mean you have two displays connected ??
Try with just one then the other. It could be related to having both displays on at the same time with the Pico W.
I have an older display without the switch, so its a bit harder to change the address and I have only one spare so could not test with two. The demo worked ok with a Pico W and the one OLED.
The other thing that comes to mind is the pullup resistors. You may have to disconnect one pair. In another project I had a note to myself that this was necessary, because I had 4 x I2C devices on the same bus. The device at the end of the link is the one to keep the pullups on.
Anyway, hope you get it sorted.
Cheers
Jim
3 Likes
Hi Jim.
Yes I have two displays connected (at present). Not my intention just one of the many configurations I tried, I have run the same code on 2 different Pico and 2 different Pico W boards and have tried these with each OLED display in either address setting both individually and together with opposing setting.
The pullup resistor have not been touched, these are all new boards, my only input being to solder on the headers and to load code onto the Pico boards.
The web-server code works without issue on the Pico W boards, the OLED demo code runs on the Pico but throws up i2c device not found errors when run on a Pico W.
I could be wrong but at this point am surmising that all my hardware is intact and the issue lies within the MicroPython OLED demo code.
Thank you for taking the time to look through my dilemma.
David.
.
2 Likes
I just tested two displays together both running the demo.
Modified the address of one, solder blob across the addr pads.
Thought it was a track cut but I was wrong, solder much easier.
My setup is the same as you have described; Pico W plugged into Lipo Expansion Board connected to OLED connected to next OLED. I used 50mm Piicodev cables. Pullup settings NOT changed.
One of my displays is damaged missing every alternate scan line, but it still shows the demo ok. Damage was me on a previous project. Both displays show the demo at the same time. Demo was modified to use two displays.
If yours works on a Pico and not on a Pico W, you might have a faulty Pico W. But as you have said you tested it on 2 and all combinations; you would think at least one should be ok. If you have connected the wiring by soldering to the board, you may have the SDA & SCL lines crossed. The LED on the OLED lighting up would mean the power is ok. Another thing you could check is the continuity between the SDA & SCL pins on just the Pico W, with the power off, there should be none. Solder bridges can be quite small but it should not have happened on both boards.
If you suspect faulty boards suggest you contact Core Electronics.
Regards
Jim
PS Software on the Pico W is rp2-pico-w-20220831-unstable-v1.19.1-358-g0b26efe73.uf2
3 Likes
Thanks Jim
The Lights are on but nobody is home when the Pico W is connected up. I am using the same hardware carrier with the Pico and the Pico W. Running an I2C scan show the OLED displays all present &correct. So we can rule out crossed lines etc.
the MicroPython image I have loaded is rp2-pico-w-20220909-unstable-v1.19.1-389-g4903e48e3.uf2
I might try nuking the image and then loading the next MicroPython build.
David.
1 Like
There is my answer, the current uf2 file is borked.
If I load rp2-pico-w-20220826-unstable-v1.19.1-337-gbd4e45fd6.uf2 all works correctly.
If I load rp2-pico-w-20220909-unstable-v1.19.1-389-g4903e48e3.uf2 the display is not found, yet some i2c scan code still finds the display. Again loading the older file returns operation to what would be expected.
Thanks Liam & Jim for the assistance.
David.
5 Likes
Hi David,
Good catch Re the Micropython version, Great pointer there Jim!
It’s a shame there isn’t an inbuilt Pico W environment in Thonny just yet.
1 Like
I loaded the latest Thonny 4.0.0 because of some other problems I was experiencing, thinking it might solve them. It has links to Pico W and others but the interfacing is rather flacky and slow. The Pico W I used today was loaded manually as Thonny kept timing out.
@David8704 experience will be something to keep in mind.
Hopefully the Pico W .uf2 file will be set as a release soon, same as the Pico; for now it seems to still be in development phase.
Cheers
Jim
2 Likes
Hi All
I am just an outside observer when dealing with RPi and Python/Micropython but it seems to me that during the time I have been involved with this forum there appears to be a more than fair share of backward compatibility problems. Just like David’s problem above. This does not seem to be confined to software as hardware compatibility rears its ugly head quite often also.
Would it be that if you have some last generation hardware you are stuck with that era software and vice versa if you have new software you have to purchase the latest hardware to use it with.
This to me is a very undesirable situation and is one of the reasons that in the back of my mind I have steered well clear of RPi and Python products. Forum participants seem to be forever re-flashing or re-loading this stuff or looking for a version that will work for them. Admittedly there could be a fair share of finger or user trouble but this can’t be the problem in all cases. From the outside it looks though a bit of this material is released to the market on the assumption that the user purchases the latest product every couple of months.
Having got that off my chest I have relented and ordered a couple of Picos. Reason being that most think it is a better proposition than Arduino and the faster clock could be of use. And I have recently discovered that Arduino IDE can be used. One down side is the 3.3V operation although you can power it with 5V. I think I can live with that. It might be an advantage if using an OLED display as these seem to prefer the lower voltage. If it will do what I want then it could be better for my immediate requirement or if not they might reside in the too hard basket for a while. Will see.
I have a need to measure pulse width and would like to do it with the relatively easy Arduino “pulseIn” function. I have not been able to confirm or deny this in any of the documentation I can find so will just have to try it. Not a too expensive exercise.
Cheers Bob
3 Likes
Hi Bob,
The Pico, no ‘W’ is quite stable now I think.
I think David’s problem above was just linked to a particular nightly release of Micropython that was quickly patched.
The Pico and Pico W are definitely here to stay now, the silicon itself is very very new vs the Arduino
(The full Pi single board computer’s however are their own can of worms Re compatibility, but very powerful and have their own place, I try to stick to microcontrollers where possible)
I think some kind of expectation also drives the current need for a faster more powerful product, the machine learning guides for example(some of those topics are nearing 200 replies with very similar questions).
On the flipside I’ve only got a couple of new bits of hardware running legacy code - there’s definitely an effort being made to keep things reverse compatible
Hard agree here - sometimes someone else might have run into the issue but not listed a solution.
(Thanks again BTW David and James!)
Jim summarises it well with ‘…for now it seems to still be in development phase.’ - which just needs more people pushing the edge of what current firmware can do (a perfect example)
I think this is just different manufacturers trying to make their own versions of the Pi/HAT’s and quickly there are too many variants (4 variants of the Pi 4, each with different amounts of RAM, 10+ versions of compute module - a Pi 4 oriented towards industry use)…
…And an endless amount of HAT’s that serve one or more purposes, e.g. searching for Pi motor driver yields 10+ million results on Google and 1000+ results on Core search (though some HAT’s and motors appeared, if 10% were relevant that’s still 100 products that do close to the same thing)
2 Likes
Hi Liam
That just about sums it up.
A couple of statements seem to agree with most of what I say
“think”??? would be nice to have confidence that a device is going to behave the way it is advertised or quoted. I am losing enough hair now without pulling any more out wondering just what could be wrong.
I think “quickly” is the relevant word here. I think sometimes a little too quickly and could use a bit more “beta” testing in the practical sense before claiming to be a finished product.
We probably have to put this down to modern marketing. If the consumer is hungry enough for a type of product and happy to put up with a minimally tested product then the manufacturers will be only too glad to oblige. Can’t blame them really and it does keep the price down to very competitive levels. I am very aware of how much it can cost to meet tight specs.
One spec I dealt with many years ago which is a bit hard to forget. One of my tasks was the repair of complete units and modules out of a very high spec HF receiver. This requirement was to survive an interfering signal of 200VRMS straight into the antenna connector and still come up smiling when the interference was removed. Try that with the average wireless. The mind boggles when you think of the costs to develop a front end that met that requirement. I think the company that employed me and was responsible for this development took out a patent on this system. Yes it was done along with a good many other innovations in that receiver right here in Sydney. With a very limited market the end cost of this unit was a bit eye watering.
Cheers Bob
1 Like
I’ve been working with electronic controllers since the late 70’s and am still going. Stepping down from some of the systems I work with into microcontrollers and SBCs, I’d have to say Raspberry PI on the whole are doing an excellent job with continuity and the Achilles Heal of any range of systems, backward compatibility. Not perfect by any means but the level of documentation and the flow of product development puts many of the professional systems I’ve worked with/on to shame.
Pico W is less than 12 months old, and though frustrating , my problem here has been solved with little issue via some wonderful community support.
If only some of the issues I’ve had with professional PLC and Automation controllers could have been resolved as easily life could have been a whole lot less stressful. I don’t have the threat of liquidated damages over my head in my dabbling with Pico
What is impressing me with Pico Pi the ease at which you can get something happening and can try out ideas on the fly. Core’s PiicoDev products further enhance this ability to quickly mock up a platform for all manner of project ideas.
Bang for Bucks these little boards are pretty impressive.
2 Likes
Hi David
AH, yes, “Liquidated Damages” can be a game changer. I know of a couple of companies that were severely damaged when the contract clauses were activated. So are “User Trials” which I am sure you would be familiar with. The use of “Force Majeure” gets a bit of a work out sometimes.
I must extend my apologies to all here as after giving everything some thought I have not factored in the sheer number of these products in use by such a massive number of people of extremely wide range of ability and expertise. If I have trodden on any toes I am sorry.
Would have to agree with that pretty much across the board. Some of these things are a ridiculous price. BUT, I still stand by my comment about releasing too soon to get something out there before the opposition then trying to band aid or patch up later.
Cheers Bob
2 Likes
All good Bob, no toes trodden on, steel caps not required. I share your frustration with the growing tendency to use the market as beta testers for new products. Equally I despise the replacement of solid well written user manuals by buggy apps and haphazard bubble help.
I’ll cut a lot more slack with a $9 micro board than with a $1500 Phone or a $3K notebook, the scary part of that being Pi Foundation are doing a much better job than Samsung, Microsoft, Apple & Google at presenting their wares.
Here is hoping that we’ll one day be able to actually buy 4B Pi’s again. Till then I will seeing just what I can push out of these Tiny Pico boards.
Cheers for your insight & opinions.
David
3 Likes
