Dear All,
I’m newbie with dragonboard. Is there any java gpio library for this board?
Regards
It will be really good to have java gpio library like what is available for Raspberry Pi.
http://pi4j.com/
We are trying to plan to enable GPIO and I2C controlling libraries one by one, but not quite reached to the point.
It will be good if the community could start the activity too. 
Lets make the world of 96Boards together.
Hi, Interesting.
I’m not got in java, but finally made the gpio library.
Anyway, I’ve got problem with gpio power level.
I’m trying to make RTC DS1307 library, but unfortunately having problem with the level shifter.
Does anyone know what component should I use for I2C?
In my place, I’ve only found BSS138 and 74LVC254. Which one should I use?
Thanks
@mmsafr The problem is with GPIO voltage levels, not power. Specifically, the GPIOs are using 1.8V signals, and externally you may need 3.3V or 5V signal levels.
There are a variety of chips that provide solutions to this, but each only in a portion of possible scenarios. As it happens, I2C is particularly tricky, because it needs to be bi-directional, yet its pull-up resistance values don’t interact well with the method that most bidirectional level-shifter chips use to detect which direction to operate in.
So, a good place to look is the not-yet-released 96Boards Sensor board, to see how it implements I2C. You can see that here:
https://github.com/96boards/96boards-sensors > Sensors.pdf
Here we see TXB0108 and TXS0108 used to implement most level shifting. However, for I2C, the BSS138 solution is used.
Hope that’s enough to proceed confidently.
Thanks for your input.
I couldn’t fine TXBxxxx in my place, I’ll try with BSS138.
The BSS138 from SparkFun is popular.
Also the PCA9306 is very popular for using as a logic level converter for I2C.
Trying out both might be better choice.
@mmsafr: To clarify, the TXBxxxx won’t work for I2C.
Instead, ne choice is the BSS138: one transistor per wire, conveniently available at Sparkfun or Adafruit on a breakout board.
Or the chip form of the same idea, which may include several wires-worth of level shifter, and may include rising edge acceleration circuitry to increase the speed of the device. Examples is NXP NTS0104 and family, and Maxim MAX3372, MAX3390 and family. The data sheets, application notes and selection guides from NXP and Maxim are very informative.
@gwiderman: thanks, for your info.
At the moment I’m testing with BSS138, it seems work. I can get I2C component address using “i2cdetect -r 0”.
Hope, I’m right.
Hi @mmsafr
I played with most of the level shifters available. All of them work fine as long as your wiring is reasonably short (a few inches), but when you get to longer wiring the “chip” style level shifters burst into oscillation. I strongly recommend the BSS138 solution for use with I2C.
I managed to get the DS1307 RTC running, see the notes here: https://www.96boards.org/forums/topic/dragonboard-410c-with-real-time-clock-rtc/
Full Disclosure: I am an employee of Qualcomm Canada any opinions I have expressed in this or any other post may not reflect the opinions of my employer.
@ljking Could you please clarify what you mean by ’ “chip” style level shifters’? It makes a big difference whether you are referring to the TXSnnnn and TXBnnnn which are not intended for I2C, versus the NXP NTS0104 series or Maxim MAX3372, MAX3390 series, which are intended for I2C. Thanks.
Hi @gwideman
All of the “chip style” level shifters that I tried include a one-shot speed-up circuit that actively pulls up on the I2C signal as the edge is rising. This is intended to improve the rise time to faster that just a pull-up would cause the signal to rise. This improves the maximum possible I2C data transfer rates (into the 10-50MHz range). The side-effect of these one-shot speed-up circuits becomes obvious when you get long cables (such as the Seeed Studio cables included with many sensor break-out boards). You run into two problems 1) the cross-talk greatly increases and often creates data errors and 2) if the cables become long enough the reflections from the end of the cable bounce back and falsely triggers the one-shot. Once this happens the SCL and SDA lines will oscillate at high frequency (around 35MHz) and it will not be possible to transfer data.
The BSS138 solution doesn’t have the one-shot circuit and does not burst into oscillation. The transistor is fast enough for I2C traffic speeds up to 400kHz. The active (with a one-shot) are devices are mostly intended for much higher speeds (up to 50MHz).
I did test The following: PCA9306, TXS, TXB, MAX3001, MAX3000. All burst into oscillation when you connect a Seeed Studio cable, followed by a Seeed Studio I2C hub, followed by 3 more cables connected to the hub. All work fine IF you have short cables.
Side note: The TXB works fine for I2C (as long as the cables are short), but TXS doesn’t work well with I2C.
Side Note 2: Many sensor-modules (but not all) have BSS138 level shifters onboard that shift the 3.3V or 5V I2C signals back down to 1.8V so you end up going through two level shifters. You can bypass the level shifters by doing a bit of minor surgery on the board and drive the boards directly from 1.8V I2C signals.
Full Disclosure: I am an employee of Qualcomm Canada any opinions I have expressed in this or any other post may not reflect the opinions of my employer.
@ljking First of all, thanks for the valuable detailed discussion, and sorry I didn’t respond earlier. I’ve been conducting a bit of a review of available devices, and their merits and shortcomings in the role discussed here. I’ve also stumbled on the email list exchange between you and Grant over the design of the Sensors board, very interesting and informative too.
What’s especially noteworthy, as you highlight, is the unusually high probability that these level-translator solutions behave poorly in a “wires hanging off the board” situation, versus their desirable behavior on a board with nice short well-routed traces.
That said, a few notes:
> “All the chips I tried… have one-shots”.
I don’t think the PCA9306 has edge accelerator one-shots. Actually, I think the PCA9306 should be quite close to the BSS138s in behavior, so long as attention is paid to the pin connection details that set the bias on the FETs’ gates (and which should give it larger logic margins).
> “I tested the following…”
From a static DC analysis point of view, the PCA9306 and the TXS series are the only ones that should have a chance of working for I2C. The TXB and similar MAX3000/1 should not, and their datasheets say they should not.
I would also point out that the TXS0108, intended for I2C or at least open drain, has a particularly aggressive edge-acceleration scheme, accelerating both edges, not just the rising edge as in the seemingly same-family TXS0102 and 0104.
> “Side note: The TXB works fine for I2C (as long as cables are short)”
Are you sure it was the TXB? That seems counterintuitive judging from the circuitry. Perhaps you meant the TXS?
