Teensy 4.0 First Beta Test

Status
Not open for further replies.
@Frank B (I think) - I think I remember you posting (several pages ago) that there was an issue with how some Hardware Serial was working with parity... My quick look did not find the posting, but...

So did another quick test:
Code:
void setup() {
  delay(1000);
  Serial4.begin(115200);  // used for debug output.

  Serial1.begin(115200, SERIAL_8N2);
  Serial2.begin(115200, SERIAL_7E1);
  Serial3.begin(115200, SERIAL_7O1);
  Serial5.begin(115200, SERIAL_8N1_RXINV_TXINV);
  
  Serial4.println("Enter text to echo...");
}

void loop() {
  while (Serial4.available()) {
    char ch = Serial4.read();
    Serial1.write(ch);
    Serial2.write(ch);
    Serial3.write(ch);
    Serial4.write(ch);
    Serial5.write(ch);
  }

}
Then ran it, checked out the different outputs using Logic Analyzer:
screenshot.jpg
I set all of the Serial Analyzers to the expected settings and I believe all of these worked.

Let me know if I missed something. Still need to setup and try to do some of the 9 bit code.
 
@Paul

Post #1 UPDATE SUMMARY for libraries tested so far:

Code:
works       Adafruit_GFX             Teensyduino library version needs to be updated to latest from Adafruit

works       Adafruit_ILI9341         Teensyduino library version needs to be updated to latest from Adafruit

works       CapacitiveSensor         tested post [URL="https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=195470&viewfull=1#post195470"]#850[/URL]

works       EasyTransfer             post [URL="https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=194954&viewfull=1#post194954"]#621[/URL],

partial     EasyTransferI2C          needs I2C slave address, see post [URL="https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=194954&viewfull=1#post194954"]#621[/URL]

works       FreqMeasure              post [URL="https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=194641&viewfull=1#post194641"]#464[/URL]

works       ResponsiveAnalogRead     post [URL="https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=195108&viewfull=1#post195108"]#677[/URL], Teensyduino version needs to be updated    

works       Talkie                    post [URL="https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=195108&viewfull=1#post195108"]#677[/URL], Teensyduino version needs to be updated

            NXPMotionSense            Needs EEPROM.h to compile

Before anyone asks I don't have permission to edit post #1.

<EDIT UPDATE> Mike check the update work:: post #4 for these items ... Mike "Sr+" allows edit - Paul noted as Beta tester, IIRC, you can ask Robin for an upgrade to Sr+.
 
Last edited by a moderator:
Yep - As I mentioned in #839 there may be some real hacking available to try out. Also forget to mention, that I believe @Frank is maybe working on a DMA version, like his ili9341_dma...
Kurt,
I was running with your new SPI stuff with missing defintions pasted in, and it was working with my simple SPI sketch. But I just tried to build SerialFlash listfiles example and I get SPI compile errors. Maybe I didn't hack everything that needed to hacked. Can you try compiling listfiles example?
(SerialFlash stuff had been working with beta7 SPI)

Code:
/u1/home/linux/arduino-1.8.8/hardware/teensy/avr/libraries/SerialFlash/SerialFlashChip.cpp: In static member function 'static bool SerialFlashChip::begin(SPIClass&, uint8_t)':
/u1/home/linux/arduino-1.8.8/hardware/teensy/avr/libraries/SerialFlash/SerialFlashChip.cpp:338:10: error: use of deleted function 'SPIClass& SPIClass::operator=(const SPIClass&)'
  SPIPORT = device;
          ^
In file included from /u1/home/linux/arduino-1.8.8/hardware/teensy/avr/libraries/SerialFlash/SerialFlash.h:32:0,
                 from /u1/home/linux/arduino-1.8.8/hardware/teensy/avr/libraries/SerialFlash/SerialFlashChip.cpp:28:
