Teensy 4.0 First Beta Test

Status
Not open for further replies.
Kurt, I don't think digitalRead is working, just pointing it out since you're using it in your code, im using a toggled bool as an alternative for blinking

Code: 
 static bool flip;
    digitalWrite(13, flip = !flip);
 
Kurt - not sure what this does - except my prior notes - I get T4 LED Flash and working Serial Text with this, Faster and Faster w/LTO:
<edit>: It is not half second On then Off - and tonton !flip doesn't help. It is quicker with a long pause at times...

Code: 
class TestSerial : public Stream {
  public:
    virtual int available(void);
    virtual int peek(void);
    virtual void flush(void);
    virtual size_t write(uint8_t c);
    virtual int read(void);
    using Print::write;
};

int TestSerial::available(void) {return 0;}
int TestSerial::peek(void){return 0;}
void TestSerial::flush(void) {return;}

size_t TestSerial::write(uint8_t c) {
 digitalWrite(13, !digitalRead(13));
 return 0;  
}

int TestSerial::read(void){return 0;}

TestSerial ts;

void setup() {
  while ( !Serial && millis() < 600 ) {
    if ( 0 == ARM_DWT_CYCCNT &&  0 == ARM_DWT_CYCCNT ) {
      pinMode(LED_BUILTIN, OUTPUT);
      digitalWrite(LED_BUILTIN, HIGH);
      Serial4.println( "   ARM_DEMCR_TRCENA done!" );
      ARM_DEMCR |= ARM_DEMCR_TRCENA;
      ARM_DWT_CTRL |= ARM_DWT_CTRL_CYCCNTENA; // turn on cycle counter
    }
  }
  Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);
  
}

void loop() {
  ts.print(0);  // see if we call through the virtual function
  Serial.print("\n" __FILE__ );
  delay(500);
  Serial.println( __DATE__ " " __TIME__);
}
 
Code: 
    Serial4.print("D13: ");
    Serial4.println(digitalReadFast(13));

all the reads after toggling have been showing always 0 on the outputs for all 3 betas

Code: 
value = 989680
12345678
[COLOR="#FF0000"]D13: 0[/COLOR]
577953
Toggled Led
4660
1 2 3 4 5 
123.67942
value = 989680
12345678
[COLOR="#FF0000"]D13: 0[/COLOR]
578454
Toggled Led
4660
1 2 3 4 5 
123.67942
value = 989680
12345678
[COLOR="#FF0000"]D13: 0[/COLOR]
578955
Toggled Led
4660
1 2 3 4 5 
123.67942
value = 989680
12345678
[COLOR="#FF0000"]D13: 0[/COLOR]
579456
 
Right now doing it without other hardware, so can sit watching puppy.

But with changing to having own flag and not use digitalRead did not help much...

Code: 
class TestSerial : public Stream {
  public:
    TestSerial() {state_ = 0;};
    virtual int available(void);
    virtual int peek(void);
    virtual void flush(void);
    virtual size_t write(uint8_t c);
    virtual int read(void);
    using Print::write;
    size_t nonVirtualfunc(uint8_t c);
    uint8_t state_;
};

int TestSerial::available(void) {return 0;}
int TestSerial::peek(void){return 0;}
void TestSerial::flush(void) {return;}

size_t TestSerial::write(uint8_t c) {
  state_ = state_? 0 : 1;
 digitalWrite(13, state_);
 return 0;  
}

size_t TestSerial::nonVirtualfunc(uint8_t c) {
  state_ = state_? 0 : 1;
 digitalWrite(13, state_);
 return 0;  
}

int TestSerial::read(void){return 0;}

TestSerial ts;

void setup() {
  // put your setup code here, to run once:
  pinMode(13, OUTPUT);
  
}

void loop() {
  //ts.print(0);  // see if we call through the virtual function
  ts.nonVirtualfunc(0);
  delay(500);
}
Using a non-virtual function above works as expected. Slow blink of led. But if I instead use the ts.print() which is virtual, I get a real fast blink and no USB device after...

Edit: Actually if I directly call write instead of print, I get the simple blink, which is working... So now need to see why print 0 is not working
 
Last edited:
Just tested i2c using the PJRC version of the i2c scanner:
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 Serial4 communication.
//
//
// This sketch tests the standard 7-bit addresses
// Devices with higher bit address might not be seen properly.
//

