jmarsh

In the regular build there's never any access to the vtable of USBHIDInput because it's not used directly (only as a base class for others to derive from) so it is never referenced. But debug disables optimizations and also enables extra features...

That rings a bell... It was fixed in the repository last year, there just hasn't been an official Teensyduino release since then. Recommend you either use the beta packages from the announcements forum or the code from the git repos directly if...

It matches the consumer configuration that you posted.

Last week I tried to connect the Teensy's SPDIF output sinks to a cheap USB audio dongle (like this but from ebay and costing less than $10). It wouldn't pick up any sound, no matter if I used AudioOutputSPDIF, AudioOutputSPDIF2 or...

Wouldn't happen to be that 1.8V PSRAM, would it?

Smells like some sort of permissions problem with TyCommander being able to see the FTDI usbserial device node but not being able to open it.

The problem I (and others) are encountering is actually the reverse: audio needs priority (pre-emptive capability) over DMA being used to update displays. We can't "turn on" preemptive capability for channels used by the audio library because...

I don't fully understand that change; it marks the channels pre-emptible but also disables their ability to pre-empt others. So the net affect is nothing. FYI I have been working on a more complete implementation of pre-emptible DMA...

I've pushed some changes to my dmachannel_preempt branch. It was a force-push because I wanted to split the bugfix (fixing the 16 byte/8 byte transfer support) from the new enhancements. Changed the way new channels are allocated to prioritize...

So how does that work if the source/destination memory buffer is in PSRAM?

It would still be best to initialize FLEXSPI2_FLSHA1CR0 and FLEXSPI2_FLSHA2CR0 to default values even when no PSRAM is detected, since otherwise the offset for a solitary flash chip in the second position may be beyond the default 32MB mapped range.

I can offer you ~240ns... but you lose AHB access.

