Forum Rule: Always post complete source code & details to reproduce any issue!
Page 27 of 32 FirstFirst ... 17 25 26 27 28 29 ... LastLast
Results 651 to 675 of 784

Thread: Teensy 4.1 Beta Test

  1. #651
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,674
    Quote Originally Posted by manitou View Post
    macros are used for testing compile-time variables, you're trying to use run-time variable with compile-time statements
    #define X 2
    #if X > 1
    ....
    To amplify what manitou said, you cannot use this in a pre-processor statement. It is a run-time variable that is set by the startup code to the size of the psram chips that are soldered on the board. The Teensy startup code basically sends commands to the first memory, saying are you a psram chip, and if so, what size are you? If it is a psram chip, it will also query the second pad, and if you have two psram chips soldered on (instead of a psram and a flash chip), the variable will include both chips, and use them automatically.

    So, you need to write your code that for the Teensy 4.1, add the possibility of psram chips, but you can't depend on knowing whether they are soldered in at compile.time.

  2. #652
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,812
    Quote Originally Posted by mjs513 View Post
    The problem is that the #if (psram_size > 0) is never executed even though external_psram_size = 8. Tried variations on a theme including external_psram_size directly as the test case.

    Any suggestions?
    You can't do this with preprocessor #if directives. You need to do it with normal code.

    Code:
      if (external_psram_size > 0) {
    	uint16_t writeaddress = 0x00;
    	uint8_t valERAM;
    	uint8_t *ptrERAM = (uint8_t *)0x70000000;  // Set to ERAM
    	const uint32_t  sizeofERAM = 0x7FFFFE / sizeof( valERAM ); // sizeof free RAM in 
      }
    external_psram_size is an ordinary variable which gets written during startup when the hardware sends ID commands to locations. While compiling, the preprocessor can't possibly know whether one or both locations will answer with the ID of a PSRAM chip.

  3. #653
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,874
    not sure what "writeaddress" is - uint16_t seems a bit short (Sorry for the pun)
    64kB only? But again - I don't know what it is used for.

  4. #654
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    5,099
    Thanks everyone. Had a feeling that was going to be the case.

    My local copy of library has been updated and is working no issues to identify the possible chip combinations (not posted yet). The lib automatically sets the correct configuration and tests the following cases:
    1. No Chips- exits with warning message
    2. 1 PSRAM chip and 1 FLASH chip - sets correct configuration parameters (0x2000 and 0x4000) respectively
    3. 2 PSRAM chip - exits with warning message that you only have 2 psram chips.
    3. only 1 FLASH Chip - assumes what I wrote in post #632
    4. If not T4.1 exits with warning.

    Was trying to get cute with the examples and play around a bit to see what I could get away with. Now I know I cant get cute

  5. #655
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    5,099
    Quote Originally Posted by Frank B View Post
    not sure what "writeaddress" is - uint16_t seems a bit short (Sorry for the pun)
    64kB only? But again - I don't know what it is used for.
    That's one of things that is in one of the examples I am cleaning up that has to get deleted - not used or needed anymore believe it or not

  6. #656
    Member JaredReabow's Avatar
    Join Date
    May 2020
    Location
    oxford , UK
    Posts
    56
    Click image for larger version. 

Name:	T4.1B.png 
Views:	53 
Size:	239.2 KB 
ID:	20145
    Is this correct?
    Where are pins 42 to 47?

  7. #657
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    11,490
    Quote Originally Posted by MichaelMeissner View Post
    Sure in a bit.
    The Ethernet pins have the PHY chip derived function as noted on the silkscreen. That matches 1::1 the Paul posted OSH MagJack breakout. They have no direct 'Arduino/TD' pin mapping - the 12'ish pins feeding the PHY chip are consumed to present the indicated signals.

  8. #658
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    11,490
    Quote Originally Posted by JaredReabow View Post
    Click image for larger version. 

Name:	T4.1B.png 
Views:	53 
Size:	239.2 KB 
ID:	20145
    Is this correct?
    Where are pins 42 to 47?
    AFAIK - without looking - 42 to 47 are the SDIO pins feeding the SD socket. They shifted from T_4.0 pin # to allow those numbers to appear on the edge pins.

  9. #659
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    6,624
    Another FYI - I have hacked up a quick and dirty castellated adapter for T4.1, which I got back this morning from OSHPark.

    Click image for larger version. 

