4710EVM : Programmatic Control Capability with Beaglebone Black / Linux

Hello Nadine,

actually even i am trying to make it work with Cypress API...

I have Young Optics 4710 module with UV Led.. and i checked electronics its almost identical(They seperated it in 3 part pcb.. and in Gen2 we have 2 part pcb ).. but all basic communications are same AFAIK.... now they provide us few function in form of SDK 

here is the code 

public class Ddp343x
{
enum CommandType {
WRITE,
READ
}

enum CommandId {
WRITE_LED_ENABLE = 0x52,
READ_LED_ENABLE = 0x53,
WRITE_LED_CURRENT = 0x54,
READ_LED_CURRENT = 0x55,
READ_TEMPERATRUE = 0xd6,
WRITE_PROJCETOR_FLIP = 0x14,
WRITE_PWR = 0xa0,
READ_LIGHT = 0xac
}

CypressI2c mCpressI2c;
public const byte cSlaveAddress7bit = 0x1B;
const String cReadSlaveAddress = "37";
const String cWriteSlaveAddress = "36";
public const byte aSlaveAddress7bit = 0x39;
const String aReadSlaveAddress = "73";
const String aWriteSlaveAddress = "72";

i think we just need to change few address like cSlaveAddress7bit etc....

and yes cypress has linux source code too..

i am just missing address AFAIK...i know they have custom firmware for MSP430.. 

if they can do it with regular 4710 than we can surely do it (With Help of NADINE :))

Thanks,

Regards,

himanshu

We don't care about the GUI. We care about the fact that TI's documentation is misleading. We understand how to talk on the i2c bus - we know that is what is happening. TI's chips are not responding to the commands TI's documentation says they should respond to.

For instance, the documentation says that the slave address should be 36h. Should that not be written as just "36"? or with some other signifier that the quantity is being shown in the decimal value, rather than it's hexadecimal equivalent of 0x1b? If this primary item is written this way - it follows that ALL of the other commands are written out in this fashion (which I would consider wrong, but if it's consistent, then we can work with that). so that a command we want to use, say 52h, should really be written as 0x34. Can you confirm if that's correct? 

We will have trouble verifying this, if we have to repeat this command 5 times (or more, or a random number of times) to get an actual result from the system.

Hey Nadine--
Thanks for your help. We were able to sort some of the issues out thanks to your tip about the GPIOs (which, incidentally, I didn't find in the documentation... just for those who may be interested in improving it :) )

I now have another question if you're able to help answer it -- are there any special instructions for *reading* over I2C that I should be aware of? I'm not sure if the CyI2cRead(...) operation is enough. I seem to be getting mostly zeroes for the address locations that I'm interested in---namely 55h : read LED current---Even though our LED power when read by the GUI is 9501ma.

Please help!