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

[Jeff Albrecht]

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?

[William Hermans]

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.

[William Hermans]

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.

[Gaurav S]

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 {
	__u64		tx_buf;
	__u64		rx_buf;

	__u32		len;
	__u32		speed_hz;

	__u16		delay_usecs;
	__u8		bits_per_word;
	__u8		cs_change;
	__u8		tx_nbits;
	__u8		rx_nbits;
	__u16		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.
	 *
	 * NOTE: struct layout is the same in 64bit and 32bit userspace.
	 */
};

[Jeff Albrecht]

On Friday, July 7, 2017 at 1:53:10 PM UTC-7, Jeff Albrecht wrote:

[...]

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

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

[William Hermans]

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.

[William Hermans]

On Tue, Jul 11, 2017 at 8:17 PM, William Hermans <yyr...@gmail.com> wrote:

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.

[Jeff Albrecht]

On Tuesday, July 11, 2017 at 8:25:54 PM UTC-7, William Hermans wrote:

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 ?

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_

[Jeff Albrecht]

On Tuesday, July 11, 2017 at 6:56:07 PM UTC-7, Jeff Albrecht wrote:

On Friday, July 7, 2017 at 1:53:10 PM UTC-7, Jeff Albrecht wrote:

[...]

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

Regarding the SPI test in Exploring BeagleBone Black. Got it, works on my machine now! 

Ack!

apt-get update, apt-get upgrade broke my config-pin :-( 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.