Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Question about SPI1_Write ?

Status
Not open for further replies.

bianchi77

Advanced Member level 4
Joined
Jun 11, 2009
Messages
1,313
Helped
21
Reputation
44
Reaction score
20
Trophy points
1,318
Location
California
Activity points
9,442
Guys,

Why can't send the complete file to SPI1_write()?
I'm using MikroC Pro For ARM...

When I pass the variable to UART1_Write()....I can read all the file content but when I put on SPI1_Write() only top part of the file..

Anyone knows ?

Thanks
 

Certainly you are not referring to UART1_Write() but rather to UART1_Write_Text(), which accept arguments as pointer of an array. Anyway, why should both functions work likewise ? Apropos, you can make your own function SPI1_write_Text() building with the SPI1_write() inside, although a priori would not make much sense, once AFAIK most SPI packs sent by Master device are shorts.
 

Certainly you are not referring to UART1_Write() but rather to UART1_Write_Text(), which accept arguments as pointer of an array. Anyway, why should both functions work likewise ? Apropos, you can make your own function SPI1_write_Text() building with the SPI1_write() inside, although a priori would not make much sense, once AFAIK most SPI packs sent by Master device are shorts.

I don't understand what you mean ....
Why can't I transfer data on SPI1_Write().....but it's transfered ok on UART ??
 

Why can't I transfer data on SPI1_Write().....but it's transfered ok on UART ??

I'm giving you an example of what I meant at the code posted on the following thread, on which you can see that the function UART1_Write() was used to send a single character, whereas the function UART1_Write_Text() was used to send a string:

 

I'm giving you an example of what I meant at the code posted on the following thread, on which you can see that the function UART1_Write() was used to send a single character, whereas the function UART1_Write_Text() was used to send a string:


How can I say it to explain it........when I use UART1_Write

Please have a look at the code....
Code:
void MP3_SDI_Write(char data_) {

  
    MP3_CS = 1;
    
    //while (DREQ == 0);             // wait until DREQ becomes 1, see MP3 codec datasheet, Serial Protocol for SCI
      BSYNC = 0;
    UART1_Write(data_);
    //SPI1_Write(data_);
   
    BSYNC = 1;

}

I send the same data_......
but when I used SPI1_Write(), it's sending only 512bytes....
When I used UART1_Write()...it can send the whole files perfectly....

Why ??
Code:
void Read_Play_MP3()
{

    unsigned long i, fsize;
    unsigned int j, cnt,count;
    short fhandle;

    char readBuffer[BUFSIZE];
    char str[55];

             LED = 0;

    fhandle = FAT32_Open("hello.mp3", FILE_READ);
    if (fhandle >= 0)
    {
          
          UART1_Write_Text("File test1.mp3 opened sucessfully!\n");
          FAT32_Size("hello.mp3", &fsize);

          LongToStr(fsize, str);
          UART_Write_Text("hello.mp3 size: ");
          UART_Write_Text(str);
          UART_Write(CR);
          
          while (FAT32_Eof(fhandle) != 1)
          
          {
          
            FAT32_Read(fhandle, readBuffer, BUFSIZE);
                     count =0;
                      
                        while(count<512)
                        {
                           for(j=0;j<32;j++)
                            {


                                 if (DREQ == 1)
                                 {
                                   
                                   MP3_SDI_Write(readBuffer[count]); //????
                                   //UART_Write(readBuffer[count]); //????
                                   count++;
                                   
                                  }
                            }
                            //Delay_ms(10);
                        }
                 LED = 1;
                 Delay_ms(100);
                 LED = 0;
           }
                 UART1_Write_Text("\nDone  !\n DONE! \n");
                 LED = 1;
                 Delay_ms(1000);
                 LED = 0;
                 FAT32_Close(fhandle);
         
     }
     else
     {
            UART1_Write_Text("Opening file hello.mp3 failure!\n");
     }


 }

MP3_SDI_Write(readBuffer[count]);

Thanks

- - - Updated - - -

When I used UART1_Write()....the file is completely read :
File test1.mp3 opened sucessfully!
hello.mp3 size:

............

Done !
DONE!


with SPI1_Write()...

only 512 bytes...not complete file...
 

when I used SPI1_Write(), it's sending only 512bytes....
When I used UART1_Write()...it can send the whole files perfectly...

Sending bytes to what ?
If worked for 512 bytes, you are missing to analyse the part of the code that calls the function MP3_SDI_Write().
 

Sending bytes to what ?
If worked for 512 bytes, you are missing to analyse the part of the code that calls the function MP3_SDI_Write().

Sending the bytes to VS1053....and for a test I used UART

- - - Updated - - -

How exactly? Signalling eof after 512 bytes? or?

Eof after file finish...sending 512 bytes on buffer until eof and divide 512 bytes into 32 bytes each...
 

Not answering the question.

You see eof after 512 bytes although the file is larger than 512 bytes?
 

Not answering the question.

You see eof after 512 bytes although the file is larger than 512 bytes?

Scratch my head....I don't understand....hehehehe

If I used UART, it can see EOF but if I used SPI it can not see EOF only the first 512 bytes and repeat...never been into EOF....
 

but if I used SPI it can not see EOF only the first 512 bytes and repeat
Why don't you report your observation clearly from the start?

Most likely, from the second function call, FAT32_Read() simply does nothing, the initially read sector data is preserved. You're ignoring the result of FAT32_Read() and don't become aware of it's failure.

Question is of course why file read is failing, a specific reason can't be seen in the code. I guess there might be an unexpected side effect of SPI1_write() on the SD card SPI interface. Either a problem in your code or a bug of the MikroC built-in libraries.
 

Why don't you report your observation clearly from the start?

Most likely, from the second function call, FAT32_Read() simply does nothing, the initially read sector data is preserved. You're ignoring the result of FAT32_Read() and don't become aware of it's failure.

Question is of course why file read is failing, a specific reason can't be seen in the code. I guess there might be an unexpected side effect of SPI1_write() on the SD card SPI interface. Either a problem in your code or a bug of the MikroC built-in libraries.

If I increase BUFFSIZE = 2048, I can run send all the file content to SPI1....?
But what happened if I have 5Mbytes file ???
 

You had not mentioned anywhere in what context parameter BUFFSIZE is being used, neither answered whether you checked or not the loop where function MP3_SDI_Write() is called, as mentioned in post #6. You're not analyzing the situation in a systematic way.
 

Increasing BUFFSIZE means you are reading a larger part of the file at once. But you want to read it incrementally.

As andre_teprom said, you need to analyze why FAT32_Read() is apparently failing on second and succeeding call. Presently you don't even check for successful execution.

Regarding possible faults, what does
Code:
MP3_CS = 1;
Why is it only set and not reset? I presume BSYNC is the actual SPI nCS line?
 

Zip and post the complete project. Remove all unnecessary codes.
 

I use EasyMx Pro for STM32 from mikroE.

Ok, you can give a try, I used SPI1 on this code

focus on this function :
void Read_Play_MP3()

I've tested reading only and VS1053 only...
See at main()...

The loop for reading file is working on atmega128

Please let me know, how's the result ? thanks
 

Attachments

  • FAT32 MP3 Player No TFT Rev4 19March2016.zip
    334.9 KB · Views: 95

Should I just Compile and burn and test ? Any changes to be made ?

I Compiled, burned and tested. I don't hear anything. It is only Silence.
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top