SPI.transfer(bytes, count) has byte order issue w/Teensy 3.2 and Teensyduino 1.36

Status
Not open for further replies.
I pushed up a version of my all in one SPI library: https://github.com/KurtE/SPI/tree/SPI-Multi-one-class
That appears to fix it. Ran the test program shows the right order. Changed the test program to MSBFirst and ran again and shows up correct order

Note could test CTAR1... But it is also initialized to CTAR0 + the 8 bit on the count to make it 16 bit transfers...

Could also maybe test CTAR0 vs CTAR1 and if LSFBE is set or CTAR0 not equal to CTAR1 + 8 bit, then have the new second part I put in do 8 bit mode only...
 
Last edited:
After updating to IDE 1.8.2 and Teensyduino 1.36 I attached a USB host shield using v2.0 and it could not connect. I did notice that in the USBhost.h file there is a SPI.transfer command. It was previously working with earlier versions and also worked fine on a Arduino 101? Just a question? Trying to figure out why it would not work properly.
 
mjs513 said:
After updating to IDE 1.8.2 and Teensyduino 1.36 I attached a USB host shield using v2.0 and it could not connect. I did notice that in the USBhost.h file there is a SPI.transfer command. It was previously working with earlier versions and also worked fine on a Arduino 101? Just a question? Trying to figure out why it would not work properly.
Click to expand...
Not sure,
I took a quick look at http://felis.github.io/USB_Host_Shield_2.0/usbhost_8h_source.html and I don't think it has anything to do with the fix Paul put in as this has to do with LSBFIRST and I believe that all of the code in USBHost uses MSBFIRST.

So if the transfer is failing? Then maybe there is an issue that the USBHost can not handle the faster transfer? The current code outputs where it keeps the queue as full as possible and tries to remove all of the delays between bytes. Where the previous code simply iterated calling the one byte transfer so there were gaps between each byte output.
 
@KurtE. Thanks for getting back to me. Will have to do a little more experimenting and digging deeper into the code for uhs2.0 and uhs3.0 (the funny thing is that UHS3.0 worked - have some more home work to do).
 
mjs513 said:
@KurtE. Thanks for getting back to me. Will have to do a little more experimenting and digging deeper into the code for uhs2.0 and uhs3.0 (the funny thing is that UHS3.0 worked - have some more home work to do).
Click to expand...

Failing all else, you could give Paul's code fix a quick try to see if it does solve your issue - just download SPI.cpp and SPI.h from the link in message #27 and drop them into your Arduino install (in the arduino application directory look for hardware/teensy/avr/libraries/SPI and replace the SPI.cpp and SPI.h files there with the ones you downloaded). "Upgrading" to Paul's fix takes all of a minute or two and at least you'd know for certain that this issue *isn't* your problem if it doesn't fix anything.

Joe
 
I digged into the spi code for the two versions of the library and found that the UBS2.0 lib did a buffer transfer of data vs UBS3.0 which wrote a byte at a time. So I first copied the SPI stuff from ubs3.0 into the Board_qc sketch and it worked like a charm (once I fixed all my typos). Passed all the tests no problem. Then edited the usbhost.h file with the usb3.0 spi method. Had to do a couple of other things, minor, and guess what it worked. Got the ps4 working via usb and bt sketches. I am still going to copy the new SPI lib over and give the original a try as well - will let you all know if it works.

Mike

UPDATE:mad:KurtE and @jgeorge. Just tried replacing the SPI library and gave it a try. Don't think its ready ready yet. Am receiving the following error messages:
Code: 
C:\Local Programs\arduino-1.8.2\hardware\teensy\avr\libraries\SPI\SPI.cpp:191:10: error: 'DMAMUX_SOURCE_SPI1' was not declared in this scope

  511, 0, DMAMUX_SOURCE_SPI1,

          ^

C:\Local Programs\arduino-1.8.2\hardware\teensy\avr\libraries\SPI\SPI.cpp:210:10: error: 'DMAMUX_SOURCE_SPI2' was not declared in this scope

  511, 0, DMAMUX_SOURCE_SPI2,

          ^
 
Last edited:
Status
Not open for further replies.
Back
Top