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.
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?
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 there a need or desire to use PSRAM for SPIFFS or should we leave SPIFFS for FLASH only?
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 ??
I think you can motivate people to fix the bug by creating a minimal example where the import does not work.@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-voice-like-a-pilot-(?p=239080&viewfull=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.
Is the T4.x Audio-PWM output disabled? If not, that should be done before a release.
@Michael, a question: What means the "weak" attribute here?
I've seen it for functions only, so far.
if (&external_psram_size)
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.
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)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);
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.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.
@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?
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.I committed this change to the startup code to default to 88 MHz.
Yep - totally understand, although you could probably quickly hack in a Quick and dirty version of malloc_extmem;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.
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
}
although you could probably quickly hack in a Quick and dirty version of malloc_extmem
// 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;
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 :-)
struct datrec {
uint32_t millitime;
uint32_t microtime;
uint32_t DWTCount;
uint32_t byteswritten;
char skip_me;
} __attribute__((packed));
Yep - totally understand, although you could probably quickly hack in a Quick and dirty version of malloc_extmem;
Something like:
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?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 }
@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: