MikroBus on BeaglePlay

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
[ 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.

I am using a

MIKROE-2882 mikroBUS Shuttle
MIKROE-4496 Temp&Hum 15 Click
MIKROE-2880 Shuttle Click

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.

Pseudocode Temp&Hum 15:
i2c_write(i2c_addr=0x44, tx_bytes=[0xFD])
rx_bytes = i2c_read(i2c_addr=0x44,
t_ticks = rx_bytes[0] * 256 + rx_bytes[1]
rh_ticks = rx_bytes[3] * 256 + rx_bytes[4]
t_degC = -45 + 175 * t_ticks/65535
rh_pRH = -6 + 125 * rh_ticks/65535
if (rh_pRH > 100):
rh_pRH = 100
if (rh_pRH < 0):
rh_pRH = 0

Is this something that needs a manifest file in the distribution?

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.

1 Like

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

OK, I haven’t tested this, but I hope that you can…

I checked out the Click board.

I found the driver for it and a touch of documentation on the driver.

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.

I created a manifest for the Click board.

I built the manifest in the ‘untested’ directory in this Debian package:

manifesto-15144.zip (16.4 KB)

Download it, copy it to the board, unzip it and install with sudo dpkg -i <file.deb>.

The instructions at Using mikroBUS — BeagleBoard Documentation might be able to help from there.

Report the steps you take and the results.

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

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 saw I left out

“# cat /home/mwx/mikro/tmphm15/TEMPHUM-15-CLICK.mnfs > /sys/bus/mikrobus/devices/mikrobus-0/new_device”

did dmesg report anything?

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.

yes, you need to do the cat before checking the output of dmesg.

oh, a couple more notes.

Because the driver is “hwmon” instead of “iio”, the interface is different. Instead, you need to use “lmsensors”.

Also, looks like “CONFIG_SENSORS_SHT4X” wasn’t defined in the defconfig: 5.10.168-ti-arm64-r110 (ac2750db) · Commits · BeagleBoard.org / Linux · GitLab

@RobertCNelson will add and rebuild the kernel. Let’s see what the dmesg error is when this kernel module isn’t built.

Also, see you on Discord! I accepted your friend request.

Test image is up: build (#15155) · Jobs · Robert Nelson / ti-linux-kernel-dev · GitLab

(click download) then unzip locally…