Date: Sun, 12 Aug 2018 01:01:18 -0300 From: "Dr. Rolf Jansen" <rj@obsigna.com> To: freebsd-arm@FreeBSD.org Subject: Re: BeagleBone Black with a I2C Digital Analog Converter Message-ID: <74831EA5-1BBD-442A-BD24-6DE1FDBBD575@obsigna.com> In-Reply-To: <1534020139.31375.16.camel@freebsd.org> References: <3C191052-1E2C-4D85-8CF1-AAC64F0500B7@obsigna.com> <1533743140.9860.99.camel@freebsd.org> <3007D25E-4884-4652-8B0D-9C6A837D4ADB@obsigna.com> <A8BCB12A-7D7E-46C7-A6B0-081DADAA1530@obsigna.com> <1534020139.31375.16.camel@freebsd.org>
index | next in thread | previous in thread | raw e-mail
> Am 11.08.2018 um 17:42 schrieb Ian Lepore <ian@freebsd.org>: > > On Sat, 2018-08-11 at 17:30 -0300, Dr. Rolf Jansen wrote: >>> >>> ... >>> , 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). >> ... >> >> 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. >> > > Ah. The board probably does support 2.7-5.5v, but if the i2c bus has > pullups that only pull the lines up to 3.3v, that may be too close to > the VIH transition levels for the DAC chip running at 5v. Even if it's > within the VIH range, if the pulls aren't strong enough the clock > signal may not rise above the 5v VIH fast enough for reliable comms. I was too happy too soon. Now, I updated my system to the 12 snapshot from yesterday, which turned it from 12-CURRENT to 12-ALPHA1, and with that one, the issue number 2 above turned from a minor issue to a major problem, in order not to say a whole new barrier is now blocking all my further efforts. It seems that in 12-ALPHA1 the DTB is statically compiled into the kernel, and now I cannot simply hack-in anymore some nodes which don't work by the way of overlays OK, in the moment I may switch back to 12-CURRENT, however, I am elaborating this project with 12 now, so I won't have any headaches in the future. Now I am stuck again. Please may I ask for an advice? May I expect that pinmuxing will work in a not too distant future with overlays? Am I really supposed to build a custom kernel, only for getting 2 pins straight? Building a kernel takes forever on the BBB. Shall, I forget 12 and stay with 11 for the next years? BTW: The startup script /etc/rc.d/ntpd got a flaw. The -p option must be removed from the cmdargs. Best regards Rolfhelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?74831EA5-1BBD-442A-BD24-6DE1FDBBD575>