Shop OBEX P1 Docs P2 Docs Learn Events
I2C Object — Parallax Forums

I2C Object

Does anyone have an I2C serial object available for the P1? I need to communicate with an I2C ADC.

Comments

  • Welcome to the forums!

    Which device? May be in the OBEX ZIP file which I can give you.
  • Here are the first two I found.
    The two copyrights are listed as:
    2010 Dave Hein
    2014 Chris Gadd

    I don't think these have clock stretching options. I'm pretty sure I wrote an I2C driver which uses clock stretching so if you need that feature, let me know and I'll try to find a working version of my driver.
  • JonnyMacJonnyMac Posts: 8,912
    edited 2020-09-04 03:14
    I'll add to the pot. One of these is Spin only, the other is PASM so it's fast, but uses a cog. Both have been deployed in several commercial products.
  • Thanks for the quick reply. I'm using a Texas Instruments ADC081C021/ADC081C027.

    I greatly Appreciate it all!
  • Thanks for the quick reply. I'm using a Texas Instruments ADC081C021/ADC081C027.

    I also need to write a few of my veriable to the epprom, to save for a power cycle so I can retain the data. Are these the best I2C to use for this too? Looked like I saw some post referring to one thats designed to work with the epprom.
  • As long as the I2C routines wait for a device ack when they are being addressed, then it should work fine for writing to the EEPROM. Once the EEPROM has received a stop condition following a write, it will be busy erasing and programming that byte or page. During that time the device will not acknowledge if it is addressed, which is the recommended way to handle writes. The other simple way is just to wait for at least 5ms but that blocks code from doing other things.

    Anyway, if JM recommended it, why question it as if "someone" else's opinion would be accepted over what works?
  • msrobotsmsrobots Posts: 3,701
    edited 2020-09-14 03:08
    There is a very neat concept to save variables of your program into the EEPROM.

    If you have a Variable in a DAT section the address of the Variable in HUB is also the address of the Variable in EEPROM.

    so a i2c.write(@myVar, myVar) will store your value at exact the same location the spin compiler put myVar in the EEPROM while programming.

    And at the next reboot you have your new value there.

    While programming the EEPROM the P1 uses a checksum to confirm the EEPROM is valid, while booting from the EEPROM the checksum is not checked.

    Easy to handle, except your settings get lost when you overwrite your EEPROM with a newer version of your program.

    Most Parallax boards have 64K EEPROMS (careful, not all), but just the first 32K are used (and overwritten) while programming. So if you need settings survive reprogramming you will need to use EEPROM addresses above 32K.

    And just use @JonnyMac's objects he posted, can't go wrong

    Mike
  • I designed and coded a laser tag controller that consists of three applications: configuration, player, and referee. Settings for the device are held in the upper 32K of the EEPROM so that the applications (read from a binary file on the SD into the EEPROM).

    As Mike points out, if you use the variable save approach those values will be wiped out if the program is updated. Values saved in the upper EE will persist between downloads, but require extra code to move between the upper EE and the application.
Sign In or Register to comment.