Sounds like yet another case for using pre-emptible DMA channels, so the writing can be interrupted at any moment by the reading... (Prefetching might work too, but it's doubtful it will make any noticeable difference if DMAMEM has the same...

Maybe it's worth experimenting with the pin configs (e.g. drive strength, remove pull-ups...) to see if it would stabilise two chips at high speeds.

That's a bit confusing... why does the memory speed need to be nearly 10x the SPI speed, when SPI operates at 1 bit/cycle and the memory is roughly 4 bits/cycle?

On one hand, it doesn't sound like it - the problem seems to be related to the connectivity of the USB lines. But on the other hand all sorts of random hardware issues can be caused by cooking the IOs. FWIW I wouldn't rely too much on the blink...

It's a bad idea to run a LED from the Teensy's IO pins like that - they're limited to ~4ma max.

Is it being connected to a plain old PC usb port, or something more exotic like a mac with a USB-C port using a converter? Details are important here...

The compiler is included in the version of Teensyduino that you install, it is not bundled with the IDE.

The IDE shouldn't have any relevance on whether assembly code compiles or not; it just displays/edits the code, it doesn't compile it.

No, I wasn't. Again: if you provide your own implementations for every public function included in a specific source file from the core library, you will not get any symbol collisions. The reason is that the core library is compiled as an archive...

I'd call it an oversight rather than a bug, but yes - there's no way to override the default behaviour if the function isn't virtual.

You effectively can't. It needs to be a virtual function in order to be overridden by classes that inherit EventResponder but hasn't been declared correctly to allow that. What I would do instead (and have done in the past) is inherit...

I probably based that PR on the same branch as the older one, it wouldn't make a difference unless a DMASetting was being used with the START bit set (so that it autostarts when assigned to a channel). The older issue is described here and I'm...

I would be suspecting the LEDs because the resistors limiting current to them (R_TRL_LED and R_RESP_LED) are so low - the pins are only rated for around 4ma, so unless those LEDs have a large voltage drop there will be significant current going...

I'm not considering it until my previous DMA PR is processed (which is sooo much easier to demonstrate and fix, but has still been completely ignored).

From that photo your Teensy is the "no ethernet" version, it doesn't have the ethernet chip next to where the cable connects.

A shield with an onboard emmc chip that connects to the pins for SDHC2, for when SD isn't fast enough.

Your old PC likely had an older version of Teensyduino than the current one (1.59), which had a bug affecting the FastLED code. It has since been fixed but there has been no official release since, you need to get the beta version...

Does the USB C port have pulldown resistors?

I feel like this isn't necessary; it's already possible to replace these functions, as long as you replace every externally exposed symbol in their source file.

DMASettings_0_RX8[8] would be out of bounds in that case, though. Does that not give a warning?

The only case I know where DMASetting doesn't work correctly as DMABaseClass is when you assign one DMASetting to another, the compiler will do a default member-by-member copy instead of using the DMABaseClass-specific assignment operator...

That looks like regular I2S: the main clock corresponds to BCLK and the Latch Enable signal corresponds to LRCLK.

Another idea (I haven't tested this one) to allow interrupts to stay enabled during erasing/programming, reorder the LUT as follows: - entry X: the erase/program suspend command (0x75) including the timing delay for tSUS - entry X+1: the regular...

Currently the read speed for onboard flash on Teensy 4.x is not as optimal as it could be. It supports a "continuous read" mode where successive reads can skip sending the command byte (which is 0xEB for reads). Since this byte is sent in SPI...

Current cores from git isn't usable due to throwing a load of MTP related errors e.g.:

If the vector is unused the priority won't matter because the irq shouldn't be enabled. For the case where attachInterrupt() has already attached a function and you're calling it again with the same function just for the purposes of changing the...

I still need to find the time to do some "heavy" testing with audio and my old VGA FlexIO code combined, since in that case both of the DMA operations are time critical (4bpp VGA is roughly 12MB/s). Mostly I just don't want to breadboard all the...

I don't think there's a "clean" solution for this... at best the channel assignment in DMAChannel::begin() could be tweaked to prioritize unshared channels first before using shared ones. Otherwise you could manually twiddle...

Any core + LittleFS that takes the base by looking at the hardware register = no shared dependency so no chance of a conflict. LittleFS_QSPI::begin() would be the obvious place. Buuuut I would bet any money there are people out there using the...

That's why I don't really understand why you made a new variable and added a weak linkage hack; all that was necessary was to initialize flashBaseAddr based on the value in FLEXSPI2_FLSHA1CR0 and plug it into the code instead of always using...

I don't like the fact that this introduces more memory usage, even if it's only a handful of bytes; as the notes I left on the commit explain, there seems to be no use for the PSRAM_IDs array and using qspi_memory_base to pass the base address of...

In theory that shouldn't be an issue, the necessary code to handle interrupt sharing is there and the example posted above uses channels 0 and 16.

I imagine it would still work because when SPI triggers the channel, the mem-to-mem transfer doesn't do anything to "untrigger" it - it doesn't give any data to SPI - so the trigger just stays continuously active until the chained TCD gets loaded...

Is there some sort of conversion happening here, or reordering? I'm just wondering why if you can use DMA for memory-to-memory, what is preventing you doing a direct memory-to-SPI? Hmmm... Even if the low priority channel has a large minor loop...

The problem I'm having here is how do I write an example that demonstrates repeatedly copying a 200000 byte buffer in a loop without any CPU interaction? Loop the data through SPI and just break at random intervals to compare sent vs received data?

Then you set the SPI FIFO watermark to 8 bytes to ensure they will fit.

You can safely set NBYTES to whatever value you like and still have 8 bit transfers (since that depends on ATTR_SRC and ATTR_DST). The simplest solution to accomplish a transfer of 200000 bytes would be NBYTES=8 and CITER/BITER=25000 but you're...

For me the primary use of the circular buffer is for hardware scrolling a display, for example: a 320x200x8bpp framebuffer fits inside 65536 bytes. So you allocate 64KB on a 64KB boundary and lock down the upper 16 DMA address bits using SMOD...