Teensy 4.1 Beta Test

You'll get an email soon with instructions. So will everyone on the list who wasn't sent a early board. The message will go to the email you used to register on the forum, so if you used a different account, be sure to check that inbox.

Tomorrow we'll finish shipping the backlog of pending orders. Then we'll ship to everyone who responds to that email. I imagine most will ship Thursday.

Thank you Paul, Awesome job yet again.
 
Ok, emails have been sent to everyone on the list who hasn't already been a board.

If you're on the list but didn't get the email, first check your spam/junk filter. Then email me... I copied every address manually from a file so it's possible I might have made a mistake.

My hope is to send all these Teensy 4.1 by the end of this week.
 
Native Ethernet 2x3 ribbon cable with ends. I got a set of five of these for $10 from Amazon :: Sydien 2 Row 6 Pins F/F IDC Connector Flat Ribbon Cable 2mm Pitch, 30cm Length,5Pcs

They are 2x the length of Paul's test cable - but it seems to work in place of it with the FNET_Native_Ethernet.ino sketch to FBench.exe. Though only 13 sets in stock at Amazon.

It should be a press fit assembly cable - and has stress relief cable reverse and snap on cover that probably comes off - though first quick attempt didn't find the key. If one end comes off it could be shortened to desired length and may reassemble - or could be cut down with fresh new ends ( Amphenol FCI 893610-706LF :: from ???) replaced on the cut end.
 
I got latest NativeEthernet from github.

Hmmm, not quite. Seems to fix 25 second delay before SYN packet, but if the server is not running for a while, then client eventually gets into a state where no SYN packets are being sent ??? sketch is just printing "connect failed". maybe fails after an ARP request shows up ?
Code:
06:16:29.461450 IP 192.168.1.113.8888 > 192.168.1.4.5001: Flags [S], seq 4416001, win 5840, options [mss 1460,wscale 0,eol], length 0
06:16:29.461485 IP 192.168.1.4.5001 > 192.168.1.113.8888: Flags [R.], seq 1477920147, ack 4224001, win 0, length 0
06:16:34.462502 IP 192.168.1.113.8888 > 192.168.1.4.5001: Flags [S], seq 5120001, win 5840, options [mss 1460,wscale 0,eol], length 0
06:16:34.462538 IP 192.168.1.4.5001 > 192.168.1.113.8888: Flags [R.], seq 1477920147, ack 4928001, win 0, length 0
06:16:39.468200 ARP, Request who-has 192.168.1.113 tell 192.168.1.4, length 28
06:16:39.468291 ARP, Reply 192.168.1.113 is-at 0a:1b:3c:4d:5e:6f, length 46

Yep that does seem to be the case, I forgot to close the socket if it doesn't find a connection, the fix has been pushed to GitHub.

On a side note, now that Teensy 4.1 is released should I make a separate forum post for this library?
 
I'd say for sure a new thread for the native ethernet library. ... needed secondary libs FNET and extention to share USBHost code TeensyASIXEthernet?

Got the latest NATIVE update. Looks like it works well with the FNET_Native_Ethernet sketch with FBench.exe.
Code:
2:57:53.658	Tx	Tcp	192.168.0.165	1.053	12,720,000	96,681.660
2:57:55.597	Tx	Tcp	192.168.0.165	1.052	12,720,000	96,714.317
2:57:58.38	Tx	Tcp	192.168.0.165	1.054	12,720,000	96,542.120

Then running the USBHost sketch it is about one thord the speed and it 'forcibly rejected' and quit:
Code:
[B]3:0:7.285	Tx	Tcp	192.168.0.167	3.878	2,323,944	4,794.136[/B] // this one QUIT
3:0:34.844	Tx	Tcp	192.168.0.167	0.009	199,704	184,322.304  // did a restart here
3:0:49.243	Tx	Tcp	192.168.0.167	3.967	12,720,000	25,653.126
3:0:54.635	Tx	Tcp	192.168.0.167	3.783	12,720,000	26,896.342   // this is slow - IIRC it was 75 Mbps before this change?
3:1:1.487	Tx	Tcp	192.168.0.167	5.152	12,720,000	19,752.798

