Forum Rule: Always post complete source code & details to reproduce any issue!
Page 131 of 173 FirstFirst ... 31 81 121 129 130 131 132 133 141 ... LastLast
Results 3,251 to 3,275 of 4314

Thread: Teensy 4.0 First Beta Test

  1. #3251
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,103
    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.

  2. #3252
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,423
    Unless there has been a very recent update, Paul has only implemented
    USB serial...

  3. #3253
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,103
    @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

  4. #3254
    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?

  5. #3255
    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.

  6. #3256
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,576
    I've committed a first attempt at Serial.availableForWrite().

    https://github.com/PaulStoffregen/co...06e57912b65ecd

    I believe together with Kurt's recent pull request, this completes all the Serial functionality. Much more optimization is still possible, but at least everything should now work.

  7. #3257
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,576
    @Frank - On the list of known issues (msg #6) is this early problem with the cache.

    write back cache & DMA problems, #485, #482
    I'm guessing this is no longer an issue? Is removing it from the list ok?

  8. #3258
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,423
    Quote Originally Posted by PaulStoffregen View Post
    I've committed a first attempt at Serial.availableForWrite().

    https://github.com/PaulStoffregen/co...06e57912b65ecd

    I believe together with Kurt's recent pull request, this completes all the Serial functionality. Much more optimization is still possible, but at least everything should now work.
    Did quick check with Serial repeater test app, and reenabled the call to availableForWrite and it runs!

  9. #3259
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,423
    Quote Originally Posted by PaulStoffregen View Post
    @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?

  10. #3260
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,576
    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?

  11. #3261
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,423
    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)

  12. #3262
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,576
    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.

  13. #3263
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    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 by Frank B; 06-12-2019 at 04:35 PM.

  14. #3264
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    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.

  15. #3265
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,576
    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.

  16. #3266
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,576
    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.

  17. #3267
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,711
    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;
      }

  18. #3268
    Member ETMoody3's Avatar
    Join Date
    Mar 2014
    Location
    New Ulm, Mn
    Posts
    79
    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.

  19. #3269
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,711
    Quote Originally Posted by ETMoody3 View Post
    ...

    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?

  20. #3270
    Member ETMoody3's Avatar
    Join Date
    Mar 2014
    Location
    New Ulm, Mn
    Posts
    79
    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.

  21. #3271
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,711
    Quote Originally Posted by ETMoody3 View Post
    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.

  22. #3272
    Member ETMoody3's Avatar
    Join Date
    Mar 2014
    Location
    New Ulm, Mn
    Posts
    79
    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.

  23. #3273
    Quote Originally Posted by PaulStoffregen View Post
    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

  24. #3274
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Quote Originally Posted by Jean-Marc View Post
    Anyone experimented with PSRAM on the T4B2?
    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..
    Last edited by Frank B; 06-12-2019 at 10:17 PM.

  25. #3275
    Senior Member
    Join Date
    Aug 2016
    Posts
    129
    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •