Tic T825 control with Matlab via I2C


I am driving a stepper motor with the Tic T825 connected to the I2C pins of an Arduino uno board. I am developing a Matlab-based GUI as I need some level of dynamic control and user input to the system alongside feedback from a pressure sensor.

In matlab it is possible to write to the I2C device by first creating the appropriate I2C object I2Cobj and then using the command

write(i2Cobj, writecommand, ‘precision’)

In order to properly function with the TIC the writecommand needs to be formatted as an array of bytes. for example

write(i2Cobj, [0xE3 0x00 0x00 0x00 0x00], uint8)

sets target velocity to 0

The issue pops up when trying to send such a 32-bit command to the Tic, such as the example above to set target velocity (or similarly target position).

Matlab needs to use the uint8 format in order to properly send 0xE3, since the value is outside the range of the int8 format. Yet if using uint8 only positive values of velocity and positions are accessible.

Since the write command autmatically handles the I2C communication and the address of the device, it is not possible to split the command into a uint8 0xE3 and an int8 value as it would re-send the S Addr+W, resetting the start of the command.

Does anyone have a suggestion on how to address this?

I understand possible workarounds exist including setting a 0 position so that every useful value is positive and using the command-line program to send commands over USB, but for the best possible setup with low latency, controlling with I2C through the arduino is the preferred solution.

I am not sure I understand why you think you cannot send negative target values if you use uint8. When sending a negative target value you should use the two’s complement representation of it. So, for example, here is a breakdown of the bytes for setting the target velocity to -10000:

11111111 11111111 11011000 11110000
(binary representation of -10000 using two’s complement)

0xFF FF D8 F0
(hexadecimal representation)

Since the data bytes are in little-endian order (starting with the least-significant byte), they would be:

Cmd: 0xE3
data 1: 0xF0
data 2: 0xD8
data 3: 0xFF
data 4: 0xFF