Teensy 4.0 First Beta Test

Status
Not open for further replies.
Hi Paul - Not needed for T4, but might at some point pull in
https://github.com/PaulStoffregen/USBHost_t36/pull/23

As this fixes the Mouse to work on some combo units from Microsoft and Logitech - The first fix for the gigabyte keyboards was to always set the keyboards into BOOT mode, which worked fine for all keyboards I tried. However it had the side effect on the wireless combo units of causing the Mice to also change which caused at least some of them not to work...

As related question - Have you looked at doing USB Host stuff on this board? And if so how much different is it than T3.6.
 
UPDATE: Nevermind - not working tested on pins 8/9 and 10/11 but if someone wants to double check. Not sure what pins are going to be allowed

Found my answer and now I understand the code:
So guess the same applies to T4.

Re: SoftwareSerial

You could add pin checks for backside UART's. I think it is supposed to work with non-uart pins too, but the code uses F_CPU and cycle counts, so that would need some T4 adjustments. Lib has magic cycles count WORST_INTERRUPT_CYCLES ?? which might need T4 adjustment. One wonders for code that depends on cycle counts, how do the various compiler optimizations (Fast Faster Fastest ...) affect cycle count loop delays ??

Correction: I had never tried SoftwareSerial on Teensy 3* -- it seems it only works on UART ports as you noted.
 
Last edited:
Think I got it working - can someone verify for me. Here are the files new files:
View attachment 15696

Thanks

UPDATE: Nevermind - not working tested on pins 8/9 and 10/11 but if someone wants to double check. Not sure what pins are going to be allowed

Found my answer and now I understand the code:
So guess the same applies to T4.

I think that this might be a valid first approach. However I was also thinking that this might also be another interesting place to try out FLEXIO.
That is a lot of the IO pins have FlexIO pins associated with them. And if you look at about page 2732 in newer PDF you see that for Transmit requires one Timer, one shifter and one pin. Likewise receive also takes one timer, shifter, pin... Maybe more stuff if you wish to support RTS/CTS signals...

At one point I was starting on trying to setup a FLEXIO SPI, but lost it...

Was also wondering about has anyone setup any more generic setup for managing Flex IO objects.
That is it looks like with have 3 FLEXIO units as you can see in table where some of the pins are marked 1:n, 2:n, 3:n... Each of these units have 4 timers, shifters, compares? So would be good if I said I wanted to create a

Flex UART Transmit on pin 2, there would be a set of calls, where it says: Pin 2 is FlexIO 1:4

And then the FlexSerial would ask for a free Timer on unit 1 as well as a free shifter on unit 1... Where then it could do the configuration stuff to use those items...
There are some complications, like for some objects that need two timers. The are needed to be N and N+1, so probably need to the API to ask for two...

Thoughts?
 
I think that this might be a valid first approach. However I was also thinking that this might also be another interesting place to try out FLEXIO.
That is a lot of the IO pins have FlexIO pins associated with them. And if you look at about page 2732 in newer PDF you see that for Transmit requires one Timer, one shifter and one pin. Likewise receive also takes one timer, shifter, pin... Maybe more stuff if you wish to support RTS/CTS signals...

At one point I was starting on trying to setup a FLEXIO SPI, but lost it...

Was also wondering about has anyone setup any more generic setup for managing Flex IO objects.
That is it looks like with have 3 FLEXIO units as you can see in table where some of the pins are marked 1:n, 2:n, 3:n... Each of these units have 4 timers, shifters, compares? So would be good if I said I wanted to create a

Flex UART Transmit on pin 2, there would be a set of calls, where it says: Pin 2 is FlexIO 1:4

And then the FlexSerial would ask for a free Timer on unit 1 as well as a free shifter on unit 1... Where then it could do the configuration stuff to use those items...
There are some complications, like for some objects that need two timers. The are needed to be N and N+1, so probably need to the API to ask for two...

Thoughts?
Hi Kurt,
My two cents - leave software serial as is just for compatibility and maybe update altsoftserial.
 
Follow up on SoftwareSerial.

Going back to T3.5 and 3.6, the additional Serial objects were not added above Serial3 even though they both had additional objects.

Question is why? First thought is, because apps that were converting from AVR boards expected that was all there were and if they needed to convert to different pins in their code, they might as well convert from using SoftwareSerial and simply specify the actual hardware Serial object they were going to use?

I guess what I am asking, is it that we wanted to be able to support 3 SoftwareSerial objects and/or we wanted to support them on the same pins as T3.2 and/or we were lazy and never added the others?

