• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 101 subscribers
  • Views 33589 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SCCB vs. I2C

zozi
Intellectual 480 points

Hi,

Recently I got a new imager (Omnivision OV10121) with SCCB interface on itself and I’d like to replace Micron Imager sensor with this one. Problem is that I don’t understand what the difference between SCCB and I2C interfaces is? If I understood it correctly SCCB, in two wire mode, is just simplified version of I2C. Also I found on Omnivision site that imager is equipped with SCCB interface that is compatible with the I2C interface. So does it mean that I can use I2C communication (with same drivers) to setup imager like I used it with Micron Imager (just with different slave address)?

According to information that I have, it’s the same but I’d like ask someone that already did it. Any information/advice on that topic will be appreciated.

  • 0
    TI__Mastermind 41665 points

    Hopefully someone from the community with some more experience with Omnivision sensors can provide some more direct feedback, but it does look to me like SCCB is a clone of I2C. I suspect that this was done to avoid I2C licensing fees, I have seen this with other ICs before where they use a serial protocol that is 'I2C like' but that cannot actually be called I2C without consent from Phillips. I would probably start with the existing I2C driver and see how it works and only start digging into the SCCB protocol and timings if you run into problems with the existing I2C driver.

  • 0 in reply to Bernie Thompson TI
    Genius 3575 points

    I can confirm that you can talk to an omnivision "sccb" device using the I2C.  Seems like there might be a clock limit of 100 kHz for some devices IIRC, I would double check that.

  • 0 in reply to MattLipsey
    Intellectual 480 points

    I'd like to confirm that SCCB works fine with CSL_i2c functions. I'm able to setup OmniVision sensor using SCCB connection(with CSL_i2c functions) on EVM6437.

    Thanks everyone !!!

     

  • 0
    Prodigy 20 points

    >the difference between SCCB and I2C interfaces

    I'm in the situation of trying to work with an Omnivision sensor (SCCB) also, also with an I2C controller (master).  Not sure everything else is worked out but I started looking into the two standards.   There seem to be at least one non-obviously reconciled difference (I'd say it differently, except it seems others have made it work.  Hmm) that I'd value someone commenting on.

    FIrst, I2C specifies pullups drawing >= 3 mA and open collector(drain) drivers everywhere. SCCB specifies regular CMOS-like drivers (i.e. always driven, whether HI or LO) and so, of course, no pullups.    ??  As long as everything works right I guess this isn't a show-stopper, but grr.

    Second, I2C calls the 9th bit ACK, for the otherwise non-data-driving end to pull low to ack.  SCCB calls the 9th bit Don't-Care, and explicitly says in its SCCB Spec AN that it (the master) continues regardless of whether there's an ACK,  The spec describes 2 possible behaviours for slaves during the Don'tCare period.  Either they don't respond by ACKing, or they do. From this, So until I see it happen (ahem, not there just yet) I can't count on my OV imager ACKing to my I2C master.  Grr.  Sounds like OV imagers just might, tho.

    Third, the spec talks about something that is a natural consequence of using drivers instead of open drains--Serial data contention resistors.  It has a whole section number devoted to it but says, in total, "Incorporating series resistors between DIO_D output of the master and the DIO_D input of the slave(s) can avoid short circuits when bus contention occurs.".  Grr.  With noone spec'ing current limits for their TWI I/O that doesn't do me a whole lot of good. 

    Does it make obvious sense to change the TWI hardware like OV did?  I don't think it'd be necessary for patent reasons.  Are there electrical reasons?  When I realized that power in the pullup resistors only flows when LOs are being asserted (i.e. not when the bus is idle) doing it for power savings doesn't seem to make sense.  The only maybe sane reason I can think of is to decrease resistor count, but even then that's iffy.  2 pullups per I2C bus and N protection resistors for SCCB w/N devices.

    Please, comments, especially confirmation that OV slaves do Ack? ___________________Marty

     

  • 0 in reply to Marty14609
    Genius 3575 points

    I will re-confirm my earlier confirmation, that I have successfully communicated with an omnivision sensor using a "standard" I2C setup for a dm6437.  I have no idea why their devices are described as such, whether it is to avoid licensing I2C or just because they don't conform to the full I2C spec.  The TI i2c drivers won't complete an I2C transaction without receiving an ack, so I was definitely receiving an ack.

  • 0 in reply to MattLipsey
    Prodigy 90 points

    I got same problem in DM355. the OV7620 don't have ACK  when DM355 send ID address, so the I2C module always stop send data.

  • 0 in reply to zhenghao chen
    Prodigy 20 points

    zhenghao chen said:

    I got same problem in DM355. the OV7620 don't have ACK  when DM355 send ID address, so the I2C module always stop send data.

    I have to agree w/MattLipsay, the OV products do indeed acknowledge with an ACK.  My problem turned out to be trying to use too low a voltage with for controller.  Upping the voltage just a bit resulted in the controller seeing the first byte ACK and continuing correctly.  I suggest scoping your clock and data lines and see what you see, and maybe upping your voltage a bit.   ____________Marty

     

  • Anonymous
    0 Anonymous in reply to MattLipsey

    Matt,

    Do you talk to OV SCCB using GPIO simulated signal, or using I2C controller of TI devices directly?

     

    Zheng

  • Anonymous
    0 Anonymous in reply to MattLipsey

    Matt,

    I have started a new post on this topic. Could you have a look at it?

     

    Zheng