#include <Wire.h>

void setup() {

  while ( !Serial4 && millis() < 4000 ) ;
  delay(3000);
  Serial4.println(F("\nI2C Scanner"));

  Wire.begin();
  
  while (!Serial4);        // Leonardo: wait for Serial4 monitor
  Serial4.println(F("\nI2C Scanner"));
}

void loop() {
  byte error, address;
  int nDevices;

  Serial4.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) {
      Serial4.print(F("Device found at address 0x"));
      if (address < 16) {
        Serial4.print("0");
      }
      Serial4.print(address,HEX);
      Serial4.print("  (");
      printKnownChips(address);
      Serial4.println(")");

      nDevices++;
    } else if (error==4) {
      Serial4.print(F("Unknown error at address 0x"));
      if (address < 16) {
        Serial4.print("0");
      }
      Serial4.println(address,HEX);
    }
  }
  if (nDevices == 0) {
    Serial4.println(F("No I2C devices found\n"));
  } else {
    Serial4.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/Wire1/issues/new
  switch (address) {
    case 0x00: Serial4.print(F("AS3935")); break;
    case 0x01: Serial4.print(F("AS3935")); break;
    case 0x02: Serial4.print(F("AS3935")); break;
    case 0x03: Serial4.print(F("AS3935")); break;
    case 0x0A: Serial4.print(F("SGTL5000")); break; // MCLK required
    case 0x0B: Serial4.print(F("SMBusBattery?")); break;
    case 0x0C: Serial4.print(F("AK8963")); break;
    case 0x10: Serial4.print(F("CS4272")); break;
    case 0x11: Serial4.print(F("Si4713")); break;
    case 0x13: Serial4.print(F("VCNL4000,AK4558")); break;
    case 0x18: Serial4.print(F("LIS331DLH")); break;
    case 0x19: Serial4.print(F("LSM303,LIS331DLH")); break;
    case 0x1A: Serial4.print(F("WM8731")); break;
    case 0x1C: Serial4.print(F("LIS3MDL")); break;
    case 0x1D: Serial4.print(F("LSM303D,LSM9DS0,ADXL345,MMA7455L,LSM9DS1,LIS3DSH")); break;
    case 0x1E: Serial4.print(F("LSM303D,HMC58/983L,FXOS8700,LIS3DSH")); break;
    case 0x20: Serial4.print(F("MCP23017,MCP23008,PCF8574,FXAS21002")); break;
    case 0x21: Serial4.print(F("MCP23017,MCP23008,PCF8574")); break;
    case 0x22: Serial4.print(F("MCP23017,MCP23008,PCF8574")); break;
    case 0x23: Serial4.print(F("MCP23017,MCP23008,PCF8574")); break;
    case 0x24: Serial4.print(F("MCP23017,MCP23008,PCF8574")); break;
    case 0x25: Serial4.print(F("MCP23017,MCP23008,PCF8574")); break;
    case 0x26: Serial4.print(F("MCP23017,MCP23008,PCF8574")); break;
    case 0x27: Serial4.print(F("MCP23017,MCP23008,PCF8574,LCD16x2,DigoleDisplay")); break;
    case 0x28: Serial4.print(F("BNO055,EM7180,CAP1188")); break;
    case 0x29: Serial4.print(F("VL53L0X,VLTSL2561,VL6180,TSL2561,TSL2591,BNO055,CAP1188")); break;
    case 0x2A: Serial4.print(F("SGTL5000,CAP1188")); break;
    case 0x2B: Serial4.print(F("CAP1188")); break;
    case 0x2C: Serial4.print(F("MCP44XX ePot")); break;
    case 0x2D: Serial4.print(F("MCP44XX ePot")); break;
    case 0x2E: Serial4.print(F("MCP44XX ePot")); break;
    case 0x2F: Serial4.print(F("MCP44XX ePot")); break;
    case 0x38: Serial4.print(F("RA8875,FT6206")); break;
    case 0x39: Serial4.print(F("TSL2561")); break;
    case 0x3C: Serial4.print(F("SSD1306,DigisparkOLED")); break;
    case 0x3D: Serial4.print(F("SSD1306")); break;
    case 0x40: Serial4.print(F("PCA9685,Si7021")); break;
    case 0x41: Serial4.print(F("STMPE610,PCA9685")); break;
    case 0x42: Serial4.print(F("PCA9685")); break;
    case 0x43: Serial4.print(F("PCA9685")); break;
    case 0x44: Serial4.print(F("PCA9685")); break;
    case 0x45: Serial4.print(F("PCA9685")); break;
    case 0x46: Serial4.print(F("PCA9685")); break;
    case 0x47: Serial4.print(F("PCA9685")); break;
    case 0x48: Serial4.print(F("ADS1115,PN532,TMP102,PCF8591")); break;
    case 0x49: Serial4.print(F("ADS1115,TSL2561,PCF8591")); break;
    case 0x4A: Serial4.print(F("ADS1115")); break;
    case 0x4B: Serial4.print(F("ADS1115,TMP102")); break;
    case 0x50: Serial4.print(F("EEPROM")); break;
    case 0x51: Serial4.print(F("EEPROM")); break;
    case 0x52: Serial4.print(F("Nunchuk,EEPROM")); break;
    case 0x53: Serial4.print(F("ADXL345,EEPROM")); break;
    case 0x54: Serial4.print(F("EEPROM")); break;
    case 0x55: Serial4.print(F("EEPROM")); break;
    case 0x56: Serial4.print(F("EEPROM")); break;
    case 0x57: Serial4.print(F("EEPROM")); break;
    case 0x58: Serial4.print(F("TPA2016,MAX21100")); break;
    case 0x5A: Serial4.print(F("MPR121")); break;
    case 0x60: Serial4.print(F("MPL3115,MCP4725,MCP4728,TEA5767,Si5351")); break;
    case 0x61: Serial4.print(F("MCP4725")); break;
    case 0x62: Serial4.print(F("LidarLite,MCP4725")); break;
    case 0x63: Serial4.print(F("MCP4725")); break;
    case 0x68: Serial4.print(F("DS1307,DS3231,MPU6050,MPU9050,MPU9250,ITG3200,ITG3701,LSM9DS0,L3G4200D")); break;
    case 0x69: Serial4.print(F("MPU6050,MPU9050,MPU9250,ITG3701,L3G4200D")); break;
    case 0x6A: Serial4.print(F("LSM9DS1")); break;
    case 0x6B: Serial4.print(F("LSM9DS0")); break;
    case 0x70: Serial4.print(F("AdafruitLED")); break;
    case 0x71: Serial4.print(F("SFE7SEG,AdafruitLED")); break;
    case 0x72: Serial4.print(F("AdafruitLED")); break;
    case 0x73: Serial4.print(F("AdafruitLED")); break;
    case 0x76: Serial4.print(F("MS5607,MS5611,MS5637,BMP280, BME280")); break;
    case 0x77: Serial4.print(F("BMP085,BMA180,BMP280,MS5611,BME280")); break;
    default: Serial4.print(F("unknown chip"));
  }
}
Notes:
1. Had to use serial4, when I tried nothing printed to Serial.
2. The scanner returned that there was a device at every address listed.
Code: 
Device found at address 0x02  (AS3935)
Device found at address 0x04  (unknown chip)
Device found at address 0x06  (unknown chip)
Device found at address 0x08  (unknown chip)
Device found at address 0x0A  (SGTL5000)
Device found at address 0x0C  (AK8963)
Device found at address 0x0E  (unknown chip)
Device found at address 0x10  (CS4272)
Device found at address 0x12  (unknown chip)
Device found at address 0x14  (unknown chip)
Device found at address 0x16  (unknown chip)
Device found at address 0x18  (LIS331DLH)
Device found at address 0x1A  (WM8731)
Device found at address 0x1C  (LIS3MDL)
Device found at address 0x1E  (LSM303D,HMC58/983L,FXOS8700,LIS3DSH)
Device found at address 0x20  (MCP23017,MCP23008,PCF8574,FXAS21002)
Device found at address 0x22  (MCP23017,MCP23008,PCF8574)
Device found at address 0x24  (MCP23017,MCP23008,PCF8574)
Device found at address 0x26  (MCP23017,MCP23008,PCF8574)
Device found at address 0x28  (BNO055,EM7180,CAP1188)
Device found at address 0x2A  (SGTL5000,CAP1188)
Device found at address 0x2C  (MCP44XX ePot)
Device found at address 0x2E  (MCP44XX ePot)
Device found at address 0x30  (unknown chip)
Device found at address 0x32  (unknown chip)
Device found at address 0x34  (unknown chip)
Device found at address 0x36  (unknown chip)
Device found at address 0x38  (RA8875,FT6206)
Device found at address 0x3A  (unknown chip)
Device found at address 0x3C  (SSD1306,DigisparkOLED)
Device found at address 0x3E  (unknown chip)
Device found at address 0x40  (PCA9685,Si7021)
Device found at address 0x42  (PCA9685)
Device found at address 0x44  (PCA9685)
Device found at address 0x46  (PCA9685)
Device found at address 0x48  (ADS1115,PN532,TMP102,PCF8591)
Device found at address 0x4A  (ADS1115)
Device found at address 0x4C  (unknown chip)
Device found at address 0x4E  (unknown chip)
Device found at address 0x50  (EEPROM)
Device found at address 0x52  (Nunchuk,EEPROM)
Device found at address 0x54  (EEPROM)
Device found at address 0x56  (EEPROM)
Device found at address 0x58  (TPA2016,MAX21100)
Device found at address 0x5A  (MPR121)
Device found at address 0x5C  (unknown chip)
Device found at address 0x5E  (unknown chip)
Device found at address 0x60  (MPL3115,MCP4725,MCP4728,TEA5767,Si5351)
Device found at address 0x62  (LidarLite,MCP4725)
Device found at address 0x64  (unknown chip)
Device found at address 0x66  (unknown chip)
Device found at address 0x68  (DS1307,DS3231,MPU6050,MPU9050,MPU9250,ITG3200,ITG3701,LSM9DS0,L3G4200D)
Device found at address 0x6A  (LSM9DS1)
Device found at address 0x6C  (unknown chip)
Device found at address 0x6E  (unknown chip)
Device found at address 0x70  (AdafruitLED)
Device found at address 0x72  (AdafruitLED)
Device found at address 0x74  (unknown chip)
Device found at address 0x76  (MS5607,MS5611,MS5637,BMP280, BME280)
Device found at address 0x77  (BMP085,BMA180,BMP280,MS5611,BME280)
Device found at address 0x79  (unknown chip)
Device found at address 0x7B  (unknown chip)
Device found at address 0x7D  (unknown chip)
3. Not sure if this is correct in the WireImxrt.cpp file:
Code: 
	IOMUXC_SW_MUX_CTL_PAD_GPIO_AD_B1_00, // 18/A4  AD_B1_01  GPIO1.17  I2C1_SDA
	IOMUXC_SW_MUX_CTL_PAD_GPIO_AD_B1_01, // 19/A5  AD_B1_00  GPIO1.16  I2C1_SCL
	IOMUXC_SW_PAD_CTL_PAD_GPIO_AD_B1_00,
	IOMUXC_SW_PAD_CTL_PAD_GPIO_AD_B1_01,
	IOMUXC_LPI2C1_SDA_SELECT_INPUT,
	IOMUXC_LPI2C1_SCL_SELECT_INPUT,
