Recently I've been working with the SPI slave boot mode on the BF548, and I was hoping to find out if the specification in the hardware reference manual is unnecessarily conservative or not.
Let me quickly summarize the scenario. Currently, the host device is sending down the application as defined by the BF548 HRM. That is to say, transmit a byte, verify HWAIT is not asserted, transmit next byte, etc. This works fine, but the host is running a Linux user-space application, and the context switching to do a transfer and GPIO check per byte is bringing it to a crawl. In a simple attempt to speed the transfer up without a total reconstruction of the host, I attempted to transfer 8 bytes at a time between checks. This worked without fail over several trials, but no longer adheres to the specification to check the HWAIT signal after each byte. Eight bytes per payload was not chosen arbitrarily, but because the manual describes that as the number of bytes before the first HWAIT is asserted.
To address the more obvious solution, increasing the transfer rate isn't a significant impact on its own. At the nominal rate of 0.5 MHz, about 10% of the transfer time is spent sending bytes, and the remainder is system overhead. In this regard, reducing the number of initiated transfers (increasing payload from 1 to 8 bytes) in user-space saves much more time.
My question is, are there any other results that show that the per byte checking of HWAIT is overkill, or some assurance from Analog that this would be safe regardless of what the HRM says on this chip (and future silicon revisions of the BF548)? "No" is a valid answer, I just wanted to exhaust this option since the alternatives are not so simple, and initial results seem to suggest this could work.
Thank you in advance for any help or advice!