onioniot / i2c-exp-driver Goto Github PK

Create a mechanism for output verbosity

Needs to include mechanism for json output as well

I want to use the function i2c_writeBuffer(int devNum, int devAddr, int addr, uint8_t *buffer, int size) to talk to an I2C device. However, the function copies one-byte too much into the malloc-ed buffer, thus causing a potential heap corruption and other problems.

int i2c_writeBuffer(int devNum, int devAddr, int addr, uint8_t *buffer, int size)
{
	int 	status;
	uint8_t *bufferNew;

	// allocate the new buffer
	size++;		// adding addr to buffer
	bufferNew 	= malloc( size * sizeof *bufferNew );

	// add the address to the data buffer
	bufferNew[0]	= addr;
	memcpy( &bufferNew[1], &buffer[0], size * sizeof *buffer );

 	// perform the write
 	status 	= _i2c_writeBuffer(devNum, devAddr, bufferNew, size);

 	// free the allocated memory
 	free(bufferNew);

	return (status);
}

Say the function is called with size = 3. Then, size will be incremented by one to 4 and bufferNew will be a 4-byte buffer on the heap. The first byte is filled with the address. But then, memcpy( &bufferNew[1], &buffer[0], size * sizeof *buffer ); will again copy size = 4 bytes starting at &bufferNew[1] into the buffer. This is an off-by-one, since it goes 1 byte beyond the size of the buffer. It ought to copy size - 1 bytes (the original value of the size parameter) instead.

Currently there is on readBytes(deviceAddr, addr, numBytes) -> [values] method.
It makes impossible to implement some I2C chip protocols. e.g. https://s3.amazonaws.com/controleverything.media/controleverything/Production%20Run%205/10_SI7006-A20_I2CS/Datasheets/Si7006-A20.pdf

There should be something like read(deviceAddr: int, numBytes: int) -> [values] or read(deviceAddr: int, [args]: int[], numBytes: int) -> [values]

Please, add config structure or function for change I2C address.
Now I2C address is define PWM_I2C_DEVICE_ADDR 0x5A, but in my hardware PWM is 0x40 address.
I can't understand how compile src PWM for Omega2.

If use the draw command in oled-exp without specifying the values for all the pixels, the undefined pixels take random values. I'm running this command:

./oled-exp -i draw "data:ffffffff00000000ffffffff00000000ffffffff00000000ffffffff00000000ffffffff00000000ffffffff00000000ffffffff00000000ffffffff00000000ffffffff00000000ffffffff00000000ffffffff00000000ffffffff00000000ffffffff00000000ffffffff00000000ffffffff00000000ffffffff00000000"

The expected result is this:

What I actually get is this:

I don't know what region of the memory is printed on the random pixels. Would be funny to convert that in the password entered in the last instance of ssh. 😸

Calls to functions like i2c_writeBytes or i2c_readRaw never return an error value (EXIT_FAILURE), although no device is connected to the bus. When using i2c_readRaw, the function fills the receive buffer with all 0xff and returns EXIT_SUCCESS when no device is present. Thus a userspace program cannot determine if the returned data is really 0xff or if the device just isn't there.

Feature request: The function should return an error value of the I2C subsystem doesn't read the ACK bit in any read/write operation.

After installing gcc, make, git, and python-dev on Omega2+ booting from SD card, the Python "setCursor()" function fails, with the following message:

IOError: I2C transaction failed.

The command-line and C versions set row correctly, but not column. No error is returned.

I am not getting new line character working python module?

The following still displays text on single line of OLED display expansion (with \n characters removed)

Was looking at source and only thing i can figure is that you are not getting right value for the total number of characters in the row when you go to print spaces?

Actually while writing this i found the problem in oled-exp.h
OLED_EXP_CHAR_COLUMNS
OLED_EXP_CHAR_COLUMN

I'll submit issue on github

from OmegaExpansion import oledExp
                              
msg = "test\nFrom\n\n\nPython"
                              
status  = oledExp.driverInit()                        
                  
oledExp.clear()   
                  
oledExp.write(msg)

I have configured a SD card for local storage, installed gcc, make, git, git-http, libcurl, ca-certificates, ca-bundle, python-dev then cloned this repo and executed make. Error is as follows:

root@Omega-17FD:~/i2c-exp-driver# make
CC: gcc
CFLAGS: -g
LDFLAGS:
LIB:
 gcc -g  -I include -I/usr/include/python2.7 -c -o build/lib/onion-debug.o src/lib/onion-debug.c
 Compiling lib/liboniondebug.so
