Is there some step I’m omitting for MikroBus with Click boards? I have no manifest that I could find and thought Clicks had ID so not to need or expect.
I get the dmesg
Found
[ 3.880782] mikrobus:mikrobus_port_register: registering port mikrobus-0
[ 3.880849] mikrobus mikrobus-0: mikrobus port 0 eeprom empty probing default eeprom
iio_info does not find the Temp&Hum 15 Click, only a TI ADC.
to check if working and plan a non-i2c MIKROE-4701 PROFET Click - 15A on a MIKROE-2882 mikroBUS Shuttle later with it on the MIKROE-2880 Shuttle Click.
The Temp&Hum 15 and ProFET 15 have no ClickID. I don’t recall either in the manifests. How does one get those added? And I guess I should be more careful reading whether a board has a click ID.
It would appear the ProFET 15 uses an AN(alog) pin and GPIO which I would hope I can control with reads and writes to the pins without a driver. (Not sure yet about AN use and connection)
Ordered a Temp&Hum 24 MIKROE-5651 which has a Click-ID from Digi-Key.
I was trying to understand what MikroBus pinouts are used and go so far with the GPIO and power and ground, but wondered about what seems to be others of which it takes control:
gpiochip3 - 88 lines:
line 0: unnamed unused input active-high
line 1: unnamed unused input active-high
line 2: unnamed unused input active-high
line 3: unnamed unused input active-high
line 4: unnamed unused input active-high
line 5: “SPE_RSTN” “PHY reset” output active-low [used]
line 6: “SPE_INTN” unused input active-high
line 7: “MIKROBUS_GPIO1_7” “mikrobus” output active-high [used]
line 8: “MIKROBUS_GPIO1_8” “mikrobus” output active-high [used]
line 9: “MIKROBUS_GPIO1_9” “mikrobus” output active-high [used]
line 10: “MIKROBUS_GPIO1_10” “mikrobus” output active-high [used]
line 11: “MIKROBUS_GPIO1_11” “mikrobus” output active-high [used]
line 12: “MIKROBUS_GPIO1_12” “mikrobus” output active-high [used]
line 13: “MIKROBUS_W1_GPIO0” “w1-gpio.0” output active-high [used open-drain]
line 14: “MIKROBUS_GPIO1_14” “mikrobus” output active-high [used]
line 22: “MIKROBUS_GPIO1_22” “mikrobus” output active-high [used]
line 23: “MIKROBUS_GPIO1_23” “mikrobus” output active-high [used]
line 24: “MIKROBUS_GPIO1_24” “mikrobus” output active-high [used]
line 25: “MIKROBUS_GPIO1_25” “mikrobus” output active-high [used]
and mapped
line 9: "MIKROBUS_GPIO1_9" "mikrobus" output active-high [used]~~INT,7
line 10: "MIKROBUS_GPIO1_10" "mikrobus" output active-high [used]~AIN1~AN~9
line 11: "MIKROBUS_GPIO1_11" "mikrobus" output active-high [used]~~PWM~8
line 12: "MIKROBUS_GPIO1_12" "mikrobus" output active-high [used]~~RST,10
where ~ is a field delimiter
Before I got off into its other signals I wanted to confirm or not that those gpios are not rt, tx, i2c.
AN - Analog pin
RST - Reset pin
CS - SPI Chip Select line
SCK - SPI Clock line
MISO - SPI Slave Output line
MOSI - SPI Slave Input line
+3.3V - VCC-3.3V power line
GND - Reference Ground
PWM - PWM output line
INT - Hardware Interrupt line
RX - UART Receive line
TX - UART Transmit line
SCL - I2C Clock line
SDA - I2C Data line
+5V - VCC-5V power line
GND - Reference Ground
I noted that the driver id is “sht4x” in the kernel source.
I found out that the default I2C address is 0x44 in the data sheet. I should have looked at the Click population, but I was in a hurry. There is a chance it could be at a different address.
After `sudo dpkg -i bbb.io-clickid-manifests_1.20230616.0_arm64.deb
dpkg: warning: downgrading bbb.io-clickid-manifests from 1.20230713.0-0~bullseye+20230713 to 1.20230616.0
(Reading database … 154035 files and directories currently installed.)
Preparing to unpack bbb.io-clickid-manifests_1.20230616.0_arm64.deb …
Unpacking bbb.io-clickid-manifests (1.20230616.0) over (1.20230713.0-0~bullseye+20230713) …
and with no reboot, iio_info gives
iio_info
Library version: 0.24 (git tag: v0.24)
Compiled with backends: local xml ip usb
IIO context created with local backend.
Backend version: 0.24 (git tag: v0.24)
Backend description string: Linux BPLAY4DCA 5.10.168-ti-arm64-r110 #1bullseye SMP Fri Sep 1 21:26:47 UTC 2023 aarch64
IIO context has 2 attributes:
local,kernel: 5.10.168-ti-arm64-r110
uri: local:
IIO context has 1 devices:
iio:device0: adc102s051
2 channels found:
voltage1: (input)
2 channel-specific attributes found:
attr 0: raw value: 4064
attr 1: scale value: 0.805664062
voltage0: (input)
2 channel-specific attributes found:
attr 0: raw value: 4
attr 1: scale value: 0.805664062
No trigger on this device
I must admit I don’t yet see a simple way to test if such works. I searched i2cdetect busses (0-3, 5) and only found something at 0: 0x30 and 0x50. got Warning : Can’t use SMBus Quick Write command, will skip some addresses.
I’m trying to create a pattern to help people add support for new Click boards. If you want to do a live debug session, look for me on Discord (jkridner) or schedule something via Calendly - Jason Kridner.
Does this require the “# cat /home/mwx/mikro/tmphm15/TEMPHUM-15-CLICK.mnfs > /sys/bus/mikrobus/devices/mikrobus-0/new_device” before dmesg would be useful?
Sent friend request on Discord, never used such before.
