Teensy 4.0 First Beta Test

Status
Not open for further replies.
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.
 
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.
 
... wide bar PWM visualized to make room for SPI1 pins …
View 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...

...
 
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....

card10b_rev1.png
 
@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?
 
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...
 
@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.
 
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.
 
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?
 
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.


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.

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.
 
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.
 
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.
 
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.
 
What did you pay for the shield?

Got my T4 with ribbon today.. looks fantastic. The Raspberry heat sink I found still fits - great.
 
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.
 
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
 
KurtE said:
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 */
 
@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
 
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)...
 
@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 :)
 
@WMXZ:
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.
 
@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...
 
Status
Not open for further replies.
Back
Top