Teensy 4.0 First Beta Test

Status
Not open for further replies.
If you mean are they available for purchase... Not exactly

I do often put some of the designs I am working with up on github in a hodge podge of stuff: https://github.com/KurtE/Teensy3.1-Breakout-Boards
There as Diptrace Design and layout files for these, plus a zip file that you can send off to places like: OSHPark, Seeedstudio, pcbway...

For the one partially assembled board, I put up a xls file with parts on it, which is probably only partially correct. I just updated it a little as I found earlier I called out the wrong resistors for R11 and R12...

Again I only do this for my own fun, so guarantee it is good for anything.

That’s more than a good starting place, much gratitude for sharing the files.

I’ve bought TallDog’s board for the 3.5/3.6 and playing with the beta rig I definitely see the “need” for a backplane to make work with the T4 less...balding.
 
As for access to the bottom pins, @mjs513 shows the one way, which I am also using on my board, I showed earlier.
IMG_0847-(002).jpg

Then you can also do it using POGO pins, like Paul did in his beta boards shown below.

IMG_0846-(002).jpg

The Beta board shows how you can use the Ribbon cable to connect up the SD adapter and/or use the 6 signal pins for other things, like another SPI port and ...
Also under the ribbon in the photo is two more Pogo pins, like mine shows that make friction connection with the USB Host pins.

One interesting thing with Pogo pins, is if you put too many on the board, the chip may start to be pressed up out of the socket and then you might get a mysterious circuit not working, until you press the chip back down.
 
One interesting thing with Pogo pins, is if you put too many on the board, the chip may start to be pressed up out of the socket and then you might get a mysterious circuit not working, until you press the chip back down.

I have used solid wire clips made from 22ga. to hold down boards that I’ve used pogo pins on. Just need to watch where they grab, a little planning goes a long way.
 