Shouldn't the sda/scl pins be reversed?
Code: 
IOMUXC_SW_MUX_CTL_PAD_GPIO_AD_B1_01, // 18/A4  AD_B1_01  GPIO1.17  I2C1_SDA
	IOMUXC_SW_MUX_CTL_PAD_GPIO_AD_B1_00, // 19/A5  AD_B1_00  GPIO1.16  I2C1_SCL
	IOMUXC_SW_PAD_CTL_PAD_GPIO_AD_B1_01,
	IOMUXC_SW_PAD_CTL_PAD_GPIO_AD_B1_00,

EDIT:Forgot the key piece. There is one i2c device attached to pin 18/19, an Adafruit BME280 with an address of 0x77 Without the sensor attached the sketch with return No I2C devices found
 
Last edited:
Shouldn't the sda/scl pins be reversed?
can you watch the I2C pins with scope or analyzer and see if you see CLK ?
does it work if you reverse the definitions?
 
does it work if you reverse the definitions
Click to expand...
Nope. Same behavior
can you watch the I2C pins with scope or analyzer and see if you see CLK ?
Click to expand...
Going to pull it out now and test after dinner. Getting tired and frustrated with something simple like the temp monitor. The fix for the clock frequencies was something simple and stupid on my part and took all day to figure out. DONT KNOW HOW PAUL DID ALL THIS!
 
