MicroSD Cards and SDFS

Hi all,

Well, this is probably a very dumb question :eek:. I'm trying to get a MicroSD card to work with SDFS. The first question I have is about the pin names. In the schematics provided in the SDFS zip file there are 12 pins for the SD card, and they are named as

• CS
• DATA IN
• Vss
• Vdd
• SCLK
• DATA OUT
• CD
• WP
• GROUND

Plus some NC pins. Now, all of the SD cards that I can find have 8 pins named as follows

• DAT2
• DAT3/CD
• CMD
• VDD
• CLK
• VSS
• DAT0
• DAT1

So the question would be, how do you relate one to the other? Am I talking about two different things here?

My second question would be about about the PIC speed when initializing the SD card. Do I need to slow down the PIC to initialize the SD card?

Thank you all for your help,

Robert

Attachment 4388

SD cards have 9 pads.
Looking at the pads and the pads towards you the right hand pad is #9(the pad on the angle). From there they then going from right to left 1 to 8

The other three connections from the socket are a common, Write Protect, and Card Detect.

SD pads 8 and 9 are pulled high (3.3 volt) with a 10k.
Pad #4 is 3.3 volt.
Pads 3 and 6 are VSS.
Pad #1 is Chip Select, CS
Pad #2 is Data Out from PIC, into SD.
Pad #7 is Data In to PIC, out from SD.

mackrackit,

Thank you for your response.

Quote:

---

Originally Posted by mackrackit

SD cards have 9 pads.

---

All the MicroSD cards that I have seen so far have 8 pads. Look at the attached picture.

Attachment 4398

Can I use SDFS with MicroSD cards that have 8 pads? From searching in google, I found that these MicroSD cards can operate in two modes, SPI and SD modes. Please take a look at the attached pics.

Attachment 4399Attachment 4400

What mode should I use? How do you relate the pin functions to the schematics in the SDFS help file?


Robert

Just a guess but use an adapter and SPI mode is by far most common.

Norm

Doh.... I was thinking regular SD cards.

The only time I have used them was with an adapter so using one straight should not be a problem.

Looking at the pin outs between the two it appears pin 9 has been dropped and pin 1 is not used on the micros. Pin 2 on the micro is the same as pin 1 on the full size, I think. Just compare the pin names and functions between the two.

SPI.... That is what SDFS uses. The only option it hardware SPI or not. Testing for speed between the two I have not seen a difference. Hardware SPI on the chip I use is also one of the USART pins so I have been using software SPI.

Hi,

I will use the SPI mode for the SDFS as you guys suggested. I've already ordered my MicroSD socket from mouser. So, I will keep you posted if I get it to work or not.

About all the extra pins that the MicroSD card doesn't use like the WP, I guess that I can comment out these lines of code that I don't need in the SDFS program. I'm going to have to study this SDFS code to see how it works.

Robert

When not using Write Protect do a search through SDFS for "SD_WE" and comment out anything to do with it. It only shows up in about 6 places.
Comment this

Code:

---

SD_WE_TRIS = 1

---

And all occurrences of this

Code:

---

If (SD_WE) Then
        FAT_error = CE_WRITE_PROTECTED
        Return        ' Return Byte FAT_error.
    Endif

---

The PIC® pin assignments will look something like this

Code:

---

SDI        Var    PORTB.2    ' SPI data in SD #7
SDI_TRIS    Var    TRISB.2    ' SPI data in direction
SCL        Var    PORTB.1    ' SPI clock  SD #5
SCL_TRIS    Var    TRISB.1    ' SPI clock direction
SD_CS        Var    PORTB.3    ' SD card chip select SD #1
SD_CS_TRIS    Var    TRISB.3    ' SD card chip select direction
SD_CD        Var    PORTB.4    ' SD card detect
SD_CD_TRIS    Var    TRISB.4    ' SD card detect direction
SDO        Var    PORTC.7    ' SPI data out  SD #2
SDO_TRIS    Var    TRISC.7    ' SPI data out direction

---

