onioniot / i2c-exp-driver

Driver to program I2C based Onion Expansions

i2c-exp-driver

Project for drivers to program Omega Expansions that are I2C-based.

ubus Integration

The drivers for the I2C-based Onion Expansions have been integrated with the ubus service via RPCD. They can be accessed through the i2c_exp service.

pwm-exp ubus Commands

The Servo Expansion can be programmed using the pwm-exp command in the i2c_exp ubus service:

ubus call i2c_exp pwm-exp '{"command":"String", "params": {"key": "value" } }'

The following commands are available:

• init
• sleep
• set
• set-period

Init Command

The init command will reset the chip on the Servo Expansion and enable the oscillator.

ubus call i2c_exp pwm-exp '{"command":"init"}'

Sleep Command

The sleep command will put the oscillator into sleep mode, disabling all PWM signals

ubus call i2c_exp pwm-exp '{"command":"sleep"}'

Set Command

The set command is used to generate a PWM signal on a specific channel based on a duty cycle percentage:

ubus call i2c_exp pwm-exp '{"command":"set", "params":{"channel":"<CHANNEL>", "duty":"<DUTY CYCLE>"} }'

The CHANNEL can be:

• 0 - 15
  • control an individual channel
• all
  • control all channels at once

The DUTY CYCLE can be an integer or floating point number between 0 and 100

Optional parameters:

• "frequency":"<signal frequency>"
  • Sets the PWM signal frequency
  • If not specified, default of 50 Hz is used
  • Frequency range is 24 Hz to 1526 Hz
• "delay":"<delay percentage>"
  • Adds a delay in the PWM signal, can be an integer or floating point number between 0 and 100
  • 0% delay by default

Set-Period Command

The set-period command is used to generate a PWM signal on a specific channel based on a PWM period and pulse width (both can be integer or floating point numbers):

ubus call i2c_exp pwm-exp '{"command":"set-period", "params":{"channel":9, "pulse":"1.5", "period":20}}'

relay-exp ubus Commands

The Relay Expansion can be programmed using the relay-exp command in the i2c_exp ubus service:

Set Command

The set command allows for programming the relay state:

ubus call i2c_exp relay-exp '{"command":"set", "params":{"channel":"<CHANNEL>", "state":"RELAY STATE", "address":"<ADDRESS>"}}'

The CHANNEL can be one of:

• 0 - controls Relay0
• 1 - controls Relay1
• all - controls both relays

The RELAY STATE can be one of:

• off - relay is switched off
• on - relay is switched on

The ADDRESS argument can be either:

• The DIP-SWITCH STATES
• The Hex I2C device address

Dip Switch States

The DIP-SWITCH STATES should reflect the dip switch settings in binary starting with switch 1, then switch 2, then switch 3. The 0 position is when the switch is close the numbers.

Not required when all switches are 0.

Examples:

• Switches 1 and 2 are 0 (close to the printed numbers), switch 3 is 1:
  • "address":"001"
• Switches 1 and 3 are 1, switch 2 is 0:
  • "address":"101"
• All switches are 1:
  • "address":"111"

I2C Device Address

The I2C Device Address should be just the hex address.

For example:

• 0x27
• 0x23

Get Command

The get command implements reading the current state of a relay:

ubus call i2c_exp relay-exp '{"command":"get", "params":{"channel":"<CHANNEL>", "address":"<ADDRESS>"}}'

The CHANNEL can be one of:

• 0 - controls Relay0
• 1 - controls Relay1

The ADDRESS argument can be either:

• The DIP-SWITCH STATES
• The Hex I2C device address

Dip Switch States

The DIP-SWITCH STATES should reflect the dip switch settings in binary starting with switch 1, then switch 2, then switch 3. The 0 position is when the switch is close the numbers.

Not required when all switches are 0.

Examples:

• Switches 1 and 2 are 0 (close to the printed numbers), switch 3 is 1:
  • "address":"001"
• Switches 1 and 3 are 1, switch 2 is 0:
  • "address":"101"
• All switches are 1:
  • "address":"111"

I2C Device Address

The I2C Device Address should be just the hex address.

For example:

• 0x27
• 0x23

Return Values

The ubus call will return different values based on if the command was successful or not.

