Teensy 4.0 First Beta Test

Status
Not open for further replies.
Hi @MichaelMeissner - Are you trying T4 using something like breadboard or using Paul's breakout? With Paul's breakout getting some of those specific pins as many of the signals are not routed to the socket you plug the Audio board into... But I think all of those are brought out...
CS - A8 - ??? Not sure?
DC - A1 - You can use the RX pin on the Serial3 connection
Reset A0 - You can use the TX pin on Serial 3 connection
SCLK does route to pin marked SCK on Audio connection
MOSI 11 routes to MOSI (different location but labeled)

Since I have not yet done the PR: I added your suggestion for #ifndef SPICLOCK

Pushed it up...

Note: I hacked my copy yesterday and the display appeared to work at 25mhz SPI speed. Although Spec almost looks like it should work at 4mhz?

Yes, after testing the pins, I settled on CS=10, DC=15, RESET=18, MOSI=11 (but using pin #7 on the board, due to sound card using alt. MOSI), and SCLK=13 (but using pin #14). The two simple demo programs worked.
 
Yes there is a way to use the built in SDHC card slot with uSDFS. If you look in the examples directory of uSDFS you will find several examples that give you the option to mount SPI, SDHC, USB or all three. Check out lines 5-13 of 'uSDFS_test.ino' for example:
Code:
#define TEST_DRV 2
//
#if TEST_DRV == 0
  const char *Dev = "0:/";  // SPI
#elif TEST_DRV == 1
  const char *Dev = "1:/";  // SDHC
#elif TEST_DRV == 2
  const char *Dev = "2:/";  // USB
#endif

If you define 'TEST_DRV' as 1 uSDFS will mount and change to the built in SDHC card slot. If you check further down the example you will see where 'Dev' is used in those operations.
I have used all three at the same time successfully when copying files.

I hope I understood your question correctly.

Will checkout your Github site. Sounds real interesting.

EDIT:
I have been wanting to try out your emulators for a long time now. Just lost site of it:)

In 'teensysync.ino' I see you are using Sdfat and uSDFS together. You might try using uSDFS for both:
Code:
  if((rc = f_mount (&fatfs, SDpath, 1))) { 
    emu_printf("f_mount() for USB MSC  failed");
  }
Code:
  if((rc = f_mount (&fatfs1, USBpath, 1))) { 
    emu_printf("f_mount() for USB MSC  failed");
  }

USBpath = "2:/" and SDpath = "1:/".

Of course all I/O ref's to SDFat would have to change to FatFS I/O op's.
Not sure if SDFat and uSDFS play well together.

Thanks, I had noticed that you could also use uSDFS with the SD card but when I tried it was not working. May be it is because of my card. I use to format it Fat on the Mac. I will try again when I am back from holiday. USDFS is a better choice anyhow, also it handles long name so I will move all emulators code to it. I used SDFat on the T3.6 in the past, it is because I used initially the SPI SD of the ILI display that I had moved to SD. If uSDFS does it all and work also on the T3.6, I will use it, it is a nice piece. Good work!
 
Paul: I've been (begrudgingly) using TeensyLoader instead of TyCommander for upload. It has been working well enough - maybe because it has been easy enough to just Button push the right device for upload. Though TyComm(ander) for multi SerMon is my only other terminal program when viewing multiple Teensy's - which is typical.

Programming a T4B2 today I turned it off long enough it seems for the IDE to autoswitch to a T_3.5 that happened to be plugged in? So when I turned the T4 back on and hit IDE upload I got the 'Wrong MCU' kraap from TLoader and powering down the T_3.5 was the easy way to get back to work.

Not sure if I did anything to inspire that - other than turning off the T4?

<edit>: perhaps since IDE/TeensyPorts knows the Teensy device list - if it could see the selected Teensy didn't match the Type/Boards - maybe it could pop up a selection dialog or something better?
 
@KurtE
SSD1351: So far just one:https://smile.amazon.com/gp/product/B01HHPOD44/


And @mjs513 ...
Talking about the OLED. I hacked up the uncannyEyes and have it working with the st7735 library in 16 bit color mode...
And have it sort of working for just one eye. Don't see any way without mods to do some of the sendCommands... Could maybe add to his library...