Took a quick look at the rt1050 manual and a glimpse of the SPI code, not a priority but for notes
Code: 
	IOMUXC_SW_MUX_CTL_PAD_GPIO_B0_03 = 3 | 0x10; // SCK
	//digitalWriteFast(10, HIGH);
	//pinMode(10, OUTPUT);
	//digitalWriteFast(10, HIGH);
	LPSPI4_CR = LPSPI_CR_RST;
bit 1 & 2 of the IOMUX are listed as reserve, and after reset the CR is not touched at all so the bit needs to be cleared after reset
 
Got TEMPMONITOR sketch working so temps are being printed. Sketch was working because I made a real dumb mistake with the base address for the temp monitor registers:
Code: 
#define IMXRT_TEMPMON				(*(IMXRT_REGISTER32_t *)0x400F8180)
should be
Code: 
#define IMXRT_TEMPMON				(*(IMXRT_REGISTER32_t *)0x400D8180)

If I did all right the temp at 600Mhz I am getting is about 53degC. The temp from the EVKB was running at about 20degC cooler (33degC) but it was on a much larger board (heat sink?).

At 798Mhz the temp levels out at around 58-59 deg C.
 
No not yet just found it and was testing. I also hate pull requests - have to figure out how to update my version first.

EDIT: Ok Merge request submitted. Have fun. Haven't tried the interrupts yet just getting the temperatures as a first step.
 