If you are not using the hardware SPI from the PIC® and need to use other pins put this in your code

Code:

---

SDC_UseHardSPI = FALSE

---

If you run into problems let us know.

Quote:

---

Originally Posted by mackrackit

If you run into problems let us know.

---

Thank you. As soon as I get the parts, I will start playing with the SDFS and the MicroSD card. I am sure I will have some questions.

Robert

Hi,

I finally got the parts that I needed and started playing with SDFS. Since I'm running my 18F4550 at 3.3V I connected all the MicroSD card pins directly to the PIC. I did not install the 10k resistors since my configuration is a little bit different. Do I need to use these 10K resistors?

I ran the SDTEST.BAS and it worked. It created a file TEST1.TXT with the text "ABC". I could see the file in my cell phone that runs Windows Mobile 6.1. Now, I can't read this card in my Windows XP PC. Somehow, XP does not like FAT16 format in the SD cards. How do you read your SD files in your computer? Is there any work around for this? I don't want to install Win98 in one of my old computers just for this :(.

Robert

Quote:

---

Originally Posted by rsocor01

Now, I can't read this card in my Windows XP PC. Somehow, XP does not like FAT16 format in the SD cards. How do you read your SD files in your computer? Is there any work around for this? I don't want to install Win98 in one of my old computers just for this :(.

Robert

---

Try formatting the card with XP using right click on SD drive > format > file system FAT(FAT16).
Be sure you have the correct drive or data loss will occur.

Norm

Quote:

---

Originally Posted by rsocor01

Hi,

I finally got the parts that I needed and started playing with SDFS. Since I'm running my 18F4550 at 3.3V I connected all the MicroSD card pins directly to the PIC. I did not install the 10k resistors since my configuration is a little bit different. Do I need to use these 10K resistors?
Robert

---

I haven't seen the wiring diagram but a 10k resistor would only be required for a 5 volt PIC to
pull up the PIC in-data line as well as others to split the PIC 5 volt lines to SD 3.3 volts.

Norm

Running at 3.3 volts I still pull up pins 8 and 9 on the full size SD cards, the remainder I run straight.

Norn is correct about the formatting. I read my FAT16 cards on XP, Vista, Vista 7, and Linux. No problems.

Hi,

Thank you guys for your help. Yes, Norm is correct about the formatting of the MicroSD card. It works :).

Quote:

---

Originally Posted by mackrackit

Running at 3.3 volts I still pull up pins 8 and 9 on the full size SD cards, the remainder I run straight.

---

The breakout board that I got from sparkfun.com doesn't have the connection for the NC pad. Maybe, the resistor at NC is not necessary after all :confused:.

http://www.sparkfun.com/commerce/pro...roducts_id=544


Now, I have a question about SDTEST.BAS. The code to write to the card is

Code:

---

' Write to file
        FAT_src[0] = "A"
        FAT_src[1] = "B"
        FAT_src[2] = "C"
        FAT_count = 3
        Gosub FSfwrite
        Serout2 PORTC.6, 84, [ "Write ", Dec FAT_error, $d, $a]
        If (FAT_error != 0) Then Stop

---

This code will write "ABC" to the card

Code:

---

ABC

---

But, for data logging I need the entries in diferent lines

Code:

---

A
B
C

---

Can you do that with SDFS? Thank you for your help.

Robert

Maybe the pull-ups on pins 8 and 9 are not needed... Old habits are hard to break. :o

Code:

---


' Write to file
        FAT_src[0] = "A"
        FAT_src[1] = $d
        FAT_src[2] = $a
        FAT_src[3] = "B"
        FAT_src[4] = $d
        FAT_src[5] = $a
        FAT_src[6] = "C"
        FAT_src[7] = $d
        FAT_src[8] = $a
    FAT_src[9] = $d
    FAT_src[10] = $a
        FAT_count = 11
    Gosub FSfwrite
    Serout2 PORTC.6, 84, [ "Write ", Dec FAT_error, $d, $a]
    If (FAT_error != 0) Then Stop

---

mackrackit,

Very nice. It works!! This is not in the readme.txt file. How do you know these things? Just kidding. :)


