Teensy 4.0 First Beta Test

Status
Not open for further replies.
USB_JOYSTICK

@KurtE - @defragster - @...

Ok ,,, I must be missing something. But I just tried to run the Basic sketch for usb joystick and got the following error:
Code:
Basic:20: error: 'Joystick' was not declared in this scope
To make a USB Joystick, use the Tools > USB Type menu
1. I have Serial-Mouse-Keyboard-Joystick selected for USB type
2. I copied over usb_joystick.h/.c files from the Teensy 3 folder.
 
@KurtE
Yeah - just kind of figured that out about the same time as I got your message. Did a hack and include "usb_joystick.h" in the sketch and got an error about usb_packet_t not defined. Looked and its commented out - so guess a little premature as usual. Oh well - guess it will have to wait on to something else :)
 
I didn't find anything with the thread search, but has anyone in the beta group tried anything with the Pixel Pipeline hardware? It seems like it has the hardware for a SNES/GBA style hardware assisted 2d graphics engine.

I'm also curious about the LCD driver. Although it doesn't look like all the required pins are available, is this something that might show up in a future Teensy 4.x?
 
On reading the actual reference manual and not just the product sheet the scaling and rotation hardware appears less capable than I hoped, and probably not worth dealing with unless you also had access to the actual LCD interface.
 
@Frank - On the list of known issues (msg #6) is this early problem with the cache.
I'm guessing this is no longer an issue? Is removing it from the list ok?

@PaulStoffregen - I probably should just look ;)

But I know one of the issues before was if you did something like:

DMAMEM uint8_t frame_buffer[320*240*2];
...
memset (frame_buffer, 0, sizeof(frame_buffer);

do DMA to SPI from frame_buffer - The display was not updated correctly...

I got around this (or is solution?) in ili9341_t3n library by doing something like: if ((uint32_t)_pfbtft >= 0x20200000u) arm_dcache_flush(_pfbtft, CBALLOC);

Which works, but is different than T3.x (5/6) for the frame buffer code.

The last time I looked (or was discussed) you would run into this with both: DMAMEM and malloc() areas of memory?
 
Yes, the cache flush is required on this new chip.

Maybe I should add those cache functions as empty inline functions for Teensy 3.x, so the same code will be able to compile (without ifdefs) for the 3.x boards?
 
Adding empty inline functions for T3 might not be bad idea...

Will probably need to document this pretty well, as I am not sure how many places this will hit.

If it were just DMAMEM - than user had already done something special and as such may be ready and understanding they may need to something.

I think it might be a little more problematic with malloc, as who knows how many places might be hit by this with no clue on what happened...

I did put in code into SPI, to handle it when we do DMA transfers. In there I believe there were two cases:
The one above, plus the input from DMA where I also added call to arm_dcache_delete... Otherwise receiving code did not get what came in from DMA, but what was stale in cache.

And speaking of malloc Wondering if we need ways to allocate memory both in the area where malloc allocates from today, as well as any memory left over in the lower region of memory?

Example I believe it was ESP32 I was playing with where I could not allocate one allocation for Frame buffer, but if I allocated it in two halves I was able to get memory from both of their sections which allowed the frame buffer code to work (with help)
 
Yeah, this is the reality of using DMA on a chip with cached RAM. If you have an arbitrary pointer to a buffer, it might be in cached memory. Not flushing the cache for that region before the DMA transfer risks the DMA accessing stale data. But if you're not doing DMA, as most libs and programs using malloc(), the cached memory works exactly as you'd expect. The need to flush the cache is only with DMA.

You already can allocate memory from the non-cached DTCM, using ordinary global, static and local (stack) variables.

As far as I know, the newlib malloc() only works with a single continuous memory range. So far, the plan as been to put the all the ordinary variables in DTCM and let the stack grow downward, and let malloc() serve up the OCRAM memory.
 
Paul, I don't remember that I added this to the list. And I don't think that it was me :) But yes, it can be removed from the list.

But - there was an (other) issue with PROGMEM - if code and data is marked as PROGMEM they use the same section name and the linker does not like this - Not sure if this is really is an issue - but I'm sure this will lead to questions sooner or later. (I hope I remember correctly)

I had tried to force different names per file at least - but the arduino-builder did'nt allow any trick I tried.
I can't imagine any way to solve this.. so.. maybe we have to live with that anyway.
Or add an additional section to the linkerscript?
 
Last edited:
perhaps add a function to reconfigure the cache of ocram to "write-through" and "disabled"- it will be useful for debugging or help users to solve cache-issues.
 
I deleted that old line from msg #6.

I've also added empty copies of the cache functions to kinetis.h, so code using them can compile on Teensy 3.x boards without needing lots of #ifdef checks.