The TSET CMDLine build still fails - have to build with IDE :(
> It keys on the INO to start and may be failing to pick up the second functions.ino - any change it could refactor to functions.c? I gave a quick try and then it is missing #defines like int32_t and then I got other errors.
 
I'd say for sure a new thread for the native ethernet library. ... needed secondary libs FNET and extention to share USBHost code TeensyASIXEthernet?

Got the latest NATIVE update. Looks like it works well with the FNET_Native_Ethernet sketch with FBench.exe.
Code:
2:57:53.658	Tx	Tcp	192.168.0.165	1.053	12,720,000	96,681.660
2:57:55.597	Tx	Tcp	192.168.0.165	1.052	12,720,000	96,714.317
2:57:58.38	Tx	Tcp	192.168.0.165	1.054	12,720,000	96,542.120

Then running the USBHost sketch it is about one thord the speed and it 'forcibly rejected' and quit:
Code:
[B]3:0:7.285	Tx	Tcp	192.168.0.167	3.878	2,323,944	4,794.136[/B] // this one QUIT
3:0:34.844	Tx	Tcp	192.168.0.167	0.009	199,704	184,322.304  // did a restart here
3:0:49.243	Tx	Tcp	192.168.0.167	3.967	12,720,000	25,653.126
3:0:54.635	Tx	Tcp	192.168.0.167	3.783	12,720,000	26,896.342   // this is slow - IIRC it was 75 Mbps before this change?
3:1:1.487	Tx	Tcp	192.168.0.167	5.152	12,720,000	19,752.798

The TSET CMDLine build still fails - have to build with IDE :(
> It keys on the INO to start and may be failing to pick up the second functions.ino - any change it could refactor to functions.c? I gave a quick try and then it is missing #defines like int32_t and then I got other errors.

I went ahead and made the other thread: https://forum.pjrc.com/threads/60857-T4-1-Ethernet-Library

I'm not too worried about the USB Ethernet speeds since it really won't be needed anymore and it still has driver issues because it's not very well put together, if anything the driver would be the only thing affecting it's speed.
 
I should also mention, I made a 2nd OSH Park board but haven't had time to test it.

The new one uses a less expensive magjack. They print the part number on top so you can't easily forget how to reorder!

eth.jpg
 
Got it and a ili9488 - have to figure out what to do for MPU data … only BNo080 here is tied to a board. Have some onehorse 9250's - but not free. I did just get two of these 'triple-axis accelerometer' Adafruit LIS3DH Triple-Axis Accelerometer - wouldn't be as clean but with library would give an XYZ?

@defragster - typically you use the accelerometer just to get the roll and pitch angles. Did see a tech note on getting yaw https://www.nxp.com/docs/en/application-note/AN3461.pdf never really tried it with just an accel.
 
I should also mention, I made a 2nd OSH Park board but haven't had time to test it.

The new one uses a less expensive magjack. They print the part number on top so you can't easily forget how to reorder!

View attachment 20088

Hi Paul,

I finally received my beta T4.1!

MAybe you can help me with a small issue. I still have quite a few HanRun HR911102A from a previous project around, which I connected at that time as follows:
HR911102A.jpg

What do you think? Can I simply leave RDC and TDC of my magjack unconnected?

Kind regards,
Sebastian
 
HanRun HR911102A can probably work. But do not use that circuit with so many resistors. That circuit is for W5500. The PHY chip on Teensy 4.1 does all the impedance stuff internally, so it does not require those resistors (and using them would likely weaken the signal or not work at all).

Connect RDC and TDC together and use a 0.1 uF capacitor between RDC+TDC and GND on Teensy. Then just connect the 4 signals directly, no extra resistors or capacitors. Also connect the S1 & S2 ground pins directly to Teensy's GND.

The LED output on Teensy 4.1 is active high, and it has the resistor built in. So if you want the LED to show link status, connect the LED output to pin 9 on HR911102A, and connect pin 10 to GND.
 
I received my two Teensy 4.1 ordered from ExpTech two days after the order! My beta T4.1 sent from PJRC on April 22nd still seems to circle around somewhere in San Francisco . . .
Some questions:
* ExpTech did not deliver the pinout cards with the T4.1. I found this: https://www.pjrc.com/store/teensy41.html But where can I find the pinout card of the BACKSIDE/the extra pins?
* I soldered the PSRAM chip to the backside and tried an example from here: https://github.com/PaulStoffregen/teensy41_extram
I cannot get the examples to work, eg. structReadWrite_check42 -->
Code:
structReadWrite_check42: In function 'void setup()':
structReadWrite_check42:41: error: 'class extRAM_t4' has no member named 'eramBegin'
   mymemory.eramBegin();

            ^

In file included from C:\Users\DD4WH\Documents\Arduino\libraries\extRAM_t4\examples\structReadWrite_check42\structReadWrite_check42.ino:2:0:

and also I cannot get the code from #371 in this thread to work (TD 1.52 beta-4). Do I miss the correct files/lib?
Code:
DataloggerPSRAM329v3:35: error: 'INIT_PSRAM_ONLY' was not declared in this scope
 uint8_t config = INIT_PSRAM_ONLY;

EDIT: found out that I have to copy extRAM_SPIFFS_t4 folder to my Arduino lib folder AND unzip the folder SPIFFStest (which was hidden in a folder "test") and copy that to my Arduino lib folder.
Then the examples work!
 
Last edited:
@mjs513, awesome! The BNO080s are really interesting. I'm wondering if they'll release a new chipset soon, as this has been out for awhile now. Another thing of great interest to me is at what point will relatively inexpensive MEMS IMUs be able to do north finding without the magnetometer. I think that's going to be a big breakthrough. You can get very good north finding with two RTK GPS units, or decent with moving GPS, but getting north finding from affordable MEMS (of maybe low cost FOG) gyros will be amazing. Don
 
I received my two Teensy 4.1 ordered from ExpTech two days after the order! My beta T4.1 sent from PJRC on April 22nd still seems to circle around somewhere in San Francisco . . .
Some questions:
* ExpTech did not deliver the pinout cards with the T4.1. I found this: https://www.pjrc.com/store/teensy41.html But where can I find the pinout card of the BACKSIDE/the extra pins?
* I soldered the PSRAM chip to the backside and tried an example from here: https://github.com/PaulStoffregen/teensy41_extram
I cannot get the examples to work, eg. structReadWrite_check42 -->
Code:
structReadWrite_check42: In function 'void setup()':
structReadWrite_check42:41: error: 'class extRAM_t4' has no member named 'eramBegin'
   mymemory.eramBegin();

            ^

In file included from C:\Users\DD4WH\Documents\Arduino\libraries\extRAM_t4\examples\structReadWrite_check42\structReadWrite_check42.ino:2:0:

and also I cannot get the code from #371 in this thread to work (TD 1.52 beta-4). Do I miss the correct files/lib?
Code:
DataloggerPSRAM329v3:35: error: 'INIT_PSRAM_ONLY' was not declared in this scope
 uint8_t config = INIT_PSRAM_ONLY;

EDIT: found out that I have to copy extRAM_SPIFFS_t4 folder to my Arduino lib folder AND unzip the folder SPIFFStest (which was hidden in a folder "test") and copy that to my Arduino lib folder.
Then the examples work!

Great that you got it working.

Actually 2 folders need to added to the libraries folder:
1. SPIFFS_t4 and
2. extRAM_SPIFFS_t4.

I just added a warning to the readme to that affect:
WARNING: Both the SPIFFS_t4 and the extRAM_SPIFFS_t4 libraries need to be installed into your libraries folder to use the external PSRAM or FLASH!

The reason adding the SPIFFStest folder worked was because the SPIFF_t4 is a dup of the zip that is buried in the SPIFFStest folder.
 
@mjs513, awesome! The BNO080s are really interesting. I'm wondering if they'll release a new chipset soon, as this has been out for awhile now. Another thing of great interest to me is at what point will relatively inexpensive MEMS IMUs be able to do north finding without the magnetometer. I think that's going to be a big breakthrough. You can get very good north finding with two RTK GPS units, or decent with moving GPS, but getting north finding from affordable MEMS (of maybe low cost FOG) gyros will be amazing. Don

Not sure that is going to happen very soon. But would be nice. If you have gps's using rtk then you probably don't need the magnetometer but they also suffer from trying to use indoors so think it may be one of those use cases :)
 
I've committed the FlexSPI2 and PSRAM startup code.

https://github.com/PaulStoffregen/cores/commit/0ac84cfcbf9935b32987b30ab1fc335a5e733338

This will have 2 consequences for use of flash.

1: The starting address is now 0x7080000, not 0x71000000.

2: To use more than 8 megabytes, you'll need to write FLEXSPI2_FLSHA2CR0 with a larger number.

The motivation for these changes is the pattern of orders we're seeing people place. It's pretty clear many people are buying 2 PSRAM chips to pair with each Teensy 4.1.

Hopefully this won't be too disruptive to the flash usage?
 
I've committed the FlexSPI2 and PSRAM startup code.

https://github.com/PaulStoffregen/cores/commit/0ac84cfcbf9935b32987b30ab1fc335a5e733338

This will have 2 consequences for use of flash.

1: The starting address is now 0x7080000, not 0x71000000.

2: To use more than 8 megabytes, you'll need to write FLEXSPI2_FLSHA2CR0 with a larger number.

The motivation for these changes is the pattern of orders we're seeing people place. It's pretty clear many people are buying 2 PSRAM chips to pair with each Teensy 4.1.

Hopefully this won't be too disruptive to the flash usage?

Ok! This is going to be interesting going to have to do a bit of an overhaul of the extRAM library now. Using different address is an easy change but going to have to do some regression testing of the initialization with flash and PSRAM. Guess we are going to be busy for the a couple of days :)
 