Now, I have another problem when trying to combine USB and SDFS. I'm not sure if I should open another thread for this problem.

When using USB with PBPL you get the next errors

Code:

---

ERROR: Macro USBINIT? not found in macro file.
ERROR: Macro USBSERVICE? not found in macro file.
ERROR: Macro USBIN?CBBL not found in macro file.
ERROR: Macro USBOUT?CBBL not found in macro file.

---

The fix for this problem is to include the 18F4550.bal file and the project files in the same directory. This solution was given by Mister_E in the next thread

http://www.picbasic.co.uk/forum/show...=macro+usbinit

Now, if I want to combine USB and SDFS I would have to use the file 18F4550.bal. But if I compile my SDFS file with this file in the same directory I get the following error

Code:

---

ERROR: Unable to fit variable SDC_buffer

---

I'm using PBP 2.50, MPASM 5.22, and MCS 3.0.0.5. Any help would be greatly appreciated. Thank you.

Robert

Unfortunately it looks like you need a chip with more memory to do both.

Any way you could use two MCUs and have them share data? Not the best solution but... it is all I can think of off the top.

Quote:

---

Originally Posted by mackrackit

Unfortunately it looks like you need a chip with more memory to do both.

Any way you could use two MCUs and have them share data? Not the best solution but... it is all I can think of off the top.

---

Hmmm, I problably didn't explain myself very clear :(. I get this SDC_buffer error running SDFS only with the file 18F4550.bal in the same directory. This file is necessary to run USB with PBPL. I haven't tried both USB and SDFS at the same time yet. I will probably open a new thread on this problem.

Robert

If you do not need the USB function of the chip then remove the bal file.
I am pretty sure PBP will include it if it is in the project directory even if you are not using it. IT being bal :)

mackrackit,

My project is going well. Without your help I would be still stuck trying to make this SDFS work. Thank you for your help.

After a lot of reading, I figured out a way to make USB and SDFS work. I had to modify the 18F4550.bal file. There are two versions of this file, one for USB and one for non-USB devices. The option for USB devices had some memory settings commented out. I enabled back these settings and BINGO, it worked.

Robert

mackrackit,

In my project, data is read from the MicroSD card and sent to a TFT LCD display. As you can imagine, speed is very important. Let's say that I have the following bytes in my TXT file and I want to read them

Code:

---

203
37
92

---

When you read these values with SDFS you get something like

Code:

---

FAT_dest[0] = 50    'ASCII number for "2"
FAT_dest[1] = 48    'ASCII number for "0"
FAT_dest[2] = 51    'ASCII number for "3"
FAT_dest[3] = 13    'ASCII number for "CR"
FAT_dest[4] = 10    'ASCII number for "LF"
FAT_dest[5] = 51    'ASCII number for "3"
FAT_dest[6] = 55    'ASCII number for "7"
FAT_dest[7] = 13    'ASCII number for "CR"
FAT_dest[8] = 10    'ASCII number for "LF"
FAT_dest[9] = 57    'ASCII number for "9"
FAT_dest[10] = 50    'ASCII number for "2"

---

Then, you have to do some data manipulation to obtain the bytes that you need, 203, 37, and 92. This takes too much time :eek:. Is there any way or is there any format for my TXT file that I can use were I would obtain a SDFS reading like the following?

Code:

---

FAT_dest[0] = 203 
FAT_dest[1] = 37
FAT_dest[2] = 92

---

This would speed up my program a lot and I would obtain much better graphics in my TFT display. Thank you for your help.

Robert

I do not have a good answer at the moment. I mostly use SD card for logging and yes the FAT file system can be a bit slow.

How often is the display updated in your app?

Quote:

---

Originally Posted by mackrackit

........ and yes the FAT file system can be a bit slow.

---

So, is the FAT32 (SDFSHC32) much faster than FAT (SDFS3)? I didn't go for the FAT32 because it takes a lot of space in the chip.