But With this hacked up version, it is now updating the eye at about 55 frames per second
Did receive my 1351 yesterday afternoon but as you know was distracted with getting that other display working with the T4. So finally hooked it up and ran the simpletest and indexcolors sketches and didn't see any problems. Ran out of the box. The only thing I modified in indexcolors was to add a delay(200) when it went through the colors - otherwise it just flashed the screen so fast couldn't see what was happening.

I also gave your hacked up version of UncannyEyes a try and that worked out of the box as well - again only tested one screen as you said. Too bad two eyes for the 1351 will take a bit of hacking to get it work. You know me - never did mind to add to the libraries :)
 
Thanks, I had noticed that you could also use uSDFS with the SD card but when I tried it was not working. May be it is because of my card. I use to format it Fat on the Mac. I will try again when I am back from holiday. USDFS is a better choice anyhow, also it handles long name so I will move all emulators code to it. I used SDFat on the T3.6 in the past, it is because I used initially the SPI SD of the ILI display that I had moved to SD. If uSDFS does it all and work also on the T3.6, I will use it, it is a nice piece. Good work!

The credit for uSDFS goes to @WMXZ. I agree it is a great piece of work. Very easy to understand and use.
 
@KurtE
Did receive my 1351 yesterday afternoon but as you know was distracted with getting that other display working with the T4. So finally hooked it up and ran the simpletest and indexcolors sketches and didn't see any problems. Ran out of the box. The only thing I modified in indexcolors was to add a delay(200) when it went through the colors - otherwise it just flashed the screen so fast couldn't see what was happening.

I also gave your hacked up version of UncannyEyes a try and that worked out of the box as well - again only tested one screen as you said. Too bad two eyes for the 1351 will take a bit of hacking to get it work. You know me - never did mind to add to the libraries :)

Yep - OK, I think things are far working well enough with the library so I did to a Pull Request: https://github.com/kirberich/teensy_ssd1351/pull/1
Now to mark up message on first page.

I was/am tempted to order 2nd one to try out two eyes, but figure I have enough distractions :D (for now)
 
Yep - OK, I think things are far working well enough with the library so I did to a Pull Request: https://github.com/kirberich/teensy_ssd1351/pull/1
Now to mark up message on first page.

I was/am tempted to order 2nd one to try out two eyes, but figure I have enough distractions :D (for now)

Now, that I'm slowly learning bits and pieces of the Teensy 4.0, and that we don't seem to have accelerated support for more than one CS, I'm wondering for the uncanny eyes, whether we would have separate CS pins. I.e. we would use pin 10 as the 'CS' pin for the SPI calls, but we would connect up two other pins, one to each of the displays CS pin, and manually set that other two pin when we are switching eyes. Obviously we would have to what for the I/O to drain out before doing this switch.

Or just use two different SPI buses.

I haven't yet looked at modifications to uncanny eyes for Teensy 4.0.

I'm getting kind of tired of the standard Arduino libraries assuming you only have one i2c port and one SPI port, and the standard calls only use that port. I realize why it is, but it would be nice if the base code were updated to know that more than one bus is possible.
 
@MichaelMeissner - Yes with the T4, the CS pins are very different than T3.x, which for many of our drivers like the ili9341_t3 library, the main speedup is the ability to keep the queue active while the DC state changes. That is when you draw a pixel, there is data output sort of like:
<DC LOW>0x2a<DC HIGH>X 16 bits, X 16 bits<DC LOW>0x2b<DC HIGH>Y 16 bits, Y 16 bits<DC LOW>0x2c<DC HIGH>color 16 bits
Note: most of the time CS is asserted at the start of this and unasserted at the end of this. Most of the time even with hardware CS we wait until completion before doing the end transaction...

So using two different non hardware pins for CS for uncannyEyes probably does not hurt much...

And I am totally with you on wishing most libraries would support (somehow different SPI busses). Which is one of the differences between ili9341_t3 library and ili9341_t3n... Where I added support for multiple SPI busses, at the time to test the T3.6 during beta... Put all of the stuff into SPIN library to make it easier. But then most of that I was able to pull back into SPI library. Note: With ili9341_t3n I put in support for not having CS on hardware CS as on T3.6 SPI1 only had one CS pin...

