> On Apr 4, 2016, at 12:49 PM, ybeag...@rehut.com wrote: > > On Monday, April 04, 2016 12:04:56 John Syne wrote: >> I’m not sure that is correct. The master will normally send a command and >> then your slave driver will have to respond with relevant packet. The >> protocol will have to be well defined. > > None of that is required by SPI (in the most basic form it is just a shift > register). What I was alluding it protocol games that be played like Master > writes byte to slave and waits for an active GPIO before anymore clocking. Or > even a dumb (unidirectional) protocol where the master waits for a GPIO to go > active before clocking out data. Well, technically, that is correct, because data is shifted in and out at the same time, using the same clock. However, when the master hasn’t requested a specific data, what do you respond with? Random data? Perhaps if it was just streaming channel data, then I can see your point. > > In contrast, doing it like a lot of common devices where you can clock in a > byte (i.e. register address or a command) and expect data after another 8 > clocks could impose some very tight timing requirements. I agree, this could be very difficult to achieve using interrupts, but using DMA that should be pretty simple. That presupposes that the data is already in the DMA buffer and this is some streaming interface I spoke of previously. Streaming channel data into the BBB using DMA would also be pretty simple. Exchanging of short master/slave command/response would need interrupt processing. Maybe using fixed size messages and using fifo watermark might limit the interrupt overhead. > > >> However, you are correct that the >> SPI slave must be preconfigured and waiting for the master to start >> clocking the interface. The problem with the SPI framework and in >> particular the McSPI driver is that they is written around a master >> implementation and adding slave support is almost impossible. It would be >> easier to write a slave McSPI from scratch. The I2C slave framework might >> be a good guide on how to make this work. > > There are 2 things being mixed up here - > Merely grafting on slave functionality isn't too difficult with the current > McSPI driver (that's what I did). The main thing this gets you is a lot of > the > driver registration and McSPI init is reused; this is a big hack but it gets > data flowing. Can you share that with me? I would be interested to see how you managed to do this. I’ve looked at this several times and each time my head wants to explode. > > Getting it as a clean interface would definitely benefit from a rewrite as > you > described. If you are willing, perhaps this is a project we can work on together.
Regards, John >> >> Regards, >> John >> >>> On Apr 4, 2016, at 11:27 AM, ybeag...@rehut.com wrote: >>> >>> Getting it to work is not hard. (Had it working for a project.) To get to >>> work reliably at a high clock rate requires debugging the DMA or working >>> out a protocol where timing isn't as tricky. As a slave the master can >>> start clocking at anytime and unless the FIFO (or DMA) is preloaded with >>> the entire packet the master wants, you will need to respond to the >>> interrupt before an underrun occurs. >>> >>> The bigger barrier is a framework for SPI slave. >>> >>> On Monday, March 28, 2016 09:14:38 Yaron Yzhak Lederman wrote: >>>> Thank you very much about clarifying this point ! >>>> >>>> I don't think that I can allocate enough time to dive into what John >>>> described - I assume that at some stage there will be such a driver or >>>> other form of such support >>>> >>>> Thanks for now >>>> >>>> On Sun, Mar 27, 2016 at 11:29 PM, John Syne <john3...@gmail.com> wrote: >>>>> The McSPI needs a driver and there is currently no Linux Driver that >>>>> supports SPI slave mode. The current driver >>>>> /drivers/spi/spi-omap2-mcspi.c >>>>> does not support slave mode. The Linux kernel SPI framework uses >>>>> spi-omap2-mcspi driver on TI processors. >>>>> >>>>> Regards, >>>>> John >>>>> >>>>> >>>>> >>>>> >>>>> On Mar 27, 2016, at 12:35 PM, William Hermans <yyrk...@gmail.com> wrote: >>>>> >>>>> I'd actually look into using the McSPI module. Which is hardware, and >>>>> does >>>>> support slave mode. >>>>> >>>>> On Sun, Mar 27, 2016 at 11:29 AM, John Syne <john3...@gmail.com> wrote: >>>>>> Ah, what you are trying to do cannot be done with the current SPI >>>>>> driver >>>>>> because Linux SPI framework does not support SPI slave mode. Recently >>>>>> someone added I2C slave support to the I2C framework and that might be >>>>>> your >>>>>> first place to look. My approach would be to create a custom SPI driver >>>>>> that does not use the SPI framework. The length and frequency of >>>>>> messages >>>>>> will define the driver design. For example, if the message length is >>>>>> smaller than the SPI receive FIFO size, I would do this with >>>>>> interrupts, >>>>>> but the interrupt would occur only when exceeding the FIFO threshold >>>>>> and >>>>>> then dump the full FIFO in the bottom half interrupt handler. This way, >>>>>> you >>>>>> would get an interrupt on every say every 32 receive bytes, which will >>>>>> reduce the interrupt overhead and improve throughput. >>>>>> >>>>>> If the message length is more than the FIFO length, or if the message >>>>>> is >>>>>> cyclical, then I would use DMA to copy the SPI data into a ping-pong >>>>>> buffer >>>>>> arrangement. From the use space app, you would use poll to wait for a >>>>>> complete buffer, and then read that buffer via read or mmap. >>>>>> >>>>>> Question is, how experienced are you at writing Linux drivers? This >>>>>> isn’t >>>>>> a trivial task. >>>>>> >>>>>> Regards, >>>>>> John >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Mar 27, 2016, at 12:26 AM, Yaron Yzhak Lederman < >>>>>> yaron.leder...@gmail.com> wrote: >>>>>> >>>>>> John Hi, >>>>>> >>>>>> Thank you for coming back on this. >>>>>> >>>>>> I'm trying to connect 2 SPI busses on the BBB (HDMI disabled) and >>>>>> configure SPI1 as SPI slave so that I can sent messages from SPI0 to >>>>>> SPI1 >>>>>> - >>>>>> this allows me my application development and laterone I'll connect the >>>>>> respective SPI slave and master devices >>>>>> >>>>>> Thank you >>>>>> Yaron >>>>>> >>>>>> On Wed, Mar 23, 2016 at 10:37 PM, John Syne <john3...@gmail.com> wrote: >>>>>>> What exactly are you trying to do? Please explain your application so >>>>>>> that we can propose a solution. >>>>>>> >>>>>>> Regards, >>>>>>> John >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mar 23, 2016, at 4:29 AM, yaron.leder...@gmail.com wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Is there any resolution about this ? Since I'm having the same >>>>>>> consideration >>>>>>> >>>>>>> Thanks ! >>>>>>> >>>>>>> >>>>>>> On Wednesday, November 4, 2015 at 4:15:23 PM UTC+2, ravi...@gmail.com >>>>>>> >>>>>>> wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I'm trying to setup SPI slave mode with same above method and >>>>>>>> changed OMAP2_MCSPI_MODULCTRL_MS set to 0 for slave mode. >>>>>>>> >>>>>>>> i'm facing issue in master mode and slave both on sckl pin >>>>>>>> configuration. >>>>>>>> >>>>>>>> http://elinux.org/BeagleBone_Black_Enable_SPIDEV in this link why >>>>>>>> sckl >>>>>>>> pin is configured as INPUT 0x33 but it will work with same >>>>>>>> configuration if >>>>>>>> i change it to OUTPUT it doesn't work with any slave device and no >>>>>>>> clock on >>>>>>>> that pin. >>>>>>>> >>>>>>>> Please anyone clarify this doubt and issues. >>>>>>>> >>>>>>>> For slave mode i tried to change OMAP2_MCSPI_MODULCTRL_MS bit in >>>>>>>> driver >>>>>>>> file spi_omap2_mcspi.c but no use. still its master only. >>>>>>>> >>>>>>>> Please provide any suggestion or exact procedure. >>>>>>>> >>>>>>>> Thank you in advance. >>>>>>>> >>>>>>>> Regard s >>>>>>>> Ravi >>>>>>>> >>>>>>>> On Thursday, September 18, 2014 at 5:45:47 AM UTC+5:30, >>>>>>>> >>>>>>>> phil...@gmail.com wrote: >>>>>>>>> I am having issues with SPI between two BBB that may be simple to >>>>>>>>> solve. I have spidev_test loopback working on each board but am >>>>>>>>> having >>>>>>>>> problems connecting the two. >>>>>>>>> >>>>>>>>> spi0 master dts: >>>>>>>>> 0x150 0x10 /* spi0_sclk, OUTPUT_PULLUP | MODE0 */ >>>>>>>>> 0x154 0x30 /* spi0_d0, INPUT_PULLUP | MODE0 */ >>>>>>>>> 0x158 0x10 /* spi0_d1, OUTPUT_PULLUP | MODE0 */ >>>>>>>>> 0x15c 0x10 /* spi0_cs0, OUTPUT_PULLUP | MODE0 */ >>>>>>>>> >>>>>>>>> spi slave dts: >>>>>>>>> 0x150 0x30 /* spi0_sclk, INPUT_PULLUP | MODE0 */ >>>>>>>>> 0x154 0x10 /* spi0_d0, OUTPUT_PULLUP | MODE0 */ >>>>>>>>> 0x158 0x30 /* spi0_d1, INPUT_PULLUP | MODE0 */ >>>>>>>>> 0x15c 0x30 /* spi0_cs0, INPUT_PULLUP | MODE0 */ >>>>>>>>> >>>>>>>>> The oscilloscope shows activity when spi0_sckl (P9_17) is not >>>>>>>>> connected but nothing when P9_17 is connected between both boards. >>>>>>>>> I am sending bytes from master with the command: echo 1 > >>>>>>>>> /dev/spidev1.0 >>>>>>>>> >>>>>>>>> I need 4-8mbit/sec transfer, is this achievable by bit banging over >>>>>>>>> GPIO and would that be a viable alternative to getting SPI working? >>>>>>> >>>>>>> -- >>>>>>> For more options, visit http://beagleboard.org/discuss >>>>>>> --- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "BeagleBoard" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>>>> an email to beagleboard+unsubscr...@googlegroups.com. >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> For more options, visit http://beagleboard.org/discuss >>>>>>> --- >>>>>>> You received this message because you are subscribed to a topic in the >>>>>>> Google Groups "BeagleBoard" group. >>>>>>> To unsubscribe from this topic, visit >>>>>>> https://groups.google.com/d/topic/beagleboard/jQ1LH6IDH1A/unsubscribe. >>>>>>> To unsubscribe from this group and all its topics, send an email to >>>>>>> beagleboard+unsubscr...@googlegroups.com. >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>>> -- >>>>>> בברכה, >>>>>> >>>>>> ירון יצחק לדרמן >>>>>> 08-6909594 >>>>>> >>>>>> -- >>>>>> For more options, visit http://beagleboard.org/discuss >>>>>> --- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups >>>>>> "BeagleBoard" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>>> an >>>>>> email to beagleboard+unsubscr...@googlegroups.com. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> For more options, visit http://beagleboard.org/discuss >>>>>> --- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups >>>>>> "BeagleBoard" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>>> an >>>>>> email to beagleboard+unsubscr...@googlegroups.com. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>>> -- >>>>> For more options, visit http://beagleboard.org/discuss >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups >>>>> "BeagleBoard" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an >>>>> email to beagleboard+unsubscr...@googlegroups.com. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>>> >>>>> -- >>>>> For more options, visit http://beagleboard.org/discuss >>>>> --- >>>>> You received this message because you are subscribed to a topic in the >>>>> Google Groups "BeagleBoard" group. >>>>> To unsubscribe from this topic, visit >>>>> https://groups.google.com/d/topic/beagleboard/jQ1LH6IDH1A/unsubscribe. >>>>> To unsubscribe from this group and all its topics, send an email to >>>>> beagleboard+unsubscr...@googlegroups.com. >>>>> For more options, visit https://groups.google.com/d/optout. > > -- > Hunyue Yau > http://www.hy-research.com/ > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to beagleboard+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
