On Mon, 4 Apr 2016 13:13:48 -0700, you wrote: > > >> On Apr 4, 2016, at 12:49 PM, [email protected] 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. >> >> 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
