Forum Rule: Always post complete source code & details to reproduce any issue!
Page 133 of 173 FirstFirst ... 33 83 123 131 132 133 134 135 143 ... LastLast
Results 3,301 to 3,325 of 4311

Thread: Teensy 4.0 First Beta Test

  1. #3301
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,101
    Quote Originally Posted by PaulStoffregen View Post
    Here's another draft with text added about the red LED.
    ...

    For everyone who's used the betas, does this description make sense? Space is limited on the card, need to choose words carefully...
    Man - you all been busy. As othesr have said the Card really looks good!. Just a couple of comments: (1) on the audio the outXX and inXX stuff got me confused probably just got use to looking at the spreadsheet (2) I like the idea of the bar for the PWM - may make some extra room, (3) for XBAR and FLEXIO maybe you can add some pin assignments to the back of the card - not how much extra room you will have on the back side though.

  2. #3302
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,568
    I'm still not sure if IN# and OUT# are a good idea. But I'm trying to avoid TX# and RX# since we use those same names for the serial ports. Several times on this forum and in emails, people have confused the CAN signals on the Teensy 3.2 card for another serial port, even though they lack a number and have a different color background (and distinct intensity difference for colorblind folks). So I'm really trying to avoid anything that would look confusingly similar to the serial signals.

    Not sure how I feel about the horizontal bar idea. Yeah, it saves space. Maybe I just need a little time to warm up to the idea?

    The back side has less space available, due to the bar code and other stuff needed near the bottom of the card. I'm also considering trying to put a little info about SD.begin(pin) vs SD.begin(BUILTIN_SDCARD), and a mention to use USBHost_t36 for the host port.

  3. #3303
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,331
    Quote Originally Posted by PaulStoffregen View Post
    I'm still not sure if IN# and OUT# are a good idea. But I'm trying to avoid TX# and RX# since we use those same names for the serial ports.
    maybe something like RD#, TD# ?

  4. #3304
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,421
    Quote Originally Posted by defragster View Post
    ... wide bar PWM visualized to make room for SPI1 pins
    Attachment 16761

    Is it worth the ink to add along with 'All digital pins have int...' the up front note ... 'All pins are limited to 3.3V'
    I was going to suggest doing something else with PWM pins as well. First suggestion was to simply mark with P instead of PWM...
    Or maybe just a PWM color band right next to the digital pin marking...

    ...

  5. #3305
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,568
    Here's a first draft for the back side. Didn't get the colors into this one yet, so a little more imagination required for this early draft....

    Click image for larger version. 

