Shop OBEX P1 Docs P2 Docs Learn Events
I2CIN and I2COUT — Parallax Forums

I2CIN and I2COUT

basicstampedebasicstampede Posts: 214
edited 2004-08-30 05:15 in BASIC Stamp
I think I read a while ago (not sure where) that the I2CIN and I2COUT was changed on BS2p to work with either traditional I2C parts that has internal addresses or those that don't have internal address such as PCF8574.

Does anyone know what was changed or what this is all about?

Thanks.

Comments

  • Jon WilliamsJon Williams Posts: 6,491
    edited 2004-08-26 02:36
    Up to firmware 1.2, the I2C commands wanted an adress -- at least one byte. V1.3 and a compiler update changed this; now you can have no address byte, one address byte, or two. Version 1.3 also relaxed the timing just a tad so that devices that didn't hold the clock line low while busy still had a chance to succeed.

    By the way ... this is all ancient history....

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Jon Williams
    Applications Engineer, Parallax
    Dallas Office
  • basicstampedebasicstampede Posts: 214
    edited 2004-08-26 11:40
    Jon,

    I must have missed this announcement.· I wasn't even sure that it went from 1.2 to 1.3.·

    By the way, my old BS2p has a light tan PCB, but new BS2p has a much darker tan color.· Is that how I can distinguish the 1.2 vs. 1.3?

    Or is the 1.2 vs. 1.3 referring to the PBASIC compiler?

    And, please point to a document that explains all this in further detail.· I'm especially interested in seeing an example of code using 1.2 and 1.3 version for say PCF8574 or others such as EEPROM.
    Was this on a N&V?· Or is there an updated BS2 manual?

    Thanks.
  • Jon WilliamsJon Williams Posts: 6,491
    edited 2004-08-26 12:46
    Use the Identification function of the editor; it will tell you.

    The color is a non-issue. We get creative with soldermask and on one batch our vendor had a color issue. We decided not to junk a lot of perfectly good modules because of their color (waste not, want not...).

    I did cover this in Nuts & Volts (as we offered free reporgramming at the time), and the documentation section of our web site has a paper that discusses firmware updates.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Jon Williams
    Applications Engineer, Parallax
    Dallas Office
  • Bruce BatesBruce Bates Posts: 3,045
    edited 2004-08-26 12:58
    Jon -

    Is this to imply that re-programming is no longer available, or that it is no longer free, or what IS the policy on upgrading from V1.2 to V1.3?

    In the back of my mind I think I remember seeing a download for the firmware in the software download section of the Parallax web site. Can it be user installed?

    Bruce
  • Jon WilliamsJon Williams Posts: 6,491
    edited 2004-08-26 13:09
    The end user cannot install new firmware -- we have to do it in house. We offered free reprogramming of BS2p modules because they were very new and there were not many on the streets -- and we had erred. We made announcements in N&V and on our web site. I think there may be a small fee now, but I will have to check with the Marketing and Tech Support groups.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Jon Williams
    Applications Engineer, Parallax
    Dallas Office
  • Jon WilliamsJon Williams Posts: 6,491
    edited 2004-08-26 13:20
    I've attached a program that works with the PCF8574 using V1.2 BS2p modules.· The program has lots of comments that explain what's happening with the PCF8574 and how to deal with it.· Not that this program was last updated two years ago when we adjusted the firmware (this was part of our test code).
    EEPROMs do, in fact, have internal addresses so the old firmware was never a problem.
    basicstampede said...


    <snip>

    And, please point to a document that explains all this in further detail.· I'm especially interested in seeing an example of code using 1.2 and 1.3 version for say PCF8574 or others such as EEPROM.
    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Jon Williams
    Applications Engineer, Parallax
    Dallas Office
    BSP
    BSP
    PCF8574 Test - Rev B.BSP
    3K
  • Jon WilliamsJon Williams Posts: 6,491
    edited 2004-08-26 13:22
    One last comment on all this -- the PCF8574 is not that great ... the Microchip MCP23016 is a better choice in my opinion. It has 16 IOs and every one of them can sink or source 25 mA. The [noparse][[/noparse]weakling] PCF8574 is only capable of sinking 3 mA per pin -- and can only source in the microamps.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Jon Williams
    Applications Engineer, Parallax
    Dallas Office
  • basicstampedebasicstampede Posts: 214
    edited 2004-08-26 16:18
    OK.· Jon, my light colored 2p is 1.3, whereas darker one is 1.4 firmware.

    What is the difference between 1.3 and 1.4 (aside from the fact that I need the new 2.1 PBASIC editor for 1.4 firmware)?

    Thanks.
  • Jon WilliamsJon Williams Posts: 6,491
    edited 2004-08-26 23:28
    Very small adjustments; none having to do with I2C -- contact Tech Support for the information (support@parallax.com).

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Jon Williams
    Applications Engineer, Parallax
    Dallas Office
  • basicstampedebasicstampede Posts: 214
    edited 2004-08-28 16:25
    Jon,

    I don't mean to drag this on, but now I'm curious.

    In the attached file you sent, it says,
    "' Note: Most (not all) I2C devices have multiple internal addresses, so the
    ' I2CIN and I2COUT commands support this with an address parameter (this byte
    ' comes after the Slave Address byte).· With the PCF8574, replace the address
    ' byte with a value that reflects the desired state of the I/O pins, where
    ' 1 is an input.· For example:
    '
    ' %11100000 = Bits 0 - 4 are outputs, bits 5 - 7 are inputs
    '
    ' For the PCF8574 the syntax becomes:
    '
    '··· I2CIN· pin, ddr_value, [noparse][[/noparse]in_byte]
    '··· I2COUT pin, ddr_value, [noparse][[/noparse]out_byte]············ "

    So for firmware 1.2, the syntax above is correct.

    But what would be the syntax for firmware 1.3 and 1.4?

    I2CIN pin, [noparse][[/noparse]in_byte] and

    I2COUT pin, [noparse][[/noparse]out_byte] for PCF8574?

    I know your comment about using MCP23016, and I agree that is a better part.

    My aim here is to learn the syntax difference for a part like PCF8574.

    Thanks.
  • Jon WilliamsJon Williams Posts: 6,491
    edited 2004-08-29 06:38
    If you have a version 1.2 part, you must use the syntax above. If you have a version 1.3 or greater part, AND are using the version 2.1 compiler, you can leave out the address parameter.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Jon Williams
    Applications Engineer, Parallax
    Dallas Office
  • Tracy AllenTracy Allen Posts: 6,662
    edited 2004-08-30 05:15
    Maybe part of your confusion that the explanation text is missing the slave ID.IO byte:

    '    I2CIN  pin, ddr_value, [noparse][[/noparse]in_byte]