gcc -shared -o lib/liboniondebug.so  build/lib/onion-debug.o
/usr/bin/ld: build/lib/onion-debug.o: relocation R_MIPS_HI16 against `__gnu_local_gp' can not be used when making a shared object; recompile with -fPIC
build/lib/onion-debug.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
make: *** [makefile:117: lib/liboniondebug.so] Error 1

If you change the makefile line from

CFLAGS := -g # -Wall

to

CFLAGS := -g -fPIC # -Wall

it works. Just thought I'd let you know about this issue.

When performing reads and writes the buffer is often cleared by performing a memset. the driver assumes a buffer of 32 bytes and always performs
memset( buffer, 0, I2C_BUFFER_SIZE );

If the user supplies a smaller or bigger buffer, this could not have the intended effect. For a smaller buffer this can overwrite memory past the end of the supplied buffer, thus causing a segmentation fault.

Rather use the nbytes parameter and only perform a memset on the length of the buffer provided.

I came across a problem with the oled-exp cursor command:
When I run the following expression (via ssh):

oled-exp cursor 2,5 write "test"

I get the following (expected) output:

> Setting cursor to (2, 5)
> Writing 'test' to display

but on the display, the text is displayed at position 2,0.

This happens on every use of the cursor command for me, not only on row 2. Looks like setting the column isn't working at all.

Nowhere in the code is it mentioned that I2C write calls of up to only 64 bytes are allowed -- all bigger transfers will fail with error message

onion-i2c:: write issue for register 0x01, errno is 122: Not supported

Debug output from your liboniondebug when such a write is requested:

onion-i2c:: writing buffer:
        buffer[0]: 0x01
        buffer[1]: 0xab
        buffer[2]: 0xab
        buffer[3]: 0xab
        buffer[4]: 0xab
        buffer[5]: 0xab
        buffer[6]: 0xab
        buffer[7]: 0xab
        buffer[8]: 0xab
        buffer[9]: 0xab
        buffer[10]: 0xab
        buffer[11]: 0xab
        buffer[12]: 0xab
        buffer[13]: 0xab
        buffer[14]: 0xab
        buffer[15]: 0xab
        buffer[16]: 0xab
        buffer[17]: 0xab
        buffer[18]: 0xab
        buffer[19]: 0xab
        buffer[20]: 0xab
        buffer[21]: 0xab
        buffer[22]: 0xab
        buffer[23]: 0xab
        buffer[24]: 0xab
        buffer[25]: 0xab
        buffer[26]: 0xab
        buffer[27]: 0xab
        buffer[28]: 0xab
        buffer[29]: 0xab
        buffer[30]: 0xab
        buffer[31]: 0xab
        buffer[32]: 0xab
        buffer[33]: 0xab
        buffer[34]: 0xab
        buffer[35]: 0xab
        buffer[36]: 0xab
        buffer[37]: 0xab
        buffer[38]: 0xab
        buffer[39]: 0xab
        buffer[40]: 0xab
        buffer[41]: 0xab
        buffer[42]: 0xab
        buffer[43]: 0xab
        buffer[44]: 0xab
        buffer[45]: 0xab
        buffer[46]: 0xab
        buffer[47]: 0xab
        buffer[48]: 0xab
        buffer[49]: 0xab
        buffer[50]: 0xab
        buffer[51]: 0xab
        buffer[52]: 0xab
        buffer[53]: 0xab
        buffer[54]: 0xab
        buffer[55]: 0xab
        buffer[56]: 0xab
        buffer[57]: 0xab
        buffer[58]: 0xab
        buffer[59]: 0xab
        buffer[60]: 0xab
        buffer[61]: 0xab
        buffer[62]: 0xab
        buffer[63]: 0xab
        buffer[64]: 0xab
onion-i2c:: write issue for register 0x01, errno is 122: Not supported

The used function was i2c_writeBufferRaw.

Could this transfer size also be increased? Some chips (e.g. I2C to SPI bridges) will allow for higher transfer sizes (in that case, 200 bytes). With the 64 byte limit that would take 4 I2C write calls instead of one if the limit was higher.

Hello. I'm trying to communicate with an I2C accelerometer(MMA8452Q) but im having problems getting a response.

I plugged an oscilloscope and I found that there is an "idling" (or bus pulling up) that is way too long and makes the accelerometer communication timeout or something.

I have done it via the terminal and via python(with python the idling is even worse)

I tried the same request with an Arduino and worked fine. The only difference I can see is the "idling"

Does anyone has an idea about this problem or a workaround?

Thank you very much.

I am reading the register 0x0D and the device address is 0x1D
< i2cget -y 0 0x1D 0x0D >

THE BOTTOM ONE IS THE ARDUINO WITH THE CORRECT RESPONSE

there is an image about this on this post http://community.onion.io/topic/2711/i2c-timming-problems

thank you very much!

Just updated from b234 to b236, now the Image function of the OLED Expansion Control of the Control Panel displays the image in a torn, skewed manner. It worked correctly in b234. Worked correctly in b234.

I'm connecting the LCD Display with Onion omega. But i have a issue:

"ImportError: Error relocating /usr/lib/python2.7/OmegaExpansion/onionI2C.so: i2c_writeBufferRaw: symbol not found"

Could you please tell me a solution for my issue, thank you!

Hello,

I seem to be unable to find any instructions to build the driver for use with python3. Is there any available out there, or should it be created ?

I'm facing a very annoying issue when I try to fill manually the display with custom contents using the following command:

oled-exp -i draw "data:ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff"

The output is this:

> Initializing display
Segmentation fault