This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

I2C

hi to all from last two 3 day's i strucked with some the problem. i have already done the i2c routine for AT24c04. Which works fine i can read from that and can write in. now i am going to use the LCD and printing the string on that i also developed small VB6 application to send the string to LCD. now what i tring to do the string which i passing from PC should be printed to LCD and to be stored in EEPROM. But the problem is that the string is printing on LCD but not get stored to EEPROM.
EX.ABCDEFGHIJKLMNOP is the string which i pass to LCD it properly printing on LCD.but not get stored in EEPROM. When i read EEPROM it show's me the A C D F H J L N P these parameter get stored in eeprom.
before this project i have complited lot much EEPROM contain instrument in which i can READ and WRITE EEPROM Without any problem.and still working so nicely.
canany one tell me what is the peoblem.

Parents
  • By some happy coincidence, you just happen to have had parts just at the "right" ends of their tolerance spans so that your timings just happened to work.

    I call this the "Proven-Product" Syndrome.
    love that name.

    anyhow, there is another case of the "Proven-Product" Syndrome which is that something works because some routine unrelated to where the design error is happens to be fast enough or slow enough to hide the design error. Then when something is changed in another part of the code or some change in input happens BOOM! the design error show up. I have experienced that some, when this happens, work night and day on the code they changed simply because they were blind to the cause being in code they did not change.

    Erik

Reply
  • By some happy coincidence, you just happen to have had parts just at the "right" ends of their tolerance spans so that your timings just happened to work.

    I call this the "Proven-Product" Syndrome.
    love that name.

    anyhow, there is another case of the "Proven-Product" Syndrome which is that something works because some routine unrelated to where the design error is happens to be fast enough or slow enough to hide the design error. Then when something is changed in another part of the code or some change in input happens BOOM! the design error show up. I have experienced that some, when this happens, work night and day on the code they changed simply because they were blind to the cause being in code they did not change.

    Erik

Children
  • If you found one timing error check all the code.
    I had the same issues years back. Also with an I2C EEPROM. Except it worked for over 3 years. The "Good" and "bad chips back to the manufacturer. I was told the "Good" chip exceeded the timing spec. while the "bad" chip was in the middle.

  • I agree. Testing alone is not adequate assurance that the product really works. You need design and review and analysis to know that it works, as well as testing. The more independent "guarantees" you have, the less likely it is that you screwed them all up at once.