Forum Rule: Always post complete source code & details to reproduce any issue!
Page 27 of 27 FirstFirst ... 17 25 26 27
Results 651 to 656 of 656

Thread: New I2C library for Teensy3

  1. #651
    Senior Member
    Join Date
    Mar 2013
    Location
    Austin TX
    Posts
    419
    Also to anyone following this thread - in regards to Teensy4:

    I was offered a T4 beta board back when it started, but I could not accept as I did not have the requisite time to work on a library port.

    I have now obtained a couple of the retail boards, and although I still lack time, I will probably attempt a port as I can get to it. I have not reviewed Wire code on T4 to know how different it is, but I did read something about it using a FIFO, so my guess is the ISR code would be different enough to warrant a new lib (eg. i2c_t4). I am uncertain of interest level, if any, so any comments would be helpful.

  2. #652
    Senior Member
    Join Date
    Jun 2015
    Posts
    228
    Hi nox771,

    Thanks for getting back on this.

    Before I waste any of your time trying to help me - as I could be trying to achieve the impossible here.
    Would you expect your library to help increase the speed/performance of sending & displaying text to 8 x i2c displays?

    I have now managed to get the "spoof (wire/ic2_t3) " method to compile, but I'm not really seeing much difference performance wise.

    I know there are limitations with this protocol - but not sure what your library is offering versus the std Wire lib.
    As per a post on another thread - I'm seeing a cascading/domino effect when sending the text updates.

    I'm not a software person, so don't really understand most of this stuff.
    Just someone who manages to fumble his way through with the help of forums like this.

    Thanks

  3. #653
    Senior Member
    Join Date
    Mar 2013
    Location
    Austin TX
    Posts
    419
    Quote Originally Posted by bossredman View Post
    Hi nox771,

    Thanks for getting back on this.

    Before I waste any of your time trying to help me - as I could be trying to achieve the impossible here.
    Would you expect your library to help increase the speed/performance of sending & displaying text to 8 x i2c displays?

    I have now managed to get the "spoof (wire/ic2_t3) " method to compile, but I'm not really seeing much difference performance wise.

    I know there are limitations with this protocol - but not sure what your library is offering versus the std Wire lib.
    As per a post on another thread - I'm seeing a cascading/domino effect when sending the text updates.

    I'm not a software person, so don't really understand most of this stuff.
    Just someone who manages to fumble his way through with the help of forums like this.

    Thanks
    It depends. Mostly any speedup will depend on the slave device and if it will respond well to faster than normal I2C speeds. I've gotten faster than normal communication working on something like a SSD1306 I2C display (like the cheap ones on ebay: https://www.ebay.com/sch/i.html?_nkw...06+i2c&_sop=12 ). In that case IIRC it can help with refresh speeds.

    If you are using standard default settings (100kHz/400kHz), then you will likely see the same performance as Wire, as that is what it uses, so it does require specifying something above normal rates.

    Also there are other indirect ways to improve performance. Typical Wire is a blocking interface. Such that the program halts and waits for communication to complete. For i2c_t3 you can background transfers. So in that case you can load the buffer, start the transfer, then continue to a foreground task while it transfers in the background. Most recent releases also support a Master callback that can call a given function when the background transfer completes, so you do not need to monitor it. These are capabilities above and beyond what the standard Wire library will offer. You can check the "basic_master_callback" example for further information on that.

    Note the library linked in post #1 in this thread is obsolete. You should grab the latest one from GitHub (currently v11.0). Due to updated forum rules I can no longer edit the top post to maintain it, so GitHub is the main location now.

  4. #654
    Senior Member
    Join Date
    Jun 2015
    Posts
    228
    Quote Originally Posted by nox771 View Post
    Note the library linked in post #1 in this thread is obsolete. You should grab the latest one from GitHub (currently v11.0). Due to updated forum rules I can no longer edit the top post to maintain it, so GitHub is the main location now.
    Thanks.

    I picked up v11.0 already. It's the only 1 I've tried.

  5. #655
    Senior Member
    Join Date
    Jun 2015
    Posts
    228
    The Digole displays come with their own library for sending data (text, shapes etc) to them.
    So apart from the include for wire.h - all commands for sending the data are Digole specific commands.
    I'm don't directly interact with the Wire libray & commands - I guess that is done indirectly via the Digole Library.

    I just add these statements for each Display & then create an array listing each instance :
    Code:
    DigoleSerialDisp mydisp1(&Wire, '\x27'); 
    DigoleSerialDisp mydisp2(&Wire, '\x28'); 
    ...
    DigoleSerialDisp mydisp8(&Wire, '\x34'); 
    
    mydisp[8] = {mydisp1, mydisp2, ... mydisp8};
    This lets me easily loop each Display & send the data as required.

    Apart from what this statement is actually doing
    Code:
    DigoleSerialDisp mydisp1(&Wire, '\x27');
    I'm able to mostly understand the above.
    But I think I'm just not smart enough to figure out how to make changes to use Master Callbacks etc.

  6. #656
    Senior Member
    Join Date
    Mar 2013
    Location
    Austin TX
    Posts
    419
    Quote Originally Posted by bossredman View Post
    The Digole displays come with their own library for sending data (text, shapes etc) to them.
    So apart from the include for wire.h - all commands for sending the data are Digole specific commands.
    I'm don't directly interact with the Wire libray & commands - I guess that is done indirectly via the Digole Library.
    ...
    You'll have to supply a link to your library you are using. Other than that it is guessing. Using google I can see a DigoleSerial.h lib at:
    https://github.com/phalpern/Thermost...DigoleSerial.h

    That one has a very generic init for I2C config:
    Code:
    _myWire->begin();
    That may be giving you a 100kHz clock, which is standard for Arduino.

    A simple option is to use your init code as-is, then insert a Wire command to adjust the clock:
    Code:
    DigoleSerialDisp mydisp1(&Wire, '\x27'); 
    DigoleSerialDisp mydisp2(&Wire, '\x28'); 
    ...
    DigoleSerialDisp mydisp8(&Wire, '\x34'); 
    Wire.setClock(200000);  // 200kHz
    ...
    ...
    Add that, test it, and see if it works. Then increase it and try again: 400000 = 400kHz, 600000 == 600kHz, 800000 = 800kHz, and so on.

    i2c_t3 lib will quantize the number to the nearest legal value, so you can use any number you like. Most T3 parts can run up to 3000000 = 3MHz. Recent T3.5/3.6 can do higher.

    At some point it will fail and the screen will get garbage or something, then you can back it off.

    Edit: Forgot to mention, high speeds are also limited by the pullup resistor value. If the R-value on the bus is too high the pullups will be slow and it will limit your speeds. Refer to this link:
    http://dsscircuits.com/articles/86-a...l-up-resistors

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •