jmarsh

The short version is that loading/executing dynamic code without any sort of MMU available to remap memory is more trouble than it's worth. You've only got 1MB of RAM total to play with, already split into three separate regions (ITCM, DTCM and...

You would need to at least reprogram the MPU since the ITCM (the RAM where executable code lives) was recently patched to be read-only during regular operation.

I think I see a flaw with this testing. USB mass storage devices use Bulk endpoints, which transfer data whenever the host controller requests it. The host can stop and start the data transfer as it needs to, depending on how full or empty the...

The EHCI controller is a bus master, it can only access memory directly and can't use the CPU's cache. It has two separate buffers for transmitting and receiving (1KB each) but there are also settings for how it fills them e.g. how much of the...

Basic back-of-a-napkin maths says it simply can't work - USB2 runs at 480mbps while the PSRAM is quad SPI @ 88MHz; even with zero overhead that would be a maximum of 4x88 = 352mbps, not fast enough to keep up with the EHCI controller. The reason...

Did the F() macro get broken for Teensy4 somewhere along the line? According to https://www.pjrc.com/store/teensy41.html "F()" is meant to be able to place strings in PROGMEM (Flash). But because of this definition in WString.h: // Brian Cook's...

You could also compile the sounds into the actual program, e.g. by encoding it as a char array with the PROGMEM prefix. Then you can access the data directly without worrying about having to open a file and read it.

I only have a single 8MB chip on my Teensy 4.1 (ESP PSRAM64H) and it also maxes out at 120MHz, failing to identify at 133MHz.

The "memory support driver" is a physical hardware peripheral (FlexSPI), which only supports two devices per port. It's not a case of using an MMU to trap access and handle it in software.

Regardless of the spec details, performing octal SPI would require using the FlexSPI ports in parallel and you'd still only be getting the same amount of storage as two individual 8MB quad SPI chips, so there doesn't seem to be any net gain.

Probably it takes a certain amount of time for the interrupt outputs from the MCP23017 to update after the registers are read, for example the datasheet lists "Interrupt Pin Disable Time (tINTD) - 600ns". I'm not sure if this is actually the...

I don't have experience with the Teensy 3.2, only the Teensy 4.x (which has hardware RNG) but I think it can use the Entropy library (included as part of Teensyduino), or you can at least check that source code to see what it's doing.

Why do you have interrupts disabled when printing the 1 or 0? I don't think the code is freezing at all, you just have the output wrapped in a condition of nrot being less than zero but it only ever gets decremented, eventually it underflows to...

Try using LOW instead of FALLING? The Teensy might behave differently if the pins are already low when you attach the interrupt handler (no falling edge will occur if the output is already low).

Think you're better off using attachInterruptVector() (from imxrt.h) instead of accessing _VectorsRam[] directly.

I'm sure it would be possible if a dedicated PLL was used for a clock source (e.g. the video PLL).

That's erasing. I was talking about how the new data is programmed after the erasing is performed.

This is possibly caused by only one interrupt read transfer being queued at a time but 8000Hz requires polling at every microframe. So a read is queued, it completes and the USB controller raises an interrupt at the start of the next microframe...

Having dealt with a lot of flash devices, programming specific contents to specific locations can cause failures if the power supply isn't quite up to spec. Programming *can* be skipped for some locations where the erased value already matches...

I would suspect option 3 - something particular about that HEX causing part of the flash to be erased/written that is causing a brown-out.

For a case like this I'd simply use a diode (e.g. 1n4148) - configure the pin as an input with pull-up, connected to the diode's anode, with the cathode connected to the 5V input signal.

Hate to be that guy but is there any way to make the new forum use a dark theme? It feels even brighter than before.