Author Topic: I2C control  (Read 4722 times)

Offline hervé

  • Jr. Member
  • **
  • Posts: 98
    • View Profile
I2C control
« on: March 12, 2010, 12:08:49 PM »
Hello,

I use I2c for onboard component and it works fine.

I plan to use it with external PIA (8254 type) controlling a keyboard/display pad.
I send a command to the PIA but I don't know if it is connected or not :
"the function  (!fnWrite(MODAPortID, (unsigned char *)ucTramePIA, sizeof(ucTramePIA))) always reply OK."
How can I manage to see that there is no I2C component connected at this address?

The purpose is to test when keyboard/display are hot plugged so I can initialize them.
 
Thank.

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3188
    • View Profile
    • uTasker
Re: I2C control
« Reply #1 on: March 12, 2010, 02:06:38 PM »
Hi Hervé

The I2C driver is designed for applications where the I2C device is integrated in the board - that means that it assumes that the device is always operational.

When you send data you will not receive information about whether the device is connected or not.

When you read data you can often use the returned data content to distinguish between a device answering correctly or a device not being connected, but this also depends on the device type that is being used. If reading a parallel input you may not be able to reliably distinguish it.

The best method to detect whether the device is connected or not is to see whether the device acknowledged its bus address. Although this is not actually used by the driver it is not difficult to add - but does depend on the processor being used exactly how it is recognised.

In the case of the LPC there is a case which detects this:

    case MASTER_TX_DATA_NOT_ACKED:                                       // (0x30) a byte of data has been sent but was not acked

This is treated as an acknowledge so that the output buffer can be completely sent - on the I2C bus, data will still be transmitted even if the slave doesn't respond. A simple method to quickly use this is to let this case continue doing what it does but set a transmission error flag. When you send the message you can also get the driver to wake a transmitter task so that it knows that the transmission has completed - it can check this flag to see whether the slave is actually present or not and then reset it for next use.

Regards

Mark




Offline hervé

  • Jr. Member
  • **
  • Posts: 98
    • View Profile
Re: I2C control
« Reply #2 on: March 15, 2010, 06:31:16 PM »
Hi Mark,

Thanks a lot for your prompt reply.
It works fine and knox I got plugin-detection of mys pads....

This not so difficult when you explain it.

Offline hervé

  • Jr. Member
  • **
  • Posts: 98
    • View Profile
Re: I2C control
« Reply #3 on: March 17, 2010, 04:15:45 PM »
For this issue I also got a problem with dynamic allocation of I2C drivers.
When I plug an I2C module, I can detect it and do something like that :
Code: [Select]
if((adc.modA_status==MOD_I2C) && (MODAPortID==0)){
    tIICParameters.Channel = MODA_IIC_CHANNEL;
    MODAPortID = fnOpen( TYPE_IIC, FOR_I_O, &tIICParameters); // open the channel with defined configurations
}

When I unplug it (to plug another sort of module) I wanted to shut down the corresponding MODAPortID driver.
But I did not found any fnClose()....

Is it normal?
What is the best way to free the corresponding buffer ?
Can I use fnFreeBuffer() ? Is it enough ?

Regards

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3188
    • View Profile
    • uTasker
Re: I2C control
« Reply #4 on: March 17, 2010, 04:33:11 PM »
Hi Hervé

Generally there is no real need to uninstall drivers in small embedded systems and that is the reason why there is no close().

In your case, the I2C interface is not specific to any device so you can simply continue using the existing handle for other things if the plug-in detection is negative. When you open the driver ensure that it is opened with the buffer size adequate for its largest use.

Regards

Mark