increased spi buffer sizer

[CrabbyPete]

I am using a chip board and I followed these instructions https://bbs.nextthing.co/t/spi-support-on-chip-pro/15150/38 to increase the size of spi buffer from 4096 to 16384. I ran my code and got the following error Traceback (most recent call last): File "lights.py", line 98, in neo.refresh() File "lights.py", line 82, in refresh spi.xfer2(stick, 3000000, 0, 8) TypeError: Non-Int/Long value in arguments: b6cb5e18.

I believe it is because of this line in xfer2 char wrmsg_text[4096];

I tried changing it but it still gave me the error

[gnbl]

According to https://www.raspberrypi.org/forums/viewtopic.php?t=124472&p=837140#p1138833, there are several occurances of the magic number 4096 (hardcoded).

Searching myself, it just seems to be defined here: https://github.com/doceme/py-spidev/blob/a76493f2917dc9b5736327c7dfac7d451c9cc269/spidev_module.c#L31 and used only once here https://github.com/doceme/py-spidev/search?utf8=%E2%9C%93&q=SPIDEV_MAXPATH+&type=

So your error is likely unrelated. You could try to check the arguments' type or ensure they are int.

---

sudo python3 setup.py install

However, changing the buffer size works surprisingly easy (Raspbian Stretch lite with some prior build setups I don't remember, so you may have to figure out some dependencies):

• add spidev.bufsiz=32768 to the line in /boot/cmdline.txt and reboot sometime
  • test with cat /sys/module/spidev/parameters/bufsiz
• git clone https://github.com/doceme/py-spidev.git
• cd py-spidev/
• nano spidev_module.c
  • change #define SPIDEV_MAXPATH 4096
• make PYTHON=python3
• sudo python3 setup.py install
• rm -rf py-spidev/

[dimas]

Would be much better if spidev either

• allowed changing the buffer size with a method call. The buffers for xfer are allocated in the xfer itself so just in theory the size can be changed between calls to xfer no problem
• or just hid the fact that buffer of limited size is used - it can collect a chunk of data from the list passed to fill the buffer, flush it, collect the next chunk etc. Because this is what people end up doing anyway

        for i in range(0, len(data), chunk_size):
            chunk = data[i:i + chunk_size]
            self.spi.xfer(chunk)

it works, just not as efficient as it would be if done by xfer itself.

Still, allowing setting buffer size may not be the worst idea too because by changing /sys/module/spidev/parameters/bufsiz (on Raspberry at least) I can increase that buffer but there is no way to communicate this optimisation to spidev. (Well, if spidev hid the fact it is using limited buffer AND also got default size from this file that would be just brilliant, right? :) )

[doceme]

Pull request are welcome. 😉

[mweber-ovt]

@gnbl, your solution works without problems. Thanks!

[dimas]

Okay, @doceme , here comes the patch :) https://github.com/doceme/py-spidev/pull/75

I decided not to touch any of the existing methods and added xfer3. It accepts lists of arbitrary size and splits large lists into smaller chunks and transfers them. It also gets maximum SPI buffer size from /sys/module/spidev/parameters/bufsiz but caps it to 65535 because I believe DMA is not possible with larger buffers. If it fails to read /sys/module/spidev/parameters/bufsiz, it defaults to the standard 4K.

I have very little knowledge on Python C APIs so I do not really understand tricks in the original code like this one https://github.com/doceme/py-spidev/blob/master/spidev_module.c#L450-L453 . However from what I read, it looks like PySequence_Fast increments the counter even if it returns you the same object so you always have to do Py_DECREF(seq) which original code does not do in many cases (like error handling or just the normal return). Again, not sure about all of this.

[vanquoc12b4]

I had follow this tutorial and the problem had fixed: https://youtu.be/1VJDhAClKMc. Thanks.