Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 11 Aug 2018 17:30:38 -0300
From:      "Dr. Rolf Jansen" <rj@obsigna.com>
To:        Ian Lepore <ian@freebsd.org>
Cc:        freebsd-arm@FreeBSD.org
Subject:   Re: BeagleBone Black with a I2C Digital Analog Converter 
Message-ID:  <A8BCB12A-7D7E-46C7-A6B0-081DADAA1530@obsigna.com>
In-Reply-To: <3007D25E-4884-4652-8B0D-9C6A837D4ADB@obsigna.com>
References:  <3C191052-1E2C-4D85-8CF1-AAC64F0500B7@obsigna.com> <1533743140.9860.99.camel@freebsd.org> <3007D25E-4884-4652-8B0D-9C6A837D4ADB@obsigna.com>

next in thread | previous in thread | raw e-mail | index | archive | help
> Am 08.08.2018 um 14:05 schrieb Dr. Rolf Jansen <rj@obsigna.com>:
>=20
>> Am 08.08.2018 um 12:45 schrieb Ian Lepore <ian@freebsd.org =
<mailto:ian@freebsd.org>>:
>>=20
>> On Wed, 2018-08-08 at 10:59 -0300, Dr. Rolf Jansen wrote:
>>>=20
>>> ...
>>> Please can somebody, check this, and perhaps give some hints in case =
I got something wrong? I don't have an oscilloscope, a multimeter only, =
can I check somehow if I specified the correct pins?
>>>=20
>>> What needs to be done next? I guess, I need to write a simple device =
driver, don't I? Or can I use somehow the iicbb(4) =E2=80=93 I2C generic =
bit-banging driver, since actually that DAC chip needs bit banging only =
-- repeatedly write 3 byte in row. I yes, how can I use it for my =
purpose?
>>=20
>> At this point, i2c(8) is your friend, it lets you do i2c bus
>> transactions from the commandline without a device-specific driver =
for
>> each i2c device. A good starting point is a bus scan:
>>=20
>>   i2c -f /dev/iic1 -s
>>=20
>> If the bus is working you should see something like:
>>=20
>>   Scanning I2C devices on /dev/iic1: 60
>=20
> Ian, thank you very much for your response.
>=20
> As a matter of fact, the source of all my doubts told in the initial =
post above is that yesterday after hours in a trial&error circle, I was =
not able to get a sensible response from the exact bus scan command =
which suggested:
>=20
> i2c -f  /dev/iic1 -s -v
>=20
> Up to now, by no means I was able to see anything else than:
>=20
> dev: /dev/iic1, addr: 0x0, r/w: r, offset: 0x00, width: 8, count: 1
> Hardware may not support START/STOP scanning; trying less-reliable =
read method.
>=20
> This START/STOP thing let me to think that I perhaps need to get =
attached a device driver.
>=20
> I am also still in doubt, whether I really got the pinmux straight. I =
checked very carefully the physical connections, anyway I am stuck at =
this point.

I got it working.

1.) The specification of the DAC board which I attached to my BBB was =
wrong in regards to the acceptable Vcc voltage range (2.7 to 5.5 V). I =
started to use it with 5 V, and by no means I got any response from it. =
After doing a full u-turn around the block =E2=80=93 to no avail I tried =
all possible settings with FreeBSD 11.2, then all with Debian/Linux 9, =
then all with new spare DAC board =E2=80=93 I switched the Vcc to the =
3.3 V supply, and it works. Halleluja! I am back on FreeBSD 12-CURRENT, =
and I can live with 3.3 V, since I need to pass the DAC output through a =
scaling OpAmp anyway in order to have 0 ... 10 V.=20

2. There is still something wrong with my overlay. I need to hack in the =
same I2C1 changes into the main DT, and then the bus scan by i2c -f  =
/dev/iic1 -s gives me the expected output. For my present project this =
is a minor issue, though. My best guess here is, that there is a problem =
with the reference of the I2C1 node to the proposed pinmux node.

On Debian/Linux the very overlay does work.

Best regards

Rolf




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A8BCB12A-7D7E-46C7-A6B0-081DADAA1530>