In reference to post #130, I change the pin assignments as indicated and put a scope on it as @manitou suggested, my scope is giving me about 96.15 to 97.08khz freq for the 100Mhz specified:
Clock on pin 19
20181230_195409.png

Was having problems capturing SDA on 18:
20181230_201557.jpg
 
tonton81 said:
Code: 
    Serial4.print("D13: ");
    Serial4.println(digitalReadFast(13));

all the reads after toggling have been showing always 0 on the outputs for all 3 betas
Click to expand...

Might be leftover debugging code messing with pin 13. When I wrote the latest linker script (and you wouldn't believe how messy the earlier unreleased ones were) there were many startup problems. I ended up putting LED stuff in several places to figure out the crashes that happened before anything could start printing. There may also be some leftover LED stuff in the USB code. I tried to remove most of that stuff... but more cleanup is needed.

Please try input on a different pin.

Also remember pin 13 has the LED, so for a reliable logic high you need a low impedance drive on the pin. Weak pullups sometimes work, sometimes don't.
 
mjs513 said:
The fix for the clock frequencies was something simple and stupid on my part and took all day to figure out. DONT KNOW HOW PAUL DID ALL THIS!
Click to expand...

Oh, I can assure you I've had *plenty* of those over the last ~8 months! Hopefully I at least got them all fixed in the bootloader...
 
Re: post #6 bug analogWrite doesn't work on pin 1 (maybe others?)

problem in core_pins.h
#define CORE_PIN0_CONFIG IOMUXC_SW_MUX_CTL_PAD_GPIO_AD_B0_02
#define CORE_PIN1_CONFIG IOMUXC_SW_MUX_CTL_PAD_GPIO_AD_B0_03

FIX:
#define CORE_PIN0_CONFIG IOMUXC_SW_MUX_CTL_PAD_GPIO_AD_B0_03
#define CORE_PIN1_CONFIG IOMUXC_SW_MUX_CTL_PAD_GPIO_AD_B0_02

untested
Click to expand...
In regards to this I put a scope on pin0 and saw the signal on the scope if I used pin1 in the pwmServo library. Making the proposed change loses the signal from pin0 (on the T4) and there is no signal on Pin1 of the Teensy either.

If I change servo.attach from 1 to 0 I will see the signal on pin1 of the teensy. Confusing aint it. Think there is something else that has to be changed as well will have to look closer.

PWM.png
 
mjs513 said:
3. Not sure if this is correct in the WireImxrt.cpp file:
...
Shouldn't the sda/scl pins be reversed?
Click to expand...

I'll double check it later tonight.

Here's the code I used earlier for testing the Wire library. I had a 24LC02B EEPROM chip connected to pins 18 & 19. I would occasionally change the 4 numbers in dowrite() and watch the results change.

I did most of the testing with 4.7K pullup resistors, then near the end I removed the resistors and did a few more tests with only the chip's internal pullups (which I'm happy to say do work, but the rise times are just barely enough for 100 kHz).

