Other Parts Discussed in Thread: DLPC-API
Tool/software:
Hi everyone,
I use the DLPC-API-1.10.
I run the program dlpc347x.
as known that dlpc347x build in c language, not C#.
To use it, you have no choice but to create cyusbserial.dll and code in C# yourself.
Of course I am in that process too.
If you look at the dlpc347x_samples.c code of dlpc-api 1.10, there is a function called CYPRESS_I2C_ReadI2C, and when this function is converted to C#, it is as follows.
private bool CYPRESS_I2C_ReadI2C(UInt32 ReadDataLength, byte[] ReadData)
{
CY_RETURN_STATUS Status;
CY_DATA_BUFFER ReadBuffer;
ReadBuffer.buffer = ReadData;
ReadBuffer.length = ReadDataLength;
ReadBuffer.transferCount = 0;
//0x071e3c18
Status = CyI2cRead(cy_handle,
ref s_DataConfig,
ref ReadBuffer,
I2C_TIMEOUT_MILLISECONDS);
if ((Status != CY_RETURN_STATUS.CY_SUCCESS) && (Status != CY_RETURN_STATUS.CY_ERROR_IO_TIMEOUT))
{
//printf("Read I2C Error %d!!! \n", Status);
CyI2cReset(cy_handle, false);
CyI2cReset(cy_handle, true);
return false;
}
return true;
}
CY_DATA_BUFFER was declared as follows:
struct CY_DATA_BUFFER
{
public byte[] buffer; // Pointer to the buffer from where the data is read/written
public uint length; // Length of the buffer
public uint transferCount; // Number of bytes actually read/written
}
In the step of getting the initial device ID, the sample code in C can confirm that the value 15 is entered into the buffer.
However, in the C# code, data is not loaded into the buffer.
There is no data in the buffer.
Is there a problem with the data type of the CY_DATA_BUFFER configuration format? or,
in c Code DLPC_COMMON_SendRead follows:
uint32_t DLPC_COMMON_SendRead(uint16_t ReadLength)
{
return s_ReadCommandCallback(s_WriteBufferIndex,
s_WriteBuffer,
ReadLength,
s_ReadBuffer,
&s_ProtocolData);
}
Since I couldn't implement the s_ReadCommandCallback function, I just implemented it as follows.
private uint DLPC_COMMON_SendRead(ushort ReadLength)
{
return ReadI2C(s_WriteBufferIndex, s_WriteBuffer, ReadLength, s_ReadBuffer, ref s_ProtocolData); ;
}
I thought it wouldn't be a big problem since s_ReadCommandCallback is the code that calls ReadI2C anyway. Is this causing a problem?
Thanks.