If it was that we wanted the same pins supported, then not sure what we should do here as we dont support 7-10 as there is not underlying UART at these pins...

But again FlexIO could fix..


On the actual code. Looks like your mapping should work. Could obviously add more.

Also now with common class for HardwareSerial on T4, could add members to the class like SPI isMISO, could add isRX isTX like methods, then could simply iterate over each of the objects asking are these valid pins... Or could add staticMember, like mapRXTXpinstoSerial...
 
Re: SoftwareSerial

You could add pin checks for backside UART's. I think it is supposed to work with non-uart pins too, but the code uses F_CPU and cycle counts, so that would need some T4 adjustments. Lib has magic cycles count WORST_INTERRUPT_CYCLES ?? which might need T4 adjustment. One wonders for code that depends on cycle counts, how do the various compiler optimizations (Fast Faster Fastest ...) affect cycle count loop delays ??

Correction: I had never tried SoftwareSerial on Teensy 3* -- it seems it only works on UART ports as you noted.

Yeah, I had the same reaction as well, that was my confusion in the post. I never really used softwareserial either. Always just used the Hardware serials direct.
 
Question is why? First thought is, because apps that were converting from AVR boards expected that was all there were and if they needed to convert to different pins in their code, they might as well convert from using SoftwareSerial and simply specify the actual hardware Serial object they were going to use?

I guess what I am asking, is it that we wanted to be able to support 3 SoftwareSerial objects and/or we wanted to support them on the same pins as T3.2 and/or we were lazy and never added the others?

@KurtE.
Have no idea. Think Paul needs to add the history and real function in the Teensy universe. I was thinking about adding more but again not sure of the function so I didn't expand on available ports.

EDIT: Believe NewSoftSerial superseded softwareserial but looking at it only supports teensy 2x.
 
my three cents - inflation ;)

I would not spend anytime trying to make a version of SoftwareSerial or AltSoft or... that is any bit banging version of Serial... Especially since there are 8 hardware Uarts... However it still might be fun to have a FLEXIO version, if for no other reason as a (hopefully) simple implementation to try out flexIO.

Now assuming that it works well, I would probably then think we could update all of the Soft/Alt/???Serial libraries to do the same mapping like you are doing, to almost all of the IO pins... That way anyone converting from something like Arduino UNO or the like who may have their display output on pins 2 and/or 3 and recompile for T4 it hopefully just works...
 
My worlds smallest software serial (TX only, any pin), once upon a time written for 3.2 - should work for T4, too (untested) :
- can be used in NMI fault handlers instead of using anything more complicated:

Code:
//smallest software serial : (c) Frank B
#define DEBUG_BAUD (115200)

void _serialDebugPrint(const uint8_t pin, const char * s) {
  const unsigned long bit = F_CPU / DEBUG_BAUD;
  ARM_DEMCR |= ARM_DEMCR_TRCENA; // <- may be not neeed
  ARM_DWT_CTRL |= ARM_DWT_CTRL_CYCCNTENA; // <- may be not neeed
  pinMode(pin, OUTPUT); // <- needed only once
  digitalWriteFast(pin, 1);// <- needed only once
  
  while (*s) {
   uint16_t c = (0x100 | *s++) << 1; //Add start & stop bits
    noInterrupts(); //<-- not needed in NMI
    unsigned long t = ARM_DWT_CYCCNT;    
    for (int i = 1; i<11; i++) {
      digitalWriteFast(pin, (c & 1) );
      c = c >> 1;      
      while ( ARM_DWT_CYCCNT - t < (i * bit) ) {;}
    }
    interrupts();//<-- not needed in NMI
  }
}
just one cent.
 
Seeing this odd "Â" char in printf output of temp before °==ascii(248) symbol. It isn't always present :confused:
°C=44.63

also amazing how fast the temp fluctuates - or how rarely it doesn't change:
Code:
void setup() {
  while ( !Serial );
  Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);
}

float myTemp, mtl = 0, ii = 0;
void loop() {
  myTemp = tempmonGetTemp();
  if ( myTemp != mtl ) {
    mtl = myTemp;
    Serial.printf( "\t°C=%f\n" , myTemp );
    if ( 0 != ii) {
      Serial.print( "\t    NoChange=" );
      Serial.println( ii );
      ii = 0;
    }
    //delayMicroseconds(500);
  }
  else ii++;
}
 