/u1/home/linux/arduino-1.8.8/hardware/teensy/avr/libraries/SPI/SPI.h:1119:7: note: 'SPIClass& SPIClass::operator=(const SPIClass&)' is implicitly deleted because the default definition would be ill-formed:
 class SPIClass { // Teensy 4
       ^
/u1/home/linux/arduino-1.8.8/hardware/teensy/avr/libraries/SPI/SPI.h:1119:7: error: non-static const member 'IMXRT_LPSPI_t* const SPIClass::port', can't use default assignment operator
/u1/home/linux/arduino-1.8.8/hardware/teensy/avr/libraries/SPI/SPI.h:1119:7: error: non-static const member 'const SPIClass::SPI_Hardware_t* const SPIClass::hardware', can't use default assignment operator
Error compiling for board Teensy 4-Beta1.
 
Note that if you don't run Serial.begin(x) and attempt to write to Serial a couple times this would cause faults on T4, doesnt happen on T3.

Code:
void loop() {
  delay(500);
  Serial.println("HELLO WORLD");
}

the debug spew on Serial4 shows the crash
Code:
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
status = 00020080
 
@manitou / @KurtE

Getting same error with serialFlash on my machine and I am pretty sure I pulled everything in.
 
FWIW, a few weeks back working on NXP EVK eval board, I got this bits/c++config.h error when trying to use the Arduino tool chain to test gcc 5.4.1 on EVKB programs. Eventually I fetched a fresh 5.4.1 tool chain from GNU and the problem disappeared.

Were you able to get an Arduino built .hex file to load into the EVK?
I am trying to use a J-Link to flash the EVK with an Arduino hex file, it looks successful, but does not execute successfully. I am trying both a simple UART (using LPUART1/Serial6 for the UART/USB bridge) or LED blink example, which has to adapt pin13 to use the correct pin on the EVK for the user LED (GPIO_AD_B0_09 instead of GPIO_B0_03) .
 
@manitou / @KurtE

Getting same error with serialFlash on my machine and I am pretty sure I pulled everything in.

Same here ;)

Note: with c++ I am not sure sometimes on how these operators should work with things passed by reference...

That is: Serial flash has:

Code:
static SPIClass& SPIPORT = SPI;

bool SerialFlashChip::begin(SPIClass& device, uint8_t pin)
{
	SPIPORT = device;
	return begin(pin);
}
so it tries to assign a reference to another reference...
My few times when I used references with classes, I only typically assigned a reference as part of a constructor...
That if I wanted to assign it later. I would then need to convert it to pointer.

Not sure in this case if I need to convert the references to hardware-> and port-> to hardware to hardware(). and port(). like what was done for Teensy 3.x?
May try that as a quick hack to see if that makes a difference.
This implies that I would need to also change the constructors plus the variables stored...
 
Hi all, the flexcan MCR issue is ressolved, so can be crossed off the list, guess T4 will have a new library in future. Although most of the code is same as IFCT there are still subtle differences. We also currently lack teensythreads so polling mode and interval timer would be alternative, any name suggestions? :p

Will probably keep the same object calls as Can0 and Can1 for legacy, and CanFD for the 3rd object
 
Last edited:
Before I spend the next couple of hours search for the answer to this question, is there a way to enable std::threads (I am on a windows machined)?
 
Were you able to get an Arduino built .hex file to load into the EVK?
I am trying to use a J-Link to flash the EVK with an Arduino hex file, it looks successful, but does not execute successfully. I am trying both a simple UART (using LPUART1/Serial6 for the UART/USB bridge) or LED blink example, which has to adapt pin13 to use the correct pin on the EVK for the user LED (GPIO_AD_B0_09 instead of GPIO_B0_03) .

No. I never tried anything like that. My comments about the Arduino tool chain was merely to use the GNU g++ in my Arduino/teensyduino folders to compile EVKB program exported from the mbed on-line compiler. So I was just modifying a Makefile to point to a gcc toolchain.
 
SerialFlash issue with SPI...

I just checked in a change that at least makes it compile on my machine... Uses port() and hardware() functions like T3.x...

I issued PR: https://github.com/PaulStoffregen/SPI/pull/42

Changes in the branch: https://github.com/KurtE/SPI/tree/T4-SerialFlash-fix

Did quick test to make sure one of my SPI tests still ran.

Edit: But still wonder how references work here. In particular: SPIPORT = device;

That is if I have simple app working with ints and references like:
Code:
void setup() {
  delay(500);
  Serial4.begin(115200);
  delay(1000);
  int x = 100;
  int y = 200;

  int &ref_x(x);
  int &ref_y(y);

  ref_x = ref_y;

  Serial4.printf("%d %d %d %d\n", x, y, ref_x, ref_y);

  ref_x = 300;

  Serial4.printf("%d %d %d %d\n", x, y, ref_x, ref_y);
}

void loop() {
}
It does what I expect: that is the print out is:
Code:
200 200 200 200
300 200 300 200

So to me if I passed in device = SPI2. The line SPIPORT = device;
Would try to do the same thing as SPI = SPI2; ...
But maybe works different wit constexpr init classes...
 
Last edited:
No. I never tried anything like that. My comments about the Arduino tool chain was merely to use the GNU g++ in my Arduino/teensyduino folders to compile EVKB program exported from the mbed on-line compiler. So I was just modifying a Makefile to point to a gcc toolchain.