The display changes whenever a new screen is selected and hopefully the transition should be smooth. What do you think would be the best way to read the data from the card the way I need it?

Robert

Can not say exactly but FAT32 should be a little slower, larger sectors to read I guess.

Can you have the data on the card in CSV format instead of line by line? Be a little less reading.

Might post your code, maybe someone will see something?

Quote:

---

Originally Posted by mackrackit

Can not say exactly but FAT32 should be a little slower, larger sectors to read I guess.

---

Good guess! I did some research in google and FAT32 is slower than FAT. I think that I found a solution to the problem I'm having, but I have to test it before I post it here.

My code is just the SDFS code, the EasyHID code, and the code to drive the TFT display all mixed together. I'm just testing everything together and so far my program is working fine.

Robert

mackrackit,

I probably found a way to speed up the process of writing to the TFT display. If you write bytes to the SD card with values from 0 to 255, which is what I need

Code:

---

' Write to file
FOR I = 0 TO 255
    FAT_src[0] = I
    FAT_count = 1
    Gosub FSfwrite
    Serout2 PORTC.6, 84, [ "Write ", Dec FAT_error, $d, $a]
    If (FAT_error != 0) Then Stop
NEXT I

---

The program will sucessfully write 256 bytes to the txt file (a bunch of weird characters :)). Now, when you try to read them back, it will always give you wrong values between the byte 210th and the byte 250th. However, by using only 7 bits in every byte (from 0 to 127) I can make my display work pretty fast. Have you seen this happen to you? Any comments?

Now, for some strange reason my SD card is only working the first time after I reprogram the 18F4550 chip. The second time that I restart the chip I get the following errors for the FSinit

Code:

---

FAT_error = 6
SDC_status = 2
SDC_response = 63

---

I know what the FAT_error = 6 is (Init error), but the others I'm not sure what they are. Have you encounter these kind of errors before? Remember, it always works right after I reprogram the MCU. Any ideas?

Thank you for all your help

Robert

Not sure about the writing problem.

The errors.
Open SDFS and about 70 lines down it has the errors listed. #2 is "card not present", #63 I do not see.

But, to get around the problem I have this in my "SDINIT" routine.

Code:

---

IF (FAT_error = 6) THEN SD_MAIN

---

Here is a snippet from my code template.

Code:

---

'###############################################
 SD_MAIN:
    TOGGLE PORTD.7
    GOSUB SDINIT
    GOSUB SDFILENAME
    GOSUB SDOPEN_W
    GOSUB SD_WRITE
    GOSUB SDCLOSE
 RETURN      '##############################################################
SDINIT:
' FSInit initializes the card and reads all the preliminary information from it
Gosub FSInit
Serout2 PORTC.6, 16572, ["Init: ", Dec FAT_error, " ", Dec SDC_status, " ", Dec SDC_response, $d, $a]
    IF (FAT_error = 6) THEN SD_MAIN
    If (FAT_error != 0) Then Stop
    ' Display card directory
    Gosub FINDfirst        ' Find first file on card
    While (FAT_error = 0)
        Serout2 PORTC.6,16572, [Str FAT_FileName\11, $d, $a]
        Gosub FINDnext    ' Find next file on card
    Wend
    RETURN
 '################################################################

---

mackrackit,

Thank you for your help. I will try that as soon as I get out of work. I will keep you posted.

Robert

Speed between SDFS(FAT16) and SDFS32(FAT32) from the guy that modified SDFS for FAT32.

Quote:

---

Compared to SDFS, SDFS32 should access the SD cards at almost the same speed, maybe a few microseconds difference here and there.
The speed difference really comes into play when dealing with large files. Each sector read or write has to traverse the entire FAT cluster chain. The larger the file, the longer it takes to access a sector.
In other words, for example, writing 1 sector takes 1 ms. Appending a 2nd sector might take an extra 1.1ms, a third sector takes another 1.2ms, and so on.

Kinda like writing a book. Only instead of turning the page to add another page of writing, each time you want to add another page of something, you have to close the book, reopen the book, and re-read thru everything you've already written to find the end, before you can start adding stuff again.

