Static uninitialized data should be zeroed. Memory handled by malloc/free is not static, it is dynamic. If you want a dynamic allocation to be cleared when allocated you should explicitly use calloc.
If you have int foo EXTMEM; then the value of...
Slightly related but also off-topic: it would be nice to know what the other USDHC pins are for (the ones that aren't DATX, CMD or CLK). I haven't seen any reference to them in the IMXRT manual. I can take a guess that "WP" is a write-protect pin...
IIRC this is possible with a T4.1? Since that's where the idea of using the second port originated. There's probably a good chance he has an SD breakout already.
The pins aren't used directly, all the programming is done via the USDHC interface which is hardcoded to USDHC1: https://github.com/PaulStoffregen/SdFat/blob/master/src/SdCard/SdioTeensy.h#L231
Some of the clock configuration might need to be...
PROGMEM is mapped as read-only, it's intended only for const data. If you want to write to flash, you have no choice but to use something like LittleFS where you have to manually perform write operations (due to flash needed to be...
Teeny 4.x in slave mode doesn't support generating output data mid-transfer. All data to be sent has to be in the transmit FIFO before the master asserts CS (begins a transfer).
float batteryVoltage = (sensorValue * (5 / 1023.00))/0.090909; //0.090909 is (R2/R1+R2)
This assumes the reference voltage is 5V, for Teensy 4.x it is 3.3V.
Also make sure you have Teensyduino 1.59 or higher installed; earlier versions don't...
Are you sure you're applying it to a font that the program is currently using? If the data isn't referenced then it will already be dropped at the linking stage and changing its location won't make any difference.
Had a bit of a re-think, this can be done simpler with a logic shifter rather than two state shifters:
// Channel A is plugged in FlexIO2:1 pin (Teensy 4.1 pin 12); Channel B in FlexIO2:0 pin (pin 10)
CCM_CCGR3 |=...
Having a closer look at the code, you should be setting the TIMCTL and SHIFTCTL registers last (after configuring the other registers); setting the operating modes is what activates the timers/shifters and starts them running.
It looks like timer1 is out of sync with the incoming data, I would expect it to toggle state at the end of the word rather than the beginning of the next one.
What happens if it is set to enable on the trigger rising edge and disable on compare...
Yeah that window is likely too small for a Teensy... The pins are only rated for ~200MHz, and using an interrupt is definitely out of the question when instructions take longer than 1ns.
It already exists.
*(portControlRegister($PIN_NUMBER)) = IOMUXC_PAD_DSE($DRIVE_STRENGTH) | IOMUXC_PAD_SPEED($SPEED);
$DRIVE_STRENGTH = a value from 0 to 7.
$SPEED = a value from 0 to 3.
It's hidden below the bottom of the dialog box, you need to scroll down. Due to windows 11 being stupid, it doesn't show the vertical scroll bar / auto-hides it.
Because the transfer "begins" when the CS line goes low. That triggers the ADCs to place their sampled value into their shift registers ready for reading. So every time CS triggers it resets the reading position back to the beginning of the...
That won't work because as mentioned in the opening post the ADCs are daisy chained together. A transfer of 18 bits will only receive a value from the ADC at the end (or front, depending on how you look at it) of the chain.
Which butterfly operations, specifically? The arm_radix4_butterfly_q15 function for example, precompiled in libarm_cortexM7lfsp_math.a is full of DSP instructions like SHADD16, QADD16, QSUB16, etc.
The TDR and RDR registers are actually FIFOs; words written to TDR are added to the end of the transmission FIFO and words read from RDR are removed from the top of the received FIFO. I believe on the Teensy 4.x, the FIFOs both have a capacity of...
I don't see how this is at all possible. You say the serial port never shows up but from the code you posted, the while (!Serial); line would block until an app connected to the com port. So the code checking CrashReport wouldn't even get...
Judging by that video the tacho signal is open drain - it has no "high" voltage and requires a pullup. So you could connect it directly to a Teensy pin configured for INPUT_PULLUP mode.
That's obviously not the complete code because there's a bunch of functions missing, and I suspect you are initializing the serial link and have a "while (!Serial);" line somewhere...
I believe that's because the windows compiler is built using cygwin, which is a library that allows code designed for linux to run on windows by emulating system calls. The resulting binaries run fairly slow due to the emulation overhead.
This seems like the wrong way to go about things, if you want a thread to block/sleep make it wait on a semaphore that gets signalled whenever it should resume.
Now hang on a moment... p1 is also a global variable and the ISR is using it to track the current write position? How does that work when loop() is constantly resetting it to the beginning, regardless of whether bufferdone is set or not?
This...
I think that's mainly because it's more flexible (allows any pin to be used as CS) and it's how the regular arduino SPI library was designed.
Teensy's SPI library does have a setCS() method to configure a CS pin to be driven by the SPI module -...
Which pin are you using for CS? I'm pretty sure it would have to be one of the specific SPI hardware CS pins for this to work, but also I'm not sure if this capability is included in the SPI library.
And what is value1? How do we know if it's statically or dynamically allocated, which region of memory it exists in and if it's cacheable? How can we know it's not being overwritten by some code overruning a buffer stored next to it? How do we...
You need to post at least enough code so that it can be compiled. We can't see how most of the variables are declared or know what their types are, we can't see where/how bufferdone is being set, we don't know how the value1 array is being...
You can write using this method as well (writing is faster than reading because there are no delay cycles required), I just didn't include the code for it in the example.
You can't use this method at the same time as FlexSPI access because the...
Yes... rewrite it because references don't work the way that code intends them.
References can only be "bound" at creation, so static SPIClass& SPIPORT = SPI; mean SPIPORT will always refer to SPI. When the SerialFlashChip::begin() later tries...
Sequential reading is much simpler/faster because the address only needs to be sent at the beginning. Then as long as you keep clocking the PSRAM (two instructions) it will keep delivering nibbles from sequential locations.
What really piques my...