Forum Rule: Always post complete source code & details to reproduce any issue!
Page 132 of 137 FirstFirst ... 32 82 122 130 131 132 133 134 ... LastLast
Results 3,276 to 3,300 of 3410

Thread: Teensy 4.0 First Beta Test

  1. #3276
    Quote Originally Posted by Frank B View Post
    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

  2. #3277
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,095
    Quote Originally Posted by defragster View Post
    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.


    Quote Originally Posted by defragster View Post
    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.


    Quote Originally Posted by ETMoody3 View Post
    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.



    Quote Originally Posted by Jean-Marc View Post
    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.

  3. #3278
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,095
    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.

  4. #3279
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,613
    Quote Originally Posted by PaulStoffregen View Post

    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.

  5. #3280
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,095
    Quote Originally Posted by defragster View Post
    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.

  6. #3281
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,613
    Quote Originally Posted by PaulStoffregen View Post
    Nope, const variables without PROGMEM are allocated in RAM.
    ...
    I figured not - const doesn't mean slow ...

    … That Frank - always showing up when there is trouble

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

  8. #3283
    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

  9. #3284
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,204
    Quote Originally Posted by defragster View Post
    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)

  10. #3285
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,204
    Quote Originally Posted by PaulStoffregen View Post
    status / news / stuff confirmed working


    USBHost_t36 Works same as T3.6 More devices in testing
    Maybe this should be changed in post #4 as USBHost ehci does not work (hangs) for data transfer with buffers >=16k
    PR issued

  11. #3286
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,605
    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()

  12. #3287
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,613
    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\XPT204 6_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.

    Quote Originally Posted by WMXZ View Post
    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)

  13. #3288
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,613
    Quote Originally Posted by Frank B View Post
    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
    }

  14. #3289
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,605
    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 by Frank B; 06-13-2019 at 07:43 AM.

  15. #3290
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,095
    Here is a first draft for the front side of the pinout card.

    Click image for larger version. 

Name:	card10a_rev1.png 
Views:	90 
Size:	99.1 KB 
ID:	16758

    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.

  16. #3291
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,605
    You could just offer a PDF with a third page for xbar and flexio.

    The card looks great!

  17. #3292
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,613
    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?

  18. #3293
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,095
    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.


    Quote Originally Posted by defragster View Post
    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....

  19. #3294
    Junior Member
    Join Date
    Mar 2019
    Location
    Germany
    Posts
    6
    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...

  20. #3295
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,095
    Here's another draft with text added about the red LED.

    Click image for larger version. 

Name:	card10a_rev1.png 
Views:	72 
Size:	103.7 KB 
ID:	16759

    For everyone who's used the betas, does this description make sense? Space is limited on the card, need to choose words carefully...

  21. #3296
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,204
    Quote Originally Posted by PaulStoffregen View Post
    I struggled for quite a while about how to name the I2S signals, or whether to even include the audio stuff on the card.
    you could use SAI instead (this is as it also called in NXP document)
    but dropping SAI as with actual card should be OK

  22. #3297
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,613
    ... wide bar PWM visualized to make room for SPI1 pins …
    Click image for larger version. 

Name:	T4_SPI1.png 
Views:	13 
Size:	11.8 KB 
ID:	16761

    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?

  23. #3298
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,095
    Quote Originally Posted by defragster View Post
    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.

  24. #3299
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,613
    Quote Originally Posted by PaulStoffregen View Post
    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.

  25. #3300
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,204
    Quote Originally Posted by PaulStoffregen View Post
    Here's another draft with text added about the red LED.
    Q: Vin 3.5 to 5.2 Volts: So a power supply of 6V does not work? (was using it for T3.6)

Posting Permissions

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