Successful Command:

{"status":"success", "channel":"<CHANNEL>, "state":"<RELAY STATE>"}

Unsuccessful Command:

{"status":"success", "error":"<INFO ON ERROR>"}

oled-exp ubus Commands

The OLED Expansion can be programmed using the oled-exp command in the i2c_exp ubus service:

Set Command

The only command is the set command, it allows the relays to be programmed:

ubus call i2c_exp relay-exp '{"command":"set", "option":"opt" "params":{"<COMMAND>":"<COMMAND PARAMETER>}}'

Options

Available options are

• i
  • Initialize the display, this must be done at powerup
• c
  • Clear the screen and set the cursor to the top left"

Example Usage:

• Initialize the display
  • ubus call i2c_exp oled-exp '{"command":"set", "option":"i"}}'
• Clear the display and then write Onion Omega to it
  • ubus call i2c_exp oled-exp '{"command":"set", "option":"c", "params":{"write":"Onion Omega"}}'

Commands

The following are the commands and their parameters as accepted by the oled-exp:

• power <on|off>
• invert <on|off>
• dim <on|off>
• cursor <row>,<column>
• write <msg>
• scroll <direction>
• draw <lcd file>

Commands can be strung together!

Power

Turn the display on or off. Can be used to toggle the display after it has been initialized.

"params":{"power":"<on|off>"}

Invert

Invert black and white on the display. Setting to on will enable the invert, setting to off will disable the inversion.

"params":{"invert":"<on|off>"}

Dim

Enable dimming the display. Setting to on will dim the display, setting to off will restore the default brightness.

"params":{"dim":"<on|off>"}

Cursor

Set the cursor position on the display.

The row parameter represents each character row (8 pixel rows) on the display, so the range is 0 to 7

The column parameter represents each character column, the range is 0 to 20

"params":{"cursor":"<row>,<column>"}

Examples

Set the cursor to the start of the last character row:

"params":{"cursor":"7,0"}

Set the cursor to the middle of the 4th character row:

"params":{"cursor":"3,10"}

Set the cursor to the start of the 2nd character row:

"params":{"cursor":"1,0"}

Set the cursor to the top left (home position):

"params":{"cursor":"0,0"}

Write

Write a string to the display.

"params":{"write":"<message>"}

Notes

To get a newline on the display, need to write \\\\\n in the message.

For now, avoid the following characters:

• "
• '

Examples

Write Onion Omega to the display:

"params":{"write":"Onion Omega"}

Write Onion Corporation and then the office address on the lines below:

"params":{"write":"Onion Corporation\\\\\n187 Denison St\\\\\nMarkham, ON\\\\\nCanada\\\\\nL3R-1B5"}

Scroll

Enable scrolling of whatever is currently on the display.

"params":{"scroll":"<direction>"}

Directions

Available directions:

• left
• right
• diagonal-left
• diagonal-right
• stop
  • To disable scrolling

Draw

Display an image from an LCD file on the display.

Details on LCD file: The LCD file must be generated by the Onion utility. For a 128x64 image, there should be 1024 bytes. Each byte is one character column (8 vertical pixels), with the LSB representing the top-most pixel.

"params":{"draw":"<path to lcd file>"}

i2c-exp-driver's Issues

I2C functions never return an error

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.

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

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!

Off-By-One Error in i2c_writeBuffer

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.

Instructions on how to build/install for Python 3

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 ?

Image skewed by OLEC Expansion Control of Control Panel after b236

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.

Compilation error: recompile with -fPIC

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.

Omega I2C driver misses reading without defining register address

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]

Timming issues

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!

setCursor() function in Python module returns "I2C transaction failed."

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.

oled-exp draw command fills the screen with random pixels in the undefined zones.

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. 😸

Document maximum I2C transfer size of 64 bytes

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.

Output Verbosity

Create a mechanism for output verbosity

Needs to include mechanism for json output as well

oled-exp segmentation fault when using the draw command

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

Problem with oled-exp cursor command

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.

Change I2C address

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.

I2C driver causing segmentation fault in onion-i2c.c

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.

OLED_EXP_CHAR_COLUMN not OLED_EXP_CHAR_COLUMNS

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)