search

bablokb / pcb-pico-pi-base

An Interface PCB to use Pi-Hats with a Pi-Pico(w)
Creative Commons Attribution Share Alike 4.0 International
12 stars 1 forks source link

Not an issue: link to similar solution... #1

Closed dglaude closed 4 months ago

dglaude commented 5 months ago

Hello,

Sorry not sure how to contact you... I found your article in Adafruit Playground.

When the Pico came out, I tried to find solution to reuse my HAT and pHAT collection on the pico... and use that with CircuitPython.

The best solution available at the time was Red Robotic Pico 2 Pi (that was available from Tindie): https://www.tomshardware.com/reviews/red-robotics-pico-2-pi-review-use-hats-with-raspberry-pi-pico ... maybe you can check this page to compare the mapping: https://www.hackster.io/news/the-pico-2-pi-adaptor-plate-proves-that-sometimes-it-s-the-simple-things-in-life-that-help-out-7f27e1de6208

I accumulated a few test in Circuit Python with various HAT: https://github.com/dglaude/circuitpython_phat_on_pico

I was in contact with the maker and helped make a new revision with SDA/SCL pull-up resistor. Indeed, your Raspberry Pi has that, and HAT / pHAT expect that, but on the Raspberry Pi Pico, because almost any pair of GPIO can be an I2C, there is none with the pull-up resistor.

At the time @arturo182 now owning Solder Party was working on a mapping and wanted to do a product that maybe never existed: https://www.hackster.io/news/the-zero-rp2040-is-an-rp2040-dev-board-that-tips-its-hat-to-the-former-zero-form-factor-8b71bf5a5deb

Now-a-day if someone want a PiZero like with with RP2040, I would suggest WaveShare RP2040-PiZero: https://www.waveshare.com/rp2040-pizero.htm ... I have two, I did not use them a lot, and especially not the unique aspect such as DVI/HDMI port or the USB Host (it require a OTG kind of cable).

Maybe you want to check those various attempt or product and compare your pin mapping or other technical decision they took.

Kind regards

David Glaude

bablokb commented 5 months ago

Thanks for the links and infos. I indeed knew about the Robotic Pico 2 Pi hat, but it was neither available nor did I like the mappings. I will check your repo and if you like link from my examples page.

I also own the Waveshare board, but have not tested it. It is a very nice piece of engineering and the mapping seems ok except for I2S. The biggest drawback is the lack of WLAN. Another drawback is that many pins are used for other purposes and have added resistors, so you cannot just reuse them for your own purpose.

There is another adapter I recently discovered, available from The Pi Hut: https://thepihut.com/products/pico-to-pi-hat. Here also the mapping seems fine, but I also see no pullups.

dglaude commented 5 months ago

Nice catch that PiHut version.

While writing my first message, I had in mind that I may have another I forgot to talk about... but that thing for pico to Pi mapping, I have "done it" (acquiring a few option) to map from Microbit (and especially the CLUE to Pi pinout) and also "done it" for Feather to Pi pinout too (also with one option from Arturo).

One thing I may have done is to import an alternate or overlay board.py that would map well know GPIO pin name to whatever is on the real board (like the pico). The goal was to have the example code work on different hardware without any modification.

One of the pin naming I wanted to have is the same that on CircuitPython running bare metal on Raspberry Pi Zero and/or on Blinka running on a Raspberry Pi (not sure if they are the same).

I think that the issue with WLAN is that it is kind of hard to have the Pico W chip and required licence outside of the Pico W... I don't think you can take a RP2040 and create a replica of the Pico W. So only adaptation board can have the Wifi and do that.

Anyway, good continuation with your project, I might get a copy, just like a might get the one from PiHut... just to have the whole collection. ;-)

bablokb commented 5 months ago

I also tried to write a generic abstraction layer that makes the code work with all boards. It is too bad that you cannot monkey-patch board.py.

You can see my solution to the problem in the project https://github.com/bablokb/cp-departure-monitor. The hardware-abstraction-layer is loaded in src/application.py. This works with dynamic imports at runtime, loading a board-specific file and/or reading hardware-configuration from a settings-file. I am using this setup with all my (newer) projects and it works fine.

bablokb commented 4 months ago

I added a link on the page examples/Readme.md to your repository.