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

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

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!!

0 Likes
3 Replies
MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

Adding jamesle1​ on the application team as he may be able to help.

0 Likes
Anonymous
Not applicable

Thanks mwf_mmfae​ !

just to be clear: what we need is something like

extern void (*puart_rxCb)(void *);

extern void (*puart_rxIntCb)(void);

extern void (*puart_txCb)(void);

as found at the top of puart.h

so that we can register our own interrupt handler functions (as in the example from Application note "WICED SmartTM Hardware Interfaces")

// Set callback function to app callback function.

  puart_rxCb = my_uart_rx_interrupt_callback;

as well as a function to enable the interrupt.

0 Likes
Anonymous
Not applicable

Hello foolography

Looking at the source code of the spiffydriver, there isn't seem to be any interrupt handler analogous to that of the puart.

If you want interrupts for SPI, it seems like you have to use regular GPIO interrupts for SPI transactions.

I'll ask the developers if there's any other way for SPI interrupts.

James

0 Likes