Possible problem report (I searched this thread and didn't see it mentioned):

If USB type is set to Audio, the compilation errors out due to several files using Serial for printf. For example these files:
https://github.com/PaulStoffregen/SD/blob/master/utility/SdFatUtil.h
https://github.com/PaulStoffregen/Audio/blob/master/control_tlv320aic3206.cpp

I looked around the T3 core code (usb_audio.h/.cpp) looking for a "trick" that would keep the compiler happy, but I didn't see one.

It's entirely possible I'm just doing something wrong, but I thought I would pass it along in case anyone else had encountered it.
 
Why does it take so much memory to do the simplest Arduino blink sketch?

16K Flash and 20k Ram?

Is it Arduino bloatware and complexities in manipulating ARM peripheral registers or is it simply that there is 2MB of Flash and 1MB of RAM available?
 
Paul has a post where he talks in depth about that, but the short version is that a large amount of setup code is required for the very complex peripherals on this chip.
 
A quick source check shows that this Install of TeensyDuino 1.47 beta 5 is still compiled with some DEBUG code present that will not present final usage.

On prior Teensy's the USB Stack used most of that initial Code/Ram. Currently the Teensy 4.0 can only build with "USB Type : Serial" - so that cannot be disabled to compare.

Also - having worked with Teensy 3.x's and this T_4 that past months - I've not seen much of anything where Arduino Bloats anything about the Teensy. It looks to be refined Bare Metal that just happens to be configured run to the Arduino IDE specification using the Toolchain and Sources as installed with TeensyDuino installer. All chip resources and capabilities are presented to the user as documented in the 3,000+ page reference manual for the NXP 1062 MCU processor - as expressed through the pins presented in the final design.
* The only exception is calling yield() between each loop() re-entry and that yield() code can be replaced, or avoided by not leaving loop() and setting up a permanent loop() as desired.
 
Congrats on the release Paul.
This MCU is stupid fast, and I'm still thinking of some interesting data acquisition uses, and it *might* be even quick enough to do OpenCV. I'm still having to look into the DMA on this chip, but if I can get enough bandwidth, I could even eliminate using the ESP32 for image capture. Who knows though, could be a good idea to keep the subsystems separate, I'm just undecided at this point, but this has been one of those uses I have been wanting to work on, and hope to get some play time and come up with something.
 
The Teensy 4 is similar price to Teensy 3.2

What will happen to Teensy 3.2 ?

A better question might be what will happen to Teensy 2.0, since the ~$20 price isn't too far off from $16. We probably will discontinue Teensy 2.0 in late 2020 or 2021. They do still sell, slowly, and we have enough inventory to keep 2.0 in stock into at least early 2020.

Teensy 3.2 will be around for quite some time. Even if everyone buys Teensy 4.0 for new projects, quite a large number of people are still using 3.2. We just put a large batch into production last week, so I'm not expecting any shortages.

Our experience has generally been with each new Teensy that people do still keep using the older models. That's why only 4 models have ever been discontinued, the oldest 1.0 boards (from 2008 & 2009), 3.0 and 3.1. Only 3.1 was easy, since 3.2 was pretty much a drop in replacement. Even with 3.0, we ended up making one last medium size batch after we has resolved to end it, because we heard from a good number of people who were depending on 3.0 and hadn't yet been able to migrate to 3.1 or 3.2.

But eventually everything ends. I can't predict the future, but based on every experience we've had, I'd guess Teensy 3.2 will be around for quite a long time. We're not like a huge corporation that discontinues stuff the moment sales decline. That's why even Teensy 2.0 and Teensy++ 2.0 are still available. :)
 
BUILTIN_SDCARD on T4B2R no longer working.

I was testing beta5, and SD example listfiles failed for my BUILTIN_SDCARD on my T4B2R. At first I thought it was beta5, but on another host with beta4, listfiles still failed. I then tried my older T4B2 board with beta5 and BUILTIN_CARD listfiles worked ok on that earlier T4 ... sigh. I'm not aware of any physical trauma to the T4B2R other than pulling the audio shield in and out over the last few weeks. listfiles works on uSD on the audio shield. I've never pulled out the MCU board or messed with the ribbon.

thoughts?

I got a Sparkfun uSD breakout so I could put a meter on the SDHC pins. I set T4 pins 34-39 to HIGH and checked the uSD breakout with the meter. All pins were HIGH except CLK ... sigh. So i bravely unseated the MCU board from Paul's T4B2R breakout. I jiggled the ribbon cable and such. All pins actually worked ONCE with the MCU out of the female headers. But I couldn't ever get all pins HIGH with the MCU PCB seated. I did manage to change the behavior so that CLK was HIGH but now DAT0 was not. And often the folded ribbon cable blocked the two pogo pins underneath the USB connector. My clumsy hands could never find the magic folding of the ribbon cable to get the BUILTIN_SDCARD to work ... At some point I will try someone else's T4 breakout board.
 
I have sort of run into this myself on some of my own boards, I have tried, where one or more signals were not being picked up properly... I also have one of those breakouts. On my own boards, I also added a set of breakout pins, so I could use the signals for other things.
 
Yes, the SD pads moved and changed to 1 mm spacing.

Rather than pogo pins, the intended connection method is to solder a HFW8R-1STE1LF (or similar FFC connector) onto the T4 and your breakout board, and plug a flat flex cable into both.

With that in mind, here are the new locations of the pads.

SD DAT1, x=361.22, y=487.80
SD DAT0, x=361.22, y=448.43
SD GND, x=361.22, y=409.06
SD CLK, x=361.22, y=369.69
SD 3.3V, x=361.22, y=330.32
SD CMD, x=361.22, y=290.95
SD DAT3, x=361.22, y=251.58
SD DAT2, x=361.22, y=212.21

i'm gonna order 10 flex cable connectors because i'm probably going to melt several. is hot air the best way to solder these? i'm thinking not a hot plate/reflow oven because the board is all populated and maybe just tape off the rest of the board and use hot air? any pro tips would be appreciated. thanks.
 
Although I’m 55 years old and wearing progressive glasses, I’d give hand soldering a try. IMHO 1mm pitch can easily be hand soldered, if needed with a x2.5 magnifier lens which roughly “lifts” the pin spacing to the classic DIP format. Just don’t use lead free tin, take the good old leaded one which melts at lower temperatures and flows better. ;)
 
Although I’m 55 years old and wearing progressive glasses, I’d give hand soldering a try. IMHO 1mm pitch can easily be hand soldered, if needed with a x2.5 magnifier lens which roughly “lifts” the pin spacing to the classic DIP format. Just don’t use lead free tin, take the good old leaded one which melts at lower temperatures and flows better. ;)

Same here (55/lenses). Have seen a uTube vid of soldering tiny SMD pins - that video is 0.65 mm SMD. With flux and the right amount of solder the resist mask puts it in place - and bridges can be fixed.
 
