Closed MrSVCD closed 1 month ago
We could use a separate I2C bus for the lower speed stuff.
I am asking since in issue #44 there was talk about adding a SPI port and in that discussion there was talk about using GPIO09 for Chip Select for a SD card and that would block I2C0 and I presume here that I2C1 on GPIO06-07 is busy being used on GPIO20-21 for the screen (but I don't know if that is how it works).
This is what I propose as a connector (IDC) and pinout. It is based on the rebelliously shitty add on 1.69bis "standard" for conference badges. The difference is that the two GPIO pins have the definitions of INTerrupt and PWR?. I don't know what PWR? is yet and might turn into another GND or a NC.
That sounds about right. Since we are getting a bit short on io, I would suggest that the best option would be if peripherals shared i2c1 bus with the display. I think we could add low bandwidth peripherals like keypads without slowing the display too much.
@dawsonjon at what frequency is the display bus set at? 100kHz? 400kHz? more?
400kHz. If you only need something slow, why not use software i2c? Otherwise we might need to start getting creative :-)
That is true, I didn't think of that. I have some cable laying around so I am going to do a distance test with a display. I will be happy if it works over 5 meters but I think 2 meters will be enough for most people.
@dawsonjon do you think that the pico should be polling or work on interrupt basis? It would require a extra pin but it would lower the load on the ui core. (And if using the display I2C works it would not interrupt the display update.)
If you're looking for metres of distance, I wouldnt use I2C - I'd recommend using USB (Serial). It's shielded and uses differential signalling so will cause much less EMI and interference to the radio.
The PicoRX is already a USB serial "device" so you could easily hang it off a bigger Raspberry Pi. This depends on implementing a CAT style serial interface for control and status which is already on the list. With the USB Audio streaming thats nearly complete you also get the audio at your controlling RPi.
I have to admit defeat on external use of the I2C bus. While there exists solutions https://www.adafruit.com/product/4756, I think it's is better and cheaper option to use a second Pico, and for my needs, a USB keyboard/keypad. Then you get plenty of i/o to control attenuation, amplifier etc.
The second Pico would still use the display I2C bus to save on pins on the main Pico.
I have thought about making a standard, of the de-facto kind, for external I2C devices to be used with PicoRX. My proposal is here: https://github.com/MrSVCD/PicoRX-accessories/tree/main/I2C and it is very much in the alpha phase of writing.
Examples of peripherals would be a keypad for entering frequencies or a full remote control panel like some ham radios have.
One thing that would stop this in its tracks is the speed of the I2C bus used with the display since I was thinking of reusing it and if it is too fast it would not be able to be reused because of cable length and signal degradation. This might not be a problem since I suspect that the cable length will not be longer that 2 meters in total.
In the proposal I am writing about using one pin for interrupts so that the pico don't need to poll the I2C bus constantly and can update the display without slowdown.
(Some of you might see the similarity to SOA standard that hack-a-day likes and that is what it is with modifications for PicoRX use.)