Teensy 4.0 First Beta Test

Status
Not open for further replies.
I have some PSRAMs, but did not do much with them, so far. I think that's one of the next things I'll do. Still not sure which pins to use for the (quad-) I/O..

I have one item with psram but its not a teensy, its a m5stack fire edition. (esp32 basicly) but thats not a t4 :)
 
Looking at the memory report in p#3267 - can the sketch really get all dynamic memory: "local variables >> Maximum is 1048576 bytes" ?

No, not really. The memory organization of this chip is far more complex than can be fully shown by Arduino's simple summary. Trade-offs had to be made. I went with showing an aggregate of all RAM usage, with the consequence of finer details obscured, but at least no static allocations (known at compile time) should be hidden from the total.


Is no code moved to RAM if used by the sketch?

Nope, it works pretty much the opposite of that. Whatever code you have that is *not* marked as PROGMEM gets put into RAM first. Then the rest of the RAM (rounded to the nearest 32K boundary) is available for variables. Or at least the rest of the first half. The 2nd half is always dedicated to DMAMEM and malloc().

Like with AVR, you can save RAM by using PROGMEM. Unlike AVR, it applies to functions as well as variables. Also unlike AVR, everything is always accessible by ordinary C/C++ code, so no need for stuff like pgm_read_byte().


And the sketch make 'Global variables' that cross all boundaries and fill RAM?

Oh wouldn't that be nice. But no, the linker doesn't work that way. Neither does the hardware, really, since ARM designed the M7 core with 3 different buses and NXP built the chip around that approach.


Allocations at run time - like Audio Buffers - or malloc() are not included in the compile time allocations from the dynamic RAM.

This is true for malloc() & C++ new. But the audio library does not use malloc. Instead it uses a static allocation, depending on the AudioMemory() line in setup(). The audio lib then does its own allocation from that fixed amount of memory. I designed it this way so the audio library would have 100% deterministic timing.


I'm sorry, I should clarify that I increased the delay times in the example to 1100 2200 3300 respectively. Before, this showed no difference from the unaltered example.

Noting that I'm not entirely sure this *worked*. It only compiled and uploaded.

Using the audio delay, the memory for storing the sound comes from the AudioMemory() buffers. If you configure longer delays, it simply uses more of that memory. If you use too much, so the audio lib runs out of RAM, the audio will stutter or stop.



The T4B1 I got has unfortunately not enough RAM for that experiment but 512K of OCRAM in the T4B2 for the 68000 would be enough

Please email Robin directly. We'll send you the latest beta hardware. If we're sending to Europe, please let her know if you prefer UPS or DHL.
 
Ok, I've removed the Raspberry Pi build problems from the list on msg #6.

If anyone using Raspberry Pi sees a problem like Kurt reported on msg #2773, please speak up. Otherwise, I'm assuming 1.47-beta4 fully fixed the missing toolchain files.

I've also deleted a couple dozen other things from msg #6 that I'm sure are fixed in 1.47-beta4.
 

Oh wouldn't that be nice. But no, the linker doesn't work that way. Neither does the hardware, really, since ARM designed the M7 core with 3 different buses and NXP built the chip around that approach.

This is true for malloc() & C++ new. But the audio library does not use malloc. Instead it uses a static allocation, depending on the AudioMemory() line in setup(). The audio lib then does its own allocation from that fixed amount of memory. I designed it this way so the audio library would have 100% deterministic timing.
...

Wasn't sure it was meant to show the 'other 512KB' in that context - indeed no 'nice' answer given how Arduino posts 'Free RAM' - and how the MCU has it in place.

Will be fun to Add not remove PROGMEM's - now I see why FrankB made a note about code&data fighting in the build when doing multiple things static in FLASH. Assume data marked 'const' stays in FLASH?

Good work on static Audio RAM - hadn't followed that through and wrongly assumed it was a runtime alloc.
 
Assume data marked 'const' stays in FLASH?

Nope, const variables without PROGMEM are allocated in RAM. They have been in every version of the beta software. That's why the wavetable stuff (months ago when Frank got the audio outputs working) needed PROGMEM to build.

Currently everything defaults to optimize for maximum performance. That means even const variables get allocated in the fast TCM memory. If you want to conserve the RAM, you need to use PROGMEM, even for const variables. Because this chip has large caches, often there is little or no performance hit with PROGMEM, but of course a cache miss does mean the CPU will wait many cycles. That's why TCM allocation is the default.

