- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!!
- Labels:
-
SPI
- Tags:
- long transfers spi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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