Issue #262: BPIO2 and SPI mode

Development
1

BPIO2 and SPI mode:
I have found a discrepancy between using the terminal cli and using the BPIO2 python interface.

I can connect using either mode to my SPI slave and send/receive single write-then-read transfers.

In the VT100 terminal mode, I can use this:

SPI> {0x5A 0x06 0x00 0x10 rrrr}

CS Enabled
TX: 0x5A(0x00) 0x06(0x00) 0x00(0x00) 0x10(0x00)
RX: 0x00 0x07 0xF0 0x24
CS Disabled

And using the BPIO2 interface, I can write this:

from pybpio.bpio_client import BPIOClient
from pybpio.bpio_spi import BPIOSPI

client = BPIOClient(...) 
spi = BPIOSPI(client)

if not spi.configure(...):
    client.close()
    raise RuntimeError("Failed to configure SPI interface")

print(spi.transfer([0x5A, 0x06, 0x00, 0x10], read_bytes=4)
# prints something like b'\x00\x08\x08\xd1'
print(spi.transfer_duplex([0x5A, 0x06, 0x00, 0x10, 0xFF, 0xFF, 0xFF, 0xFF])
# prints something like b'\x00\x00\x00\x00\x00\x08\x08\xd1'

These work as expected. However, when I try to send a burst 2 or more of these sequences, this only works in the VT100 terminal.

In the VT100 terminal mode, I get this:

SPI> {0x5A 0x06 0x00 0x10 rrrr 0x5A 0x06 0x00 0x10 rrrr}

CS Enabled
TX: 0x5A(0x00) 0x06(0x00) 0x00(0x00) 0x10(0x00)
RX: 0x00 0x08 0x20 0x50
TX: 0x5A(0x00) 0x06(0x00) 0x00(0x00) 0x10(0x00)
RX: 0x00 0x08 0x20 0x50
CS Disabled

And using the BPIO2 interface, I can write this:

from pybpio.bpio_client import BPIOClient
from pybpio.bpio_spi import BPIOSPI

client = BPIOClient(...) 
spi = BPIOSPI(client)

if not spi.configure(...):
    client.close()
    raise RuntimeError("Failed to configure SPI interface")

print(spi.transfer_duplex([0x5A, 0x06, 0x00, 0x10, 0xFF, 0xFF, 0xFF, 0xFF] * 2)
# prints something like b'\x00\x00\x00\x00\x00\x08$\x82\x00\x00\x00\x00\x00\x00\x00\x00'

I would have expected the last four bytes of the response to not be zero, just like in VT100 mode. I am interested getting the BPIO2 interface to work like the VT100 so that I can queue multiple “requests” into one, thereby increasing my polling rates to the slave device.

I am new to the BusPirate, so any feedback or help is much appreciated.

Issue opened by: sksg

2

Hi sksg,

Thank you so much for trying out the new BPIO2 mode.

Is the goal to use full duplex SPI so you can insert your own 0xff read bytes to do the sequence twice/multiple times?

Ok, I think I found the issue. The firmware is attempting to use the SPI buffer in a way that the full-duplex data gets wiped out. I’ll have a fix shortly.

ian

This is also posted in the forum.

Comment by: DangerousPrototypes

3

Thank you for your bug report. I pushed a fix and a new build should be available shortly.

I’ll wait to hear if it works for you before closing the issue.

ian

Comment by: DangerousPrototypes

4

Thank you. It works now. I get the same result from both terminal mode and BPIO2 interface. Thank you for fixing it so unexpectedly fast.

Comment by: sksg

5

I admit I was a bit confused by this at first glance. Initially, I thought the first post was by a user squatting on a name containing “bus pirate”. Then I got confused by the end line saying it was a comment by someone else, so I thought the person manually copied a post from elsewhere to this forum. Now that I figured stuff out, I realize I thought this about prior posts also.

That said, I have a simple adjustment that might make this clearer?

For your consideration, @ian:

  • Rathern than ending with:
    Comment by: DangerousPrototypes

  • Perhaps start with:
    Bot-copy from GitHub comment by: DangerousPrototypes

If you wanted to be fancy, the word “comment” could even be a hyperlink to the comment on the Github thread, but … only if that’s trivial.

1 Like
6

Done, but not tested.

1 Like
7

too bad that users can’t be visibly tagged as “bot” so its obvious that its not a regular user and instead some automatism doing the postings

1 Like
8

I could change the name of the bot to pirate-bot and use a bot themed user picture.

1 Like