Teensy 4.0 First Beta Test

Status
Not open for further replies.
Changing -fsingle-precision-constant sounds like fun - across all 32b Teensy boards?

Teensy 3.x isn't changing.

And on those 3.x boards without 64 bit support in the FPU, you take a massive hit in performance for any constant without the "f" suffix, because the compiler automatically promotes each intermediate result in an equation to full 64 bits.

On Teensy 4, we can expect this performance impact to be about 50% speed. Maybe? I'm a little concerned it may be worse if the conversions from 32 to 64 have extra overhead.
 
I still have to push the program button afer an upload.

I've asked Robin to send you a replacement. You should hear from her tomorrow. After you've got a new one, I want to get the board back here so I can look into what went wrong.

I just tested the replacement board here. It definitely auto-reboots on Ubuntu 18.04 64-bit.
 
Another sort of generic question: What state to set IO pins when you call some subsystems ::end method
....
So far I am not seeing us doing anything on T4 yet. So question is what should we do? Try to emulate T3, where each type is different?

EDIT: Also what is a disabled and/or default state on T4 0?

EDIT2: I know looking at the PDF file that for some of these pins the default is MUX_MODE = 5, could default to this, or could build that into my HardwareTable (SerialX objects). Probably likewise for Wire, SPI...

Looks like we don't get a disable state in this chip. I've been setting them back to mux = 5. But maybe it should be 0x15, so the input path bit is set? I'm not 100% sure - don't have all the answers here.

The pad config register is the other issue. The pins default to input keeper mode. That's a nice feature for many things, but not sure how I feel about it with serial. I'm guessing we probably want weak pullup on the receive pins?

But these are fairly minor issues. I wouldn't lose any sleep over them right now.
 
As I believe a lot of the USB serial code may be updated maybe this week? ...

Yes. I had meant to do audio this weekend and USB next week, but I'm now way behind where I wanted to be. :(

I'm going to look into several more bugs recently reported, fix as many as I can and roll all that up into beta7. Then look at USB & audio, but the idea is to get beta7 with as many fixes as possible before messing with new USB code.


Again I know I can copy some of the stuff from onewire to fix... But wondering if some of the OneWire stuff maybe should be defined in Core?

Oh, that's a complicated matter for another day! Really doesn't make much sense unless we coordinate on an API with the all the other boards (maybe even Arduino too, but I've kind of given up hope they'll ever care about this).
 
Teensy 3.x isn't changing.

And on those 3.x boards without 64 bit support in the FPU, you take a massive hit in performance for any constant without the "f" suffix, because the compiler automatically promotes each intermediate result in an equation to full 64 bits.

On Teensy 4, we can expect this performance impact to be about 50% speed. Maybe? I'm a little concerned it may be worse if the conversions from 32 to 64 have extra overhead.

Indeed ... have been following that - but the 3.x unchanged wasn't clear - having the default in one different from the other means the same sketch would act differently numerically was where I was headed. Though T4 and after will be unique and must have a way to get full 64b.


I pulled down current cores - is Mike's code on tap for :: void analogReadRes(unsigned int bits) { }
 
KurtE/Paul - with the github/CORE I got earlier today I find this to be working on Serial 2 and 3 with them looped to themselves.

