SPI doubt

Discussion created by Ezequiel Paolinelli on Apr 16, 2008
Latest reply on Apr 18, 2008 by Ezequiel Paolinelli

Like • Show 0 Likes0
Comment • 11

Hi I am trying to make an SPI interphase wihtout interrupts. When i send one byte I just check the SPSCR register until the flag SPRF goes high

WAIT: BRCLR #7,SPSCR,WAIT

At that moment I know that i sent one byte. Now, I want to know if I can do the same thing to wait for response. And in this case, I check the SPRF flag or the SPTE flag? I can´t tell the difference between them.

Thanks

Outcomes

11 Replies

Peter House Apr 16, 2008 2:05 PM
Kacto,

SPI is normally configured as a simultaneous bidirectional interface. This means that when you send one byte, a byte is also received. This is due to the fact that SPI has only one clock signal provided by the master.

If you are checking status of a remote device after issuing a command you must send the command and then send another dummy byte in order to clock in the response byte. The remote CPU or device cannot see the command until after it is clocked in and then must formulate a reply and wait for the master SPI device to send the dummy byte to it can respond.

Good Luck,

Peter House
Like • Show 0 Likes0
Actions
Ezequiel Paolinelli Apr 16, 2008 2:37 PM
Thanks Peter House. Look im trying to comunicate with an SD memory. In order to initializate i have to send 6 bytes 0x41,0x00,0x00,0x00,0x00,0x95 and then wait for a response byte 0x01, the response interval is 1 to 8 bytes. What I did was move the first byte into the spi data register, then move the second....to the last one. Everytime I sent one byte I cheked the SPRF flag to see if I could send the next one. After this I should send the dummy byte (could be any byte?), and once I send it read the SPI data register and check if I recived my response? and in case I didn´t, send another dummy byte again?
Thanks
Like • Show 0 Likes0
Actions
- Jim Donelson @ Ezequiel Paolinelli on Apr 16, 2008 3:34 PM
  
  It should be 0xff.
  I recommend you look at chans code.
  
  If you are going to make a fat file system, you should start with his code that does work, unlike most others I've tried it . You cans study how he sets things up in the card. The problem with developing a fat file system is testing - just because you can write a file or two is no proof of correctness . This code has a fair amount of testing, and hes is actively maintaining it.
  
  This code is a port to hcs12, that does not implement his file system, but the low level routines do successfully init the card and R/W sectors. Note that the chan code in this is not up to date, and this code is only tested to a certain extent. It was written for a Dragon12, so if your hard ward is different, you may have make adujestment, but it will show how the set up the SPI and talk to the card.
  
  You could take these two pieces and put together a working file system.
  
  Message Edited by JimDon on 2008-04-16 11:34 AM
  Like • Show 0 Likes0
  Actions
  - Ezequiel Paolinelli @ Jim Donelson on Apr 16, 2008 4:25 PM
    Thanks for the quick answer. I took a look at the web pages you gave me and they explain a lot. My problem is that i am not into the c language, i´m using assembler code. That´s why i wanted to know if a should keep sending dummy bytes until i receive my response. I know that doing a fat file system with assembler could sound like a lot of code lines but i only need to read files from the memory. I´ve been studying the fat file system and pretty much know everything to handle the memory, now i just need to put it in practice. So my problem right know is how to use spi in the correct manner. I know how to send a command but no how to receive my response. What i think is that after sending the command i should keep sending dummy bytes, at least 8 (1 to 8 bytes is the response interval), before i get the correct response. If you could help me with that i´ll be very gratefull.
    I´m using the instructions: MOV (to put the byte on the spi data register) and BRCLR (to keep cheking the SPFR flag to know when i sent the byte and that i can send another one. Or in the case of the dummy byte to know that i received my response, don´t know if this last thing is correct)
    Like • Show 0 Likes0
    Actions
    - Jim Donelson @ Ezequiel Paolinelli on Apr 16, 2008 4:48 PM
      Well, I am not an assembly language expert, but yes as you can see from the code, you need to keep sending ff until you get back status. Unless you are clocking the card, nothing happens. Also pay close attention to the select line. You must not de-select during a command. Also after you de-select, the card need more clocks.
      The select line acts like a command reset, so you must de-select between commands.
      
      Even if you do not use "C" that code will show you the over all flow of talking to the card.
      I also recommend you carefully study chans fat code. There are many man hours of effort there, and while perhaps you are very smart, so is chan and it has taken him quite some time to get this code to where it is.
      
      You will also find that SD card access is very very slow in the context you are in because you do not have big buffers. Each time you write a sector, the card has to erase and re-write and entire block, and this take time.
      The blocks vary in size, so actually you may get better performance with smaller cards.
      
      Like • Show 0 Likes0
      Actions
      - Ezequiel Paolinelli @ Jim Donelson on Apr 16, 2008 5:41 PM
        Well, thanks again. I will pay attention to what you said and take a good read to chans fat code. In case i need some more assistance i´ll ask again.
        
        Like • Show 0 Likes0
        Actions
        bigmac @ Ezequiel Paolinelli on Apr 16, 2008 6:29 PM
        
        Hello,
        
        You do not say which device you are using, but the following code uses register names associated with 9S08AW devices. The following is a general sub-routine suitable for SPI master transfer of a single byte. The one routine can be used whether sending a command, or getting returned data in response to sending a dummy byte.
        
        ; Bit name aliases:
        SPTEF     EQU    SPI1S_SPTEF
        SPRF      EQU    SPI1S_SPRF
        
        ; SPI MASTER BI-DIRECTIONAL TRANSFER
        ; On entry, ACC = byte value to be sent
        ; On exit, ACC = received byte value
        
        SPI_TRANS:
                  BRCLR SPTEF,SPI1S,* ; Wait until ready to send
                  STA    SPI1D          ; Send byte value
                  BRCLR SPRF,SPI1S,*   ; Wait until transfer complete
                  LDA    SPI1D          ; Return value
                  RTS
        
        It is important that the SPRF flag always be cleared, whether the returned byte is used, or not. This is to prevent an overrun error from occurring, that will prevent further data transfer until the flag is cleared.
        
        Regards,
        Mac
        
        Like • Show 0 Likes0
        Actions
        Ezequiel Paolinelli @ bigmac on Apr 16, 2008 9:45 PM
        Hi Mac, i just read your post. I´m using a HC908GP32. And my code is:
        
        SPDR            EQU            SPI Data register
        SPSCR          EQU            SPI Status and control register
        SPCR            EQU            SPI Control Register
        
        SPI_TRANS:
                           MOV    DATA,SPDR
           HOLD1:  BRCLR #7,SPSCR,HOLD1          ;waiting till flag SPRF goes high
                           LDA    SPSCR           ;I use this line to reset the SPRF flag (1º step)
                           LDA    SPCR             ;I use this line to reset the SPRF flag (2º step)
                           LDA    SPDR             ;I get my value here, if i sent a dummy byte
                           RTS
        What im not doing is cheking first the SPTE flag, should I?
        The way to reset the SPRF flag is ok?
        
        Regards
        Like • Show 0 Likes0
        Actions
        David Payne @ Ezequiel Paolinelli on Apr 16, 2008 10:39 PM
        Hi kacto,
        
        Refer to this post for the differences between the HC08 and S08 SPI, as well as how to use both.
        
        Like • Show 0 Likes0
        Actions
        bigmac @ David Payne on Apr 17, 2008 4:59 AM
        Hello,
        
        Your sub-routine should work, but the flag clearing process you have used is unnecessarily complex. Whilst you test SPRF until it becomes set, this is fulfilling the first step of the clearing sequence. So the extra read of SPSCR is quite unnecessary. The second step in the sequence is to read SPDR, as you are doing. It is not necessary to read SPCR.
        
        The use of the MOV instruction is probably less efficient than transferring the data using the accumulator, since each send byte would also need to be individually moved into the DATA location. If you wish to stay with this instruction, perhaps the form MOV X+,SPDR might be better. Then simply set H:X to point to the start of the required send data sequence (that might reside in flash).
        
        Finally, my use of the asterisk (*) does the same as your code, but avoids the need for an explicit label.
        
        Regards,
        Mac
        
        Like • Show 0 Likes0
        Actions
        Ezequiel Paolinelli @ bigmac on Apr 18, 2008 12:58 PM
        Thanks Mac. I´ll take care of that.
        
        Regards
        Like • Show 0 Likes0
        Actions

SPI doubt

Outcomes

Related Content

Recommended Content