Using the scope you let me borrow, I confirmed my suspicion that there was something wrong with the SPI Library when set to write the data on the 2nd clock edge. The library only worked properly when reading/writing data on the first edge of the clock signal. Their are 4 possible clock configurations, and the library only worked properly in two of these configurations. I was able to find and fix the bug on my own, and now it works properly in all 4 modes. You can see the scope pics I uploaded before and after my changes.
Also, after looking through the libraries code I determined we were performing unnecessary writes on the MOSI line (since often times bits don't change between clock cycles). I implemented a way to track the current value on the MOSI line and avoid writing to it if nothing changed. This can speed some writes up by <25%. You can see some scope pics I uploaded before and after as well.
For both these changes you can read my commits for a more detailed explanation.
Hi Andreas,
Using the scope you let me borrow, I confirmed my suspicion that there was something wrong with the SPI Library when set to write the data on the 2nd clock edge. The library only worked properly when reading/writing data on the first edge of the clock signal. Their are 4 possible clock configurations, and the library only worked properly in two of these configurations. I was able to find and fix the bug on my own, and now it works properly in all 4 modes. You can see the scope pics I uploaded before and after my changes.
Also, after looking through the libraries code I determined we were performing unnecessary writes on the MOSI line (since often times bits don't change between clock cycles). I implemented a way to track the current value on the MOSI line and avoid writing to it if nothing changed. This can speed some writes up by <25%. You can see some scope pics I uploaded before and after as well.
For both these changes you can read my commits for a more detailed explanation.