Forum Rule: Always post complete source code & details to reproduce any issue!
Page 25 of 25 FirstFirst ... 15 23 24 25
Results 601 to 612 of 612

Thread: New I2C library for Teensy3

  1. #601
    Hello. I am new to this whole arduino stuff. Made a few cool things. However, I have a 1602 I2C display and a teensy 3.2 and I'm looking for how to make them go together. This seems hopeful, however upon opening the example basic_echo it does not work. I notice in the comments of the code it says for 3.6 and, well. I'd like to ask for help, if possible. All pins could be blank or filled, if required. Thanks, and sorry if this is confusing. Thank you, have a nice day!

  2. #602
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    1,155
    The basic_echo example is for doing communication tests between the two integrated I2C h/w units of the T3.5 and T3.6, one set up as I2C master, the other one as I2C slave. As you understood already, that can't work on a T3.2.

    To check basic communication with EXTERNAL I2C devices like displays and other, use File -> Examples -> i2c_t3 -> basic_scanner and, if needed, fix your wiring of the display until it properly responds at its i2c base address.

  3. #603
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    2,573
    On the Teensy, you typically need to add two pull-up resistors, one between pin 18/A4 to 3.3v and the other between pin 19/A5 and 3.3v. These resistors are needed to enable i2c to work. Note, some devices have resistors already. As Theremingenieur says, run the scanner first, and if finds the device, then it should work. The typical resistor needed for Teensy's i2c is 2.2K resistors, but you can use other resistors between 2.2K and 4.7K (4.7K is the appropriate value for 5v systems). If you use a higher resistor, it will prevent you from using higher i2c bus speeds (the default speed should work).

    When I still used the 16x2 displays, one of my displays worked with 5v. With that display, I needed to use level shifters. In general, if you need a level shifter, it is probably simpler to get a new display that runs on 3.3v. At the moment, you can get a 128x64 OLED display from a US seller on ebay for under $6:


    You would use the Adafruit_SSD1306 driver for this, and look at the ssd1306_128x64_i2c example. While the Adafruit driver is open source, if you buy the official Adafruit device, it funds other device/driver development:

  4. #604
    Hi nox771

    just a short question : is it correct that each bus has its own callback functions (onTransmitDone, onReqFromDone etc ? I think so but want to be sure.

  5. #605
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,236
    I am about 99% sure that each wire object (buss) has it's own callback function, which is stored in the Wire object and is called from the ISR for the specific Wire buss.

  6. #606
    Thanks, 99% is a probability high enough for trying.

  7. #607
    Senior Member
    Join Date
    Mar 2013
    Location
    Austin TX
    Posts
    406
    Quote Originally Posted by hw999 View Post
    is it correct that each bus has its own callback functions (onTransmitDone, onReqFromDone etc ?
    Yes each bus has its own callback functions.

    There is a subtle priority escalation bug if you try doing Wire calls inside the callback, as described here: https://github.com/nox771/i2c_t3/issues/14
    The fix is known, I just need to get it out. I'll try to work on it sometime today.

  8. #608
    Thanks for information. No need to rush things.

  9. #609
    Senior Member
    Join Date
    Mar 2013
    Location
    Austin TX
    Posts
    406
    All, I uploaded a v10.1 release on GitHub and the top-post.

    This has a fix for a subtle priority escalation bug involving nested Wire calls inside callbacks (refer to: https://github.com/nox771/i2c_t3/issues/14). There is now a user #define (I2C_DISABLE_PRIORITY_CHECK) to disable the checks if anyone has further problems with it (in that case set priorities manually). No other major change.

  10. #610
    Hi nox 771

    implemented the latest version tested especially the onError() callback and resetBus(). Works really nice. Is it a big deal to provide information about the I2C adress that
    was involved in the error occurence - something like onError(uint8_t i2caddress) ?

  11. #611
    Senior Member
    Join Date
    Mar 2013
    Location
    Austin TX
    Posts
    406
    Quote Originally Posted by hw999 View Post
    Is it a big deal to provide information about the I2C adress that was involved in the error occurence - something like onError(uint8_t i2caddress) ?
    The library error tracking functions do not log addresses (it is more of an error "counting" system instead of an error "logging" system). This is really the only way to do it since a true error log could use an indeterminate amount of space.

    User code could augment the onError() callback to create an actual error log. This would be something like the Master storing the Slave address in some variable, and then grabbing it if onError() occurs, then writing the output to a SD card or similar (with relevant space available checks and all that). If there was an RTC it could also include a timestamp.

  12. #612
    Quote Originally Posted by nox771 View Post
    The library error tracking functions do not log addresses (it is more of an error "counting" system instead of an error "logging" system). This is really the only way to do it since a true error log could use an indeterminate amount of space.

    User code could augment the onError() callback to create an actual error log. This would be something like the Master storing the Slave address in some variable, and then grabbing it if onError() occurs, then writing the output to a SD card or similar (with relevant space available checks and all that). If there was an RTC it could also include a timestamp.
    Hi

    I did not mean having a logging system implemented. I had a quick look at the code and had the impression that someting like :

    if(i2c->user_onError != nullptr) i2c->user_onError(addr); // run Error callback if
    instead of
    if(i2c->user_onError != nullptr) i2c->user_onError(); // run Error callback if

    might be helpfull for erro-tracking on busses with multiple slaves and not require a big change in the coding.

Posting Permissions

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