Note with my update to st7735_t3 library to support T4, I put in back door support for different SPI busses. How I did it in this case was to see if the pins passed in
That is in the commonInit I do:
Code:
	if (SPI.pinIsMOSI(_sid) && SPI.pinIsSCK(_sclk) && SPI.pinIsChipSelect(_rs)) {
 		<Setup for SPI>
    #if  defined(__MK64FX512__) || defined(__MK66FX1M0__)
	} else if (SPI1.pinIsMOSI(_sid) && SPI1.pinIsSCK(_sclk) && SPI1.pinIsChipSelect(_rs)) {
	       <Setup for SPI1>
 	} else if (SPI2.pinIsMOSI(_sid) && SPI2.pinIsSCK(_sclk) && SPI2.pinIsChipSelect(_rs)) {
	       <Setup for SPI2>
	} else {
	       <Setup for bitbang>
}
In the T4 part I don't require hardware pin chip select...

In the earlier versions of ili9341_t3n, I instead had you pass in which SPIN object (SPI wrapper) to use, but internally now, that is optional as I do like above.
 
GPT Timer Interrupt Behaviour

Interesting experience whilst experimenting with GPT1 and GPT2 today. Using the 150 MHz clock, I wrote a simple test to use GPT1 Compare1 to generate an interrupt every second. In the ISR, I reset the specific Status Register bit OF1 as the first job inside the ISR, followed by a blink of the LED. It worked fine. Same behaviour with GPT2 using Compare1.

But when I tried to do the same for Compare2, or Compare3 - still resetting the specific associated Status Register bit (OF2 or OF3) inside the ISR - then both would fail for GPT1 or GPT2. Even unplugging the T4 USB to get a hard reset still failed on restarting T4.

After puzzling this over for a while, I tried writing a '1' to all three OF1,OF2,OF3 at once in the Status Register (even though I was only enabling one interrupt at a time). To my surprise, this now worked with Compare2 and with Compare3. So I now write '3F' to the Status Register in the ISR to reset all the potential interrupts, even though only one interrupt is enabled at any one time.

I presume that writing to the SR is the correct way to reset the flags inside the ISR? But it was curious that writing to specific bits worked with Compare1 but not the other two. This is probably something to do with the fact they are all "ORed" together for the NVIC table.
 
updated GitHub
Only to make sure, what I have here is
running uSDFS_test on T4b2 with
- TEST_DRV=0 and uSD card in AudioCard: works fine

? uSDFS SPI problems with uSD on audio shield T4B2R

I fetched the latest uSDFS and MSC from github and am running 1.8.8 1.47-beta4 on T4B2R. I modified uSDFS example to just do directory listing. Listing works with on-board uSD and listing works on USB thumbdrive, but fails for uSD on audio shield on T4B2R breakout.
Code:
Test uSDFS
0:/
Mount: Failed with rc=FR_DISK_ERR.
SD lib's listfiles works on audio shield uSD on T4B2R. :confused:

EDIT: also tested on T3.6 (ye ol acrylic K66 beta). on-board SDHC uSD worked and USB thumb drive worked, but uSD on audio shield failed as on T4. Also SdFat_Beta works with T4 audio shield uSD (SPI).
 
Last edited:
Interesting experience whilst experimenting with GPT1 and GPT2 today. Using the 150 MHz clock, I wrote a simple test to use GPT1 Compare1 to generate an interrupt every second. In the ISR, I reset the specific Status Register bit OF1 as the first job inside the ISR, followed by a blink of the LED. It worked fine. Same behaviour with GPT2 using Compare1.

But when I tried to do the same for Compare2, or Compare3 - still resetting the specific associated Status Register bit (OF2 or OF3) inside the ISR - then both would fail for GPT1 or GPT2. Even unplugging the T4 USB to get a hard reset still failed on restarting T4.

After puzzling this over for a while, I tried writing a '1' to all three OF1,OF2,OF3 at once in the Status Register (even though I was only enabling one interrupt at a time). To my surprise, this now worked with Compare2 and with Compare3. So I now write '3F' to the Status Register in the ISR to reset all the potential interrupts, even though only one interrupt is enabled at any one time.

I presume that writing to the SR is the correct way to reset the flags inside the ISR? But it was curious that writing to specific bits worked with Compare1 but not the other two. This is probably something to do with the fact they are all "ORed" together for the NVIC table.

T4 ISR's are finicky, are you using asm volatile ("dsb") in your ISR? (or spinning til flag is cleared)

https://github.com/manitou48/teensy4/blob/master/gpt_isr.ino
 
Last edited:
Thanks Frank. That works with the demo wavfileplayer but not with my code so I have some digging to do.

Pete

