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

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,450
    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,628
    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,431
    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.

  13. #613

    Slave blocks bus

    I have a Teensy 3.2 operating as a slave to a Raspberry Pi. It works just fine, often for several minutes, and then everything stops. Putting a scope on the bus shows that both the SDA an SCL are being held low. Powering down the Teensy brings everything back and after resetting, the Teensy joins the bus again until the next time it stops. The initialization and operation are pretty standard:

    Wire.begin(I2C_SLAVE, 0X1c, I2C_PINS_18_19, I2C_PULLUP_EXT, 400000);
    Wire.onReceive(receiveEvent);
    Wire.onRequest(requestEvent);

    The callbacks are just like the basicSlave example. There is an IMU on the same bus but it is completely synchronous with the Teensy so there is unlikely to be any bus contention. Any help on debugging this would be greatly appreciated.

    By the way, it is probably irrelevant but I will add this piece of information in case it is related. In trying to get this to work I tried to get the standard Wire library to work. It appeared to work but the high bit on many of the bytes seemed to be wrong so that I would get 128 when the the value should have been 0.

  14. #614
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    17,022
    Quote Originally Posted by rstuart View Post
    In trying to get this to work I tried to get the standard Wire library to work. It appeared to work but the high bit on many of the bytes seemed to be wrong so that I would get 128 when the the value should have been 0.
    Would you like me to look into that issue?

    If so, please start a new thread about this problem using RPi and the normal Wire lib. Follow the "forum rule" with the complete code to be used on both sides. Please be specific about exactly what needs to be done in the RPi side. Usually when people have posted issues involving Raspberry Pi, setting up a Pi and getting everything working to the point of actually reproducing the problem has required far too much time. On the Teensy side, I can just copy & paste into Auduino and upload. If there's some way to quickly set up the RPi side, please be specific and please understand I won't spend more than about 20 minutes if the code or instructions don't work when I try them on the RPi side.

  15. #615

    Teensy3.2-RPi issue

    Quote Originally Posted by PaulStoffregen View Post
    Would you like me to look into that issue?

    If so, please start a new thread about this problem using RPi and the normal Wire lib. Follow the "forum rule" with the complete code to be used on both sides. Please be specific about exactly what needs to be done in the RPi side. Usually when people have posted issues involving Raspberry Pi, setting up a Pi and getting everything working to the point of actually reproducing the problem has required far too much time. On the Teensy side, I can just copy & paste into Auduino and upload. If there's some way to quickly set up the RPi side, please be specific and please understand I won't spend more than about 20 minutes if the code or instructions don't work when I try them on the RPi side.
    The code is too large and complex to post. I will spend some time extracting out the critical parts to reproduce the problem and then post it to a new thread as you suggest.

  16. #616
    Teensy3.2-RPi issue

    While preparing the code for Paul, I discovered a bug in the compile environment: I had the CPU speed set to "96 (overclock)". After setting this correctly, the Wire library works just fine and I am happy but a little embarrassed. However, the "New i2c library still locks up the bus from time-to-time. If anyone thinks this is a problem and wants to look into it, I am willing to help out in any way I can.

Posting Permissions

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