Planning to do some testing and maybe some initial work on the USB stuff, then package up 1.46-beta8 late Monday or early Tuesday.
Unsure if it is already there.. a little patch for platorm.txt: Can't find my inital post anmore.
Code:
## Compute size
recipe.size.pattern="{compiler.path}{build.toolchain}{build.command.size}" -A "{build.path}/{build.project_name}.elf"
recipe.size.regex=^(?:\.text|\.data|\.text.progmem|\.bootloader)\s+([0-9]+).*
recipe.size.regex.data=^(?:\.usbdescriptortable|\.dmabuffers|\.usbbuffers|\.data|\.bss|\.noinit|\.vectorsRAM)\s+([0-9]+).*
recipe.size.regex.eeprom=^(?:\.eeprom)\s+([0-9]+).*
Displays the correct sizes.

Robin / Paul:
Can you imagine a subforum (write access only for beta testers), please... it is very difficult to find anything in this thread.
 
Can you imagine a subforum (write access only for beta testers), please... it is very difficult to find anything in this thread.
Agreed things are hard to find. Do you use "Search Thread" ? that works best. i used that to search for recipe.size and got most of your posts, me thinks.
 
in boards.txt change teensy4b.build.fcpu=396000000 to
teensy4b.build.fcpu=600000000
even though F_CPU may not be meaningful for the T4, it would give me a warm comfy feeling ... :eek:
 
my three cents - inflation ;)

I would not spend anytime trying to make a version of SoftwareSerial or AltSoft or... that is any bit banging version of Serial... Especially since there are 8 hardware Uarts... However it still might be fun to have a FLEXIO version, if for no other reason as a (hopefully) simple implementation to try out flexIO.

Now assuming that it works well, I would probably then think we could update all of the Soft/Alt/???Serial libraries to do the same mapping like you are doing, to almost all of the IO pins... That way anyone converting from something like Arduino UNO or the like who may have their display output on pins 2 and/or 3 and recompile for T4 it hopefully just works...
Hi Kurt
Sorry it so long for me to get back to you all, was busy getting my wife's car towed for the last 3 hours. Argh.....

Any way I think I agree. Lets leave soft/new/altserial alone for now and then come up with a new improved version just for the T4.x, hoping Paul continues the series :)

@Frank
Copied you smallest softTxSerial code into a one note I created for the T4. Figured it might be easier to find stuff I am interested in besides using the search thread option - it does come in handy as @ manitou pointed out, but.....
 
SOFTWARE SERIAL PORTED

Ok. Created pull request, "Updated for T4 (Serial1-8) #3". And I added support for all serials
 
Seeing this odd "Â" char in printf output of temp before °==ascii(248) symbol. It isn't always present :confused:
Looks like an arduino-bug..
I tried tera-term - the same:

Thanks for confirming Frank - providing 'degrees' as a char byte works:
Serial.printf( " %cC=%2.2f\n" , '°' , tempmonGetTemp() );

<EDIT>: Just noticed this WARNING on compile of the single char '°' - so the problem is in source text parsing::
Syncron_Micros:70: warning: multi-character character constant
Serial.printf( " %cC=%2.2f\n" , '°' , tempmonGetTemp() );
This works without warning:: Serial.printf( " %cC=%2.2f\n" , 248 , tempmonGetTemp() );

Decided it would be fun to see what happens with 500K interrupts/sec during the micros() test - indeed that can nearly double the time it takes micros() to work out an un-interrupted read of the systick time variables:
T:\tCode\T4\Syncron_Micros\Syncron_Micros.ino Jan 21 2019 15:10:20
100K micros. Took cycles# 3691180
// THIS is executed between these two tests >> ITtest.begin( TimeSome, 2);
100K micros. w/IntvTimer Took cycles# 7005182
>>> 1ms systick :micros() >>> Clock Speed is:600000000 °C=44.63

With the micros() taking so long my testing code catches errors in failed reading of successive us's - so I thought to bump speed to 800 MHz - if done too early the T4 here won't make it out of setup() without restarting or faulting [fault blink really fast at 800 MHz!]. I can start at 700 MHz - then bump to 800 MHz before leaving setup() and that works okay. And those spare 100 or 200 MHz allow my test to catch the us's even with the spare 500K IntervalTimer interrupts slowing micros() return. <possible test case for the debug lib to see why it is restarting?>