I also made a number of small changes to the build process, mostly to fix incorrect size info Arduino prints after compiling. I've also updated the toolchain for Raspberry Pi, hopefully with all the missing files. But the only Pi I have set up is headless... so hoping someone with a Pi properly set up can give it a try (one more line to cross off msg #6).

Will package up 1.47-beta4 now.
 
I've uploaded 1.47-beta4. Links are on msg #2.

This version has fixes from Kurt and Mike, and should have all Serial functions working.

A number of minor changes were made to the build process, mainly to fix the sizes Arduino prints.

Raspberry Pi's toolchain is updated, hopefully now having everything need to built for T4.
 
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.

Ran a USB output flood sketch and killed the IDE quickly, then tried the lps_test and got this similar result swamping the IDE with count seeming stable at 223,209 lines per sec - then 438,361 when the IDE JAVA did the following:
Code:
Sketch uses 16208 bytes (0%) of program storage space. Maximum is 2031616 bytes.
Global variables use 20464 bytes (1%) of dynamic memory, leaving 1028112 bytes for local variables. Maximum is 1048576 bytes.
T:\Ard186t4b2\hardware\teensy/../tools/teensy_post_compile -file=lps_test.ino -path=T:\TEMP\arduino_build_100139 -tools=T:\Ard186t4b2\hardware\teensy/../tools -board=TEENSY40 -reboot -port=usb:0/140000/0/8/6 -portlabel=hid#vid_16c0&pid_0478 Bootloader -portprotocol=Teensy 
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
	at javax.swing.text.GapContent.allocateArray(GapContent.java:94)
	at javax.swing.text.GapVector.resize(GapVector.java:214)
	at javax.swing.text.GapVector.shiftEnd(GapVector.java:229)
	at javax.swing.text.GapContent.shiftEnd(GapContent.java:345)
	at javax.swing.text.GapVector.open(GapVector.java:201)
	at javax.swing.text.GapVector.replace(GapVector.java:142)
	at javax.swing.text.GapContent.insertString(GapContent.java:132)
	at javax.swing.text.AbstractDocument.handleInsertString(AbstractDocument.java:723)
	at javax.swing.text.AbstractDocument.insertString(AbstractDocument.java:707)
	at javax.swing.text.PlainDocument.insertString(PlainDocument.java:130)
	at javax.swing.JTextArea.append(JTextArea.java:477)
	at processing.app.AbstractTextMonitor.updateTextArea(AbstractTextMonitor.java:185)
	at processing.app.AbstractTextMonitor.lambda$message$0(AbstractTextMonitor.java:175)
	at processing.app.AbstractTextMonitor$$Lambda$147/29174690.run(Unknown Source)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
	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.awt.EventQueue.dispatchEvent(EventQueue.java:728)
	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)
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
	at javax.swing.text.GapContent.allocateArray(GapContent.java:94)
	at javax.swing.text.GapVector.resize(GapVector.java:214)
	at javax.swing.text.GapVector.shiftEnd(GapVector.java:229)
	at javax.swing.text.GapContent.shiftEnd(GapContent.java:345)
	at javax.swing.text.GapVector.open(GapVector.java:201)
	at javax.swing.text.GapVector.replace(GapVector.java:142)
	at javax.swing.text.GapContent.insertString(GapContent.java:132)
	at javax.swing.text.AbstractDocument.handleInsertString(AbstractDocument.java:723)
	at javax.swing.text.AbstractDocument.insertString(AbstractDocument.java:707)
	at javax.swing.text.PlainDocument.insertString(PlainDocument.java:130)
	at javax.swing.JTextArea.append(JTextArea.java:477)
	at processing.app.AbstractTextMonitor.updateTextArea(AbstractTextMonitor.java:185)
	at processing.app.AbstractTextMonitor.lambda$message$0(AbstractTextMonitor.java:175)
	at processing.app.AbstractTextMonitor$$Lambda$147/29174690.run(Unknown Source)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
	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.awt.EventQueue.dispatchEvent(EventQueue.java:728)
	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)
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
	at javax.swing.text.GapContent.allocateArray(GapContent.java:94)
	at javax.swing.text.GapVector.resize(GapVector.java:214)
	at javax.swing.text.GapVector.shiftEnd(GapVector.java:229)
	at javax.swing.text.GapContent.shiftEnd(GapContent.java:345)
	at javax.swing.text.GapVector.open(GapVector.java:201)
	at javax.swing.text.GapVector.replace(GapVector.java:142)
	at javax.swing.text.GapContent.insertString(GapContent.java:132)
	at javax.swing.text.AbstractDocument.handleInsertString(AbstractDocument.java:723)
	at javax.swing.text.AbstractDocument.insertString(AbstractDocument.java:707)
	at javax.swing.text.PlainDocument.insertString(PlainDocument.java:130)
	at javax.swing.JTextArea.append(JTextArea.java:477)
	at processing.app.AbstractTextMonitor.updateTextArea(AbstractTextMonitor.java:185)
	at processing.app.AbstractTextMonitor.lambda$message$0(AbstractTextMonitor.java:175)
	at processing.app.AbstractTextMonitor$$Lambda$147/29174690.run(Unknown Source)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
	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.awt.EventQueue.dispatchEvent(EventQueue.java:728)
	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)
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
	at javax.swing.text.GapContent.allocateArray(GapContent.java:94)
	at javax.swing.text.GapVector.resize(GapVector.java:214)
	at javax.swing.text.GapVector.shiftEnd(GapVector.java:229)
	at javax.swing.text.GapContent.shiftEnd(GapContent.java:345)
	at javax.swing.text.GapVector.open(GapVector.java:201)
	at javax.swing.text.GapVector.replace(GapVector.java:142)
	at javax.swing.text.GapContent.insertString(GapContent.java:132)
	at javax.swing.text.AbstractDocument.handleInsertString(AbstractDocument.java:723)
	at javax.swing.text.AbstractDocument.insertString(AbstractDocument.java:707)
	at javax.swing.text.PlainDocument.insertString(PlainDocument.java:130)
	at javax.swing.JTextArea.append(JTextArea.java:477)
	at processing.app.AbstractTextMonitor.updateTextArea(AbstractTextMonitor.java:185)
	at processing.app.AbstractTextMonitor.lambda$message$0(AbstractTextMonitor.java:175)
	at processing.app.AbstractTextMonitor$$Lambda$147/29174690.run(Unknown Source)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
	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.awt.EventQueue.dispatchEvent(EventQueue.java:728)
	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)
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space