However, some stuff in the core library (mostly the startup code which runs only once) already has PROGMEM.
 
1.47 b4 installed on aarch64 ubuntu..."Jetson Nano flavor".
Will try any known torture test, just doing "normal" things. Because I'm not. Right.


Nothing to add.
 
I could prolly try and install arduino and teensy on a udoo quad. dont know if its really that much different from a rpi 3b+ though
 
Downloaded and installed 1.47b4 no issue on Windows 10.

Uploaded a couple of sketches: EEPROM, RTC, Simple Primes calc and USBHost to HDD all good.
Did you check USBHost to HDD with buffersize>=16k?
AFAICS, the PR concerning the 16k buffer issue has not been merged in USBHost_t36
(did not apply yet 1.47b4)
 
It is a good idea to put all code that runs only once or where speed does not matter in PROGMEM if you want as much free ram as possible.
I'd check all libraries and their init-code, too.
And now, for T4, it makes sense to mark some arrays or other data as DMAMEM - even if not used for DMA, and to use more malloc()
 
I did just put my T4B2 on a PJRC OSH Purple display board with an ili9341 and TouchPaint is working. But looking I see that is using a local ili9341_t3 lib:
Using library XPT2046_Touchscreen at version 1.3 in folder: T:\Ard186t4b2\hardware\teensy\avr\libraries\XPT2046_Touchscreen
Using library SPI at version 1.0 in folder: T:\Ard186t4b2\hardware\teensy\avr\libraries\SPI
Using library ILI9341_t3 at version 1.0 in folder: T:\tCode\libraries\ILI9341_t3
It will not compile with the TD1.47b4 installed library: ...\hardware\teensy\avr\libraries\ILI9341_t3 - but XPT2046 and SPI are good to go.

Did you check USBHost to HDD with buffersize>=16k?
AFAICS, the PR concerning the 16k buffer issue has not been merged in USBHost_t36
(did not apply yet 1.47b4)

I did not run any USBHost tests - I didn't see that any of the updated libs were included so I still have the WIP versions.

Confirmed that the TD1.47b4 USBHost_T36 works with 2 or 3 K of uint32_t's - but fails with 4 and above:
Code:
#define BUFFSIZE (3*1024) // size of buffer to be written
uint32_t buffer[BUFFSIZE];
And a bit finer granualrity this works at 15KB :: BUFFSIZE (15*256)

I just closed and re-opened IDE with 8 open sketches - on opening the one windows flashed this in ORANGE on the console I just noticed:
Code:
	at java.awt.Container.dispatchEventImpl(Container.java:2297)
	at java.awt.Window.dispatchEventImpl(Window.java:2746)
	at java.awt.Component.dispatchEvent(Component.java:4711)
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:760)
	at java.awt.EventQueue.access$500(EventQueue.java:97)
	at java.awt.EventQueue$3.run(EventQueue.java:709)
	at java.awt.EventQueue$3.run(EventQueue.java:703)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:84)
	at java.awt.EventQueue$4.run(EventQueue.java:733)
	at java.awt.EventQueue$4.run(EventQueue.java:731)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:730)
	at java.awt.SequencedEvent.dispatch(SequencedEvent.java:128)
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
	at java.awt.EventQueue.access$500(EventQueue.java:97)
	at java.awt.EventQueue$3.run(EventQueue.java:709)
	at java.awt.EventQueue$3.run(EventQueue.java:703)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:84)
	at java.awt.EventQueue$4.run(EventQueue.java:733)
	at java.awt.EventQueue$4.run(EventQueue.java:731)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:730)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
 
It is a good idea to put all code that runs only once or where speed does not matter in PROGMEM if you want as much free ram as possible.
I'd check all libraries and their init-code, too.

Yes indeed Frank - that and the other "Cool" memory segment names/locations/limits and features need some sort of a write up for optimal usage.

Seeing 1.9+MB for FLASH storage is deceptive given that non-PROGMEM data and code will start/migrate to RAM. And expecting 1MB of RAM where only half is in the compiler space (?). Then there are the cache issues as noted when DMA is used.

The Memory map from your "imxrt-size.exe" would be much more informative. Not sure if something like that could be selectively displayed when IDE console is in Verbose mode?