OK, Thanks for confirming. It looks like the linker file needs to have modifications to include the code for the flash memory drivers of the EVKB
 
Sorry, could'nt do much this weekend (have a family member in hospital, again.. since friday - wasn't planned.)
I have some code for SPI.
It calculates PODF, so that the set SPI clock is near as possible to the requested clock - but never higher (remember the excel-sheet I posted some days ago).
This gives max. flexibility for the clock.
I don't do a pulrequest -don't want to confuse the things more...
But maybe you want to test it ?
Code:
    void init_AlwaysInline(uint32_t clock, uint8_t bitOrder, uint8_t dataMode)
      __attribute__((__always_inline__)) {
        // TODO: Need to check timings as related to chip selects?

        if (clock == 0) clock = 1;
        const uint32_t pll2 = 528000000;
        int32_t mf = pll2;
        uint32_t div = 0;
        uint32_t podf = 0;        
        uint32_t pmax = min(pll2 / clock, 8U);
        for (uint32_t p = 1; p <= pmax; p++) {
            uint32_t clkhz = pll2 / p;  
            uint32_t d = clkhz / clock;
            if (d > 257) continue;
            if (clkhz / d == clock) { podf = p; div = d; break; }
            d++;
            if (d > 257) continue;
            uint32_t c = clkhz / d;
            int32_t e = clock - c;
            if (e <= mf ) { podf = p; div = d; mf = e; }
        }        
        if (podf == 0) podf = 1;
        if (div > 2) {
            div = div - 2;
        } else {
            div =0;
        }
        Serial.printf("C:%d, P:%d, D:%d\n", clock, podf-1, div);
        CCM_CCGR1 &= ~CCM_CCGR1_LPSPI4(CCM_CCGR_ON); //Clock Gate off
        CCM_CBCMR = (CCM_CBCMR & ~(CCM_CBCMR_LPSPI_PODF_MASK | CCM_CBCMR_LPSPI_CLK_SEL_MASK)) |
            CCM_CBCMR_LPSPI_PODF(podf - 1) | CCM_CBCMR_LPSPI_CLK_SEL(2); // pg 714        
        CCM_CCGR1 |= CCM_CCGR1_LPSPI4(CCM_CCGR_ON); //Clock Gate on
...
..
This is for SPI.h - in SPI.CPP, the setting of CCM_CBCMR should be removed to make this work.
The code looks longish, but is fast - max. 8 loops.

Edit: There were long gaps between SPI-transfers of bytes - is that solved?
 
@Frank B

Remember family comes first, always, hope everything will ok.

I incorporated you change but got some strange stuff going on. First, I used a scope to look at the signals:

input 30Mhz = 29.41Mhz on scope, the CS pin had period = 2.14 us and looked good, data looked good on MOSI
input 15Mhz = 14.7Mhz , the CS pin had period =2.94us, no data on MOSI
8mhz - takes exceeding long to run, no clock signal, nothing

Input 500khz = 500khz , CS pin had period == 48.4us, no data on MOSI

Not sure whats going on, hope I incorporated correctly.

Mike
 
I saw a note recently printing to Serial USB causing a Fault issue? I tested that before [post #196] and didn't see it - just updated a test and still not seeing it - with or without .begin() I can get between ~200 to 300 of these messages that are buffered before and then displayed when Serial USB connects without issue:
292 EARLY No .begin()!!!abcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
with:
Code:
  while ( !Serial ) if ( !(millis() % 1) ) { ii++; Serial.printf( "\n%d EARLY No .begin()!!!abcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ",ii ); }

Sometimes I get weird faults - with the Optional PJRC BreakoutBoard adapter it seems to resolve when the POGO pins unseat the T4 enough on some sketches. [that may also been with hub below?]

There is a rewrite of Serial USB planned - will revisit later. NOTE: On my system I have debug Serial#4 off so I could use all 8 UARTS to run KurtE's test [ that worked perfectly over 1.07 million iterations at 2 Mbaud with data sent out #1 and chained through each to #8 and back to Serial1 where it was value checked.]

I got a NEW USB 3 'Amazon BASICS' hub - it was taking my Serial Start times to/over 2200 ms! My old USB2 hub was better ( it had that soft touch plastic that has turned gummy so I wanted to swap it out ) - right now with setup() entry at 300 with last beta change to CORE Serial on direct USB3 port is online about 520 ms.

Also saw FrankB's note and hoping all works out as well as it can.

Paul - do you have a goal release date for Beta #8?

On the Optional PJRC BreakoutBoard adapter 10 top and 6 bottom Serial# pins are there and then I find only #'s:10,12,18,19 present on the headers. No #11? And T4's #13 is brought to #14. I see some black boxes underneath that may have affected my DMM testing? That allows i2c - but short of pins for SPI without going back to breadboard?

Quick Note on Paul's good work - the T4 seems good and stable - 2 weeks now powered on with some code running 24/7 and no issues - except for when I've been doing something confusing it or Windows. I soldered on 5 end pin headers - removed them and soldered a re-oriented set on and all is well, Tim
 
Last edited:
@Paul

NEWPING and STREAMING and PING Libraries

NEWPING => simple modification to get T4 working - simple now after you all taught me a few things :)

STREAMING => worked out of the box

Can't find my PING sensor to test the PING library.

EDIT: As a hack I put the trig and echo pins on the same pin to test the PING library and it's working. Finally looked at the code as the code as well.
 
SerialFlash issue with SPI...

I just checked in a change that at least makes it compile on my machine... Uses port() and hardware() functions like T3.x...

OK, i fetched your new branch and hacked in missing def's (imrxt.h), and serialflash stuff compiled and ran. My other little SPI benchmark was OK too.

thanks
 
@Paul

NEWPING and STREAMING and PING Libraries

NEWPING => simple modification to get T4 working - simple now after you all taught me a few things :)