You'll note the added explicit call to "HardwareSerial::processSerialEvents();" is required or a call to yield(); or delay(1); as this code doesn't call yield() [it works when I added it]::
Code:
startup.c :: void ResetHandler(void)
{
    // ...
	while (1) {
		//printf("loop\n");
		loop();
	}

I put this same code in my larger cross/loop Serial 1/5 & LedControl & IntervalTimer sketch and all four Serial# ports are running together without problem/error at 5Mbaud - I have not found a faster number that works yet.

Working sketch::
Code:
#define SERIALX2 Serial2
#define SERIALX3 Serial3

void serialEvent2() {
  //SERIALX2.disableSerialEvents();
  while (SERIALX2.available()) {
    char ch = SERIALX2.read();
    Serial.write(ch);
  }
}
void serialEvent3() {
  // SERIALX3.disableSerialEvents();
  while (SERIALX3.available()) {
    char ch = SERIALX3.read();
    Serial.write(ch);
  }
}

elapsedMillis noDelay;
void setup() {
  while ( !Serial && millis() < 800 ) ;
  pinMode(13, OUTPUT);
  SERIALX2.begin(5000000);
  SERIALX2.enableSerialEvents();
  SERIALX3.begin(5000000);
  SERIALX3.enableSerialEvents();
  SERIALX2.print( "22222" );
  SERIALX3.print( "33333" );
  noDelay = 0;
}

void loop() {
  // put your main code here, to run repeatedly:
  if ( noDelay > 1000 ) {
    Serial.print( " ... " );
    Serial.println( millis() );
    SERIALX2.print( "22222" );
    SERIALX3.print( "33333" );
    noDelay = 0;
  }
 [B][U] HardwareSerial::processSerialEvents();[/U][/B]
}

Output::
2222233333 ... 1448
2222233333 ... 2452
2222233333 ... 3456
2222233333 ... 4460
 
<edit>: Mike - just glanced at Talkie code - did you alter the PWM frequency? They indicate 62500Hz for PWM. (is that working yet?) I see the AVR stuff in there - but it is the AVR method - suppose it would just be a lesser pin: analogWrite(A8, nextPwm); and that shows as 'PWM4_A0' or maybe Pin_3 common to Arduino that also has 'PWM4_B2' indicated?

Morning Tim. Gave it a try and looked through the code but was getting too late so I stopped for the night. Was going to really look at the code today and see if I can get it working. Like you said, probably pin3. Ok, have to restart my computer.

Yes frequency stuff is working, https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=194622&viewfull=1#post194622.

EDIT: just saw your other post, think Paul already incorporated the PR analogReadRes and averaging on GitHub so if you downloaded it you should have the latest.
 
Morning Tim. Gave it a try and looked through the code but was getting too late so I stopped for the night. Was going to really look at the code today and see if I can get it working. Like you said, probably pin3. Ok, have to restart my computer.

Yes frequency stuff is working, https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=194622&viewfull=1#post194622.

I thought I saw that go by as working - so much going by - with this as post #559. Speaking of late and stopping for the night … today is almost 3 hours old …

Pulled the CORE as noted - hoped to see your readFreq code there to retry that sketch … just {} :)

Nice that EventResponder working with Serial - a shame it so much like SerialEvents from yield() - but then again arbitrary calls with random interruptions would be ugly.
 
PDB equivalent?
The Teensy 3 PDB timer was real handy for clocking peripherals (ADC, DAC, ...). Is there a timer or other mechanism on T4 for doing what PDB did?
 
