Re: [beagleboard] Re: I²C reads on broken out bus #1 always return 0

Torsten: Great job. --- Graham == On Mon, May 29, 2017 at 9:32 AM, 'Torsten K.' via BeagleBoard < beagleboard@googlegroups.com> wrote: > FYI: It's working now. The PIC code that came with the motor controller > was not I²C re-start aware. > > I re-implemented the ISR to accept both stop/start

[beagleboard] Re: I²C reads on broken out bus #1 always return 0

FYI: It's working now. The PIC code that came with the motor controller was not I²C re-start aware. I re-implemented the ISR to accept both stop/start and re-start sequences before reading the slave's output. That did the trick. Best, Torsten -- For more options, visit

[beagleboard] Re: I²C reads on broken out bus #1 always return 0

Status Update (a bit off topic for beagleboard, I suppose): I took the MPLABX PIC code that the PiBorg folks provided for their motor controller and ported it to the sdcc compiler, so I have a chance to understand what's going on. Result is here: https://github.com/tkurbad/PicoBorgRev_PIC If

Re: [beagleboard] Re: I²C reads on broken out bus #1 always return 0

Hi Graham, Am Montag, 15. Mai 2017 18:39:10 UTC+2 schrieb Graham: > > When they say drop the clock speed on the bus, I am sure they mean to drop > it down to 50kbps or 10 kbps, and see if it starts working. > As a diagnostic, that would be strong indication of a timing problem in > the PIC

Re: [beagleboard] Re: I²C reads on broken out bus #1 always return 0

When they say drop the clock speed on the bus, I am sure they mean to drop it down to 50kbps or 10 kbps, and see if it starts working. As a diagnostic, that would be strong indication of a timing problem in the PIC software. If they are using the PIC hardware peripheral, then it is totally I2C

Re: [beagleboard] Re: I²C reads on broken out bus #1 always return 0

What part number PIC? --- Graham == On Mon, May 15, 2017 at 9:36 AM, 'Torsten K.' via BeagleBoard < beagleboard@googlegroups.com> wrote: > Hi Graham, > > just for reference: The guys who built the motor controller confirmed that > they are having trouble with newer kernels on the Raspberry PI,

Re: [beagleboard] Re: I²C reads on broken out bus #1 always return 0

Hi Graham, just for reference: The guys who built the motor controller confirmed that they are having trouble with newer kernels on the Raspberry PI, too. https://www.piborg.org/node/2428 They say it's probably a timing issue. And with all the information I collected so far I must assume they

Re: [beagleboard] Re: I²C reads on broken out bus #1 always return 0

Torsten: OK. That makes more sense. If it is a PIC misbehaving, I would re-program it first, then make sure you have good bypass capacitor to ground, with short leads, on the power input pin to the ground pin on the PIC. Good luck. --- Graham == On Monday, May 15, 2017 at 3:59:03 AM

Re: [beagleboard] Re: I²C reads on broken out bus #1 always return 0

Hi again, this morning, I connected another IMU unit (Polulu AltIMU10 v5) in parallel to the motor controller on I²C bus #1. It works flawlessly and I can read the ID of the accel/gyro unit using i2cget: tkurbad@beaglebone:~/projects/mipSIE/python3$ i2cget -y 1 0x6b 0x0f 0x69 However, I still

Re: [beagleboard] Re: I²C reads on broken out bus #1 always return 0

Hi again, Do you have another "trusted" I2C device you could parallel across the bus > as a test device? > I use an MCP9808 temperature sensor on most of my boards when bringing up > a new design. > I think I'll do that on Monday, when I'm near my Beaglebone again, Or as suggested by David,

Re: [beagleboard] Re: I²C reads on broken out bus #1 always return 0

On Fri, May 12, 2017 at 9:44 AM, Graham Haddock wrote: > I take back what I said about a non standard read sequence. I re-read the > data sheet, and they describe a standard concatenated write/read sequence > for a single byte read. But I do note that they do not describe

Re: [beagleboard] Re: I²C reads on broken out bus #1 always return 0

I take back what I said about a non standard read sequence. I re-read the data sheet, and they describe a standard concatenated write/read sequence for a single byte read. But I do note that they do not describe a simple read only sequence, where the part would start reading from the last

Re: [beagleboard] Re: I²C reads on broken out bus #1 always return 0

On 05/12/2017 10:48 AM, 'Torsten K.' via BeagleBoard wrote: So, I'm still convinced that it has to do with the hardware and/or the setup of the I²C bus of the beaglebone... Where else could I look? Have you stuck an oscilloscope or logic analyzer on it to see what is actually on the bus?

Re: [beagleboard] Re: I²C reads on broken out bus #1 always return 0

Hi Graham, Am Freitag, 12. Mai 2017 17:05:55 UTC+2 schrieb Graham: > > It looks like the MPU9250 has a non standard (to my way of thinking) I2C > read sequence that requires you to resend the register address as part of a > consolidated write/read sequence. The default tool i2cget does not

Re: [beagleboard] Re: I²C reads on broken out bus #1 always return 0

It looks like the MPU9250 has a non standard (to my way of thinking) I2C read sequence that requires you to resend the register address as part of a consolidated write/read sequence. The default tool i2cget does not deal with this, and only deals with simple (standard to my way of thinking) read

[beagleboard] Re: I²C reads on broken out bus #1 always return 0

Update: I lowered the clock frequency of i2c1 to 100kHz via the dtb. That also doesn't change the behaviour. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this

[beagleboard] Re: I²C reads on broken out bus #1 always return 0

Hi Graham + William, thank you for getting back to me so quickly. The device I'm trying to communicate with is this motor controller: https://www.piborg.org/picoborgrev/specs It's made for the Raspberry PI, but I don't see any reason for it not to work with the Beaglebone Blue. With the help

Re: [beagleboard] Re: I²C reads on broken out bus #1 always return 0

> On Thursday, May 11, 2017 at 11:44:40 AM UTC-5, Torsten K. wrote: >> >> >> Hi, >> >> two weeks ago I received my BeagleBone Blue. >> >> So far, I've managed to get >> >> - an OrangeRX DSMX receiver >> - a GP-735T GPS receiver >> - a Servo >> - and a 2S LiPo Akku >> >> going, more or less

[beagleboard] Re: I²C reads on broken out bus #1 always return 0

If you are successfully sending I2C commands, then everything is hooked up correctly, and the device tree is properly configured. I2C is a bi-directional bus. If it works in one direction, then it has to work in the other direction down at the hardware level. How are you "reading" the I2C