STREAMING => worked out of the box

Can't find my PING sensor to test the PING library.

EDIT: As a hack I put the trig and echo pins on the same pin to test the PING library and it's working. Finally looked at the code as the code as well.

As I recall ping lib uses pulseIn() which in turn uses micros(). But on T4, micros() only has 10us resolution :( so I wonder how ping distance calculations are affected. (i'd really prefer systick ran at current CPU clock speed so we could get microsecond resolution from micros(). if CPU clock is changed, function could take care of updating systick rate.)
 
Last edited:
ILI9341_t3 or ILI9341_t3n and SPIN? and/or maybe flex_spi?

Currently trying to decide which thing to play with next...

As I mentioned yesterday I have some ideas on how maybe to make ili9341_t3 to hopefully work pretty fast.... But I think others are playing with this library.
So maybe instead I will hack up my own version ili82341_t3n to see if I can get parts of this to work instead. This also relies on my SPIN library.

One of the reasons I may start here is I already had code in place to for example use different SPI objects other than only supporting SPI.
I will at least try it out to see how much needs to be done.
 
@manitou
As I recall ping lib uses pulseIn() which in turn uses micros(). But on T4, micros() only has 10us resolution so I wonder how ping distance calculations are affected. (i'd really prefer systick ran at current CPU clock speed so we could get microsecond resolution from micros(). if CPU clock is changed, function could take care of updating systick rate.)
Yep you are right - it uses pulseIN and microseconds. Unfortunately, I only have a 4 pin sensor vs a PING (3pin sensor) so data coming out is unreliable - I am using the trig and echo pin on the single PING sensor pin. NewPING just uses micros so it would have the 10us issue as well. If memory serves correct the micros function is on the todo list.
 
Edit: There were long gaps between SPI-transfers of bytes - is that solved?

I have not worked on SPI yet,
but you question reminds me on a SPI problem I had recently with another M7 (Allwinner A20; Linux) where SPI clock was only active while transmitting a byte, resulting in a very low data rate due to time needed between bytes. Maybe there is a flag to let clock running while data are in queue.
 
@Frank B and @WMXZ - SPI Timings...

IN some ways I slowed down SPI Transfers. That is I put in a delay between transfers. That is look at the SPISettings at the compute of the clock..
There is currently a setting: ccr = LPSPI_CCR_SCKDIV(div) | LPSPI_CCR_DBT(div/2);

That DBT setting where it appears like div/2 is pretty close... But should maybe be figured out better. Again note the //TODO: figure out ...

The issue is before this: if you did something like:
Code:
SPI.transfer(0);
SPI.transfer(1);
It looked pretty good, with little delay... The problem is if you do something like:
SPI.transfer(buf, cnt);
The clock signal was bad (like 1 or 2 clocks)
Without this setting the first case looks OK, but the timing delays are do to the overhead.

That is the SPI.transfer(x) command pushes value onto queue and then waits until the value has been completely output, then waits for data to be ready to read in, returns it, and then does all of the normal overhead for calls and the like.

We might be able to hack this value to be different if we are doing single transfer() versus buffer transfer.

I have not yet put in CS clock delays as so far don't have CS enabled... May play with that as part of my trying to use the hardware CS for DC...
 
Status
Not open for further replies.
Back
Top