ok. i'll try the hand soldering. initially when looking at the part it didn't seem to have enough metal leg on the connectors side and i figured i would not be able to get the leg up to temp. and i can relate Theremingenieur and defragster on the age/vision. i'm 67 and wear the progressives but i've found that using reading glasses and a magnifier headband works well. i watched quite a few youtube videos on cellphone repair and notice that most techs use hot air for remove/replace similar connectors. i have done that maybe 2 times successfully but i melted a few trying.
 
Re: FreqCount on T4 with quad timer

Curious that both T4 and T3 frequency counting is good up to 65 mhz. Is there some fundamental IC characteristic that determines counting threshold or capacitance/hysteresis of input or ??

Revisiting limits on FreqCount, I notice from the T3* FreqCount lib, the 65MHz max limit is a limit of the 16-bit timer rollover (FreqCount intervaltimer checks for rollover every 1000 us) so max external clock rate for the 16-bit LPTMR would be 65mhz. I made my own T3 LPTMR counter using the ISR to count rollovers to get a 32-bit counter (see lptmrcnt.ino). Testing T3.2 with T3.2 PWM at 30MHz, count is accurate. I then tested with T4B2R PWM pin 8 @50mhz (and common ground), and count (50000516) is accurate to within crystal accuracy of T3.2 and T4B2R. I then tested with 75mhz PWM, again T.32 counts accurately (75000644)! So it seems T3 can count frequencies higher than 65 mhz for FreqCount.

EDIT: used Adafruit clock generator to see what the limit of T3 LPTMR counting is (data sheet suggests 25mhz?). T3.2 LPTMR measured frequency up to 132.5 MHz!
 
Last edited:
PWM @75MHz

FWIW, the flexpwm pins can generate 75MHz PWM, e.g. analogWriteFrequency(8, 75000000) works, but the quadtimer PWM pins won't generate 75MHz, e.g. with analogWriteFrequency(10, 75000000), nothing shows on pin 10 when you do analogWrite(10,128) However, it is possible to generate 75MHz PWM with quadtimers. The following snippet will produce 75MHz on pin 10
Code:
    // pin 10 PWM
  TMR1_CTRL0 = 0;  // stop  timer
  TMR1_SCTRL0 = TMR_SCTRL_OEN; // output enable
  TMR1_CNTR0 = 0;
  TMR1_LOAD0 = 0;
  TMR1_CMPLD10 = 1 - 1;    // 75 mhz
  TMR1_CTRL0 =  TMR_CTRL_CM(1) | TMR_CTRL_PCS(8 ) | TMR_CTRL_LENGTH | TMR_CTRL_OUTMODE(3);
  //configure Teensy pin Compare output
  IOMUXC_SW_MUX_CTL_PAD_GPIO_B0_00 = 1;
So it should be possible to extend the T4 PWM library (hardware/teensy/avr/cores/teensy4/pwm.c) to provide 75MHz on quadtimer PWM pins.
 
Revisiting limits on FreqCount, I notice from the T3* FreqCount lib, the 65MHz max limit is a limit of the 16-bit timer rollover (FreqCount intervaltimer checks for rollover every 1000 us) so max external clock rate for the 16-bit LPTMR would be 65mhz. I made my own T3 LPTMR counter using the ISR to count rollovers to get a 32-bit counter (see lptmrcnt.ino). Testing T3.2 with T3.2 PWM at 30MHz, count is accurate. I then tested with T4B2R PWM pin 8 @50mhz (and common ground), and count (50000516) is accurate to within crystal accuracy of T3.2 and T4B2R. I then tested with 75mhz PWM, again T.32 counts accurately (75000644)! So it seems T3 can count frequencies higher than 65 mhz for FreqCount.

EDIT: used Adafruit clock generator to see what the limit of T3 LPTMR counting is (data sheet suggests 25mhz?). T3.2 LPTMR measured frequency up to 132.5 MHz!

@manitou

Just got home from shopping - great news for freqcount. Guess going to have to play with this later. Working on 2 things already. :)
 
Paul: Some note when next version of TD 1.47 might show up for testing?

Couple of items I suppose you are tracking with beta 5:
> Adafruit_GFX - new version from AdaFruit works for compiling on T4 - at least against the ST7789 code I tested - where the beta 5 version did not
> i2s (?) bad #ifdef led to compile breakage
> After install first Arduino startup returned to T_3.2, not last used T4.

So cool the first batch sold out - I got my order today - thanks PJRC. Hopefully the pipeline is primed to pump out a few more :)
 
Status
Not open for further replies.
Back
Top