Pete, the new code is supposed to work the same way (just translated to the new hardware). If you find the reason, I'd be interested to know why it didn't work! Maybe we need to pay more attention when doing that (changing sample-freq) on T4?
 
I have not used "DSB", but will give it a try. Thanks for your reference - useful to see how someone else does it.

I think the Compare1, 2 and 3 are completely independant of each other in their actions. If so, have you tried using either Compare2 or Compare3 on their own? I would be interested to hear your results. My experience earlier is getting even more complicated, for using Compare2 or Compare3 on their own has not worked out quite as I expected. I did a bit more work after the post and realised I'm getting weird results. Maybe "DSB" can resolve things. Will see...
 
Startup Hooks with code as noted in post #3576 edited into startup.c

Made a Pull Request for startup change of p#3576: github.com/PaulStoffregen/cores/pull/385

Discovered that the EarlyHook can do pinMode and digitalWrite[Fast] under 1,300 MicroSeconds after the Teensy 4 clock starts.
Code:
Compile Time:: T:\tCode\T4\ShowTime\ShowTime.ino Jul 11 2019 09:48:14

Start setup():: E_HOOK us>>1295 [ii3#>>1] E_hook millis is 1
Start setup():: L_HOOK us>>45341 [ii2#>>5] L_hook millis is 45
Start setup():: @us>>300001 [static ii ms>>300] setup millis is 300
@micros>>687016 [ms>>687] Time is Thu Jul 11 11:58:21 2019

@micros>>10963612 [ms>>10963] Time is Thu Jul 11 11:58:21 2019

This is the code in the sketch - uses some global variables that are set to record time and use in the _hooks and then printed when Serial comes online:
Code:
#include <time.h>
time_t tt;
uint32_t  jj, kk, ii = millis();
uint32_t  jj2, kk2, ii2 = 1;
uint32_t  jj3, kk3, ii3 = 2;
elapsedMillis ems = 0;

#ifdef __cplusplus
extern "C" {
#endif
PROGMEM void startup_early_hook(void) {
	pinMode( LED_BUILTIN, OUTPUT);
	digitalWriteFast( LED_BUILTIN, HIGH );
	delayMicroseconds(10);
	delayNanoseconds(10);
	jj3 = micros();
	kk3 = millis();
	ii3--; // prints 1 in setup
}

PROGMEM void startup_late_hook(void) {
	jj2 = micros();
	kk2 = millis();
	delay( 100 );
	while (millis() < 280) {
		if ( ems > 40 ) {
			ems = 0;
			ii2++;
			digitalWriteFast( LED_BUILTIN, !digitalReadFast( LED_BUILTIN ) );
		}
	}
}
#ifdef __cplusplus
} // extern "C"
#endif

void setup() {
	jj = micros();
	kk = millis();
	while (millis() < 300) {
		if ( ems > 20 ) {
			ems = 0;
			digitalWriteFast( LED_BUILTIN, !digitalReadFast( LED_BUILTIN ) );
		}
	}
	Serial.begin(115200);
	while (!Serial && millis() < 4000 );
	Serial.println("Compile Time:: " __FILE__ " " __DATE__ " " __TIME__);
	tt = rtc_get();
	Serial.printf("\nStart setup():: E_HOOK us>>%u [ii3#>>%u] E_hook millis is %u", jj3, ii3, kk3);
	Serial.printf("\nStart setup():: L_HOOK us>>%u [ii2#>>%u] L_hook millis is %u", jj2, ii2, kk2);
	Serial.printf("\nStart setup():: @us>>%u [static ii ms>>%u] setup millis is %u", jj, ii, kk);
	Serial.printf("\n@micros>>%u [ms>>%u] Time is %s\n", micros(), millis(), ctime(&tt));
}

void loop() {
	tt = rtc_get();
	while ( tt + 10 >= rtc_get() ) jj = micros();
	Serial.printf("@micros>>%u [ms>>%u] Time is %s", jj, millis(), ctime(&tt));
}
 
Last edited:
...I did a bit more work after the post and realised I'm getting weird results...

@Manitou - Tried "DSB" and it made no difference. If I can summarize, using GPT2 it looks like this... If you only enable Compare2 using "GPT2_IR = 0x00000002;" then it ONLY WORKS (the ISR) if you put a value in the Compare1 value register e.g. "GPT2_OCR1 = 0x08F0D180;". Note that this is the WRONG register - it should be "GPT2_OCR2 = 0x08F0D180;" - but if OCR1 is zero, and something in OCR2 then it FAILS.

Same is true of Compare3. If you use "GPT2_IR = 0x00000004;" it too only works if something is in OCR1. It cares NOT what is in OCR3. That cannot be correct?

I'm using GPT2 because eventually, I want to toggle an output pin and GPT2 looks to be the only way on GPT's to get an output. What I'm aiming for is a edge on the Compare3 output to AD_B1_07 (Teensy Pin 16) to trigger a scope channel and then put a "digitalWriteFast" in an ISR to measure the ISR latency. I read somewhere that this can be as low as 20 nanoSecs.
 
@Frank B:
I have a test WAV file that is sampled at 12kHz. I've modified the example WavFilePlayer to add setI2SFreq and then play the wav files like this:
Code:
  setI2SFreq(12000);
  playFile("000001.WAV");  // filenames are always uppercase 8.3 format
  delay(500);
  setI2SFreq(44100);
  playFile("SDTEST1.WAV");  // filenames are always uppercase 8.3 format
  delay(500);
Works perfectly. However, I then added some other WAV files for it to play which are sampled at various rates including 8kHz, 11025Hz, 12kHz and 44.1kHz and that doesn't work as well. I'm currently digging into play_sd_wav.cpp to try to sort it out.

Pete
 
I realize this is premature until the T4 is actually announced, but does anybody have plans to make a carrier to access the bottom pins? Something like this board from FrankB?

Or the Talldog boards?

I would also hope that a board similar to the board used by the beta hardware is available for those people that want to use the audio shield with the Teensy 4, but that board is kind of on the big side.
 
I realize this is premature until the T4 is actually announced, but does anybody have plans to make a carrier to access the bottom pins? Something like this board from FrankB?

Or the Talldog boards?

I would also hope that a board similar to the board used by the beta hardware is available for those people that want to use the audio shield with the Teensy 4, but that board is kind of on the big side.

I've been wondering about a board like the first for the end I/O where it has to stop short of the bottom SMD parts - which that style from FrankB does.

Also for the other end a USB HOST adapter like this :: https://oshpark.com/shared_projects/C8EaHAAq
It would need female USB on bottom and 'USB control chip' and 5V and GND pins picked up.
Suspect the SDIO line pitch too fine to get castellation to work. Might be cool to put double set of holes for female USB to mount to point either way underneath.

The Beta Board was cool - except for not having a pin row parallel to all side pins to give ready access to them.
 
@WMXZ, @Jean-Marc

Just realized I was testing SPI in uSDFS with T3.2 and T3.6. Never did try with the T4. After trying to play a wave file with uSDFS and the audio board it did not work. My bad!
And as WMXZ stated:
uSDFS is basically based on FatFS which provides a lower-level API and is written in plain C.
Adsing a SD-style API is possible, but is it needed?
 
@WMXZ, @Jean-Marc

Just realized I was testing SPI in uSDFS with T3.2 and T3.6. Never did try with the T4. After trying to play a wave file with uSDFS and the audio board it did not work. My bad!
And as WMXZ stated:
@manitou,@wmxz,
Is there a way to specify the CS when using uSDFS in SPI mode (audio board or when using the SD of the ili9341 display) iso the Sdio build-in pins? A bit like SD lib does?
 
@MichaelMeissner: I asked Daniel Gilbert (TallDog on Tindie) about his plans for a T4 breakout board similar to his DIP-64 and Standard t3.6 breakouts on Tindie. Here's his response yesterday:

"I’ll definitely have a Teensy 4.0 breakout if it needs one, which I think it will. Unfortunately Paul’s already distributed all the betas, and I can’t seem to find any pictures of the pin layout yet. There’s a preliminary pinout card, but it doesn’t show the pin/pad locations."

I'm a big fan of his DIP-64 T3.6 board.

I just want to say that I'm hugely disappointed when I look at the pinout/form-factor of the T4. My apps need the processing power of the T4, but also need lots of digital pins for front panel communication etc. I'm thinking ahead, and it's going to be a major PITA if I have to redesign everything to use I2C to talk to a sub-processor that handles the encoders etc. That was the reason for asking Daniel about his plans...

@Paul: Maybe you could work with Daniel to facilitate the production of a convenient breakout board?
 
Status
Not open for further replies.
Back
Top