Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use TSL2561 and RTC ds1307 using a different bus #514

Open
Novocaine85 opened this issue Nov 21, 2021 · 5 comments
Open

Use TSL2561 and RTC ds1307 using a different bus #514

Novocaine85 opened this issue Nov 21, 2021 · 5 comments
Labels
bug Something isn't working enhancement New feature or request

Comments

@Novocaine85
Copy link

If you need support: Please post on https://www.reddit.com/r/crankshaft/ as this is a bug tracker, not a support forum.

Note: Reporting issues not based on official published builds will be closed without any comment.

  • What phone do you have?
    Poco F3

  • What OS version?
    Android 11 / Miui 12.5.6 Global

  • What crankshaft version?
    Alpha-7.4 2021-09-22

  • Steps to reproduce the bug, if you're planning to report a bug. Please indicate whether the bug is always repoducible.
    On my RPI I have the RTC ds1307 using the regular pins (vcc, gnd, scl, sda) and using a dtoverlay (dtoverlay=i2c-gpio,bus=2,i2c_gpio_sda=17,i2c_gpio_scl=27) on config.txt, i'm using the TSL2561 connected to the pins as per dtoverlay.
    Changed TSL_I2C_BUS to 2 on crankshaft_env.sh but TSL2561 is not recognized.

  • Please provide any further information that you might find helpful if available.

pi@CRANKSHAFT-NG:~ $ crankshaft i2ccheck 39
Crankshaft Management Tool v2.4.0 is executing command...

No device found.

Done.
pi@CRANKSHAFT-NG:~ $ crankshaft i2ccheck 68
Crankshaft Management Tool v2.4.0 is executing command...

Device 0x68 found and in use by another process.

Done.


pi@CRANKSHAFT-NG:~ $ sudo i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
pi@CRANKSHAFT-NG:~ $ sudo i2cdetect -y 2
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- 39 -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
pi@CRANKSHAFT-NG:~ $

debug.zip

Thanks for any advice.

@techdev5521
Copy link
Contributor

This is a wonderfully informative bug report -- thanky you!

I'm working on an unrelated TSL2561 issue #515 and from that work I believe I know what is happening here. First I'll explain how things should work then why i think they aren't.

How Things Should Work

On boot, there are two services that run relating to I2C and the light sensor:

  • i2ccheck.service: Checks for various I2C devices.
  • lightsensor.service: Monitors light sensor and updaes day/night mode + brightness.

The Problem

i2ccheck.service calls /opt/crankshaft/service_i2ccheck.sh to look for I2C devices but assumed all devices are on bus 1.

if [ "$(i2cdetect -l | grep i2c-1)" != "" ]; then

Later, lightsensor.service call /opt/crankshaft/service_lightsensor.py which correct gets the light sensor bus from the /boot/crankshaft/crankshaft_env.sh or /opt/crankshaft/crankshaft_default_env.sh in that order. However, this service seems to fail or not start unless i2ccheck.service detects a device.


def get_var(varname):
try:
CMD = 'echo $(source /boot/crankshaft/crankshaft_env.sh; echo $%s)' % varname
p = subprocess.Popen(CMD, stdout=subprocess.PIPE,
shell=True, executable='/bin/bash')
return p.stdout.readlines()[0].strip()
except:
CMD = 'echo $(source /opt/crankshaft/crankshaft_default_env.sh; echo $%s)' % varname
p = subprocess.Popen(CMD, stdout=subprocess.PIPE,
shell=True, executable='/bin/bash')
return p.stdout.readlines()[0].strip()

Potential Solution

The files associated with i2ccheck.service should account for potential custom I2C busses. The implementation method isn't clear to me though.

@matt2005
Copy link
Contributor

matt2005 commented Nov 23, 2021

The service needs editing to support bus 1 and 2. i2ccheck

I can take a look in a few days, but feel free to submit a PR if you get it working

@techdev5521
Copy link
Contributor

Hard coding buses 1 and 2 solves this particular problem however if someone were to make a bus on any port greater than 2 then we run into the same issue.

It may be more robust to first build a list of the enabled buses then check each of those buses for devices. The list of buses could theoretically be built by listing files in /dev/ that match the regex pattern ^i2c-* where the characters matching the * are the bus number. Then, all bus numbers are scanned whether they're physical or virtual, sequential or random.

@matt2005
Copy link
Contributor

That's what I was thinking 👍

@matt2005 matt2005 added bug Something isn't working enhancement New feature or request labels Nov 24, 2021
@matt2005
Copy link
Contributor

I'm thinking it would be better to add a var in the crankshaft_env for i2c_rtcbus and fix the script to use that, that way it can hide the dtoverlay setup as it's handled by scripts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants