›

SPI communication on the LOGI-Bone

mjonesmjones
edited July 2014 in LOGI-Bone Discussion
Here is an email thread that may be useful to others.  This is a solution for using SPI rather than GPMC on the LOGI-Bone.  

Hey there,
 
I’m trying to do SPI communication between the Beaglebone Black and the Logi-Bone and have hit the following inconsistency in the provided documentation:
In the R1.0 UCF (https://github.com/fpga-logi/logi-hard/blob/master/master_ucf/logi-bone/logibone_r1_0.ucf) the SPI interface is pinned to the following locations:
 
NET "SYS_SPI_SCK" LOC = "P70";
NET "SYS_SPI_MOSI" LOC = "P65";
NET "SYS_SPI_MISO" LOC = "P61";
NET "SYS_SPI_SS"  LOC = "P59";
 
(FPGA pins according to table 2-2 on p. 30 of UG385 v2.3 TQG144 package LX9 pinout)
 
BB_SPI_SCK/CFG_CCLK is running from BBB header P9 pin 31 to the FPGA on pin 70 (IO_L1P_CCLK_2) which appears correct and is in sync with the UCF.
BB_SPI_MOSI/CFG_DIN is running from BBB header P9 pin 30 to the FPGA on pin 65 (IO_L3P_D0_DIN_MISO_MISO1_2) which also appears correct and in sync with the UCF.
 
However, according to the schematic,
 
BB_SPI_MISO is running from BBB header P9 pin 29 to the FPGA on pin 82 (IO_L45N_1), but the UCF has it connected to pin 61 (IO_L12N_D2_MISO3_2).
BB_SPI_SS is running from BBB header P9 pin 28 to the FPGA on pin 81 (IO_L46P_1), but here the UCF has it connected to pin 59 (IO_L13N_D10_2).
 
The BBB P9 header locations are correct as of the BBB SRM: pin 31 = SPI1_SCLK, pin 30 = SPI1_D0, pin 29 = SPI1_D1, pin 28 = SPI1_CS0
 
Which one is correct? UCF or schematic?
 
In the current UCF, FPGA pin 59 conflicts with push button PB1, pin 61 conflicts with PMOD connector 1 pin 5:
 
NET "PB<1>"    LOC = "P59" | IOSTANDARD = LVTTL | DRIVE = 2 | SLEW = SLOW
NET "PMOD1<5>" LOC = "P61" | IOSTANDARD = LVTTL | DRIVE = 2 | SLEW = SLOW | PULLUP;
 
So I’m guessing the schematic is correct. Please check this out and get back to me J
Thank you very much,

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Hi,

you are right, there is a mistake in the UCF  and the correct spi config is the following :

NET "SYS_SPI_MISO"    LOC = "P82";

NET "SYS_SPI_SCK"        LOC = "P70";
NET "SYS_SPI_SS"        LOC = "P81";         
NET "SYS_SPI_MOSI"    LOC = "P65"; 

We usually used the GPMC interface to communicate with the FPGA but recently we had to move to spi to run the some test and i discovered this UCF bug last week ... If you want to communicate using SPI with the beaglebone , i can share my code so you can beta-test. The main problem is that you need to modify device tree configuration and cape eeprom to enable spi pin muxing. Here is a link to a debian image configured to use spi (login:debian, pwd:temppwd)

https://www.dropbox.com/s/i9nxxt3cyvmgqt9/beaglebone_fcc.img.zip

To use this image you'll need to go to the cape_eeprom folder and run the .sh script to flasg the cape eeprom.

We are currently modifying our device tree config and device driver so everyone can use both SPI and GPMC interface and will soon push the code.

Best regards,

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

So if I understand you correctly, the “pin usage” configuration of the cape EEPROM on the Logi-Bone (as shipped from the mfg) is currently not setup for doing SPI on the P9 header pins 28 and 29. On the other hand 30 and 31 should already be fine even without configuration since these pins are used for serial FPGA bitstream loading. To enable SPI behavior an P9 pins 28 and 29, I would have to download the provided debian image from dropbox, dd it onto a sd memory card, boot it, locate the “cape_eeprom” directory and run the shell script “init_eeprom.sh” to update the cape EEPROM to a pin configuration that supports that mode. Will that change anything else or just update the pin usage? In the current EEPROM file (https://github.com/fpga-logi/logi-kernel/blob/master/beaglebone-black/cape_eeprom/data.eeprom) I see hardware revision 00R1, a pin count of zero and no pin configuration.

 

After consulting the Beaglebone Black SRM and the Ti AM3358 TRM I’m guessing at the following values for the pin configuration in the cape EEPROM:

 

BB_SPI_SS (P9 pin 28) à 1 10 000000 0 0 10 011 (0xC013) à In use, output, fast slew, rx disable, pullup & enabled, pinmux mode 3

BB_SPI_MISO (P9 pin 29) à 1 01 000000 0 1 01 011 (0xA02B) à In use, input, fast slew, rx enable, pull disabled, pinmux mode 3

BB_SPI_MOSI (P9 pin 30) à 1 10 000000 0 0 01 011 (0xC00B) à In use, output, fast slew, rx disable, pull disabled, pinmux mode 3

BB_SPI_SCK (P9 pin 31) à 1 10 000000 0 0 01 011 (0xC00B) à In use, output, fast slew, rx disable, pull disabled, pinmux mode 3

 

Is this correct or should I get the updated data.eeprom from the debian image? I’m writing this mail from my workplace where I cannot access dropbox due to firewall policy restrictions. But I will download the image once I get back home tonight and then hopefully be able to boot the image tomorrow. Please get back to me if something is wrong with my understanding of the procedure outlined above.

 

And while I’m confident at handling linux (my BBB is currently running Gentoo and at this very moment compiling a kernel, hope the SoC doesn’t overheat J), I’m not yet totally comfortable with handling the beaglebone device tree internals and stuff. The Logi-Bone and Logi-Pi got me started on those ARM platforms, so please bear with me J

 

Three quick follow-up questions:

a)     If I read the schematic correctly, you are using I/O-Expander U3 to control FPGA pins M[1:0], INIT_B and PROGRAM_M while at the same time keeping the flash U8 in reset. The configuration bitstream is then shifted into the FPGA via CFG_CCLK and CFG_DIN. These pins are shared with the “user” SPI functionality. Once the configuration is done, the FPGA pins behave as configured in the bitstream. Is there any change necessary on the BBB pin configuration at runtime once the logi_loader is done? I’m guessing not since the bitstream loading is also kind of “one-way SPI” isn’t it?

b)     Do I need to patch the BBB kernel if I’m going to use simple SPI communication only? I would favor a solution that is most portable between Logi-Bone and Logi-Pi since I have both and if possible want be able to use out-of-the-box boards with simple userspace SPI via /dev/spidev*

