[beagleboard] Re: I2C Read with length in the first byte of the transaction

Sounds like another goofy TI I2C (USB-C part?) slave interface. Two thoughts ... Is the part smart enough to send a "STOP" after it has transferred the (variable) length read? Or does it just keep going? If the part is smart enough to send a stop when it is done, wrap an error handler around

[beagleboard] Re: I2C Read with length in the first byte of the transaction

Looking at the driver at: https://github.com/torvalds/linux/blob/master/drivers/i2c/busses/i2c-davinci.c It looks like i2c_davinci_isr() only terminates a read via terminate_read() which doesn't seem to have an exit path for completion without STOP. It would be nice if somebody with more

Re: [beagleboard] I2C Read with length in the first byte of the transaction

Erm, unless you mean board. I'm using a Beaglebone Black Rev C running debian. uname -a Linux beaglebone 4.9.36-ti-r46 #1 SMP PREEMPT Tue Jul 11 21:05:08 UTC 2017 armv7l GNU/Linux On Monday, February 12, 2018 at 5:07:37 PM UTC-8, Wulf Man wrote: > > what part > > On 2/12/2018 6:03 PM, Andrew

Re: [beagleboard] I2C Read with length in the first byte of the transaction

Under NDA. So, not in linux database. On Monday, February 12, 2018 at 5:07:37 PM UTC-8, Wulf Man wrote: > > what part > > On 2/12/2018 6:03 PM, Andrew P. Lentvorski wrote: > > I'm trying to communicate with an I2C chip which returns the length of the > bytes to be read in the first byte of the

Re: [beagleboard] I2C Read with length in the first byte of the transaction

what part On 2/12/2018 6:03 PM, Andrew P. Lentvorski wrote: > I'm trying to communicate with an I2C chip which returns the length of > the bytes to be read in the first byte of the transaction.  This is > fairly straightforward on most primitive microcontrollers. > > But for the life of me, I

[beagleboard] I2C Read with length in the first byte of the transaction

I'm trying to communicate with an I2C chip which returns the length of the bytes to be read in the first byte of the transaction. This is fairly straightforward on most primitive microcontrollers. But for the life of me, I cannot figure out how to do this on Linux. A "read" always wants to

[beagleboard] [Beaglebone Black] u-boot does not seem to read uEnv.txt

Hello, I am upgrading an embedded platform that uses a Beaglebone black with the Angstrom distribution (kernel 3.8.13). This system uses spidev (as a SPI1 device) I am using the stable branch of the linux kernel (4.9.79). I am following the instructions from http://www.jumpnowtek.com/ to have

Re: [beagleboard] BB-I2C1-PCA9685-00A0.dts

On Mon, Feb 12, 2018 at 11:12 AM, evilwulfie wrote: > Robert. While looking at some I2C-1 dts files i noticed a typo in > BB-I2C1-PCA9685-00A0.dts file > > In the resources list I2C 1 has: > > > "P8.18",/* i2c1_sda */ > "P9.17",

[beagleboard] BB-I2C1-PCA9685-00A0.dts

Robert. While looking at some I2C-1 dts files i noticed a typo in BB-I2C1-PCA9685-00A0.dts file In the resources list I2C 1 has:     "P8.18",    /* i2c1_sda */     "P9.17",    /* i2c1_scl */ sda should be P9.18 just thought i should let you know -- For more

Re: [beagleboard] Speedtest-cli headache on BB black

Just for the interest of anyone reading, the issue appears to have been isolated to either the syncronous line or the Draytek Vigor. The over weekend test on a vDSL with an ASUS router returned a useful and sensible result without issue or fuss so fairly confident of the source, readers