Name:	IMG_1119.jpg 
Views:	36 
Size:	159.4 KB 
ID:	20147

    Problem is, the T4.1, I was planning on maybe trying it on, got diverted yesterday to start testing T4.1 with two memory chips...

    Looks like I will need to wait until I order some more T4.1s

  10. #660
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,874
    @Paul - you wrote you're working on the website.
    Found two more pages w/o T4.x:
    https://www.pjrc.com/teensy/techspecs.html
    https://www.pjrc.com/store/

  11. #661
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    5,099
    FLASH-ONLY SPIFFS LIBRARY

    Created a new branch SPIFFS-FLASH-ONLY that removed the PSRAM portion of the old library and renamed to spiffs_t4. EDIT: Only one library needs to be downloaded now.

    Changes from the old library:
    1. Constructor now called using spiffs_t4, i.e.
    Code:
    #include <spiffs_t4.h>
    #include <spiffs.h>
    
    spiffs_t4 eRAM;
    2. begin statement no longer needs a configuration specified the lib does it for you. so all you need is, for example:
    Code:
    eRAM.begin()
    3. Several cases are automatically addressed in the library:
    1. 1 PSRAM and 1 FLASH installed (tested)
    2. 1 FLASH installed only (not tested don't have a T4 with only a FLASH installed.
    3. Lib exits for following conditions.
    • T4.1 not specified
    • 1 PSRAM but no FLASH
    • No FLASH installed


    There is no messing with the core for the FLASH config. Done with the lib.

    Only three examples are provided.

    EDIT: Next the PSRAM lib I was working that was part of the extRAM_t4 lib but was removed.
    Last edited by mjs513; 05-16-2020 at 10:51 PM. Reason: Update

  12. #662
    Senior Member
    Join Date
    Oct 2015
    Location
    Roma (IT, EU)
    Posts
    312
    Quote Originally Posted by Frank B View Post
    @Paul - you wrote you're working on the website.
    Found two more pages w/o T4.x:
    https://www.pjrc.com/teensy/techspecs.html
    https://www.pjrc.com/store/
    I did open a thread about needed website updates (I don't know if Paul did read it; most probably he already knows):
    https://forum.pjrc.com/threads/60862...a-few-updates-)

    Maybe we could keep updating that one?

  13. #663
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    5,099
    Quote Originally Posted by defragster View Post
    didn't reply to that note the other day … if only for SPIFFS debug and development - having it on PSRAM seemed cool. A lot faster with no FLASH Abuse or wait. And for a suitably battery/constant power system PSRAM based SPIFFS could be good for a system to run and to constant data mods with file support. And faster to dump to SD or other for backup and pull for restore on startup.
    Lets see how this works - easy enough to add it back in. I left the underlying addressing there so ….

    @Paul - @manitou: any thoughts?

    EDIT: Think the problem is going to be if someone wants to use PSRAM for both direct addressing and SPIFFs - cant happen - well it can. I can actually set it up for 2 partitions on a single chip.

  14. #664
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    11,490
    The Generic-data-logger-object thread library has evolved a bit and just now filling a 32 GB exFat SD card with 4 DWORD data struct data from 15,800,000 Bytes of PSRAM memory space.
    Should not take too long ( another 2 hours?) at 250K _isr() samples per second - over one fifth full in 1411 seconds.
    Once SD full it should stop and then has a verify to check two of the 4 DWORDs when records are read back from the SD file. A few shorter tests were valid so far.
    Never got back to the place where PSRAM failed other testing after the 15s Restore? Did not reflow or alter the PSRAM chips except touching them.

    <edit> quit the logger before full - after verify completes will format and restart to fill overnight. Has cycled the 15.8MB of PSRAM to SD after filling by _isr() to write 19.7GB.
    Seemed like a good invasive real world test - reading PSRAM in 1.58 MB pieces to SD from loop() [sd fat beta] while 250,000 isr()'s/sec write new 16 byte data chunks elsewhere into PSRAM.
    Code:
    ...
    5164.230,   Records:1291057500   Overflows:    0
    5168.970,   Records:1292242500   Overflows:    0
    5174.500,   Records:1293625000   Overflows:    0
    Stopping Logger.
    Logger Status:
    MBytes Written: 19748.19   SdCard free space: 10671.93 MBytes
    Collection time: 5177 seconds
    Max Collection delay: 1 microseconds
    Average Write Time: 286.580 milliseconds
    Maximum Write Time: 853.046 milliseconds
    
    Data Logger Directory
    2020-05-17 02:48  20707480000 LOG_0122.bin
    
    Verifying last file
    Recnum: 1000000
    ...
    Recnum: 759000000
    Recnum: 760000000
    …   
    Recnum: 1292000000
    Recnum: 1293000000
    Recnum: 1294000000
    End of file playback.
    
    Verification errors:  0
    Verification complete
    
    Warning, all data on the card will be erased.
    Enter 'Y' to continue: 
    Card size:   29.723  GiB (GiB = 2^30 bytes)
    Card will be formated exFAT
    Writing FAT .................................
    
    Writing upcase table
    
    Writing root
    
    Format done
    
    
    Card Type is exFAT
    File system initialization done.
    RTC has set the system time
    
    Starting Logger.
    
    File name is:  <LOG_0313.bin>
    Pre-allocating 1GB file space 
    Allocation succeeded.
    
    Opened  File LOG_0313.bin
     
       4.345,   Records:   1086250   Overflows:    0
    ...
    Quote Originally Posted by mjs513 View Post
    Lets see how this works - easy enough to add it back in. I left the underlying addressing there so ….
    ...
    EDIT: Think the problem is going to be if someone wants to use PSRAM for both direct addressing and SPIFFs - cant happen - well it can. I can actually set it up for 2 partitions on a single chip.
    Thx, Downloaded the latest but not tried yet … FLASH or PSRAM ...
    I have one of my two production T_4.1's that could just get a FLASH alone to start and test. Should have ordered more but wasn't sure how fast they'd go.

    SparkFun got something over 250+ and they now have only 16!
    Last edited by defragster; 05-17-2020 at 10:14 AM.

  15. #665
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,494
    Quote Originally Posted by mjs513 View Post
    FLASH-ONLY SPIFFS LIBRARY

    Created a new branch SPIFFS-FLASH-ONLY that removed the PSRAM portion of the old library and renamed to spiffs_t4. EDIT: Only one library needs to be downloaded now.
    Can one still directly address the EFLASH locations for read's? and what is the base address 0x70000000? 0x71000000? 0x7080000? or depends on whether EFLASH chip is also installed?

    and EFLASH/ERAM clock is set by core in startup.c?

    ? and should it be 0x4000 in FLEXSPI2_FLSHA2CR0 = 0x40000;
    Last edited by manitou; 05-17-2020 at 10:15 AM.

  16. #666
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    11,490
    Quote Originally Posted by manitou View Post
    Can one still directly address the EFLASH locations for read's? and what is the base address 0x70000000? 0x71000000? 0x7080000?
    Flash reads AFAIK correctly are at 0x7080000 - seems that should have access to all 16MB. Using SPIFFS will 'own that space' unless it is 'segmented'?

    Looks tight and seems to expect to use all 16 MB - in :: \libraries\SPIFFS_t4\src\spiffs_t4.cpp:
    Code:
    	static const uint32_t flashBaseAddr[3] = { 0x800000u};
    	static const uint32_t eramBaseAddr = 0x07000000u;
    	static char flashID[8];
    	static const void* extBase = (void*)0x70000000u;
    	//4meg = 4,194,304‬bytes
    	static uint32_t flashCapacity[3] = {16u * 1024u * 1024u};
    Not sure if that can be runtime adjusted in config?:
    cfg.phys_size = flashCapacity[_spiffs_region]; // use 16 MB flash TODO use ID to get capacity
    <edit> 2nd Part - same file::
    Code:
    int8_t spiffs_t4::begin( ) {
    …
    	if(external_psram_size == 16){
    		Serial.println("You have 2 PSRAM Chips No Flash Installed Exiting!");
    		exit(1);
    	}
    
    	if(external_psram_size == 8) {
    	  FLEXSPI2_INTEN = 0;
    	  FLEXSPI2_FLSHA1CR0 = 0x2000;
    	  FLEXSPI2_FLSHA1CR1 = FLEXSPI_FLSHCR1_CSINTERVAL(2)
    		| FLEXSPI_FLSHCR1_TCSH(3) | FLEXSPI_FLSHCR1_TCSS(3);
    	  FLEXSPI2_FLSHA1CR2 = FLEXSPI_FLSHCR2_AWRSEQID(6) | FLEXSPI_FLSHCR2_AWRSEQNUM(0)
    		| FLEXSPI_FLSHCR2_ARDSEQID(5) | FLEXSPI_FLSHCR2_ARDSEQNUM(0);
    
    	  FLEXSPI2_FLSHA2CR0 = 0x40000;
    	  FLEXSPI2_FLSHA2CR1 = FLEXSPI_FLSHCR1_CSINTERVAL(2)
    …
    	} else if(external_psram_size == 0) {
    	  FLEXSPI2_INTEN = 0;
    	  FLEXSPI2_FLSHA1CR0 = 0x2000;

  17. #667
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    11,490
    @mjs513 - compiling ...\libraries\SPIFFS_t4\examples\MultiFileTest\Mul tiFileTest.ino

    finds error redef with files in src?
    Code:
    "T:\\TEMP\\arduino_build_MultiFileTest.ino\\libraries\\Wire\\utility\\twi.c.o" "T:\\TEMP\\arduino_build_MultiFileTest.ino/core\\core.a" "-LT:\\TEMP\\arduino_build_MultiFileTest.ino" -larm_cortexM7lfsp_math -lm -lstdc++
    T:\TEMP\arduino_build_MultiFileTest.ino\libraries\SPIFFS_t4\spiffs_t4.cpp.o:(.bss._spiffs_region+0x0): multiple definition of `_spiffs_region'
    T:\TEMP\arduino_build_MultiFileTest.ino\libraries\SPIFFS_t4\extRAM_t4.cpp.o:(.bss._spiffs_region+0x0): first defined here
    t:/arduino-1.8.12/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld.exe: Disabling relaxation: it will not work with multiple definitions
    T:\TEMP\arduino_build_MultiFileTest.ino\libraries\SPIFFS_t4\spiffs_t4.cpp.o: In function `Print::flush()':
    T:\tCode\libraries\SPIFFS_t4\src/spiffs_t4.cpp:65: multiple definition of `fd1'
    T:\TEMP\arduino_build_MultiFileTest.ino\libraries\SPIFFS_t4\extRAM_t4.cpp.o:T:\tCode\libraries\SPIFFS_t4\src/extRAM_t4.cpp:65: first defined here
    collect2.exe: error: ld returned 1 exit status

  18. #668
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    5,099
    @defragster - @manitou
    Thanks for checking but to answer your questions:
    Quote Originally Posted by manitou
    Can one still directly address the EFLASH locations for read's? and what is the base address 0x70000000? 0x71000000? 0x7080000? or depends on whether EFLASH chip is also installed?
    Depends on if there is a PSRAM chip installed. If 1 PSRAM then the base address should be 0x7080000 if no PSRAM is installed then I think the base address should be 0x70000000. But looking at it fresh and with yours and @defragster's comments think there is an error for FLEXSPI2_FLSHA1CR0 (size in MB). Currently its
    Code:
    FLEXSPI2_FLSHA1CR0 = 0x2000;
    probably should be:
    Code:
    FLEXSPI2_FLSHA1CR0 = 0x4000;
    Quote Originally Posted by manitou
    EFLASH/ERAM clock is set by core in startup.c
    Turns out yes because I forgot to copy the 132Mhz clock in!

    Quote Originally Posted by manitou
    should it be 0x4000 in FLEXSPI2_FLSHA2CR0 = 0x40000;
    Yep - typo. should be 0x4000 for 16Mb.

    Quote Originally Posted by manitou
    Can one still directly address the EFLASH locations for read's?
    Only if you don't initial the spiffs from lib. Or we could set up a config to partition the FLASH into 2 8MB sections 1 for SPIFFS and 1 for other uses depending on your flash usage as @defragster mentioned. Going to put together a second lib like what I had for readArrays, readbytes etc. might helper functions.

    Quote Originally Posted by defragster
    Not sure if that can be runtime adjusted in config?:
    cfg.phys_size = flashCapacity[_spiffs_region]; // use 16 MB flash TODO use ID to get capacity
    Yes it can, but that adds a list of chips that may or may not be able to be used. If I remember their are only 2 recommended flash chips that is recommended for the Audio card.

    Quote Originally Posted by defragster
    @mjs513 - compiling ...\libraries\SPIFFS_t4\examples\MultiFileTest\Mul tiFileTest.ino
    finds error redef with files in src?
    looks like you still have a copy of the extRAM_t4 lib in your libraries directory:
    T:\TEMP\arduino_build_MultiFileTest.ino\libraries\ SPIFFS_t4\extRAM_t4.cpp.o:T:\tCode\libraries\SPIFF S_t4\src/extRAM_t4.cpp:65: first defined here

  19. #669
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,812
    If you leave FLEXSPI2_FLSHA1CR0 alone (keeping the 0x2000 written by startup.c), the flash starting address should be 0x70800000, regardless of whether a RAM chip is installed.

  20. #670
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    5,099
    Quote Originally Posted by PaulStoffregen View Post
    If you leave FLEXSPI2_FLSHA1CR0 alone (keeping the 0x2000 written by startup.c), the flash starting address should be 0x70800000, regardless of whether a RAM chip is installed.
    Thanks Paul. That would simply things. Going to change so the address is always at 0x70800000

    But just out of curiosity if I did change it did it do it right?

  21. #671
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    5,099
    All - SPIFFS_t4 has been updated on GitHub: https://github.com/PaulStoffregen/te...ONLY/SPIFFS_t4

  22. #672
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,494
    @mjs513 i did fresh install of 1.8.12 and 1.52 on 32-bit linux, and cloned your branch and put SPIFFS_t4/ in my libraries/ and tried to compile example eram_spiffs and got errors, attached.
    Attached Files Attached Files

  23. #673
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    5,099
    Quote Originally Posted by manitou View Post
    @mjs513 i did fresh install of 1.8.12 and 1.52 on 32-bit linux, and cloned your branch and put SPIFFS_t4/ in my libraries/ and tried to compile example eram_spiffs and got errors, attached.
    Looks like you still have extRAM_t4 lib still in you libs folder:
    /tmp/arduino_build_200454/libraries/SPIFFS_t4/extRAM_t4.cpp.o:/home/dunigan/sketchbook/libraries/SPIFFS_t4/src/extRAM_t4.cpp:65:
    Delete that lib and just have SPIFFS_t4 in your lib <EDIT> meant library folder - its all self contained.
    Last edited by mjs513; 05-17-2020 at 12:30 PM.

  24. #674
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,494
    Quote Originally Posted by mjs513 View Post
    Looks like you still have extRAM_t4 lib still in you libs folder:

    Delete that lib and just have SPIFFS_t4 in your lib - its all self contained.
    i don't think i have an extra lib. you have spiffs_file fd1; in both extRAM_t4.cpp and spiffs_t4.cpp in libraries/SPIFFS_t4/src/

    maybe use static ? static spiffs_file fd1;

    and there is the message about multiple definitions: multiple definition of `_spiffs_region'

  25. #675
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    5,099
    @manitou
    One problem I am having is that I am not getting the same errors that you and @defragster are getting when I do a compile - the only difference I see I that you still are using extRAM_t4 - you don't need that library anymore for using spiffs. Essentially its now part of the spiffs_t4 library. In other words I moved the old extRAM_t4.h and extRAM.cpp files into the old SPIFFS_t4 library and renamed them spiffs_t4.h and spiffs.cpp.:
    Click image for larger version. 

Name:	Capture.PNG 
Views:	7 
Size:	19.4 KB 
ID:	20165

    Does this make sense. Just Delete the extRAM_t4 directory.

Posting Permissions

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