Forum Rule: Always post complete source code & details to reproduce any issue!
Page 23 of 32 FirstFirst ... 13 21 22 23 24 25 ... LastLast
Results 551 to 575 of 784

Thread: Teensy 4.1 Beta Test

  1. #551
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,874
    Quote Originally Posted by PaulStoffregen View Post
    Whew, that's a big relief.

    I'm feeling pretty good about wrapping up 1.52. Anyone see any issues that should block a full non-beta release?
    Is the T4.x Audio-PWM output disabled? If not, that should be done before a release.

  2. #552
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    5,099
    @PaulStoffregen and others

    Have a question on PSRAM usage: Is there a need or desire to use PSRAM for SPIFFS or should we leave SPIFFS for FLASH only? Thoughts?

  3. #553
    Quote Originally Posted by PaulStoffregen View Post
    Whew, that's a big relief.

    I'm feeling pretty good about wrapping up 1.52. Anyone see any issues that should block a full non-beta release?
    @PaulStoffregen:

    Here's a post relating to the "wires[w2] is null" error that can be experienced when using filters in the Audio System Design Tool for Teensy Audio Library GUI. Maybe it has an easy fix . . . any chance that could make it into 1.52 ??

    https://forum.pjrc.com/threads/60859...l=1#post239080

    Mark J Culross
    KD5RXT

  4. #554
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,812
    Quote Originally Posted by mjs513 View Post
    Is there a need or desire to use PSRAM for SPIFFS or should we leave SPIFFS for FLASH only?
    I personally don't see much need to use PSRAM as a filesystem. Maybe other people do?

  5. #555
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,812
    Quote Originally Posted by kd5rxt-mark View Post
    the "wires[w2] is null" error that can be experienced when using filters in the Audio System Design Tool for Teensy Audio Library GUI. Maybe it has an easy fix . . . any chance that could make it into 1.52 ??
    No, definitely not messing with the design tool for 1.52. The last thing I want to do when we've just released new hardware and really need to make a non-beta release is dive down a deep Javascript hole! While I can muddle my way through Javascript projects, it's definitely not one of my main languages.

    But after 1.52, I'm definitely going to put some time into fully updating the design tool for the many new objects 1.52 and other recent releases have added, and document the pins and other details for Teensy 4.0 in all the existing ones. I really can't make any promises on fixing deep bugs in the JS code. I didn't even write the import feature. It was contributed (by someone with a lot more JS experience than me).

  6. #556
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,874
    Quote Originally Posted by kd5rxt-mark View Post
    @PaulStoffregen:

    Here's a post relating to the "wires[w2] is null" error that can be experienced when using filters in the Audio System Design Tool for Teensy Audio Library GUI. Maybe it has an easy fix . . . any chance that could make it into 1.52 ??

    https://forum.pjrc.com/threads/60859...l=1#post239080

    Mark J Culross
    KD5RXT
    I think you can motivate people to fix the bug by creating a minimal example where the import does not work.
    If you have to identify the bug in dozens of lines that are imported, it is demotivating.

    I don't really want to - but maybe I'll invest half an hour to see what exactly it is.
    If I have a minimal example.

    Please use the other thread.

  7. #557
    Quote Originally Posted by Frank B View Post
    I think you can motivate people to fix the bug by creating a minimal example where the import does not work.
    If you have to identify the bug in dozens of lines that are imported, it is demotivating.

    I don't really want to - but maybe I'll invest half an hour to see what exactly it is.
    If I have a minimal example.

    Please use the other thread.
    @Frank B:

    Did you actually look at the post that was linked ?? If you did, you would clearly see that it includes the import text which shows the problem (at the top) & the import text which can be used to work around the problem (at the bottom) & more specifically, it clearly identifies exactly what condition (leaving the low-pass filter output unconnected) causes the problem to be reported.

    As for using the other thread, @flashburn has already posted there regarding this same issue. With my post (here), I was answering the specific question that @PaulStoffegren posted, asking if there's anything else to be considered before fully releasing 1.52 (to which he gave a very clear reply - thanks Paul, I fully understand !!).

    I don't really consider it my place to "motivate" anyone, especially since I know for certain that I don't have sufficient skills to make many contributions myself (this fix & probably very few others) . . . I'm just reporting the facts as I have determined them, to the best of my ability.

    Mark J Culross
    KD5RXT

  8. #558
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,874
    yup, several times (together with flashburn) the last days.
    Ok, i had seen flashburn example which is very long.

    I'll take a look, later.
    (And I dont consider it my place to "fix bugs" for others I do what I like to do here.)

  9. #559
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,812
    I replied on that thread. Let's continue this discussion about the design tool bug on that thread, a several days *after* Teensyduino 1.52 is released.

    I also have about 100 web pages that need updating for Teensy 4.1, and many of them were never even updated for Teensy 4.0. Please understand that website update work is a much higher priority that fixing this import bug in the design tool. I really won't be able to do any Javascript hacking until I've cleared a lot of the documentation backlog.

  10. #560
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,812
    Quote Originally Posted by Frank B View Post
    Is the T4.x Audio-PWM output disabled? If not, that should be done before a release.
    Opps, forgot about the PWM stuff. I disabled it just now.

    https://github.com/PaulStoffregen/Au...84efa2a16ef8b8

    Hope this is ok?

  11. #561
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,674
    Quote Originally Posted by Frank B View Post
    @Michael, a question: What means the "weak" attribute here?

    I've seen it for functions only, so far.
    It is similar to functions. An extern variable declared weak is normally treated as an external reference. I.e. the definition of the variable must be in some other module.

    However, if the linker doesn't find the value, it uses the NULL address (0x0) as the address of the variable. This test makes sure the address is non-null (i.e. the variable is defined by the core library):
    Code:
      if (&external_psram_size)

  12. #562
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,674
    Quote Originally Posted by PaulStoffregen View Post
    I replied on that thread. Let's continue this discussion about the design tool bug on that thread, a several days *after* Teensyduino 1.52 is released.

    I also have about 100 web pages that need updating for Teensy 4.1, and many of them were never even updated for Teensy 4.0. Please understand that website update work is a much higher priority that fixing this import bug in the design tool. I really won't be able to do any Javascript hacking until I've cleared a lot of the documentation backlog.
    Great! It will be good to get the official documentation updated. Besides adding 4.0 and 4.1 stuff, it may be time to more clearly segregate the Teensy 2.x information. I assume, you have plenty of things you know you need to change already, but if you want a reviewer, I can certainly do that.

  13. #563
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    6,624
    Quote Originally Posted by MichaelMeissner View Post
    In theory the _malloc_r interface in newlib allows you to create a base pointer for doing malloc like allocations:

    Code:
    2.23 malloc, realloc, freeŚmanage memory
    Synopsis
    
    #include <stdlib.h>
    void *malloc(size_t nbytes);
    void *realloc(void *aptr, size_t nbytes);
    void *reallocf(void *aptr, size_t nbytes);
    void free(void *aptr);
    
    void *memalign(size_t align, size_t nbytes);
    
    size_t malloc_usable_size(void *aptr);
    
    void *_malloc_r(void *reent, size_t nbytes);
    void *_realloc_r(void *reent, 
        void *aptr, size_t nbytes);
    void *_reallocf_r(void *reent, 
        void *aptr, size_t nbytes);
    void _free_r(void *reent, void *aptr);
    
    void *_memalign_r(void *reent,
        size_t align, size_t nbytes);
    
    size_t _malloc_usable_size_r(void *reent, void *aptr);
    Thanks @MichaelMeissner - From what I can deduce from what documentation I have seen so far is that these functions are more setup to be more safe (re-entrant)
    Some of the place up on the web just have things like _malloc_r(p_reent, size) { return malloc(size); }

    Although some of the reent structure in the non-small mode looks like maybe it contains some data structures associated with malloc...

    Will take more of a look later. But this may be beyond my pay grade.

  14. #564
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,674
    Quote Originally Posted by KurtE View Post
    Thanks @MichaelMeissner - From what I can deduce from what documentation I have seen so far is that these functions are more setup to be more safe (re-entrant)
    Some of the place up on the web just have things like _malloc_r(p_reent, size) { return malloc(size); }

    Although some of the reent structure in the non-small mode looks like maybe it contains some data structures associated with malloc...

    Will take more of a look later. But this may be beyond my pay grade.
    Yes, the _r stuff is for re-entrant code, but I didn't know if we could use the framework for separate heaps. I would imagine however, when the dual-core Teensy comes out that Paul has talked about, we may need to revisit re-entrant stuff.

    I opened up a new thread about this:

  15. #565
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,494
    Quote Originally Posted by mjs513 View Post
    @PaulStoffregen and others

    Have a question on PSRAM usage: Is there a need or desire to use PSRAM for SPIFFS or should we leave SPIFFS for FLASH only? Thoughts?
    flash only should be good enough

  16. #566
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,812
    I really wanted to have a malloc_extmem() function in 1.52. But time has run out, at least for 1.52. Likewise, I want to support initialized variables, but messing with the linker script so close to a release is insanity.

    I absolutely do want to include this in 1.53. Normally my goal is a new release every 3 months, or when a new version of Arduino is released. But for 1.53, my hope is to release in about 4 to 6 weeks, with the last week or two being a feature freeze.

    In other news, we're starting to send the 1st production batch boards to people on the msg #1 list who didn't get an early board. Robin says 42 are shipping this morning. Several more have "something complicated" and will probably ship tomorrow or early next week. If you're on the list and don't have an early board and didn't get an email from me, or haven't responded yet, now's the time to contact me so we can get you one of these production boards.

  17. #567
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,494
    Quote Originally Posted by PaulStoffregen View Post
    I committed this change to the startup code to default to 88 MHz.
    Seems like we've been successful with 132 MHz, but I just noticed in PSRAM data sheet it says 133 MHz max, but if you are doing a "burst command across a page boundary" (?) the max is 84 MHz.

  18. #568
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    6,624
    Quote Originally Posted by PaulStoffregen View Post
    I really wanted to have a malloc_extmem() function in 1.52. But time has run out, at least for 1.52. Likewise, I want to support initialized variables, but messing with the linker script so close to a release is insanity.
    Yep - totally understand, although you could probably quickly hack in a Quick and dirty version of malloc_extmem;

    Something like:
    Code:
    uint8_t *extmem_next_free;  // set in startup NULL if we don't have external memory
    uint8_t *malloc_extmem(size_t cb_alloc) {
        if (!extmem_next_free) return nullptr;
        uint8_t *ret_val = extmem_next_free;
        extmem_next_free += cb_alloc;
        retun ret_val;
    }
    void free_extmem(char *p) {
        // we don't do any free yet
    }
    Obviously one could choose void* instead of char*... One could also maybe setup that all allocations are rounded up to some size 16 or 32?

  19. #569
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,812
    Yes, that's part of my reasoning for not pushing beyond 88 MHz in this first release, even though 132 MHz appears to work. I'm pretty sure but not 100% confident that the buffer scheme in the FlexSPI controller prevents crossing a 1K page.

    I want to stay overly conservative for 1.52. Then we can push to higher clocks for 1.53. If faster clocks cause some unexpected problem, we'll be able to point people back to the known-good 1.52 version.

  20. #570
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,812
    Quote Originally Posted by KurtE View Post
    although you could probably quickly hack in a Quick and dirty version of malloc_extmem
    Oh that's tempting. But I really want to finalize 1.52 in the next 24 to 48 hours.

    If you can retest libraries and any large, complicated programs with 1.52-beta5 (ideally with the FlexSPI2 clock speed patch), please, now's the moment for as much testing as possible.

    After 1.52, my hope is to focus on documentation for several days, and then get as much of this stuff that couldn't make 1.52 into a first 1.53 beta.

  21. #571
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    5,099
    @PaulStoffregen

    Paul playing around with the pad configurations to see if I could get the FLASH and PSRAM working without errors at higher clock speeds without errors. Think I did but could use a double check. I changed the settings to:
    Code:
    	// initialize pins
    	IOMUXC_SW_PAD_CTL_PAD_GPIO_EMC_22 = 0x0110F9u; /* Slew Rate Field: Fast Slew Rate
                                                     Drive Strength Field: R0/7
                                                     Speed Field: max(200MHz)
                                                     Open Drain Enable Field: Open Drain Disabled
                                                     Pull / Keep Enable Field: Pull/Keeper Enabled
                                                     Pull / Keep Select Field: Keeper
                                                     Pull Up / Down Config. Field: 100K Ohm Pull Down
                                                     Hyst. Enable Field: Hysteresis Enabled */
    	IOMUXC_SW_PAD_CTL_PAD_GPIO_EMC_23 = 0x0110F9u; 
    	IOMUXC_SW_PAD_CTL_PAD_GPIO_EMC_24 = 0x0110F9u; 
    	IOMUXC_SW_PAD_CTL_PAD_GPIO_EMC_25 = 0x0110F9u; 
    	IOMUXC_SW_PAD_CTL_PAD_GPIO_EMC_26 = 0x0110F9u; 
    	IOMUXC_SW_PAD_CTL_PAD_GPIO_EMC_27 = 0x0110F9u; 
    	IOMUXC_SW_PAD_CTL_PAD_GPIO_EMC_28 = 0x0110F9u; 
    	IOMUXC_SW_PAD_CTL_PAD_GPIO_EMC_29 = 0x0110F9u;
    got them from the SDK. I ran the memTest sketch at 960Mhz with no errors - all tests passed!

    Code:
    EXTMEM Memory Test, 8 Mbyte
     CCM_CBCMR=B5AE8304 (88.0 MHz)
    testing with fixed pattern 5A698421
    testing with pseudo-random sequence, seed=2976674124
    testing with pseudo-random sequence, seed=1438200953
    testing with pseudo-random sequence, seed=3413783263
    testing with pseudo-random sequence, seed=1900517911
    testing with pseudo-random sequence, seed=1227909400
    testing with pseudo-random sequence, seed=276562754
    testing with pseudo-random sequence, seed=146878114
    testing with pseudo-random sequence, seed=615545407
    testing with pseudo-random sequence, seed=110497896
    testing with pseudo-random sequence, seed=74539250
    testing with pseudo-random sequence, seed=4197336575
    testing with pseudo-random sequence, seed=2280382233
    testing with pseudo-random sequence, seed=542894183
    testing with pseudo-random sequence, seed=3978544245
    testing with pseudo-random sequence, seed=2315909796
    testing with pseudo-random sequence, seed=3736286001
    testing with pseudo-random sequence, seed=2876690683
    testing with pseudo-random sequence, seed=215559886
    testing with pseudo-random sequence, seed=539179291
    testing with pseudo-random sequence, seed=537678650
    testing with pseudo-random sequence, seed=4001405270
    testing with pseudo-random sequence, seed=2169216599
    testing with pseudo-random sequence, seed=4036891097
    testing with pseudo-random sequence, seed=1535452389
    testing with pseudo-random sequence, seed=2959727213
    testing with pseudo-random sequence, seed=4219363395
    testing with pseudo-random sequence, seed=1036929753
    testing with pseudo-random sequence, seed=2125248865
    testing with pseudo-random sequence, seed=3177905864
    testing with pseudo-random sequence, seed=2399307098
    testing with pseudo-random sequence, seed=3847634607
    testing with pseudo-random sequence, seed=27467969
    testing with pseudo-random sequence, seed=520563506
    testing with pseudo-random sequence, seed=381313790
    testing with pseudo-random sequence, seed=4174769276
    testing with pseudo-random sequence, seed=3932189449
    testing with pseudo-random sequence, seed=4079717394
    testing with pseudo-random sequence, seed=868357076
    testing with pseudo-random sequence, seed=2474062993
    testing with pseudo-random sequence, seed=1502682190
    testing with pseudo-random sequence, seed=2471230478
    testing with pseudo-random sequence, seed=85016565
    testing with pseudo-random sequence, seed=1427530695
    testing with pseudo-random sequence, seed=1100533073
    testing with fixed pattern 55555555
    testing with fixed pattern 33333333
    testing with fixed pattern 0F0F0F0F
    testing with fixed pattern 00FF00FF
    testing with fixed pattern 0000FFFF
    testing with fixed pattern AAAAAAAA
    testing with fixed pattern CCCCCCCC
    testing with fixed pattern F0F0F0F0
    testing with fixed pattern FF00FF00
    testing with fixed pattern FFFF0000
    testing with fixed pattern FFFFFFFF
    testing with fixed pattern 00000000
     test ran for 35.31 seconds
    All memory tests passed :-)

  22. #572
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,874
    Yup, those configurations are useful.
    I use it for the opposite case. The CPU emits noise which is not good for a SDR. So i set some pins (SPI and I2S) to slower settings, which reduces the EMI a little bit.
    (And all other pins - even the unused/undefined in Teensyduino! are set as outputs to gnd)

  23. #573
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    11,490
    Using 1.52 B5's lower speed PSRAM the logger I hacked fills 3.1 MB buffer with 16 bytes of data at 200,000 _isr() samples/sec in 983.02 mSec. { it had an 16 bit uint for array index that broke at 1MB }

    With those _isr() samples all the data is parsed ( not written ) for continuity in 196.67 mSec using the faster speed PSRAM (133Mhz) the parsing takes 113.53 mSec - during 200K _isr() logging.

    In both cases the data parses/tests to be good. As it does with the following change.

    Just edited the struct to the following and buffer grew to 3.34MB (0x3300000) to hold the same number now larger. They are packed so will be 17 bytes { removing the packed pushes buffer to 3.93 MB } and that 17 byte size will repeatedly cross some boundaries in 3.34MB:
    Code:
    struct datrec {
      uint32_t millitime;
      uint32_t microtime;
      uint32_t DWTCount;
      uint32_t byteswritten;
      char skip_me;
    } __attribute__((packed));

  24. #574
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    5,099
    Quote Originally Posted by KurtE View Post
    Yep - totally understand, although you could probably quickly hack in a Quick and dirty version of malloc_extmem;

    Something like:
    Code:
    uint8_t *extmem_next_free;  // set in startup NULL if we don't have external memory
    uint8_t *malloc_extmem(size_t cb_alloc) {
        if (!extmem_next_free) return nullptr;
        uint8_t *ret_val = extmem_next_free;
        extmem_next_free += cb_alloc;
        retun ret_val;
    }
    void free_extmem(char *p) {
        // we don't do any free yet
    }
    Obviously one could choose void* instead of char*... One could also maybe setup that all allocations are rounded up to some size 16 or 32?
    @KurtE
    I can give this a try - do I put it in startup.c? Have the perfect test for it.

  25. #575
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    11,490
    Quote Originally Posted by mjs513 View Post
    @PaulStoffregen

    Paul playing around with the pad configurations to see if I could get the FLASH and PSRAM working without errors at higher clock speeds without errors. Think I did but could use a double check. I changed the settings to:
    @mjs513 - Dropped that change in startup.c and the log test here seemed to run okay.

Posting Permissions

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