At a glance - once you know to look for it - this isn't a quick read to know what is where:
MEMORY
{
ITCM (rwx): ORIGIN = 0x00000000, LENGTH = 512K
DTCM (rwx): ORIGIN = 0x20000000, LENGTH = 512K
RAM (rwx): ORIGIN = 0x20200000, LENGTH = 512K
FLASH (rwx): ORIGIN = 0x60000000, LENGTH = 1984K
}
 
With the "new" variable size of ITCM <-> DTCM my old imxrt-size is not correct anymore and needs a fix.

There is an issue with line-endings too, and I tried colors. The Arduino-builder does something with the output of the tools (modifies it) not sure what exactly, and I found no documentation.
Does someone know more?
 
Last edited:
Here is a first draft for the front side of the pinout card.

card10a_rev1.png

So far I haven't been able to find a way to squeeze in CS1 and MISO1 on pins 0 & 1. Looks like there's also no way to cram the XBAR and FlexIO features into the limited space. This is already a reduction on font width compared to what we've printed on all the other cards.
 
Card is a sight for sore eyes … looks good.

With Pins 0-12 all being PWM - maybe just a full colored bar one char high with 'PWM' Left to right - would buy about half enough space :(

Interesting Vin 3.5V to 5.2V - is that 5.2V for the regulator or to protect USB_Host?

<edit>: PDF of summary other [FAQ] notes like RAM/FLASH organization/usage as well as the added xbar and flexio would be good.
<edit2>: again no room - but - Note on Red LED as Bootloader feedback?
 
I struggled for quite a while about how to name the I2S signals, or whether to even include the audio stuff on the card. I want to avoid printing "I2S", since we've seen over and over that people confuse it with I2C. I also tried to avoid using TX# and RX# for anything other than the hardware serial ports. For CAN, I wanted to print "CAN#TX" and "CAN#RX" as we have on the Teensy 3.5 & 3.6 cards, but it just doesn't fit.


Interesting Vin 3.5V to 5.2V - is that 5.2V for the regulator or to protect USB_Host?

It's mainly that I haven't fully decided what voltage range we're going to recommend, so I lowered the number just in case this early draft leaves this forum. The info on this card is meant more as easy-to-use guidance, rather than a comprehensive spec sheet. It's meant to be conservative.


but - Note on Red LED as Bootloader feedback?

Oh, that's a good point....
 
Which pins exactly are the I2S Pins?
Perhaps you could use PAO and PAI (Philips Audio Out / In). That would also relate to a Power Amplifier we would perhaps connect there...
 
Here's another draft with text added about the red LED.

card10a_rev1.png

For everyone who's used the betas, does this description make sense? Space is limited on the card, need to choose words carefully...
 
... wide bar PWM visualized to make room for SPI1 pins …
T4_SPI1.png

Is it worth the ink to add along with 'All digital pins have int...' the up front note ... 'All pins are limited to 3.3V'

Good note on the Bootloader LED. But it also goes blinking with USB when it gets bored waiting for TeensyLoader - when USB is present after button push?
 
But it also goes blinking with USB when it gets bored waiting for TeensyLoader - when USB is present after button push?

Have you actually seen it do this? It certainly shouldn't. The blinking mode is only supposed to happen when there's no USB at all, specifically a charge-only cable or with external 5V power on VIN and no USB cable connected.
 
Have you actually seen it do this? It certainly shouldn't. The blinking mode is only supposed to happen when there's no USB at all, specifically a charge-only cable or with external 5V power on VIN and no USB cable connected at all.

Yes, just now and for some months - WHEN TeensyLoader is NOT ACTIVE or loaded [ works to stay DIM when TeensyLoader AUTO is OFF ] - but I use TyComm generally.
> With new beta 4 I am using TeensyLoader not TyComm so far - but I close TeensyLoader when I want to play with the button - like now.

Steps:
> T4B2mRibbon - fresh powered to run loaded code
> SerMon shows sketch text printed.
> TeensyLoader NOT running
> Press Button
> stays DIM about 8 seconds
> After 8 seconds the Program on a valid cable looks just like a power only cable blink.

<edit>
>> Or : Press Button with TeensyLoader active but AUTO OFF, then close TeensyLoader - it goes to blink

> TyCommander doesn't touch a Teensy in bootloader mode except to note it in the GUI and await user commands of user action Upload or Reset, which allows it to run with TeensyLoader and not jump in while it is responding to Button or programming.
 
Status
Not open for further replies.
Back
Top