Here's a very quick & simple test for the PSRAM chips, using the new initialization.

Code:
EXTMEM volatile int myint;
  
void setup()
{
        while (!Serial) ;
        Serial.println("External RAM test");

        myint = 123456;
        Serial.printf("myint = %u\n", myint); // reads from cache
        arm_dcache_flush_delete(&myint, sizeof(myint)); // write cache to memory
        Serial.printf("myint = %u\n", myint); // reads from actual memory

        volatile int *pint = (volatile int *)0x707FDCB4; // near end of first 8MB chip
        *pint = 12345678;
        Serial.printf("*pint = %u\n", *pint); // reads from cache
        arm_dcache_flush_delete(pint, sizeof(int)); // write cache to memory
        Serial.printf("*pint = %u\n", *pint); // reads from actual memory

        pint = (volatile int *)0x70CFDCB4; // near middle of second 8MB chip
        *pint = 6541230;
        Serial.printf("*pint = %u\n", *pint); // reads from cache
        arm_dcache_flush_delete(pint, sizeof(int)); // write cache to memory
        Serial.printf("*pint = %u\n", *pint); // reads from actual memory

}

void loop()
{
}
 
Guess we are going to be busy for the a couple of days :)

Yeah. I'm sorry I couldn't get to this earlier. It's the last blocking feature before releasing 1.52. (going to put malloc_extmem off until 1.53).

I'll start packaging up 1.52-beta5 so we can do maybe a day or two of final testing. Really need to get 1.52 published soon....
 
Just downloaded and installed the new core for Teensy4 and was running some tests as well. Just using your quick and dirty test sketch I get the following:
Code:
External RAM test

myint = 123456
myint = 123456
*pint = 12345678
*pint = 12345678
*pint = 6541230
*pint = 4294967295
Not sure about that last value which should be a repeat of 6541230

EDIT: Just going through the lib as well seems that even though you have the psram initialization it still works with the initialization that is in the library.
 
Also may have to change the ILI9488_t3 library on detecting if it should use extram or not. Currently it does it by detecting the user has included the extram header file with their sketch. Not sure yet best way around this. Currently it is a #define that is used in library to say use 4 byte pixels instead of the normal 2 byte. I hate the idea of having users have to edit header files in libraries for things like this as they may have 5 projects where only 1 or 2 have the extram...

So may need to either punt or rework the code, which I was looking at anyway.
 
Back
Top