Shop OBEX P1 Docs P2 Docs Learn Events
Using a different i2c bus on each of two cogs? — Parallax Forums

Using a different i2c bus on each of two cogs?

geekliftergeeklifter Posts: 4
edited 2014-09-23 20:09 in Accessories
This might be a silly question, so please feel free to point out obvious problems (I'm new to multi-core and i2c protocol but I'm enjoying myself).

Can a different i2c bus be created on different cogs? By that I mean one i2c bus per cog with 2 or more cogs. I've been trying this purely for my own education, but they seem to interfere with each other. When I use any function that does NOT create an i2c bus, the code works fine (i.e. I can blink an LED and get sensor values with different cogs just fine). And when I run the functions on the same cog, they also work fine with separate buses (similar to the great example provided in the DIY I2C section of the parallax site). However, when I try to run the sensor functions from different cogs the code runs but does not give realistic or consistent values.

Something like this:

int *cog1 = cog_run(&
get_sensor1_values, 20);
int *cog2 = cog_run(&get_sensor2_values, 20);

int main()
{
while(1)
{
...print some volatile values that are assigned by the other cogs...
}
}

void get_sensor1_values()
{
...
i2c *sensor1Bus = i2c_newbus(S1_SCL_PIN,S2_SDA_PIN,0);
while(1)
{
...get values...
}

}

void get_sensor2_values()
{
...
i2c *sensor2Bus = i2c_newbus(S2_SCL_PIN,S2_SDA_PIN,0);
while(1)
{
...get values...
}

}

Any major problems with this?

Thanks!

Tom the aspiring programmer