// …

Ran the version with this change before count++:
Code:
  if ( Serial.availableForWrite() > 15 )
    count = count + 1;
The printed count was 3,000 something and the IDE (after restarting it) died again.

That change - ( there is a PULL request on the sample ) - works as expected on T_3.6.

<edit>: Looks that code could really be as below - gives reasonable number then IDE breaks:
Code:
  if ( Serial.availableForWrite() > 15 ) {
    Serial.print("count=");
    Serial.print(count);
    Serial.print(", lines/sec=");
    Serial.println(count_per_second);
    count = count + 1;
  }
 
1.47 beta 4 tested on Raspberry Pi.( will break out the Jetson after lunch )

Noting the new size reports on a few compile/uploads. I was wondering about this before but hadn't dug around for info.
 
...

Noting the new size reports on a few compile/uploads. I was wondering about this before but hadn't dug around for info.

Looking at the memory report in p#3267 - can the sketch really get all dynamic memory: "local variables >> Maximum is 1048576 bytes" ?

Sketch uses 16208 bytes (0%) of program storage space. Maximum is 2031616 bytes.
Global variables use 20464 bytes (1%) of dynamic memory, leaving 1028112 bytes for local variables. Maximum is 1048576 bytes.

Is no code moved to RAM if used by the sketch? And the sketch make 'Global variables' that cross all boundaries and fill RAM?
 
Well, before I would get no change in reported ram usage even if I increased the audio blocks in a sketch to say, 1200. The compiler would halt above 2000. I just saw upper 30% area with the delay example sketch modified as above.

I just took it as read this chip is "different" (insert sales copy here) and the actual result was evading the report.
 
Well, before I would get no change in reported ram usage even if I increased the audio blocks in a sketch to say, 1200. The compiler would halt above 2000. I just saw upper 30% area with the delay example sketch modified as above.

I just took it as read this chip is "different" (insert sales copy here) and the actual result was evading the report.

Allocations at run time - like Audio Buffers - or malloc() are not included in the compile time allocations from the dynamic RAM.
 
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.
 
So far, the plan as been to put the all the ordinary variables in DTCM and let the stack grow downward, and let malloc() serve up the OCRAM memory.

Hi Paul,

I don't think it is a bad idea.
I guess cached/uncached memory is independent of DTCM/OCRAM
That would mean that data and DMA buffers can end up in static variables (at least 128K for e.g for the IL9341 buffer) and 512K of malloc still available in OCRAM.
That should be enough for my AtariST emulator ;-)
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.

Anyone experimented with PSRAM on the T4B2? Will it be possible to use a dedicated SPI bus for it next to the one dedicated to the display and the SD card/SDIO?
I experimented PSRAM on the ESP32 for an AtariST emu port but I was disappointed with performance. There both flash and PSRAM are on the same bus and share the same cache AFAIK. It keep swapping for 68000 emulation code and ST RAM continuously...

J-M
 
okay, on my rpi 3b+ put a fresh copy of 1.8.9 and beta 4 and it wouldnt compile fastled's demo100, applied the patch to fastled, and it does compile now. no idea if it runs :) dun have a t4 here, but I think it should. dont know if this is usefull or not. but here we are :)
 
Status
Not open for further replies.
Back
Top