---

Quote:

---

Originally Posted by mackrackit

Code:

---

'###############################################
 SD_MAIN:
    TOGGLE PORTD.7
    GOSUB SDINIT
    GOSUB SDFILENAME
    GOSUB SDOPEN_W
    GOSUB SD_WRITE
    GOSUB SDCLOSE
 RETURN      '##############################################################
SDINIT:
' FSInit initializes the card and reads all the preliminary information from it
Gosub FSInit
Serout2 PORTC.6, 16572, ["Init: ", Dec FAT_error, " ", Dec SDC_status, " ", Dec SDC_response, $d, $a]
    IF (FAT_error = 6) THEN SD_MAIN
    If (FAT_error != 0) Then Stop
    ' Display card directory
    Gosub FINDfirst        ' Find first file on card
    While (FAT_error = 0)
        Serout2 PORTC.6,16572, [Str FAT_FileName\11, $d, $a]
        Gosub FINDnext    ' Find next file on card
    Wend
    RETURN
 '################################################################

---

---

mackrackit,

Thank you. It worked. I wrote a loop

Code:

---

WHILE FAT_error = 6
    GOSUB FSInit
WEND

---

Robert

Dave,

I have my SDFS program working fine with PBP 2.50 thanks to your help :). Now, I think it's time for me to upgrade to PBP 2.60. My main concern :confused: with the upgrade is that I think (I hope I'm wrong) that half of my programs won't work with the new PBP version. I know from reading other threads that I will need to modify the USB part of my programs.

Now, what about SDFS; does it work with PBP 2.60? Or, do I need to make some changes or modifications to it? Have you tried SDFS with the new version?

Robert

PBP 2.60 and SDFS work fine together. I have not had to change anything.

I do plan to try to make use of the ARRAY WRITE feature of PBP 2.60 with the next SD project. If that works like I think it will tehn the basic routines will be much cleaner. Imagine changing the SD write array length on the fly!!!

Quote:

---

Originally Posted by mackrackit

PBP 2.60 and SDFS work fine together. I have not had to change anything.

---

Nice :D!! What about programming memory space? Is it true that PBP 2.60 compiles the program with less programming words in a more compact manner? SDFS takes many words of programming space. I think the FAT16 version takes around 12k words (I don't remember the exact number). Do you see any space utilization improvements with PBP 2.60?

Quote:

---

Originally Posted by mackrackit

I do plan to try to make use of the ARRAY WRITE feature of PBP 2.60 with the next SD project. If that works like I think it will tehn the basic routines will be much cleaner. Imagine changing the SD write array length on the fly!!!

---

Are you referring to the FAT_BUFFER_SIZE constant?

Code:

---

' Create constants and variables used by the FAT subroutines
FAT_BUFFER_SIZE        Con        MEDIA_SECTOR_SIZE

---

I replaced its value from 512 to 16 bytes in my program because it was killing my 18F4550 RAM memory. I left MEDIA_SECTOR_SIZE equal to 512 like it should be.

Robert

I do not really have a good comparison but looking at the LST files between to similar programs. I have 2.50 on one machine and 2.6 on another.

The PBP 2.5 code is using 23196 Bytes
The PBP 2.6 code is using 16220 Bytes

Both are with an 18F4550

This is the part I think ARRAY WRITE will be handy for

Code:

---

' Write to file
    FAT_src[0] = "X"
    FAT_src[1] = "B"
    FAT_src[2] = "C"
    FAT_count = 3
    Gosub FSfwrite

---

Quote:

---

Originally Posted by mackrackit

I do not really have a good comparison but looking at the LST files between to similar programs. I have 2.50 on one machine and 2.6 on another.

The PBP 2.5 code is using 23196 Bytes
The PBP 2.6 code is using 16220 Bytes

Both are with an 18F4550

---

Nice! Two similar programs and you got a reduction of 30% out of 23196 Bytes from your PBP 2.50 program. That sounds very encouraging for me to upgrade to PBP 2.60 :).

Robert