Pulled the CORE as noted - hoped to see your readFreq code there to retry that sketch … just {}
The two functions I put in (analogWriteRes and AnalogReadAveraging - are in the core. Do we need a analogReadFreq?

Nice that EventResponder working with Serial - a shame it so much like SerialEvents from yield() - but then again arbitrary calls with random interruptions would be ugly.
Remember, reading about using eventresponder for serial way back when in the eventresponder thread. So I agree it is nice!

TALKIE LIBRARY: Got it working, two simple changes using pin3. (1) set up an if define for the RT1052 and (2) added analogWriteFrequency(3, 62500). Now its working. Guess its a pull request to the teensy library, only thing is the examples may need notes in them, since you don't have make pin5 high anymore for the propshield - that one now sure how to handle, unless it gets moved to the .cpp?
 
PDB equivalent?
The Teensy 3 PDB timer was real handy for clocking peripherals (ADC, DAC, ...). Is there a timer or other mechanism on T4 for doing what PDB did?

Pretty much any of the unused FlexPWM or QuadTimer sub-modules can be used, by routing their signals through the XBAR.
 
On my todo list is coming up with an unofficial list of which libs are using which timer resources.....

Hopefully we can mostly avoid conflicts where 2 different libraries need the same module for internal triggering.
 
Some update from the SAI front

Trying to get SAI2 working I run into some issues.
first, internal logic (SAI2 triggering DMA seems to work properly)
but I cannot observe any clock signal on the ports

Solved.
The pin_mux of sai2 was wrong, should be 2 and not 3

Code:
    CORE_PIN5_CONFIG  = 2;  //2:MCLK
    CORE_PIN4_CONFIG  = 2;  //2:TX_BCLK
    CORE_PIN3_CONFIG  = 2;  //2:TX_SYNC
    CORE_PIN2_CONFIG  = 2;  //2:TX_DATA0
    CORE_PIN33_CONFIG = 2;  //2:RX_DATA0
 
Perhaps things will be even more weird when we try to *read* data that was written by DMA...
If this does not work reliable we might even have to disable the cache for these areas.

Thanks for the code, manitou!!

Edit: I found a more detailed description:

DSB in IRQ handler:

Just a follow up on use of DSB. In several of my T4 ISR handlers where I clear the interrupt flag, I would get double interrupts (as noted by tick++ in ISR), so for correct behavior, I would either have to spin waiting for the device interrupt flag to clear (69 cycles) or use DSB (asm volatile ("dsb")) which took 37 cycles. Measured with ARM_DWT_CYCCNT.
 
random is on the bug list. Compiling speedTest fails because no random(). Just copying cores/teensy3/WMath.cpp to cores/teensy4 fixes the problem, but i'm thinking there must be more to it?? The Teensy 4 TRNG is quite complicated, though the NXP SDK has working code. Was the intent for the "random" bug to try to incorporate T4 TRNG???

finding random()


I need another set of eyes to solve what should be a simple mystery. I dutifully copied WMath.cpp into T4 core to get random() to work, giving same numbers as on Teensy 3. I just recently wanted to confirm that randomSeed() was ok. T4 and T3.2 behave the same when using randomSeed(), BUT changing the seed on T4 or T3 has no effect on the values returned from random() ???? So then I ran the random() code from WMath.cpp on linux, and the random numbers don't match what T4 and T3.2 are generating --- SO it appears there is another random() hidden in the core/libraries. Where ?

EDIT: it appears that srand() does change the seed for both random() and rand(). random() and rand() on T3 and T4 return the same values. random()/randomSeed() work OK on AVR Teensy2*. Maybe T3/T4 randomSeed() should just call srand() ? T3/T4 using newlib rand() ?

UPDATE: here is what I would use for WMath.cpp on the T3 and T4.
Code:
/*
  Part of the Wiring project - http://wiring.org.co
  Copyright (c) 2004-06 Hernando Barragan
  Modified 13 August 2006, David A. Mellis for Arduino - http://www.arduino.cc/

  This library is free software; you can redistribute it and/or
  modify it under the terms of the GNU Lesser General Public
  License as published by the Free Software Foundation; either
  version 2.1 of the License, or (at your option) any later version.

  This library is distributed in the hope that it will be useful,
  but WITHOUT ANY WARRANTY; without even the implied warranty of
  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
  Lesser General Public License for more details.

  You should have received a copy of the GNU Lesser General
  Public License along with this library; if not, write to the
  Free Software Foundation, Inc., 59 Temple Place, Suite 330,
  Boston, MA  02111-1307  USA
*/

#include <stdint.h>
#include <stdlib.h>


void randomSeed(uint32_t newseed)
{
	srandom(newseed);
}

uint32_t random(uint32_t howbig)
{
	if (howbig == 0) return 0;
	return random() % howbig;
}

int32_t random(int32_t howsmall, int32_t howbig)
{
	if (howsmall >= howbig) return howsmall;
	int32_t diff = howbig - howsmall;
	return random(diff) + howsmall;
}

unsigned int makeWord(unsigned int w) { return w; }
unsigned int makeWord(unsigned char h, unsigned char l) { return (h << 8) | l; }
This uses 64-bit linear congruential PRNG from stdlib (newlib), and randomSeed() calls srandom(). Random numbers match those from other MCU/ARM tool chains.
 
Last edited:

DSB in IRQ handler:

Just a follow up on use of DSB. In several of my T4 ISR handlers where I clear the interrupt flag, I would get double interrupts (as noted by tick++ in ISR), so for correct behavior, I would either have to spin waiting for the device interrupt flag to clear (69 cycles) or use DSB (asm volatile ("dsb")) which took 37 cycles. Measured with ARM_DWT_CYCCNT.

This is very interesting to read: https://community.arm.com/processor...-dsb-isb-on-cortex-m3-m4-m7-single-core-parts
 

finding random()


I need another set of eyes to solve what should be a simple mystery. I dutifully copied WMath.cpp into T4 core to get random() to work, giving same numbers as on Teensy 3. I just recently wanted to confirm that randomSeed() was ok. T4 and T3.2 behave the same when using randomSeed(), BUT changing the seed on T4 or T3 has no effect on the values returned from random() ???? So then I ran the random() code from WMath.cpp on linux, and the random numbers don't match what T4 and T3.2 are generating --- SO it appears there is another random() hidden in the core/libraries. Where ?

NEWLIB maybe??
 
Maybe a C vs C++ namespace issue on random() ?

I'm going to leave this until beta8. Looks like we may have a long history of not using the correct random(). Will look into this soon, but right now there's been a ton of little fixes, so I'm going to package up beta7 with everything we have so far.
 
More sensor library testing:

LCDControl Library: Couldn't resist ordering that LED strip that defroster reference in his post on LEDcontrol. Gave it a try and it still works :) Pretty neat,

Sparkfun TMP102 (i2c): Sparkfun's library works fine no issue;

VL53L0X Range Library: Adafruits works, Pololu's Arduino Library does not work with the T4, the LED blinks brightly and rapidly. But it does work with T3.5's that I tested it on.
 
beta7 quick tests:
-did a few loop back tests on Serial1, Serial3 ... but what is the mapping from Serialx to UARTn (or pin numbers)?? Add to post #3
-I have one float benchmark (lat-lon to UTM) that has a few floating constants. On beta6 duration was 4230 us, on beta 7 4260 us -- not much difference
-SPI clock settings look to be working with SPISettings
-analogWrite on 0 and 1 have correct duty polarity
 
Last edited:
Status
Not open for further replies.
Back
Top