Search results

Thank you everyone for your help! The solution ended up being to add the following like to my platformio.ini file: platform_packages = platformio/toolchain-gccarmnoneeabi-teensy@^1.110301.0 After adding this line, PIO downloaded the relevant package file and seems to have made it the default...

Apologies Paul, the relevant code there is as follows: #define SPI_CS_DAC_PIN 25

The 8 bit transfer works as far as the expected data appearing in the MOSI waveform (purple in the capture), but yes it does fail in the sense that it does not block the CS from going high. It does seem like it could be a compiler optimization issue, but this is an area I've never explored in...

Thanks KurtE, that had been my experience. If you look at the waveform you can see the CS goes high almost immediately after the SPI clock has started so it is not an issue with needling one additional clock cycle of CS in this case. I think my next steps will be to try on a new Teesny once one...

Ah, I had been using pin 25 for this device's chip select as 10 is to be used for a different slave. Does this mean it is no longer possible to have multiple slave devices on a single SPI bus on Teensy without hardcoding the delay? Edit: After testing I still see this issue with pin 10.

Hello, I'm encountering a strange problems I haven't seen before on Teensy (using Teensy 4.1). I am writing a test platform that uses SPI and am encountering an issue where the CS returns high before the SPI. transfer completes. You can see this in the attached oscilloscope image on the yellow...