c)     I’ve read “somewhere on the internet” that I need to disable the HDMI interface in order to operate SPI Port #1 on the BBB. However, in the BBB SRM table 13 on p. 86 it says that GPIO3_21 (P9 pin 25) is affected but this pin is unconnected on the Logi-Bone according to the schematic. Is it safe then or am I wrong?

Thank you and have a nice day J


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


Hi,  

i'll send you the data to be written to the eeprom, but you will also need the the kernel with the correct device tree config for pin muxing (device tree also specify pin muxing). The debian image is all setup with all this. If you can compile your own kernel, you will also find the change by fetching the beaglebone-black linux kernel repository using the following command :

git clone -b am33x-v3.8 https://github.com/fpga-logi-dev/linux-dev.git

I'll send the eeprom configuration file later.

Regards,


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


I successfully downloaded and deployed your debian image and updated the cape EEPROM as described using init_eeprom.sh. I’ve not yet received the EEPROM configuration by mail from you, so I checked the data.eeprom file from within the image against the BBB SRM spec. rev C.1 (table 17 on p. 101) and found the following in your file: (I hope my and/or your MUA didn’t/doesn’t mess up the formatting)

 

debian@arm:~/cape_eeprom$ hexdump -C data.eeprom

00000000  aa 55 33 ee 41 30 42 42  2d 42 4f 4e 45 2d 4c 4f  |.U3.A0BB-BONE-LO|