'    I2COUT pin, ddr_value, [noparse][[/noparse]out_byte]



    If you read on a little further in the program you will see that both the I2CIN and I2COUT commands have one more byte, Rd8574 and Wr8574 respectively that is not in the comment section above:

    Check_Bit7:
 I2CIN I2Cpin, Rd8574, (MixDDR | cntr), [noparse][[/noparse]ioByte]     '<-- note ddr_value := (mixDDR|cntr)
  IF (ioByte.Bit7) THEN Check_Bit7
 cntr = cntr + 1
  DEBUG Home, 10, BIN4 cntr
 I2COUT I2Cpin, Wr8574, cntr, [noparse][[/noparse]cntr]          ' <---note ddr_value := cntr
 PAUSE 250
  GOTO Check_Bit7



    In BS2p version 1.2, the address byte was required, so the program expeiently stuffs the data into the address byte, but in version 1.3 and 1.4, the address byte was made optional:

    v1.1 and v1.2:
    I2CIN I2Cpin, Rd8574, (MixDDR | cntr), [noparse][[/noparse]ioByte]
    I2COUT I2Cpin, Wr8574, cntr, [noparse][[/noparse]cntr]

    v1.3 and v1.4
    I2CIN I2Cpin, Rd8574, [noparse][[/noparse] (MixDDR | cntr), ioByte]
    I2COUT I2Cpin, Wr8574, [noparse][[/noparse]cntr] <--- I think this would work without the 2nd cntr

    The version 1.2 syntax will also work just fine on version 1.3 and 1.4.

    In terms of what happens in the I2C protocol, there is really no difference between address bytes and data bytes. They all have the same mechanism for sending a byte of data and receiving an acknowledge. The differences are main in how the slave device interprets the bytes. So, the version 1.3/4 syntax is simply more versatile.

    In addition to the issue with the address byte, somewhere in the evolution they added better handling of the "clock hold" function. You may wonder why the clock line in I2C is configured as an input and requires an pullup resistor. You might think, since the clocking always comes from the master (the Stamp), why didn't they just make that an output? Well, the I2C protocol officially requires that the master allow the slave to hold the clock line low as a signal that it is busy. For example, the MAX1236 analog to digital converter. After the MAX1236 decodes the slaveID/read, it holds the clock line low while it actually preforms the analog to digital conversion, and then as part of the same I2CIN command, the Stamp waits and watches the clock line and detects when the MAX1236 releases it, "done", and then the same I2CIN command continues to input the results of the conversion.

    I think there was one small change in the I2C command in going from version 1.3 to 1.4, but it was extremely esoteric, having to do with an I2C buss with several devices with different slave IDs. If one of those devices was suddenly removed or failed, there could be in rare instances a misidenification of another device still on the buss. You see, Parallax really takes care to get things right!

    -- Tracy

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Tracy Allen
    www.emesystems.com
Sign In or Register to comment.