Thanks again, Flavor!
I can definitely try soldering to 2&3. I'm borrowing another cm4 from a friend because apparently it is not unheard of that I2C ports don't work on some compute modules.
I feel like we need another way to test the CM4 separately, then with the CM3 adapter, then with the Freeplay addon.
I really doubt that this is a i2c port/hardware problem, but it's possible.
Do you have a regular Raspberry Pi 4 (or maybe 3 or Zero 2, etc) to test some things?
One of the magnet wires became loose. I assume this happened when pushing the board down to to the connector, and had to solder it again (see photo)
Now when I run `i2cdetect` I see devices on every address:
Code:
pi@retropie:~ $ i2cdetect -y 6
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
30: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
40: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
60: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f
70: 70 71 72 73 74 75 76 77
My config file is still the same as before:
Code:
pi@retropie:~ $ cat /boot/config.txt
# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2c_vc=on
#dtparam=i2s=on
#dtparam=spi=on
# Enable audio (loads snd_bcm2835)
dtparam=audio=on
# Enable DRM VC4 V3D driver on top of the dispmanx display stack
dtoverlay=vc4-fkms-v3d
max_framebuffers=2
dtoverlay=gpio-poweroff,gpiopin=21,active_low
dtoverlay=dwc2,dr_mode=host
# BEGIN FREEPLAY MODS
framebuffer_width=320
framebuffer_height=240
hdmi_force_hotplug=1 #these HDMI lines will try to set up 1024x768 (you can remove them if you have problems playing via HDMI)
HDMI_FORCE_MODE=1
hdmi_group=2
#hdmi_mode=16
hdmi_drive=1 #Normal DVI mode (No sound) (2 for HDMI with sound)
#this next one is NOT for use with the fbcp-ili9341, only the generic/simple/slow fbcp
#dtoverlay=waveshare32b,speed=80000000,fps=60,rotate=270
dtoverlay=audremap,swap_lr=on
#dtparam=i2c1_baudrate=400000 #makes a big speed difference
#use the newer "i2c1” instead of deprecated “i2c1-bcm2708”
#dtoverlay=i2c1-bcm2708,sda1_pin=44,scl1_pin=45,pin_func=6,combine=off
#dtoverlay=i2c1,pins_0_1=1,combine=off
dtoverlay=i2c6,pins_0_1
# Disable the ACT LED on the Pi Zero.
dtparam=act_led_trigger=none
dtparam=act_led_activelow=on
audio_pwm_mode=2
dtparam=watchdog=on # Enabling watchdog.
# TESTY
hdmi_mode=87
hdmi_cvt=320 240 60 1 0 0 0
hdmi_force_hotplug=1
core_freq=400
This kind of feels like progress, I guess it's something haha
Note: oh and i2cdetect doesn't take as long as before
You show
dtoverlay=i2c6,pins_0_1
But used
i2cdetect 1
That’s a mismatch
I'm not sure I follow. I'm running `i2cdetect -y 6`.
If I list the buses I get the following:
Code:
pi@retropie:~ $ i2cdetect -l
i2c-6 i2c bcm2835 (i2c@7e205c00) I2C adapter
Should I be trying bus 1 in the config.txt file instead?
Edit: Trying bus 1 shows similar results, the only difference is that mk_arcade_joystick_rpi is configured to try to find something in I2C1 so dmesg shows this:
Code:
pi@retropie:~ $ dmesg | grep i2c
[ 3.668450] i2c /dev entries driver
[ 3.705950] mk_arcade_joystick_rpi: request_module i2c_bcm2835 returned 0
[ 5.004888] bcm2708_i2c fe804000.i2c: BSC1 Controller at 0xfe804000 (irq 37) (baudrate 100000)
`mk_arcade_joystick_rpi: request_module i2c_bcm2835 returned 0` looks wrong. Would that be a library not found type of error? That seems to be ok, but the mk_arcade_joystick_rpi still seems to be failing to find the analog chips
Code:
pi@retropie:~ $ dmesg | grep mk
[ 3.599418] mk_arcade_joystick_rpi: loading out-of-tree module taints kernel.
[ 3.600962] mk_arcade_joystick_rpi: Freeplay Button Driver
[ 3.651426] mk_arcade_joystick_rpi: request_module i2c_bcm2835 returned 0
[ 3.651451] mk_arcade_joystick_rpi: I2C bus 1 NOT opened (sleeping and retrying)
[ 4.164432] mk_arcade_joystick_rpi: I2C bus 1 NOT opened (sleeping and retrying)
[ 4.684453] mk_arcade_joystick_rpi: I2C bus 1 NOT opened (sleeping and retrying)
[ 5.204434] mk_arcade_joystick_rpi: I2C bus 1 opened
[ 5.204454] mk_arcade_joystick_rpi: I2C bus timeout set to 10 ms
[ 5.204469] mk_arcade_joystick_rpi: Analog auto center disable
[ 5.204641] mk_arcade_joystick_rpi: X1 assigned to I2C address 0x48
[ 5.204930] mk_arcade_joystick_rpi: X1 chip not found
[ 5.205158] mk_arcade_joystick_rpi: Y1 assigned to I2C address 0x4D
[ 5.205446] mk_arcade_joystick_rpi: Y1 chip not found
[ 5.205663] mk_arcade_joystick_rpi: X2 assigned to I2C address 0x4B
[ 5.205955] mk_arcade_joystick_rpi: X2 chip not found
[ 5.206185] mk_arcade_joystick_rpi: Y2 assigned to I2C address 0x4F
[ 5.206471] mk_arcade_joystick_rpi: Y2 chip not found
[ 5.206584] mk_arcade_joystick_rpi: pad type requested : 4
[ 5.206600] mk_arcade_joystick_rpi: pad type : 4
[ 5.206651] mk_arcade_joystick_rpi: GPIO configured for pad0
PS: I can also test on a CM4 IO board but I don't think I have any I2C devices
tldr; I think my wiring was too long and/or had some short somewhere.
I ended up redoing the wiring but this time I used shorter magnet wire to connect to pins 44 and 45 on the Freeplay board (see attached picture)
I then used the i2c6 configuration with GPIO0 as data and GPIO1 as clock and finally saw I2C devices
Code:
pi@retropie:~ $ i2cdetect -l
i2c-6 i2c bcm2835 (i2c@7e205c00) I2C adapter
pi@retropie:~ $ i2cdetect -y 6
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: 03 -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- 48 -- -- 4b -- 4d -- 4f
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- 62 -- -- -- -- -- --
I then edited the `mk_arcade_joystick.conf` to use bus 6 and I got joysticks running now
Thanks for the patience, Flavor
OH SNAP! Awesome news. I was hoping to have time to image an SD and boot up the CM4 IO board today. Now it looks like you beat me to a fix, which is great.
What's next? Does that get all the pieces working?
Thanks!
I still want to compile the display drivers running at different speeds so I don't have to change the core_freq through config.txt and maybe add a pair of heatsinks to cool it down.
Spoilers: considering the CM4 can handle a second HDMI display I'd like to eventually turn it into something like the attached image (I might not be able to pull it off though)
That would be cool/impressive! The way fbcp works is that it is a copy of the HDMI output. If I were to tackle this project, I would try to see if I could make it copy the HDMI that isn't being routed to the HDMI connector. Does that make sense?
Right now, I think, if you plug in HDMI, you'll see the same thing on both screens, right?
So, if you can switch the config.txt stuff (and fbcp stuff) to output to the OTHER HDMI (that you can not plug into), and get that working, it would be a good first step.
Then, you'd want to enable the HDMI output on the HDMI that does have a HDMI socket (on our Freeplay CM3 board). See if you can get any output on that while the system is still running properly on the LCD.
I hope that makes sense.
Thanks! That makes sense
I have never seen a 3.2 inch screen with HDMI input. It might not even exist due to the smaller resolution. So I was thinking I was going to need to do something on an fpga to convert HDMI to SPI or whatever interface the display I end up choosing uses.
For emulators like Drastic, if I have to go the fpga route (which I hope I do not) I might end up trying to copy only a portion of the framebuffer on the fpga and do the same on the fbcp for the other screen. This hopefully allows me to split the image without additional processing on the Pi.
Edit: it looks like they exist now:
https://www.waveshare.com/product/displa...-lcd-h.htm