This may ( I think likely will ? ) change with new USB code - as it seems there is some 'finalization of USB connect' still going on in the first second of T4 life? [ the delay that caused the special case for loop#1 in my test code]
>> else if ( dd <= 2 && 1 == Lcnt ) // extra us tick may miss loop#1 startup @600 MHz

I have not yet asked for 900 MHz - but this test running at 800 MHz is showing temp of 51.82 °C - a touch drops it 3 degrees.

Paul:: The above note reminds me of something I wanted to suggest before:: When the T4 goes into FAULT handler the F_CPU_ACTUAL could be dropped to a lower speed/power state to run the "while(1);". I've made a note to test this.
 
Last edited:
Pull 338 requested
Putting this code in T:\arduino-1.8.8T4_146\hardware\teensy\avr\cores\teensy4\startup.c:: unused_interrupt_vector()
#if 1
if ( F_CPU_ACTUAL >= 600000000 )
set_arm_clock(100000000);
IOMUXC_SW_MUX_CTL_PAD_GPIO_B0_03 = 5; // pin 13
IOMUXC_SW_PAD_CTL_PAD_GPIO_B0_03 = IOMUXC_PAD_DSE(7);
GPIO2_GDIR |= (1<<3);
GPIO2_DR_SET = (1<<3);
while (1) {
volatile uint32_t n;
GPIO2_DR_SET = (1<<3); //digitalWrite(13, HIGH);
for (n=0; n < 2000000/6; n++) ;
GPIO2_DR_CLEAR = (1<<3); //digitalWrite(13, LOW);
for (n=0; n < 1500000/6; n++) ;
}
#else
if ( F_CPU_ACTUAL >= 600000000 )
set_arm_clock(100000000);
while (1) {
}
#endif
}

Drops the T4's MCU temp ~10 degrees F using my IR thermometer - seeing 86 to 90°F instead of 96 to 100.
 
Pull 338 requested
Putting this code in T:\arduino-1.8.8T4_146\hardware\teensy\avr\cores\teensy4\startup.c:: unused_interrupt_vector()


Drops the T4's MCU temp ~10 degrees F using my IR thermometer - seeing 86 to 90°F instead of 96 to 100.

Hi Tim

You didn't do a check of what tempmonGetTemp is reading vs your IR thermometer. There is a calibration I have to pull from the OCOTP register - was wondering if it was working.
 
Hi Tim

You didn't do a check of what tempmonGetTemp is reading vs your IR thermometer. There is a calibration I have to pull from the OCOTP register - was wondering if it was working.

FWIW and for the rest of us, that 10 degrees Frankenstein == 5.58C drop
 
Hi Tim

You didn't do a check of what tempmonGetTemp is reading vs your IR thermometer. There is a calibration I have to pull from the OCOTP register - was wondering if it was working.

Patience :) ... I need to hook up Serial4 Debug again - killed it when working to test KurtE's 8 ports. So no way to print easily.

Then I'll move on with my replacement debug lib ... having a hard time starting because I don't know what to call it ...
Before it was debug_t3 - where it was Teensy 3 - but with #ifdef ideally it can work together with _t4.
It is a pain but I liked '_t' there so a search could find any debug code easily ... maybe I'll go with _tt since some may have noted I always double my temp var names that is 'i' becomes 'ii' because I can search for and see it more easily versus jj and kk

Looks like the speed drop on Fault will be in next beta! :: "PaulStoffregen commented" ... "going to merge this now... but later I'd like to see this done in a way that doesn't alter F_BUS"
 
Looks like the speed drop on Fault will be in next beta! :: "PaulStoffregen commented" ... "going to merge this now... but later I'd like to see this done in a way that doesn't alter F_BUS"
Does changing the AHB divider count as changing F_BUS
 
Hi Tim

You didn't do a check of what tempmonGetTemp is reading vs your IR thermometer. There is a calibration I have to pull from the OCOTP register - was wondering if it was working.

FWIW, my digital meter thermometer probe touching the 1052 chip reads cooler than what tempmon reports.
Code:
MCU        meter   (degrees C)
T4   49.6
T4   46.9  38.4   beta2
EVK  35.5  30.7
EVKB 39.4  31.9
1062 41.4  33
 
Last edited:
Again I guess the real question I am asking here is how we should try to make ili9341_t3 library work? Does it need to be compatible with how it works on a T3.x? Should it require hardware CS pin? Should it use FB? DMA? ...

I want to see a "default" library for ILI9341 using a frame buffer (150K DMAMEM) and some sort of timer-triggered DMA refresh. Drawing operations should probably update a "dirty region" so the refresh can transfer only the required area that's actually been modified since the prior refresh.

3.5 inch 480x320 displays with ILI9488 are now appearing on the market and likely to become the norm over the next few years. Hoping to do the same, using a big 300K buffer in OCRAM (when we move to the 1062 chip....)
 
Status
Not open for further replies.
Back
Top