PIC18F2420使用SPI读取SD卡时出现问题

HI AALI正在构建一个围绕PIC18F2420的项目，以读取SD卡（SPI模式），并通过MIDI模式中的USAT将内容（适当定时和格式化）传送到数字键盘。我曾多次使用过USAT，但这是我第一次进入SPI。我在汇编程序中进行编码（由于各种原因集中在时间上），并且在SPI前线遇到了一些奇怪的行为。我使用的时钟速度为250kHz。我已经成功地初始化了4GB超越SDHC卡，并且尝试使用CMD17单块读取操作读取数据。但是，我发现需要在SDIC传输操作和PIC内部的数据检索命令之间插入一个延迟来获得正确的数据。以下是相关代码：MOVLW H'FF；启动SPI字节读取MOVWF SSPBUFBCF PIR1，SSPIF；清除SPI中断标志…BTFSS PIR1，SSPIF；并等待它被设置为胸罩$- 02；DEFF Delt，f；强制DelayBNZ $ 02；MOVFSSPBUF，PASCUN2；用于分析无中断的传输检索字节是活动的。这里所示的延迟增加了近800μs到读取周期时间，并且导致正确的数据被存储在由FSR2指向的阵列中。如果延迟时间减少到大约200秒，则存储一些数据…几乎就像一些通过和一些不。删除延迟例程完全导致一个流的'HFF '被存储。不幸的是，我没有太多的方式的分析工具，除了一个旧的示波器，但我可以说，时钟是干净的，并响应的长度为CED Delayas预计延长时钟脉冲串之间的周期。我的理解是，（i）传输在加载SSPBUF时立即开始（如规范所述），并且在数据被成功读取之后延迟执行。或者（ii）在加载SSPBUF和发送的时钟之间存在很大的延迟。我不知道哪一个是正确的，但在这两种情况下，我都不明白为什么延迟是必要的，或者需要什么来进行。我在其他页面上读到MOVFF是双循环指令，并且可以得到“拆分”。但是正如我前面所说的，没有主动中断可以通过不完成来自SSPBUF的内部传输来“丢失”数据。我有更多的事情要看，如果我能确定事情的进展，但我想我会把这个问题放在这个论坛的权力，以防我错过了显而易见的。



      以下为原文

    Hi all

I'm building a project centred around a PIC18F2420 to read an SD card (in SPI mode) and transfer the content (suitably timed and formatted) to a digital keyboard via the USART in MIDI mode. I've used the USART many times this way, but this is my first foray into SPI.

I'm coding in assembler (for various reasons centred around timing), and have come across some strange behaviour on the SPI front. I'm using a clock speed of 250kHz throughout. I've successfully initialised the 4GB Transcend SDHC card, and am attempting to read data using the CMD17 single-block-read operation. However, I've found that I need to insert a delay between the SD transfer operation and the data-retrieval command inside the PIC to get the correct data out. Here's the relevant code:

MOVLW  h'FF'               ; initiate SPI byte read     
MOVWF  SSPBUF
BCF    PIR1,   SSPIF       ; clear SPI interrupt flag ...
BTFSS  PIR1,   SSPIF       ; ... and wait for it to be set
BRA    $-02
;
DECF   DELT,   F           ; FORCED DELAY
BNZ    $-02
;
MOVFF  SSPBUF, POSTINC2    ; transfer retrieved byte for analysis

No interrupts are active. The delay as shown here adds almost 800us to the read-cycle time, and results in the correct data being stored in the array pointed to by FSR2. If the delay time is reduced to around 200us, some data is stored ... almost as though some gets through and some doesn't. Removing the delay routine altogether results in a stream of h'FF' being stored.

Unfortunately, I don't have much in the way of analysis tools except an old oscilloscope, but I can say that the clock is clean, and responds to the length of the forced delay as expected by extending the period between clock bursts. My reading of this is that either (i) the transfer is initiated immediately on loading SSPBUF (as the spec says), and the delay is executing AFTER the data has been successfully read ... or (ii) there's a massive delay between loading SSPBUF and the clocks being sent. I have no way of telling which of these is true, but in either case, I don't understand why the delay is necessary, or what can be happening to require it.

I've read on other pages that MOVFF is a dual-cycle instruction, and can get "split" ... but as I said earlier, there are no active interrupts which can do this and "lose" data by not completing the internal transfer from SSPBUF. I have a few more things to try to see if I can pin down what's going on, but I thought I'd put the issue to the power of this forum in case I've missed the obvious.

TIA for any tips, ideas, or advice.