MicroSD Cards and SDFS

[rsocor01]

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

4388

[mackrackit]

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.

[rsocor01]

mackrackit,

Thank you for your response.


SD cards have 9 pads.

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

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.

43994400

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


Robert

[Normnet]

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

Norm

[mackrackit]

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.

[rsocor01]

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

[mackrackit]

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


SD_WE_TRIS = 1
And all occurrences of this


If (SD_WE) Then
FAT_error = CE_WRITE_PROTECTED
Return ' Return Byte FAT_error.
Endif
The PIC® pin assignments will look something like this


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


SDC_UseHardSPI = FALSE

If you run into problems let us know.

[rsocor01]

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

[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?

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

[Normnet]

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

[Normnet]

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

[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.

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

[rsocor01]

Hi,

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


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/product_info.php?products_id=544


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


' 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


ABC

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


A
B
C

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

Robert

[mackrackit]

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




' 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

[rsocor01]

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


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/showthread.php?t=8340&highlight=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


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

[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.

[rsocor01]

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

[mackrackit]

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 :)

[rsocor01]

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

[rsocor01]

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


203
37
92

When you read these values with SDFS you get something like


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?


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

[mackrackit]

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?

[rsocor01]

........ 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

[mackrackit]

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?

[rsocor01]

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

[rsocor01]

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


' 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


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

[mackrackit]

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.


IF (FAT_error = 6) THEN SD_MAIN
Here is a snippet from my code template.


'###############################################
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
'################################################# ###############

[rsocor01]

mackrackit,

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

Robert

[mackrackit]

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


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.

[rsocor01]

'###############################################
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


WHILE FAT_error = 6
GOSUB FSInit
WEND

Robert

[rsocor01]

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

[mackrackit]

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!!!

[rsocor01]

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?



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?


' 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

[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

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

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

[rsocor01]

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