Code: 
#include <Wire.h>
#include "debug/printf.h"
 
int led = 13;

void doread() {
  printf("doread\n");
  int retry=0;
  while (1) {
    Wire.beginTransmission(0x50); // EEPROM
    Wire.write(0);
    int r = Wire.endTransmission(false);
    if (r == 0) break;
    printf("error, r=%d\n", r);
    if (++retry > 10) return; // fail :(
  }
  printf("req\n");
  Wire.requestFrom(0x50, 4);
  printf("Wire read: %x,", Wire.read());
  printf(" %x,", Wire.read());
  printf(" %x,", Wire.read());
  printf(" %x\n", Wire.read());
}

void dowrite() {
  printf("dowrite\n");
  Wire.beginTransmission(0x50); // EEPROM
  Wire.write(0);
  Wire.write(0x69);
  Wire.write(0xFE);
  Wire.write(0x34);
  Wire.write(0xA5);
  Wire.endTransmission();
}

void setup() {
  pinMode(led, OUTPUT);
  digitalWrite(led, LOW);

  Wire.begin();
  doread();
  dowrite();
  doread();
}

void loop() {
  elapsedMillis t;
  digitalWrite(led, HIGH);
  t = 0;
  while (t < 2000) ; // wait
  //delay(2000);
  digitalWrite(led, LOW);
  delay(2000);
}
 
Thanks to everyone for so much testing today! It's a huge help. I've tried to go through today's messages and get all the outstanding bugs onto the list on msg #6. If I've missed anything, please add it to the list. (if anyone here needs "plus" member access to be able to edit, please email Robin directly)

I'm going to start my next major work session in about 6-7 hours. Planning to look into most of these bugs and hopefully get the USB serial output more stable.

@Kurt - on the hardware serial stuff, I want to move to a slightly different structure. Sorry, I don't have a clear picture yet. But the main goal are to implement the serialEvent stuff with EventResponder, to get the arrangement of files & weak symbols so serialEvent and polling from the fault handler doesn't cause the linker to always bring the memory for unused ports, and get to a single C++ class (like Arduino uses) with constexpr constructors (unlike Arduino - at least so far, someday I'm sure they'll embrace constexpr classes).
 
mjs513 said:
feels like deja vu from running these tests on the Arduino 101 (Curie) board years ago
Click to expand...

Yeah, but I'm not going to drag this out for over a year and repeatedly try to deny there's any problem when things clearly aren't working, like Intel's engineers did.
 
PaulStoffregen said:
@Kurt - on the hardware serial stuff, I want to move to a slightly different structure. Sorry, I don't have a clear picture yet. But the main goal are to implement the serialEvent stuff with EventResponder, to get the arrangement of files & weak symbols so serialEvent and polling from the fault handler doesn't cause the linker to always bring the memory for unused ports, and get to a single C++ class (like Arduino uses) with constexpr constructors (unlike Arduino - at least so far, someday I'm sure they'll embrace constexpr classes).
Click to expand...

Hi Paul, currently my experiments are using single class, like I started awhile ago (about a year) fore 3x...

I put link to fork showing my current stuff in the posting https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=194055&viewfull=1#post194055

But trying to debug simple virtual function issue...
 
Yeah, but I'm not going to drag this out for over a year and repeatedly try to deny there's any problem when things clearly aren't working, like Intel's engineers did.
Click to expand...
Yeah tell me about it. That is also about the time I converted over to pretty much using Teensy's for everything. At least I got help and things got fixed if broken.

Anyway back to the fun, enough reminiscing, I attached the fram and the scanner still didn't recognize the chip but I got this off the scope using one of the test sketches. Going to do more tomorrow - can't see anymore.
FRAMtest2.png

EDIT: Just a quick update - last for the night I promise :) I just ran your test sketch, just printed zeros so tomorrow will try the pullups
 
Last edited:
Status
Not open for further replies.
Back
Top