> On Apr 4, 2016, at 2:42 PM, Harvey White <ma...@dragonworks.info> wrote: > > On Mon, 4 Apr 2016 13:13:48 -0700, you wrote: > >> >> >>> 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. > > Data that is shifted back into the master is generally a known > quantity, generally 0xFF. > > I haven't run into a device that requires data to be sent within a > certain amount of time. Generally, you don't have to always run at > the maximum, although there's sometimes a minimum. > > I've been debugging SPI stuff on another platform, and the time > between bytes did not seem to be significant if it were held up by the > debugger. If you are using an SPI master, then what you say is correct, but if you are a SPI slave, then some other device is controlling the clock, which means you have to have data available before the clock starts. If there is no delay between packets, then timing is critical.
Regards, John > >>> >>> 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. > > IF you're dealing with a streaming interface, then the timing is > imposed by the data stream output, and all the timing relaxations have > limits. > > > Harvey > >>> >>> >>>> 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 > <snip> > > -- > 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.
