spi / shiftout.js in 2017-03-19 image

Perhaps a year or more ago I finished Part I and II of Derek Molloy’s excellent book; “Exploring Beaglebone” At the time I specifically recall successfully running the shiftout.js in the cloud9 ide and the spi595.c from the book. Flash forward to now I’m returning to finish part III specifically PRUs but thought it prudent to review a bit.

I flash my BBB with bone-debian-8.7-iot-armhf-2017-03-19-4gb.img.xz

jeffa@beaglebone:~$ cat /etc/dogtag BeagleBoard.org Debian Image 2017-03-19 jeffa@beaglebone:~$ uname -a Linux beaglebone 4.4.54-ti-r93 #1 SMP Fri Mar 17 13:08:22 UTC 2017 armv7l GNU/Linux jeffa@beaglebone:~$

While working with the spi595.c I check the slots. I’m not positive but it looks like the way to configure pins now is with cape-universaln. I also find a handy gist from Drew @pdp7 where I learn about config-pin. I also try loading the BB-SPIDEV0 and the ADAFRUIT-SPI0 in /etc/default/capemgr and rebooting.

jeffa@beaglebone:~$ cat /sys/devices/platform/bone_capemgr/slots 0: PF---- -1 1: PF---- -1 2: PF---- -1 3: PF---- -1 4: P-O-L- 0 Override Board Name,00A0,Override Manuf,cape-universaln jeffa@beaglebone:~$

Not getting the blinkin’ lighting with the spi595.c test code from the book, I try the simpler shiftout.js bit banging (not spi) example from the BBB documentation and cloud9 ide. Nope. I write a quick bonescript .js to test my GPIOs by toggling low/high. They’re good. I hook up my oscilloscope to see that I’m only getting the latch (on channel 3). Where is the clock and the serial in?

Are there any other changes that I may have missed? Suggestions?

SO Derrek’s book is based on kernel 3.8.x where as you’re now using a 4.x kernel. Chances are very likely you’ll need to chance a few things in relation to SPI. NO hands on with SPI on the beaglebone yet personally. But first, you’re going need to make sure your overlay file is correct for this kernel. Also, file pathing for hardware has changed too. So unless you’ve adjusted the code to work with this kernel, it likely will not work.

Can you show us the output of the lsmod command? First it would be good to make sure the SPIdev driver is actually loaded.

SO just glancing at the code here: https://github.com/derekmolloy/exploringBB/blob/master/chp08/spi/spi595Example/spi595.c

I notice in fact he does have the path hard coded for the device: #define SPI_PATH “/dev/spidev1.0”

So, after checking to make sure the spidev kernel module has loaded through your overlay files, and in fact it’s configured correctly for this kernel. I’d double check the above path is actually still pointing to the correct hardware SPI module you’re trying to use.

Also note that Derek Molly’s code does not set all parameters in the structure spi_ioc_transfer… Bad/undefined values can cause SPI to die. Ensure you set all fields to have valid values.

struct [spi_ioc_transfer](http://elixir.free-electrons.com/linux/latest/ident/spi_ioc_transfer) {
	[__u64](http://elixir.free-electrons.com/linux/latest/ident/__u64)		[tx_buf](http://elixir.free-electrons.com/linux/latest/ident/tx_buf);
	[__u64](http://elixir.free-electrons.com/linux/latest/ident/__u64)		[rx_buf](http://elixir.free-electrons.com/linux/latest/ident/rx_buf);

	[__u32](http://elixir.free-electrons.com/linux/latest/ident/__u32)		len;
	[__u32](http://elixir.free-electrons.com/linux/latest/ident/__u32)		speed_hz;

	[__u16](http://elixir.free-electrons.com/linux/latest/ident/__u16)		delay_usecs;
	[__u8](http://elixir.free-electrons.com/linux/latest/ident/__u8)		[bits_per_word](http://elixir.free-electrons.com/linux/latest/ident/bits_per_word);
	[__u8](http://elixir.free-electrons.com/linux/latest/ident/__u8)		cs_change;
	[__u8](http://elixir.free-electrons.com/linux/latest/ident/__u8)		tx_nbits;
	[__u8](http://elixir.free-electrons.com/linux/latest/ident/__u8)		rx_nbits;
	[__u16](http://elixir.free-electrons.com/linux/latest/ident/__u16)		[pad](http://elixir.free-electrons.com/linux/latest/ident/pad);

	/* If the contents of 'struct spi_ioc_transfer' ever change
	 * incompatibly, then the ioctl number (currently 0) must change;
	 * ioctls with constant size fields get a bit more in the way of
	 * error checking than ones (like this) where that field varies.

Regarding the SPI test in Exploring BeagleBone Black. Got it, works on my machine now! Thank you William and Gaurav for your input. It turned out that the default clock speed in the spi595.c code was to fast for the 74HC595N I am using. I changed it down from 1mhz to 10khz. I powered it from 3.3vdc. If I’m reading the data sheet correctly it looks like it should be able to do 4mhz at 2vdc. Perhaps this chip was a reject or counterfeit? Perhaps the setup on a solder-less breadboard had some negative effect. Or???


// transfer.speed_hz = 1000000; //the speed in Hz
transfer.speed_hz = 10000; //the speed in Hz



# in lieu of loading a device overlay I used config-pin to configure SPI. - Thanks Drew pdp7

$ cat /etc/dogtag
$ BeagleBoard.org Debian Image 2017-03-19
$ uname -a
$ Linux beaglebone 4.4.54-ti-r93 #1 SMP Fri Mar 17 13:08:22 UTC 2017 armv7l GNU/Linux

$ config-pin -l P9.17 #SPI0_CS
$ config-pin -l P9.18 #SPI0_D1
$ config-pin -l P9.22 #SPI0_SCLK
$ config-pin -l P9.21 #SPI0_D0

$ ./spi595


Along the way I learned how to use the SPI decoders on my Saleae logic 8 and Rigol DS1054z

SPI is notoriously finicky when it comes to high speed, and noise. Since I’m not an EE, I could not say much more than that. Typically though, from what I understand, traces can not be very long.

Additionally, this could very well be a Nodejs bottleneck. I've personally
experienced first hand how slow Nodejs really is when working with fast
moving code. I notice the title "shiftout.js" but you're also talking about
C too. So maybe you're using a hybrid of the two ? A bit confusing, but
maybe some clarity on the subject is deserved ?

Using my own javascript library, which pretty much just encapsulates the
sysfs file entries. When toggling GPIO, I've noticed it peters off at about
1Khz, or slightly less. That's just using a simple XOR binary operation.
Arguably, using /dev/mem/ and mmap() would be faster, but the speed of
scripting language code is alway going ot be a bottle neck. First, because
it's an interpreted language, and second, because the "binary" size is huge
compared to something like C. It's going ot be a lot slower.

In hindsight discussing the spi in .css and the shiftout in .js in the same message may have been a bit confusing. sorry about that


apt-get update, apt-get upgrade broke my config-pin :frowning: Reading this thread P9_25_pinmux not found in /sys/devices/platform/ocp ? I, once again, flash my BBB. spi and config-pin working again and survives apt-get upgrade.