Name:	card10b_rev1.png 
Views:	127 
Size:	84.2 KB 
ID:	16763

  6. #3306
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,101
    @PaulStoffregen
    Understand where the confusion can come in with the using Rx# and Tx# for In and Out. Guess its just something to get use to for me . Its probably as good as anything else. @WMXZ had a recommendation as well or maybe as a takeoff RxD, TxD? Just throwing ideas out there.

    The back side has less space available, due to the bar code and other stuff needed near the bottom of the card. I'm also considering trying to put a little info about SD.begin(pin) vs SD.begin(BUILTIN_SDCARD), and a mention to use USBHost_t36 for the host port.
    Would it be possible to add a link to maybe a larger pinout out diagram or spreadsheet like @KurtE's for XBAR and FlexIO?

  7. #3307
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,421
    Comments to some of the other comments..

    ili9341_t3 - Does not compile... I made a version of it that will run on T4.....
    I have a version that does run on T4... In Pull Request: https://github.com/PaulStoffregen/ILI9341_t3/pull/52


    usbhost_t36
    - Hang with Mass storage tests of specific sizes (also hits T3.6 as well) - There is an issue with number of buffer calculations. It adds one extra and does not need it nor init it, so has garbage...

    There is a fix that we have used for a little while part of my WIP Bluetooth branch (Lots of stuff, mainly adding Bluetooth support for some things)... https://github.com/PaulStoffregen/USBHost_t36/pull/28

    If you want to pick up only simple fix here... The problem is in ehci.cpp at line #748: for (count=(len >> 14); count; count--)
    Simple fix was: for (count=((len-1) >> 14); count; count--)

    But one in delta first put a test for len as I did not want it to allocate a lot of items if someone passed in a count of 0...

  8. #3308
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,421
    @PaulStoffregen - Back side of card.

    Probably need the warning like T3.6, that no pins are 5v tolerant....

    Also I noted: you put in the Serial5 alternate Tx/Rx pins... I suppose I should probably implement that ability

    As @mjs513 mentioned - Hard to fit everything like FlexIO and XBar... Hard to know which features will be the most interesting!

    Example suppose you integrate something like my FlexIO test stuff: https://github.com/KurtE/FlexIO_t4

    Where I have an implementation for a Serial port and an SPI port and suppose we integrate that into some library like SoftwareSerial.
    Then maybe knowing which pins are FlexIO will be more important.

  9. #3309
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,101
    Quote Originally Posted by KurtE View Post
    Comments to some of the other comments..

    ili9341_t3 - Does not compile... I made a version of it that will run on T4.....
    I have a version that does run on T4... In Pull Request: https://github.com/PaulStoffregen/ILI9341_t3/pull/52


    usbhost_t36
    - Hang with Mass storage tests of specific sizes (also hits T3.6 as well) - There is an issue with number of buffer calculations. It adds one extra and does not need it nor init it, so has garbage...

    There is a fix that we have used for a little while part of my WIP Bluetooth branch (Lots of stuff, mainly adding Bluetooth support for some things)... https://github.com/PaulStoffregen/USBHost_t36/pull/28

    If you want to pick up only simple fix here... The problem is in ehci.cpp at line #748: for (count=(len >> 14); count; count--)
    Simple fix was: for (count=((len-1) >> 14); count; count--)

    But one in delta first put a test for len as I did not want it to allocate a lot of items if someone passed in a count of 0...
    ili9341_t3 is on the list in post #6 referencing the PR (forgot to include the link.
    usbhost_t36 - is not on the post #6 list.

    Hopefully, now that T4 release is getting closer Paul will have more time to get those PRs incorporated. Right now I keep coping and pasting the PR versions to test with.

    HDMI: On a side note I tested the HDMI board with the T3.6 and looks good on the screen - just an initial test. Tried it with the T4 but it failed to recognize the RA8876 chip. Maybe an issue with SPI implementation or I2C.. Have to dig into the code more.

  10. #3310
    Quote Originally Posted by KurtE View Post
    I was going to suggest doing something else with PWM pins as well. First suggestion was to simply mark with P instead of PWM...
    Or maybe just a PWM color band right next to the digital pin marking...

    ...
    What about just using the PWM color instead of gray on the pin numbers that support PWM and removing the label entirely?

  11. #3311
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,568
    Quote Originally Posted by mjs513 View Post
    Hopefully, now that T4 release is getting closer Paul will have more time to get those PRs incorporated.
    Yes. But at this moment, I'm focusing on the pinout cards and some other essential documentation stuff.

    My plan is to finalize the cards and send them out for printing next Tuesday. Then I'll be back to focusing on the software side. If I don't do this now, the cards could possibly hold up releasing the product next month.


    Quote Originally Posted by KurtE View Post
    Probably need the warning like T3.6, that no pins are 5v tolerant....
    Oh, good catch. Will put that in later today.


    Also I noted: you put in the Serial5 alternate Tx/Rx pins... I suppose I should probably implement that ability
    I was wondering whether showing the alternate serial and I2C pins is worthwhile. Might be simpler to just not show them.


    As @mjs513 mentioned - Hard to fit everything like FlexIO and XBar... Hard to know which features will be the most interesting!
    Yeah. At this point, I'm feeling like the card is already getting a bit too overwhelming. FlexIO and all the stuff accessible by the crossbar switch are probably going to end up only on the website. I keep trying to tell myself the Zen of Github "anything added dilutes everything else". But for a fixed size card like this, it's more like hitting a tipping point of information overload or something.

    Quote Originally Posted by ecurtz View Post
    What about just using the PWM color instead of gray on the pin numbers that support PWM and removing the label entirely?
    Except for the 2 website links, and the alternate pins, all the text will be black. For printing on the glossy card, colored text (like red) has much lower contrast. The printing process uses black plus 3 colors, so anything that isn't fully black gets created by a dithered pattern of the 3 colors. Only full black achieves highest contract, when with the already small font getting even more horizontally compressed on this card, we really need that contrast on the printing.

  12. #3312
    Quote Originally Posted by PaulStoffregen View Post
    Except for the 2 website links, and the alternate pins, all the text will be black. For printing on the glossy card, colored text (like red) has much lower contrast. The printing process uses black plus 3 colors, so anything that isn't fully black gets created by a dithered pattern of the 3 colors. Only full black achieves highest contract, when with the already small font getting even more horizontally compressed on this card, we really need that contrast on the printing.
    I was thinking for the background color, not the text. i.e. the light gray background would be pink (or current light gray with a pink stripe?) to indicate the PWM capable digital pins and then the key would add the pink region onto the bottom of the light gray Digital Pin entry with "With PWM" or something.

  13. #3313
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,421
    Quote Originally Posted by PaulStoffregen View Post
    I was wondering whether showing the alternate serial and I2C pins is worthwhile. Might be simpler to just not show them.
    Easier - Maybe - But should not take me much time, to update the code/tables to make it work.

    I will try to get that done in the next few days.

  14. #3314
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,101
    T4B2 and HDMI Shield

    @KurtE, @defragster, @all....

    Ok after checking the pin assignments using the T3.6 adapter board that I got with HDMI Shield SPI pins were being reassigned, i.e., SCK on pin 14. So, after editing the config file to use standard SPI pins and a couple of other pin changes, I put the shield into my breakout board and success. Then it ran the primitive test sketch no problem. I started redoing the standard graphics test sketch to use the primitives that are in the driver. Screen quality looks good but haven't done anything with any heavy graphics yet - more to follow. Just wanted to give everyone a heads up.

    Oh, forgot, if you do use a Teensy with the HDMI shield it will output I2S sound to the monitor using the Audio Library. Of, course I can't do that yet with the T4 since the i2s are on different pins than the T3.5/T3.6 but will do a double check.

  15. #3315
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    What did you pay for the shield?

    Got my T4 with ribbon today.. looks fantastic. The Raspberry heat sink I found still fits - great.

  16. #3316
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,101
    Quote Originally Posted by Frank B View Post
    What did you pay for the shield?

    Got my T4 with ribbon today.. looks fantastic. The Raspberry heat sink I found still fits - great.
    The board is pricey but it really works nice - cost is $61 dollars. Ships from HK. The website shows it unavailable but when I contacted him he had a few left. He said he is getting more in but didn't say when.

    The T4 with ribbon is impressive. I have to agree with you on that one.

  17. #3317
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,421
    Quote Originally Posted by KurtE View Post
    Easier - Maybe - But should not take me much time, to update the code/tables to make it work.

    I will try to get that done in the next few days.
    OK, I updated the serial port code to enhance the internal tables (structures) to allow two RX and two TX pins... The ports default to using the first one defined...

    It appears to work. While testing this with my all Serial ports test code, I was having some flaky issues, where it would work, but if I changed something hardware wise it did not continue to work..

    Found that I think the code (current released as well) is/was not properly setting the RX pins port settings...

    With this update I now set:

    RX Pins to: *(portControlRegister(hardware->rx_pins[rx_pin_index_].pin)) = IOMUXC_PAD_DSE(7) | IOMUXC_PAD_PKE | IOMUXC_PAD_PUE | IOMUXC_PAD_PUS(3) | IOMUXC_PAD_HYS;


    TX pins to: *(portControlRegister(hardware->tx_pins[tx_pin_index_].pin)) = IOMUXC_PAD_SRE | IOMUXC_PAD_DSE(3) | IOMUXC_PAD_SPEED(3);
    TX with Open Drain: *(portControlRegister(pin)) = IOMUXC_PAD_ODE | IOMUXC_PAD_DSE(3) | IOMUXC_PAD_SPEED(3);

    Suggestions for what the pins should be initialized to would be appreciated.

    Created PR: https://github.com/PaulStoffregen/cores/pull/380

  18. #3318
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,331
    Quote Originally Posted by Frank B View Post

    Got my T4 with ribbon today.. looks fantastic.
    Frank,
    is on the T4 the ribbon pointing forward or backward?
    IOW, it fat cable is inserted, does it goes towards the USB connector or towards the botton?

  19. #3319
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,101
    Quote Originally Posted by KurtE
    Suggestions for what the pins should be initialized to would be appreciated.
    Don't know if its right or wrong but it looks like the NXP 1062EVKB has the pin config set up for tx and rx as 0x10B0, i will add the caveat that for the T4 this may not hold.

    Code:
      IOMUXC_SetPinConfig(
          IOMUXC_GPIO_AD_B0_12_LPUART1_TX,        /* GPIO_AD_B0_12 PAD functional properties : */
          0x10B0u);                               /* Slew Rate Field: Slow Slew Rate
                                                     Drive Strength Field: R0/6
                                                     Speed Field: medium(100MHz)
                                                     Open Drain Enable Field: Open Drain Disabled
                                                     Pull / Keep Enable Field: Pull/Keeper Enabled
                                                     Pull / Keep Select Field: Keeper
                                                     Pull Up / Down Config. Field: 100K Ohm Pull Down
                                                     Hyst. Enable Field: Hysteresis Disabled */

  20. #3320
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,421
    @mjs513 - Thanks. I guess the real question is should HardwareSerial stuff try to use the same settings as pinMode would give by default. Or should it go to some "Fast" mode?


    @PaulStoffregen and all...

    This morning did second part of the Alternate pins shown on back of draft card.

    I updated Wire library to allow multiple pins to be defined for SCL/SDA and then defined them for Wire1... I changed the hardware_t structure to use the same sub-structures I created for the hardware Serial changes.

    I tested using a very slightly modified version of Scanner.ino on Wire, Wire1, Wire2 and then back to Wire1 with setting SCL and SDA pins...
    Code:
    // --------------------------------------
    // i2c_scanner
    // http://playground.arduino.cc/Main/I2cScanner
    //
    // Version 1
    //    This program (or code that looks like it)
    //    can be found in many places.
    //    For example on the Arduino.cc forum.
    //    The original author is not know.
    // Version 2, Juni 2012, Using Arduino 1.0.1
    //     Adapted to be as simple as possible by Arduino.cc user Krodal
    // Version 3, Feb 26  2013
    //    V3 by louarnold
    // Version 4, March 3, 2013, Using Arduino 1.0.3
    //    by Arduino.cc user Krodal.
    //    Changes by louarnold removed.
    //    Scanning addresses changed from 0...127 to 1...119,
    //    according to the i2c scanner by Nick Gammon
    //    http://www.gammon.com.au/forum/?id=10896
    // Version 5, March 28, 2013
    //    As version 4, but address scans now to 127.
    //    A sensor seems to use address 120.
    // Version 6, November 27, 2015.
    //    Added waiting for the Leonardo serial communication.
    //
    //
    // This sketch tests the standard 7-bit addresses
    // Devices with higher bit address might not be seen properly.
    //
    
    #include <Wire.h>
    
    #define WIRE Wire1
    
    void setup() {
      // uncomment these to use alternate pins
      WIRE.setSCL(37);
      WIRE.setSDA(36);
      WIRE.begin();
      Serial.begin(9600);
      while (!Serial);        // Leonardo: wait for serial monitor
      Serial.println(F("\nI2C Scanner"));
    }
    
    
    void loop() {
      byte error, address;
      int nDevices;
    
      Serial.println(F("Scanning..."));
    
      nDevices = 0;
      for (address = 1; address < 127; address++) {
        // The i2c_scanner uses the return value of
        // the Write.endTransmisstion to see if
        // a device did acknowledge to the address.
        WIRE.beginTransmission(address);
        error = WIRE.endTransmission();
    
        if (error == 0) {
          Serial.print(F("Device found at address 0x"));
          if (address < 16) {
            Serial.print("0");
          }
          Serial.print(address,HEX);
          Serial.print("  (");
          printKnownChips(address);
          Serial.println(")");
    
          nDevices++;
        } else if (error==4) {
          Serial.print(F("Unknown error at address 0x"));
          if (address < 16) {
            Serial.print("0");
          }
          Serial.println(address,HEX);
        }
      }
      if (nDevices == 0) {
        Serial.println(F("No I2C devices found\n"));
      } else {
        Serial.println(F("done\n"));
      }
      delay(5000);           // wait 5 seconds for next scan
    }
    
    
    void printKnownChips(byte address)
    {
      // Is this list missing part numbers for chips you use?
      // Please suggest additions here:
      // https://github.com/PaulStoffregen/Wire/issues/new
      switch (address) {
        case 0x00: Serial.print(F("AS3935")); break;
        case 0x01: Serial.print(F("AS3935")); break;
        case 0x02: Serial.print(F("AS3935")); break;
        case 0x03: Serial.print(F("AS3935")); break;
        case 0x0A: Serial.print(F("SGTL5000")); break; // MCLK required
        case 0x0B: Serial.print(F("SMBusBattery?")); break;
        case 0x0C: Serial.print(F("AK8963")); break;
        case 0x10: Serial.print(F("CS4272")); break;
        case 0x11: Serial.print(F("Si4713")); break;
        case 0x13: Serial.print(F("VCNL4000,AK4558")); break;
        case 0x18: Serial.print(F("LIS331DLH")); break;
        case 0x19: Serial.print(F("LSM303,LIS331DLH")); break;
        case 0x1A: Serial.print(F("WM8731")); break;
        case 0x1C: Serial.print(F("LIS3MDL")); break;
        case 0x1D: Serial.print(F("LSM303D,LSM9DS0,ADXL345,MMA7455L,LSM9DS1,LIS3DSH")); break;
        case 0x1E: Serial.print(F("LSM303D,HMC5883L,FXOS8700,LIS3DSH")); break;
        case 0x20: Serial.print(F("MCP23017,MCP23008,PCF8574,FXAS21002,SoilMoisture")); break;
        case 0x21: Serial.print(F("MCP23017,MCP23008,PCF8574")); break;
        case 0x22: Serial.print(F("MCP23017,MCP23008,PCF8574")); break;
        case 0x23: Serial.print(F("MCP23017,MCP23008,PCF8574")); break;
        case 0x24: Serial.print(F("MCP23017,MCP23008,PCF8574")); break;
        case 0x25: Serial.print(F("MCP23017,MCP23008,PCF8574")); break;
        case 0x26: Serial.print(F("MCP23017,MCP23008,PCF8574")); break;
        case 0x27: Serial.print(F("MCP23017,MCP23008,PCF8574,LCD16x2,DigoleDisplay")); break;
        case 0x28: Serial.print(F("BNO055,EM7180,CAP1188")); break;
        case 0x29: Serial.print(F("TSL2561,VL6180,TSL2561,TSL2591,BNO055,CAP1188")); break;
        case 0x2A: Serial.print(F("SGTL5000,CAP1188")); break;
        case 0x2B: Serial.print(F("CAP1188")); break;
        case 0x2C: Serial.print(F("MCP44XX ePot")); break;
        case 0x2D: Serial.print(F("MCP44XX ePot")); break;
        case 0x2E: Serial.print(F("MCP44XX ePot")); break;
        case 0x2F: Serial.print(F("MCP44XX ePot")); break;
        case 0x33: Serial.print(F("MAX11614,MAX11615")); break;
        case 0x34: Serial.print(F("MAX11612,MAX11613")); break;
        case 0x35: Serial.print(F("MAX11616,MAX11617")); break;
        case 0x38: Serial.print(F("RA8875,FT6206")); break;
        case 0x39: Serial.print(F("TSL2561, APDS9960")); break;
        case 0x3C: Serial.print(F("SSD1306,DigisparkOLED")); break;
        case 0x3D: Serial.print(F("SSD1306")); break;
        case 0x40: Serial.print(F("PCA9685,Si7021")); break;
        case 0x41: Serial.print(F("STMPE610,PCA9685")); break;
        case 0x42: Serial.print(F("PCA9685")); break;
        case 0x43: Serial.print(F("PCA9685")); break;
        case 0x44: Serial.print(F("PCA9685, SHT3X")); break;
        case 0x45: Serial.print(F("PCA9685, SHT3X")); break;
        case 0x46: Serial.print(F("PCA9685")); break;
        case 0x47: Serial.print(F("PCA9685")); break;
        case 0x48: Serial.print(F("ADS1115,PN532,TMP102,PCF8591")); break;
        case 0x49: Serial.print(F("ADS1115,TSL2561,PCF8591")); break;
        case 0x4A: Serial.print(F("ADS1115")); break;
        case 0x4B: Serial.print(F("ADS1115,TMP102")); break;
        case 0x50: Serial.print(F("EEPROM")); break;
        case 0x51: Serial.print(F("EEPROM")); break;
        case 0x52: Serial.print(F("Nunchuk,EEPROM")); break;
        case 0x53: Serial.print(F("ADXL345,EEPROM")); break;
        case 0x54: Serial.print(F("EEPROM")); break;
        case 0x55: Serial.print(F("EEPROM")); break;
        case 0x56: Serial.print(F("EEPROM")); break;
        case 0x57: Serial.print(F("EEPROM")); break;
        case 0x58: Serial.print(F("TPA2016,MAX21100")); break;
        case 0x5A: Serial.print(F("MPR121")); break;
        case 0x60: Serial.print(F("MPL3115,MCP4725,MCP4728,TEA5767,Si5351")); break;
        case 0x61: Serial.print(F("MCP4725,AtlasEzoDO")); break;
        case 0x62: Serial.print(F("LidarLite,MCP4725,AtlasEzoORP")); break;
        case 0x63: Serial.print(F("MCP4725,AtlasEzoPH")); break;
        case 0x64: Serial.print(F("AtlasEzoEC")); break;
        case 0x66: Serial.print(F("AtlasEzoRTD")); break;
        case 0x68: Serial.print(F("DS1307,DS3231,MPU6050,MPU9050,MPU9250,ITG3200,ITG3701,LSM9DS0,L3G4200D")); break;
        case 0x69: Serial.print(F("MPU6050,MPU9050,MPU9250,ITG3701,L3G4200D")); break;
        case 0x6A: Serial.print(F("LSM9DS1")); break;
        case 0x6B: Serial.print(F("LSM9DS0")); break;
        case 0x70: Serial.print(F("HT16K33")); break;
        case 0x71: Serial.print(F("SFE7SEG,HT16K33")); break;
        case 0x72: Serial.print(F("HT16K33")); break;
        case 0x73: Serial.print(F("HT16K33")); break;
        case 0x76: Serial.print(F("MS5607,MS5611,MS5637,BMP280")); break;
        case 0x77: Serial.print(F("BMP085,BMA180,BMP280,MS5611")); break;
        default: Serial.print(F("unknown chip"));
      }
    }
    Issued PR: https://github.com/PaulStoffregen/Wire/pull/14

  21. #3321
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,421
    Quote Originally Posted by WMXZ View Post
    Frank,
    is on the T4 the ribbon pointing forward or backward?
    IOW, it fat cable is inserted, does it goes towards the USB connector or towards the botton?
    The ribbon is installed pointing toward the USB input plug. He did a hard bend down of the cable and then it runs back under the T4, where he has a matching connector on breakout board the front (usb connector).

    It is sort of a tight squeeze to allow the ribbon to be in place plus pogo pins to go up to hit the USB Host pins...

    Hopefully they will work on my own breakout board. Which should arrive hopefully in the next week. I have 5 of those ribbons arriving in a few days as well as some connectors.... Still don't have the RTC battery connector yet (did not see it on digikey... need to order from Mouser...)

    I probably won't assemble the whole board yet, as it is set up for ribbon cable, plus with surface mount pins for bottom, so will probably wait until I can order a few production boards to hook up. (Don't want to risk the ribbon one I have for official testing)...

  22. #3322
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,101
    Quote Originally Posted by KurtE View Post
    @mjs513 - Thanks. I guess the real question is should HardwareSerial stuff try to use the same settings as pinMode would give by default. Or should it go to some "Fast" mode?


    @PaulStoffregen and all...

    This morning did second part of the Alternate pins shown on back of draft card.

    I updated Wire library to allow multiple pins to be defined for SCL/SDA and then defined them for Wire1... I changed the hardware_t structure to use the same sub-structures I created for the hardware Serial changes.

    I tested using a very slightly modified version of Scanner.ino on Wire, Wire1, Wire2 and then back to Wire1 with setting SCL and SDA pins...
    …...
    Issued PR: https://github.com/PaulStoffregen/Wire/pull/14
    To honest, should go with the "Fast" mode. When I was playing with encoder and CAN/CANFD started with that and then made changes just in case. Just wanted to give you the reference point.

    Nice job on getting the pin assignments updated

  23. #3323
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    @WMXZ:
    Quote Originally Posted by KurtE View Post
    The ribbon is installed pointing toward the USB input plug. He did a hard bend down of the cable and then it runs back under the T4, where he has a matching connector on breakout board the front (usb connector).
    Yes, correct.

  24. #3324
    Senior Member
    Join Date
    Aug 2016
    Posts
    129
    since I didnt get on the beta list yet. I plan on trying to order one as soon as I can.

  25. #3325
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,421
    @PaullStoffregen and @others ...

    Again looking at backside of card...

    Reminds me that all of those SD card pins are PWM capable and looking at pwm.c the tables only go up to pin 33... Not sure what would happen right now if I did: analogWrite(34, 128);

    Might fault, as it walks off the table... And/or maybe it will just get garbage values... Anyway I will take a pass at updating those tables...

Posting Permissions

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