Forum Rule: Always post complete source code & details to reproduce any issue!
Page 21 of 32 FirstFirst ... 11 19 20 21 22 23 31 ... LastLast
Results 501 to 525 of 798

Thread: Teensy 4.1 Beta Test

  1. #501
    Senior Member DD4WH's Avatar
    Join Date
    Oct 2015
    Location
    Central Europe
    Posts
    618
    Soldered a second PSRAM chip to the Teensy 4.1 underside and updated to Teensyduino 1.52 beta5.

    Using Paulsī sketch from #478 it detects both chips:

    Code:
    External RAM test
    
    PSRAM size is 16 Mbyte
    myint = 123456
    myint = 123456
    *pint = 12345678
    *pint = 12345678
    *pint = 6541230
    *pint = 6541230
    will now try the logger sketch.

  2. #502
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,910
    @mjs: I was talking about the T4/T41 program flash (not the optional chips).
    But now that I'm writing this... I'm not sure anymore .. maybe it is on the Flexspi2, too? (I'm too tired to look, now)
    I've implemented a new way for stereo-decode on my sdr and take a nap now.

    Edit: T4_Powerbuttons flexRamInfo() now displays the PSRAM-size. I've updated the lib a few minutes ago.
    Last edited by Frank B; 05-13-2020 at 07:37 PM.

  3. #503
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    6,940
    Sorry I know this is not T4.1 specific as it hits T4 as well. But what is the proper way to use PROGMEM on parameters passed to a function. Note: code I am extracting it from ran earlier on AVR boards and may still want it to...
    Code:
    const short cCoxaMin1[] PROGMEM = {0, 1, 2, 3};
    void setup() {
      while (!Serial);
      Serial.begin(115200);
    }
    short foo( const short *sMin PROGMEM  ) {
      return 0;
    }
    
    void loop() {
      foo(cCoxaMin1);
    }
    I tried moving the PROGMEM to about 4 different place on this line, but in all cases it complains with:
    Code:
    zzz:6: error: section attribute not allowed for 'sMin'
     short foo( const short PROGMEM *sMin ) {
                             ^
    So is there a proper format that works both for T4.x and Atmega328?

  4. #504
    Senior Member DD4WH's Avatar
    Join Date
    Oct 2015
    Location
    Central Europe
    Posts
    618
    Quote Originally Posted by Frank B View Post
    Edit: T4_Powerbuttons flexRamInfo() now displays the PSRAM-size. I've updated the lib a few minutes ago.
    Excellent! :-)
    Code:
    FLASH:  36048  0.44% of 7936kB (8090416 Bytes free) FLASHMEM, PROGMEM
    ITCM:   24288 74.12% of   32kB (   8480 Bytes free) (RAM1) FASTRUN
    PSRAM: 16 MB
    OCRAM:
       524288 Bytes (512 kB)
    -   12384 Bytes (12 kB) DMAMEM
    -     208 Bytes (0 kB) Heap
       511696 Bytes heap free (499 kB), 12592 Bytes OCRAM in use (12 kB).
    DTCM:
       491520 Bytes (480 kB)
    -   12992 Bytes (12 kB) global variables
    -    1284 Bytes (1 kB) max. stack so far
    =========
    
       477244 Bytes free (466 kB), 14276 Bytes in use (13 kB).

  5. #505
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    936
    But what is the proper way to use PROGMEM on parameters passed to a function.
    Maybe I misunderstand something but why do you want PROGMEM in the parameter declaration? A pointer to a short is a pointer, it shouldn't play a role where it points to?

    This
    Code:
    short foo(const short *sMin)
    {
      return 0;
    }
    compiles and works?

  6. #506
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    5,363
    Quote Originally Posted by KurtE View Post
    Thanks Paul, but my issue is more that I want to compile the library differently depending on if their is external memory. The current hack is, in the
    ILI9488_t3 header file has:

    So it detected this and all of the library code changed to use 4 bytes instead of 2, DMA update code completely different...

    So again looks like for libraries like this, need a different approach, which I have been thinking of doing anyway... But more work.
    You can probably use:
    Code:
    extern "C" uint8_t external_psram_size;
    and test if external_psram_size > 0 to include the buffer?

  7. #507
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    11,824
    Quote Originally Posted by luni View Post
    Maybe I misunderstand something but why do you want PROGMEM in the parameter declaration? A pointer to a short is a pointer, it shouldn't play a role where it points to?
    ...
    compiles and works?
    I wondered that too as ARM won't care - except then 'AVR' is noted. Once moved to PROGMEM an AVR build will need the notice for memory access.

  8. #508
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    11,824
    My T_4.1's are in the mailbox ... got them and distracted ... have some chores first

    @mjs513 - Paul p#470 made a note about 'more than 8MB' :: 2: To use more than 8 megabytes, you'll need to write FLEXSPI2_FLSHA2CR0 with a larger number.
    > (afaik) That allowed the two PSRAM usage to be contiguous 16 MB.

    RE: the PSRAM log error p#498 and data found corruption:
    No joy from cache flush that should be right?
    arm_dcache_flush_delete((void *)&dbuff0[saveidx], sizeof(datrec)); // write cache to memory
    and
    arm_dcache_flush_delete((void *)&dbuff1[saveidx], sizeof(datrec)); // write cache to memory

    Summary - two PSRAM buffers in use. They are written from intervalTimer( _isr )
    The one buffer "0" starting at 70050000 is found holding data intended for buffer "1" at 70090010
    BUFF at 70050000
    skipped 0 4595, 91901, 70090010, 1 kk==16385 ????
    **: if that buffer boundary is not hit, or the _isr() speed is dropped - the data does not trigger as corrupted.
    **: the buffer size was made { while still hitting that 'boundary problem' } so one would fit in RAM1 and the other in RAM2 - and that works.

    @KurtE: Can you aim a display DMA buffer at
    Each buffer is size of 294080 bytes ( 0x47cc0 ).
    First (with trouble) starts at :: struct datrec *dbuff0 = (datrec *)0x70050000;
    I just moved the 2nd to just above that :: struct datrec *dbuff1 = (datrec *)0x7005A000;
    This puts 2nd buff just above 1st buff. The problem recurs in First buffer now at new address where 2nd buff data appears:

    After dbuff1[] write with no errors, This shows first buffer dbuff0[] got filled. Then it was marked for write and at offset 2560 the initial writes to 2nd buffer dbuff1[]
    Code:
    >>>1>>>		 1 FULL D @ 18380 &dbuff>700A1CC0
     	 BUFF at 7005A000
    	DONE 18379 >> 1838, 36759, 700A1CB0, 1	<<<<<<
    1] 918.84 mSec fill [lp#3979718] 	Written dbuff1 to data file.  tmilli =  919  took  10.60 mSec
    
    >>>0>>>		 0 FULL D @ 18380 &dbuff>70097CC0
     	 BUFF at 70050000
    skipped 6	2757, 55140, 7005A000, 1	 	 kk==2560  ????
    skipped 0	2757, 55141, 7005A010, 1	 	 kk==2561  ????
    skipped 2	1968, 39353, 7005A210, 0	 	 kk==2593  ????
    	DONE 18379 >> 2757, 55139, 70097CB0, 0	<<<<<<
    0] 919.13 mSec fill [lp#5] 	Written dbuff0 to data file.  tmilli =  1838  took  10.73 mSec

  9. #509
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,114
    Quote Originally Posted by KurtE View Post
    my issue is more that I want to compile the library differently depending on if their is external memory.
    You can't know at compile time whether the PSRAM chip will be installed on the board.

    I would create 2 different constructors for the library which initialize a constexpr pointer or other variable you use. If it's constexpr and initialized by the constructor, the compiler should optimize away code which reads it and decides which memory to use.

  10. #510
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    5,363
    Quote Originally Posted by defragster
    @mjs513 - Paul p#470 made a note about 'more than 8MB' :: 2: To use more than 8 megabytes, you'll need to write FLEXSPI2_FLSHA2CR0 with a larger number.
    > (afaik) That allowed the two PSRAM usage to be contiguous 16 MB.
    yes but unfortunately it halts the FLASH unless I can change it at run time? But have feeling maybe have to do a complete init. Also I am confused again with memory locations. Remember my little graphic:
    Click image for larger version. 

Name:	Picture1.png 
Views:	0 
Size:	30.6 KB 
ID:	20100
    Well PSRAM0 still starts at 0x07000000u, and PRAM1 starts at an offset of 0x800000 which is after flash. FLASH starts at 0x07100000u (so offset still 0x01000000u, so flash goes from 0x71000000u through 0x71FFFFFEu). So for PSRAM to be continuous would the second PSRAM need to start at 0x07FFFFE and not 0x800000

  11. #511
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,114
    Quote Originally Posted by MichaelMeissner View Post
    I am wondering for 1.53, whether we need a class that sits between the audio readers (i.e. RAW, WAV, etc.) and the actual filesystem (SD, SD-Fat Beta, SPIFFS, SerialFlash, etc.). That way, you can easily slide in new filesystems without having to make new versions of the readers.
    Yes, this was on my list of things to do in 1.52, but it's going to slip to 1.53.

    This really is desperately needed.

  12. #512
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,114
    Quote Originally Posted by mjs513 View Post
    FLASH starts at 0x07100000u
    Sorry for the last minute change. Flash now starts at 0x70800000.

  13. #513
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,114
    Quote Originally Posted by MichaelMeissner View Post
    Similarly, it would be nice if there was some way to figure out if 1 or 2 psram chips are loaded
    1.52-beta5 adds this in the startup code. See the example code on msg #478.



    Quote Originally Posted by defragster View Post
    With 1 PSRAM chip that is expected - the write works to cache - but dump of cache in code voids that value when it is not backed by a chip.
    I don't know what "dump of cache" means. The cache functions are delete, flush, and flush_delete. None of them are named "dump". Normally these functions are only used with DMA and for special hardware testing. They should not be required or used in "normal" programs, unless DMA is accessing the memory.

    Obviously if you delete data from the cache before it's been written back to memory (and you really have no way without DMA to know) then the data is deleted and gone forever. Data loss is the expected and correct behavior if using the delete function.

    But if you lost data with the other functions, that's a serious matter. Please help me to reproduce the problem if you saw anything like that.

  14. #514
    Junior Member
    Join Date
    Dec 2019
    Posts
    19
    Quote Originally Posted by PaulStoffregen View Post
    We will soon begin a public beta test for Teensy 4.1.

    At this time, PJRC would like to offer free Teensy 4.1 boards to the following people:
    ../..
    Everyone on this list who does not receive a pre-production board will be offered a free Teensy 4.1 from the first production batch (which will have all power pins correct). If you're busy right now, or you'd just prefer to wait for the production batch, there is no need to do anything right now. We expect to release Teensy 4.1 sometime in May, so the wait will not be long...
    .
    I'm not on the list but would love to test these pre-production boards early too for my current more challenging musical pcb projects, I would offer easily $10 for each of these beta boards too if it helps (and of course shipment too)

  15. #515
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,910
    fab672000: a bit late.. you can buy them already.

    https://www.pjrc.com/store/teensy41.html

  16. #516
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,910
    What is the plan if 16MB (or 32?) PSRAM occur? (Adresses)
    It will take not too long and such things will be produced.

  17. #517
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,114
    I'm updated msg #1 to clearly state the beta test is finished and Teensy 4.1 can be purchased normally.

  18. #518
    Junior Member
    Join Date
    Dec 2019
    Posts
    19
    @Franck B :I know thanks, but if there is some stock left of beta ones, I would be interested to get some of them for my lab use, as every buck counts when you spend on pcb's and various parts ...

  19. #519
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,114
    Quote Originally Posted by Frank B View Post
    What is the plan if 16MB (or 32?) PSRAM occur?
    Step 1 of the plan is to read their datasheets and hope the ID command can be used to detect which chip is used.

    Assuming the ID is usable, the startup code will need to be changed to put the correct settings into FLEXSPI2_FLSHA1CR0 and FLEXSPI2_FLSHA2CR0 and write external_psram_size with the correct total size. But until different size chips can be purchased (no, never going to support the tiny & slow 23LC1024 chips) there's little point to making the code more complicated.

    If the ID bytes are the same, any "solution" is probably going to start with a lot of swear words...

  20. #520
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    11,824
    Quote Originally Posted by Frank B View Post
    What is the plan if 16MB (or 32?) PSRAM occur? (Adresses)
    It will take not too long and such things will be produced.
    Paul showed some MATH once. Current market only showing 8MB was thought to be small layout PSRAM. Large Layout made room for 16MB+ on that channel thought to be - and early Beta shipped as FLASH.

    That seemed to show there is some limit on the boundary setting - one chip limited to 8 MB and the other can be 16 MB or some much larger size - like to allow NAND versus smaller NOR capacity.

  21. #521
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,114
    Quote Originally Posted by fab672000 View Post
    but if there is some stock left of beta ones
    No. All those early boards were used up. Most shipped in the first couple days. A few lingered here until nearly the end of the beta test, but in the end all of them were shipped to beta testers. There are no leftovers.

  22. #522
    Junior Member
    Join Date
    Dec 2019
    Posts
    19
    Quote Originally Posted by PaulStoffregen View Post
    No. All those early boards were used up. Most shipped in the first couple days. A few lingered here until nearly the end of the beta test, but in the end all of them were shipped to beta testers. There are no leftovers.
    Well too bad for me and great for the testers of this batch, thanks for your reply and long life to 4.1, again another beautiful board.
    Thank you for your sustained efforts, today I only use teensy boards for my new arduino projects, because your boards and libs are simply amazing, keep on the good work!

  23. #523
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    11,824
    Quote Originally Posted by PaulStoffregen View Post
    1.52-beta5 adds this in the startup code. See the example code on msg #478.

    I don't know what "dump of cache" means. The cache functions are delete, flush, and flush_delete. None of them are named "dump". Normally these functions are only used with DMA and for special hardware testing. They should not be required or used in "normal" programs, unless DMA is accessing the memory.

    Obviously if you delete data from the cache before it's been written back to memory (and you really have no way without DMA to know) then the data is deleted and gone forever. Data loss is the expected and correct behavior if using the delete function.

    But if you lost data with the other functions, that's a serious matter. Please help me to reproduce the problem if you saw anything like that.
    Opps word 'dump' was careless - but reference was to specific PJRC provided example code using :: arm_dcache_flush_delete()
    > that was indicated by name below and what was tried and showed no effect.
    -- > the same erroneous 'formatted' data appears where it should not be in the 'other' buffer.
    > using the 'proper' eRAM write funcs (? as extended from PJRC sample by @mjs513 in SPIFFS and other testing) in that sample shows no error { forgot to note this was added/tried }
    > same code using ptr's instead of PSRAM to RAM1 & RAM2 works - to replace the two PSRAM buffers.
    > If the base pointer does not cross the 'recurrent' error boundary location then it works as expected with same size PSRAM buffers.

    That error has shown for 3 of us - running same code that is doing Direct Pointer writes to PSRAM - write intended for dbuff1[] #2 of PSRAM seem to go there - but also 'ghosts' into some (small var size) portion of dbuff0[]

    Paul: Will get back {Code has ping/ponged between myself and mjs513 recently} and post a clearer example. Have seen it repro today with PJRC PSRAM init so that removes the need for external lib - and it is also now running PSRAM at slower speed - but still shows up in repro case.

  24. #524
    Junior Member
    Join Date
    Feb 2019
    Posts
    5
    Quote Originally Posted by KurtE View Post
    Sorry I know this is not T4.1 specific as it hits T4 as well. But what is the proper way to use PROGMEM on parameters passed to a function. Note: code I am extracting it from ran earlier on AVR boards and may still want it to...
    Code:
    const short cCoxaMin1[] PROGMEM = {0, 1, 2, 3};
    void setup() {
      while (!Serial);
      Serial.begin(115200);
    }
    short foo( const short *sMin PROGMEM  ) {
      return 0;
    }
    
    void loop() {
      foo(cCoxaMin1);
    }
    I tried moving the PROGMEM to about 4 different place on this line, but in all cases it complains with:
    Code:
    zzz:6: error: section attribute not allowed for 'sMin'
     short foo( const short PROGMEM *sMin ) {
                             ^
    So is there a proper format that works both for T4.x and Atmega328?
    I would try to undef PROGMEN if the processor is ARM based.

  25. #525
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,910
    Quote Originally Posted by jmr View Post
    I would try to undef PROGMEN if the processor is ARM based.
    PROGMEM is needed to place data in the flash. It's for the linker.
    Without it, you can't use very large data-arrays (like wavetables)

    I guess we need a tutorial for things like FLASHMEM, PROGMEM in the WIKI.
    Esp. FLASHMEM helps to save RAM... only a very few use it.

Posting Permissions

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