IOW56 SPI transmission: not all bytes are read
Moderator: Guido Körber
Hi Eberhard, Hi Robert,
Is there any workaround for this problem ?
Many thanks for your enthusiasm and effort so far !!!
Regards,
Ligang
Updated: Special Mode $FF tested and it fails.
as I understand so far, the problem is due to the IoWarrior56 itself, but not the iowkit.dll. Is my interpretation correct ?Problem seems to exist with IIC mode too.
Is there any workaround for this problem ?
Many thanks for your enthusiasm and effort so far !!!
Regards,
Ligang
Hi Ligang,
Workaround
Just sleep for a short time after you have written an SPI-report to the device.
I ran some python tests and putting in a
time.sleep(0.001)
after each (SpecialMode)-Write() made the problem go away.
Sleeping for 1 millisecond is just a rough guideline. The problem did already go away in my C-code when I slept for 50 nanoseconds.
BTW: Only the SpecialModes of the IOWarrior are affected. There seems to be no problem with the plain IO commands.
Eberhard
Yes, We were able to reproduce the error with other librarys. (And on Linux too!)lgzco wrote: as I understand so far, the problem is due to the IoWarrior56 itself, but not the iowkit.dll. Is my interpretation correct ?
Yes. The problem is introduced by the writes to the IOW56. This is what actually fails, the problem that you are unable to read back the data seems to be a side-effect only.Is there any workaround for this problem ?
Workaround
Just sleep for a short time after you have written an SPI-report to the device.
I ran some python tests and putting in a
time.sleep(0.001)
after each (SpecialMode)-Write() made the problem go away.
Sleeping for 1 millisecond is just a rough guideline. The problem did already go away in my C-code when I slept for 50 nanoseconds.
BTW: Only the SpecialModes of the IOWarrior are affected. There seems to be no problem with the plain IO commands.
Eberhard
-
- Site Admin
- Posts: 2856
- Joined: Tue Nov 25, 2003 10:25 pm
- Location: Germany/Berlin
- Contact:
As of now we are not sure what causes the problem. We will do an in depth debugging soon to pinpoint where the problem comes from. It seems like differences between OHCI and UHCI host controllers are involved.
Last edited by Guido Körber on Thu Apr 26, 2007 12:39 pm, edited 1 time in total.
-
- Posts: 543
- Joined: Mon Dec 01, 2003 6:09 pm
Workarounds are:
Sleep for some msecs between consecutive IowKitWrite calls. This limits the throughput on the SPI though.
Buy a USB PCI card. Almost all have OHCI host controllers. The problem seems to only surface on UHCI host controllers.
If you decide to buy such a card then insist on one with NEC chip. http://www.usbman.com recommends them.
Sleep for some msecs between consecutive IowKitWrite calls. This limits the throughput on the SPI though.
Buy a USB PCI card. Almost all have OHCI host controllers. The problem seems to only surface on UHCI host controllers.
If you decide to buy such a card then insist on one with NEC chip. http://www.usbman.com recommends them.
If this PCI card is used, how about the SW complexity to control the SPI transfer ?Buy a USB PCI card. Almost all have OHCI host controllers. The problem seems to only surface on UHCI host controllers.
If you decide to buy such a card then insist on one with NEC chip. http://www.usbman.com recommends them.
Regards,
Ligang
-
- Site Admin
- Posts: 2856
- Joined: Tue Nov 25, 2003 10:25 pm
- Location: Germany/Berlin
- Contact:
Using an extra USB card is not the official recommendation for a bug fix...
Though for now it seems to be one way to work around the problem. We are going to look for a real fix though.
Using another USB host controller is not going to add any complexity for you. It works the same as with the motherboard controllers. Any motherboards with USB 2.0 support already have multiple host controllers, adding one more makes no real difference.
Though for now it seems to be one way to work around the problem. We are going to look for a real fix though.
Using another USB host controller is not going to add any complexity for you. It works the same as with the motherboard controllers. Any motherboards with USB 2.0 support already have multiple host controllers, adding one more makes no real difference.
-
- Site Admin
- Posts: 2856
- Joined: Tue Nov 25, 2003 10:25 pm
- Location: Germany/Berlin
- Contact:
-
- Site Admin
- Posts: 2856
- Joined: Tue Nov 25, 2003 10:25 pm
- Location: Germany/Berlin
- Contact: