3 Replies Latest reply on Mar 21, 2016 4:58 PM by userc_19497 Branched from an earlier discussion.

    Very long SPI Transfer on the BCM20737 (con't)

      As a follow on to the discussion here: Very long SPI Transfer on the BCM20737

       

      I also have this question, and would like to offer the beginning of a solution:

       

      I'd like to make my own buffer of maybe 512 bytes, and a head + tail variable.

      my spi_long_tx(); would then

      calculate length=head-tail

      transmit up to 14 bytes to the spi hardware,

      increment tail by up to 14

      and if length >14,

           set spiffy2_TxAELevel to 4 (or so)

           enable SPI interrupt (spiffy2_IntEnable) just for Tx Almost Empty

       

       

      then the interrupt service routine for SPI would

      -check if head > tail

      send the next up to 10 bytes to spi hardware

      increment tail accordingly

      and if now head==tail, disable the almost empty interrupt.

       

      what we now need from Broadcom is

      a) full description of the SPI interrupt bits

      b) a possibility to register an interrupt service routine for the SPI interrupts

       

      That information is available for PUART, why not for SPI2?

       

       

      while you're at it, please give us a list of what is critical for the Bluetooth stack, and what we should not be using at all,

      and some documentation on the rest of the stuff.

      That interrupt service routines should never be blocking and should complete within a few cycles, I think goes without saying, and whoever breaks the bluetooth stack with these methods only has himself to blame, not broadcom ;-)

      eg. can we use the systick timer? interrupt? or is it used (sometimes?) in the stack?

       

      The BCM20737 really is awesome, and if only we had a little more documentation and access to its inner workings, it would really be an incredible chip to put into any IoT design!!