Differentiating RPi versions
Would it be worth it to either split out version-specific instructions, or perhaps make the instructions more agnostic to version? I just got an RPi 3, for example, and am pretty sure Raspberry_Pi#I2C is not applicable:
I only load
i2c-bcm2835, for example, and my Sense Hat functions properly. I'm just getting started with the RPi using Arch, so in seeing this page for the first time, it looks like it mixes and matches various drivers, possibly based on who was adding the instructions at the time. In the section on the Raspberry_Pi#Raspberry_Pi_camera_module, a fix is proposed to
blacklist i2c_bcm2708, followed by another fix which is to load
bcm2835-v4l2. I wondered if these are separate fixes for the RPi 2 vs. 3, respectively?
- Please discuss this contribution with the ALARM wiki team as described in . Thank you. -- Alad (talk) 23:51, 24 September 2017 (UTC)
Adjustments to I2C section
I just started fiddling with my RPi 3 and found the I2C setup very frustrating. I can make these edits, but would rather those more familiar with RPi with Arch Arm chime in first. Some observations:
- I believe this is only applicable for early RPi's.
# i2cdetect -y 0
This adafruit article says that
i2c-0 is for 256mb Pis and
i2c-1 is for 512mb Pis.
- This code was unclear to me:
# echo <devicename> <hardware address> >/sys/class/i2c-adapter/i2c-0/new_device
If this is necessary for something, it might be best to just give a full example. When I run
i2cdetect, I get 5 addresses; how does one know what's what and what to add?
- I ran into errors trying to use my Sense Hat and it turned out it was all due to permissions on
/dev/i2c-1. I ended up adding this:
The errors were quite cryptic ("unable to initialize humidity sensor"), so I thought I hadn't loaded the right module. I've seen various ways to apply a udev rule; maybe this is not desired and one should apply it to the device for security/safety?