Comments

  • sumdawgysumdawgy Posts: 167
    edited 2014-09-22 20:02
    first off..
    you need to seprate the ic2 busses ....by that i mean the pins.
    there's no way you can run 2 separate busses from the same pin. (separate/same being the biggest issue)
    since the cogs run round robin they will keep hitting the same pins with conflicting data.

    your code says IF I read it right...both are connected to pin0?

    after that...logically it SHOULD work.

    I'm new to prop fun myself and i didn't do any i2c stuff when I did BS-1/2 so.....
    But I'm looking into it myself. :smile:
  • David BetzDavid Betz Posts: 14,514
    edited 2014-09-22 20:03
    geeklifter wrote: »
    This might be a silly question, so please feel free to point out obvious problems (I'm new to multi-core and i2c protocol but I'm enjoying myself).

    Can a different i2c bus be created on different cogs? By that I mean one i2c bus per cog with 2 or more cogs. I've been trying this purely for my own education, but they seem to interfere with each other. When I use any function that does NOT create an i2c bus, the code works fine (i.e. I can blink an LED and get sensor values with different cogs just fine). And when I run the functions on the same cog, they also work fine with separate buses (similar to the great example provided in the DIY I2C section of the parallax site). However, when I try to run the sensor functions from different cogs the code runs but does not give realistic or consistent values.

    Something like this:

    int *cog1 = cog_run(&
    get_sensor1_values, 20);
    int *cog2 = cog_run(&get_sensor2_values, 20);

    int main()
    {
    while(1)
    {
    ...print some volatile values that are assigned by the other cogs...
    }
    }

    void get_sensor1_values()
    {
    ...
    i2c *sensor1Bus = i2c_newbus(S1_SCL_PIN,S2_SDA_PIN,0);
    while(1)
    {
    ...get values...
    }

    }

    void get_sensor2_values()
    {
    ...
    i2c *sensor2Bus = i2c_newbus(S2_SCL_PIN,S2_SDA_PIN,0);
    while(1)
    {
    ...get values...
    }

    }

    Any major problems with this?

    Thanks!

    Tom the aspiring programmer
    Maybe this is just a typo in your post but in your first call to i2c_newbus you pass S1_SCL_PIN and S2_SDA_PIN. Shouldn't that be S1_SDA_PIN?
  • geekliftergeeklifter Posts: 4
    edited 2014-09-22 20:34
    thanks sumdawgy! Sorry this was not clear from my pseudo code - the pins are different. I should have included the code that defines the S1_SCL_PIN, S2_SCL_PIN, etc.
  • geekliftergeeklifter Posts: 4
    edited 2014-09-22 20:36
    Oops! Yes a typo. The pins are defined in the code as 3 and 2 for one bus, and 13 and 12 for the other. No typos in the real code .. my apologies for being sloppy. But I'm glad to have some feedback so quick. Thanks guys!
  • David BetzDavid Betz Posts: 14,514
    edited 2014-09-22 20:44
    geeklifter wrote: »
    Oops! Yes a typo. The pins are defined in the code as 3 and 2 for one bus, and 13 and 12 for the other. No typos in the real code .. my apologies for being sloppy. But I'm glad to have some feedback so quick. Thanks guys!
    In any case, I don't think there is any reason you shouldn't be able to have two i2c busses at the same time managed by different COGs as long as they use different pins.
  • sumdawgysumdawgy Posts: 167
    edited 2014-09-22 20:56
    David Betz wrote: »
    In any case, I don't think there is any reason you shouldn't be able to have two i2c busses at the same time managed by different COGs as long as they use different pins.

    I tend to agree. and actually.....
    I intend to have 3-4 i2c buses myself as part of a home automation project I'm beginning with a couple of p8x32a units i have.
  • David BetzDavid Betz Posts: 14,514
    edited 2014-09-22 21:00
    sumdawgy wrote: »
    I tend to agree. and actually.....
    I intend to have 3-4 i2c buses myself as part of a home automation project I'm beginning with a couple of p8x32a units i have.
    You could probably even manage several i2c busses in the same COG if you used an approach similar to the way the four port version of FullDuplexSerial works.
  • geekliftergeeklifter Posts: 4
    edited 2014-09-22 21:04
    Good to know that its not my approach that is causing the problem. Thanks David. I'm paring my code back to the bare minimum to locate the real problem. I'll post it when I figure it out.
  • sumdawgysumdawgy Posts: 167
    edited 2014-09-23 07:49
    David Betz wrote: »
    You could probably even manage several i2c busses in the same COG if you used an approach similar to the way the four port version of FullDuplexSerial works.

    Ok at this point in my prop devolpment that's waaaay ahead of me in execution. But, where is this discussed so i can look at it?

    I found http://learn.parallax.com/propeller-c-simple-protocols/full-duplex-serial
    I get that and love it. (Simpler than I expected) but, not able to make it i2c relevant.
  • David BetzDavid Betz Posts: 14,514
    edited 2014-09-23 08:11
    sumdawgy wrote: »
    Ok at this point in my prop devolpment that's waaaay ahead of me in execution. But, where is this discussed so i can look at it?

    I found http://learn.parallax.com/propeller-c-simple-protocols/full-duplex-serial
    I get that and love it. (Simpler than I expected) but, not able to make it i2c relevant.
    I have not done any work on this and am not really sure it is even possible. I just mentioned it because it has worked for UART interfaces and it might be possible to do it for i2c as well. I'm not sure anyone has ever tried it though.
  • GordonMcCombGordonMcComb Posts: 3,366
    edited 2014-09-23 14:16
    I might be missing something, and the hardware specifics of the Prop is not my forte, but I'd have thunk the chip could handle multiple I2C with ease. Like UART, I2C is just a serial train -- bits on and off, and in the case of I2C, a separate clock stream to keep things synced up. From a signal standpoint, it's pretty simple.

    That said, some I2C objects might be easier to get working than others (or more to the point, some are better than others). I'd try as many as you can from OBEX to see what works.
  • kwinnkwinn Posts: 8,697
    edited 2014-09-23 20:09
    A four port I2C driver should be simpler to implement than the fullduplex4port serial driver since there is a separate clock and data signal.
Sign In or Register to comment.