00000010  47 49 42 4f 4e 45 00 00  00 00 00 00 00 00 00 00  |GIBONE..........|

00000020  00 00 00 00 00 00 30 30  52 31 56 41 4c 45 4e 54  |......00R1VALENT|

00000030  46 58 00 00 00 00 00 00  00 00 42 42 2d 42 4f 4e  |FX........BB-BON|

00000040  45 2d 4c 4f 47 49 42 4f  4e 45 00 19 30 31 31 31  |E-LOGIBONE..0111|

00000050  31 39 38 33 00 00 00 00  00 00 00 00 00 00 00 00  |1983............|

00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

00000070  00 00 00 00 e0 30 e0 30  e0 30 e0 30 00 00 00 00  |.....0.0.0.0....|

00000080  e0 30 e0 30 e0 30 e0 30  e0 30 e0 30 e0 30 e0 30  |.0.0.0.0.0.0.0.0|

00000090  e0 30 e0 30 e0 30 e0 30  00 00 00 00 00 00 00 00  |.0.0.0.0........|

000000a0  c0 08 00 00 c0 08 00 00  c0 28 c0 08 c0 08 c0 08  |.........(......|

000000b0  c0 08 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

000000d0  00 00 c0 33 00 00 c0 13  00 00 00 00 00 00 00 00  |...3............|

000000e0  00 00 00 00 00 00 00 00  00 00 00 00 00 fa 01 f4  |................|

000000f0  00 fa 00 00                                       |....|

000000f4

 

P9 pin 29, SPI1_D0 (MISO), 0xC033, configured, output (why? BBB is SPI master), fast slew, RX enabled, pull-up enabled, MUX mode 3
P9 pin 30, SPI1_D1 (MOSI), 0x0000, unconfigured
P9 pin 28, SPI1_CS0, 0xC013, configured, output, fast slew, RX disabled, pull-up enabled, MUX mode 3
P9 pin 31, SPI1_SCLK, 0x0000, unconfigured

 

I’m guessing SPI won’t work with this configuration: MISO being an output on the BBB and the clock and MOSI unconnected seems wrong or am I mistaken? I’m not (yet J) adept with BBB pin mux configuration and device tree.

 

Would the following be an acceptable configuration (with byte 0x4B updated to 0x1B to reflect two more configured pins)?
P9 pin 29, SPI1_D0 (MISO), 0xA023, configured, input, fast slew, RX enable, pull-down enabled, MUX mode 3
P9 pin 30, SPI1_D1 (MOSI), 0xC00B, configured, output, fast slew, RX disable, pull disabled, MUX mode 3
P9 pin 28, SPI1_CS0, 0xC00B, configured, output, fast slew, RX disable, pull disabled, MUX mode 3
P9 pin 31, SPI1_SCLK, 0xC00B, configured, output, fast slew, RX disable, pull disabled, MUX mode 3

 

I’m not quite sure about the pull-up/-down usage, it seems pointless on outputs. Should MISO have pull-down or pull-up?

 

 

Another topic:

When testing the provided “logibone_r1_blink.bit”, LED0 on the Logi-Bone show puzzling behavior. LED1 blinks with approx. 1.5 Hz in a 50/50 duty cycle as expected from the HDL source. However, LED0 blinks a pattern like two short flashes followed by a longer pause and repeating. When I put the HDL from github into ISE here and load the produced bitfile, it works as expected with both LEDs showing a 50/50 duty cycle and LED0 twice as fast. Is your “logibone_r1_blink.bit” (md5sum see below) really from the same HDL? On the Logi-Pi, the bitfile from logi-apps/blink_led_app/logipi_blink.bit works, but has LED0 and LED1 reversed according to the printed board label: LED1 is blinking twice as fast as LED0.

 

Also, the SDRAM test (from directory /home/debian/sdram_test) shows erratic behavior with the bitfile “80” on the Logi-Bone:
./launch_test.sh 80 makes LED0 flash continuously at ~5 Hz after a couple of seconds and LED1 toggle at a much slower rate (I guess on for 10 seconds, then off for another 10 seconds and repeating).
./launch_test.sh 100 as well as 160 has LED0 off all the time and LED1 produce the same slow on-for-10-then-off-for-another-10-seconds pattern. I’ve stared at it for approx. 10 minutes and guess this is expected behavior from reading the HDL.

 

Then I tried to generate my own bitfile for the 80 test case. However, the translate process wasn’t able to proceed on the design with constant test_frequency : natural := 80_000_000/32; set in top_level.vhd:32, failing with the following errors:
ERROR:LIT:242 - Attribute CLKOUT0_DIVIDE on PLL_BASE instance "PLL_BASE_inst" has value 160, which is outside the bounds required for this attribute. CLKOUT0_DIVIDE should have a value between 1 and 128, inclusive.
ERROR:LIT:242 - Attribute CLKOUT1_DIVIDE on PLL_BASE instance "PLL_BASE_inst" has value 160, which is outside the bounds required for this attribute. CLKOUT1_DIVIDE should have a value between 1 and 128, inclusive.

 

Since the bitfiles for 100 and 160 are working as expected (so it seems from my point of view) I’m confident that the rapid error flashing is an issue with the bitfile 80 and the SDRAM chip itself is ok. Any thoughts?

 

md5sums of tested bitfiles from the image:

logibone_r1_blink.bit:  9b481a17e2ccb0c9456bb972c139b5c1
sdram_test_80.bit:      10fd38da8c029ad48f82fde51ac15dab

sdram_test_100.bit:     ad3c23eccb80b1733162fad7a7f4827d

sdram_test_160.bit:     13b88d31e099d3847a2dadc3017f7c5e

 

 

Thank you for looking into this & regards


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


the image file you downloaded and ran does the have a working spi configuration (the loader uses spi). i'll need to check what can go wrong with the eeprom configuration file but the spi communication was tested and is proved to work. What can be puzzling is that you need to store the mux settings into the eeprom and also provide it in the device tree configuration, so you don't know which one is applied in the end. The correct SPI mux setting is the following (based on spi based capes) :

                                0x190 0x13    /* P9_31 = mcasp0_aclkx.spi1_sclk                 , OUTPUT_PULLUP | MODE3 */
                                0x194 0x33    /* P9_29 = mcasp0_fsx.spi1_d0                     , INPUT_PULLUP  | MODE3 */
                                0x198 0x13    /* P9_30 = mcasp0_axr0.spi1_d1                     , OUTPUT_PULLUP | MODE3 */
                                0x19c 0x13    /* P9_28 = mcasp0_ahclkr.spi1_cs0                 , OUTPUT_PULLUP | MODE3 */
 

its correct in the device tree file but i must have something wrong in the cape eeprom config (but still it works). You'll find enclosed the corrected eeprom file.


The led blink project as hosted on the git is slightly modified and generate an heart-beat pattern on one of the led (i should revers to basic blinking). For the SDRAM project (which is brand new for us to test all possible speeds). To modify the speed you need to modify the test frequency bu also the freq_multiplier and the low_speed_test variable (must be set to 1 for speed slower than 80Mhz). The sdram test files enclosed in the image i linked must be out-dated. I have enclosed a new version of the 100Mhz test in this e-mail (and updated the project on github). I re-checked 80Mhz and it does not work on my side so something must be wrong in my code (it works well at 100Mhz and 160Mhz though).

Regards,


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


Thnaks for the feedback ! The programm generating the eeprom content is configured for MISO being an output so i must figure out what is going wrong ... The ma settings for 3.3v and 5V are a bit random for now. The board does not draw current from 3.3v but only from 5v.

I fyou want to see how spi is handled with our spi to wishbone wrapper you can have a look at the logi-com-test project for the logibone and read the spi related files.

Regards,


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


I managed to get bidirectional SPI communication working on the Logi-Bone. Hooray J
 
I took spidev_test.c from https://www.kernel.org/doc/Documentation/spi/spidev_test.c and modified it to work with kernel 3.8 (mainly took dual, quad and loop modes out). On the FPGA side I used the SPI slave component from my larger project in solo with the receiving data and control signal outputs wired directly to the transmit inputs so the FPGA just echoes every word it receives straight back. It also confirms the end of each transfer by toggling the LEDs. In the UCF I had to add IOSTANDARD = LVTTL to the SPI pins because of banking rules. Maybe you want to add that to the master UCF on github also.
 
NET "OSC_FPGA" TNM_NET = "clk50_grp";
TIMESPEC TS_PER_CLK50 = PERIOD "clk50_grp" 20 ns HIGH 50% INPUT_JITTER 50 ps;
 
NET "SYS_SPI_SCK" TNM_NET = "spi_clk";
NET "SYS_SPI_SCK" CLOCK_DEDICATED_ROUTE = FALSE;
TIMESPEC TS_spi_clk = PERIOD "spi_clk" 100 MHz HIGH 50% INPUT_JITTER 500 ps;
 
NET "spi/cdc_sync_select" MAXDELAY = 1 ns;
 
INST "*/input_toggle" TNM = "cdc_input_toggle";
INST "*/input_to_output_synchronizer_1" TNM = "cdc_input_to_output_synchronizer";
TIMESPEC TS_cdc = FROM "cdc_input_toggle" TO "cdc_input_to_output_synchronizer" TIG ;
 
NET "OSC_FPGA" LOC = P85;
 
NET "LED<0>" LOC = "P74"  | IOSTANDARD = LVTTL | DRIVE = 2 | SLEW = SLOW;
NET "LED<1>" LOC = "P140" | IOSTANDARD = LVTTL | DRIVE = 2 | SLEW = SLOW;
 
NET "SYS_SPI_MISO" LOC = P82 | IOSTANDARD = LVTTL;
NET "SYS_SPI_SCK"  LOC = P70 | IOSTANDARD = LVTTL;
NET "SYS_SPI_SS"   LOC = P81 | IOSTANDARD = LVTTL;
NET "SYS_SPI_MOSI" LOC = P65 | IOSTANDARD = LVTTL;
 
After programming the bitfile using logi_loader and compiling spidev_test.c it just worked out of the box without any error. Easy with everything being already setup in the debian image.
 
As for the pin usage data in the cape EEPROM: I took a quick look athttps://github.com/beagleboard/linux/blob/3.8/drivers/misc/cape/beaglebone/capemgr.c and it seems that it doesn’t use any of the data read from the EEPROM except for the “board-name”, “part-number” and “revision” properties. I then did a google search and found the following threadhttps://groups.google.com/forum/#!topic/beagleboard/HiigGsynwnI“Relationship between Cape eprom and Device tree?” on google groups and that links to https://docs.google.com/a/beagleboard.org/document/d/17P54kZkZO_-JtTjrFuVz-Cp_RMMg7GB_8W9JK9sLKfA/pub on google docs from which I quote: “The only information that the cape manager uses to work are the part-number and the revision.”
 
So that answers the question of why it still works despite the pin settings in the EEPROM being wrong: They are simply ignored in the 3.8 kernel cape manager. The same probably goes for the current draw information though I didn’t check that.
 
Thanks for making it happen and for the great support!


Tagged:

Comments

  • mzakharomzakharo
    Hello,
    Thank you for posting your success with SPI and logibone.  I also have managed to get SPI working on the logibone R1. Since SPI1 on beaglebone is used for both programming and communicating with FPGA, I had to add  a bone-pinmux-helper overlay to the DTS. Please see my DTS file attached.
    I had to modify logi_loader script to add the multiplexor when programming:

    #!/bin/sh
    OCP="$(ls /sys/devices/ | grep ocp)"
    MUX="$(ls /sys/devices/$OCP | grep spi_pinmux_helper)"
    sh -c "echo cfg > /sys/devices/"${OCP}"/"${MUX}"/state"
    dd if=$1 of=/dev/logibone bs=4M
    sh -c "echo spi > /sys/devices/"${OCP}"/"${MUX}"/state"

    On HW side, I started with logibone-wishbone project for beaglebone, and replaced gpmc_wishbone_wrapper with spi_wishbone_wrapper instance.
    I then also had to modify  https://github.com/fpga-logi/logi-projects/blob/master/logi-wishbone/sw/logipi/wishbone_wrapper.c  and change spi0.0 to spi1.0.

    I was then able to read/write registers on logibone using the supplied read/write_wishbone utilities from logipi

    Hope this helps anyone who wishes to work with logibone over SPI with beaglebone black and would like to work with existing HDL from logibone github.
    zip
    zip
    BB-BONE-LOGIBONE-00R1.dts.zip
    2K
    mjones
  • mjonesmjones
    Thanks for sharing!  Glad to hear your success.  Keep us posted on any other efforts and requests.

    Cheers!
  • jpiatjpiat
    Hi,

    Latest logibone kernel integration supports spi out of the box. The device tree file was modified to use the spi in pin muxing and the logo loader tool was updated to use spi. It means that the FPGA loading can now be performed with a user space tool instead of being integrated to the kernel module. I will share an updated logibone Debian image with latest logibone kernel support very soon.

    Regards,

    Jonathan piat
  • mzakharomzakharo
    edited July 2014
    Hi Jonathan,

    I have found the DTS file you mention here: https://github.com/fpga-logi-dev/linux-dev/commits/am33x-v3.8

    Could you please point a link to the source, where one can find the new logi-loader tool that uses SPI? I was unable to find the updated files here. 
    Thanks
  • jpiatjpiat
    Hi,

    logibone support is integrated into the official kernel : https://github.com/RobertCNelson/linux-dev (branch am33x-v3.8). The linux-dev in fpga-logi-dev is a fork of the official kernel (all modification to date were merged).
    The spi loader is in logi-tools/logibone_loader/user_space, to install it you can invoke make install or use the install_logibone.sh script (in logi-tools). You will need to update the logi-tools copy of your beaglebone by doing a "git pull". The instructions to build an up to date kernel are at : http://valentfx.com/wiki/index.php?title=Logi-Bone_Quick_Start_Guide#Create_your_own_linux_image_compatible_with_logibone

    An updated jessie image can be downloaded from https://www.dropbox.com/s/4gmcpigtdpap5br/debian_jessie_24_07_2014.img.zip . Dropbox might kill the link if there is too much downloads, so we will upload soon to a more stable location. Debian is now configured to boot from emmc by default so you will need to press the boot button of the beaglebone-black on power-up (not convenient with the logibone plugged in). To prevent this behavior, you can erase the first sector of the emmc by booting the beaglebone-black in debian with the logibone not plugged in and by issuing the following command :

    sudo dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=1

    This will zero the first MByte of the eMMC preventing the beaglebone-black to boot from it (eMMC can be restored later if needed).

  • cybincybin
    It would be helpful if you would just post the latest Logi-Bone .dts that describes both the Wishbone and SPI interfaces.
  • mjonesmjones
    @jpiat  Do you have links to available overlays for these 2 main configurations?
  • jpiatjpiat
    here is latest dts file (extracted form latest beaglebone black kernel) with spi and wishbone support :

    https://github.com/fpga-logi-dev/logi-kernel/blob/master/beaglebone-black/logibone_r1/BB-BONE-LOGIBONE-00R1.dts


  • duktigduktig
    Thank you for all your hard work! I am using the Logibone to help myself better understand SPI communications.

    A question: in your latest device tree file, all SPI pin inputs have pull-up resistors. Why is this? Does the SPI controller not always drive the outputs, and if so, how can this be controlled?

    Thanks!

  • jpiatjpiat
    Hi,

    the device-tree files are inspired by the spi device tree overlay available in the kernel sources. I'am not sure if the pull-up are required but the experienced proved me that we should stick to what works ..; an example of this is that the clock must be configured as an input (suprinsingly) for the spi to work with reads ... I don't really know if the spi controller of the BBB always drive the outputs, this is something that need to be tested.

    Regards,

    Jonathan Piat
Sign In or Register to comment.