SD CARD wants

Status
Not open for further replies.

AtomSoft

Well-Known Member
THIS PIC WILL BE CONTROLLED FROM ANOTHER MCU meaning its a SLAVE so you can use a smaller PIC or ARM or what ever you want that has UART available to control a SD card. Kind of like a DOSonCHIP... they canceled it tho.

Im using a 18F4620 since its perfect heh... I wanted to know what kind of features should be added

Get directory listing
, Returns 2 byte count then Names followed by a CR byte
Read data from a file, SEND: Filename,Start,Len) returns BYTES and CR byte
Write data to a file SEND: Filename,Len returns PASS or FAIL
Append data to a file (Filename,Start,Len) same as above.

I know i can do this without issue just asking for extra advice on functions you think might be useful.
 
It would be easiest to check what other types of SD access chips like this supported. They have datasheets available for them. Or even check what functions FAT file system libraries give you and replicate those.

This is the V1 datasheet for DOSonChip. They went to a binary command system on V2.
https://www.electro-tech-online.com/custompdfs/2011/07/CD17B10_User_Guide_0v1.pdf

uALFAT:
https://www.electro-tech-online.com/custompdfs/2011/07/uALFAT20Manual.pdf

USBWiz:
https://www.electro-tech-online.com/custompdfs/2011/07/USBwiz20Library20Manual.pdf
 
Last edited:
The raw directory listing is good, but a search function would be valuable. The average user doesn't care what the entire contents of a directory are, just if a certain file is there or not. This can be coded by hand of course from the raw directory listing, but an inbuilt function to do this would make it FAR more useful to newbs.

Does this support both fat16 and fat32?
 
Thanks for both the inputs

Too many functions Mark i plan to make this simpler not that heavy. When REV 1 is done i will release full SOURCE. This isnt a money thing so its free for ALL!!! based on a 18F4620 but can be modded of course. So far i have the SD card working well on it and UART using interrupts is so cool!

Sceadwian thats a great idea! i can add that no problem im sure. You can use FAT16/FAT32 and SDHC compatible! Will be cool to see what other people add. Im working on some functions now.. the main stuff and adding comments as i go along so the code isnt too scary. I hope this will be a useful thing for the community

One thing i would love to try and add is a simple FORMAT option. Will look into boot sectors and such. I will have 2 options a QUICK and a FULL. Quick will just act like its empty ... the normal windows way and full will clear out everything! it will open every sector and erase whats not needed... but this is still just a thought. Id have to learn a bit more..

The REV 1 should be done by MONDAY tops!
 
Last edited:
They been using MINIX format for SD cards over at Jal it makes better sense it has a lot faster read write times then fat
 
wanted something compatible with windows as well. FAT32 can go to windows/linux and mac i assume.
 
OMG the way PIC handles memory sucks!

I cant seem to send one string to another funtion.

This is in my MAIN function:
Code:
	if(strncmp(CMD[LIST],RX_CMD,4) == 0)	//Send out directory listing
	{
		res = scan_files(RX_ARG);
		return;
	}

Now i know for a fact that RX_ARG is 128 bytes long and containes "/" only the rest are zeros. Why in the world when i pass it to
Code:
scan_files(RX_ARG);

It says its 0x0101

This is the function:
Code:
FRESULT scan_files (char* path);

I dont have this issue with the EXACT same ARM code so i assume its a stupid PIC thing... Can someone pls help me out... thanks
 

Attachments

  • ScreenA.jpg
    166.6 KB · Views: 164
Last edited:
It was made for slow Cpu 8 and 16 And i no for fact using MINIX on some old hardware the disk writes are faster them fat 16 or 32
I just started looking into this when they added it to Jal libs. Jal has Hd support and SD using the Minix file sys. now and it looks real good.


With Fat there a lot of fat to read to find the data you want
 
MINIX on some old hardware the disk writes are faster them fat 16 or 32
What does that have to do with a modern micro controller running on flash memory? The slowness you're talking about may have been a physical limitation of the older hardware.
 
Ok figured it was showing memory address now it has the correct one at least

EDIT: Also i forgot

Code:
#include <stdio.h>

for the sprintf
 
Last edited:
Here is a update so far:

Commands:
LIST - LIST ALL FILES AND DIRECTORY WITH A COUNT
READ - WORKING ON IT
WRITE - WORKING ON IT
APPEND - WORKING ON IT
LIST_FILES - LIST FILES ONLY WITH COUNT
LIST_DIRS - LIST DIRs ONLY WITH COUNT

It will send the count first then the data.

THE READ,WRITE,APPEND will be worked on now... then ill add more commands.

Also i have 1 pin which sets UART speed. Either 9600 or 19200... might add more later.. not sure
 
Last edited:
Ok working on READ right now...

You send the word READ with a SPACE at the end
Then 2 bytes for the position to start at MSB first with a SPACE at the end
You then send the filename with a LF at the end.

****the buffer is 128 btyes so it will try to read 128 bytes if it cannot because of end of file it will stop and send the count of bytes read and then the actual data.

It will then return 2 bytes MSB first for the count of bytes read ...
Then it will return the actual DATA READ from file.

If your original MCU doesnt have space for all 128 bytes simple skip them ...
 
CRAP ! i just noticed i was using the PETITE FS which doesnt support creating files. I will have to rewrite a couple things to use the normal FATFS heh but shouldnt take too long
 
Can someone help me out here. Running into a Syntax error and driving me crazy!!!! got a huge headache now... here is complete code so far. I dont recommend using it yet still working on a ton of things
 

Attachments

  • SD4620.zip
    63.3 KB · Views: 149
Jason... Weird that!! send_cmd(); accepts CMD10 as an argument but rejects CMD9 if I change CMD9 to just 9 it compiles
 
THANK YOU it was that

Code:
#define CMD9   (9)			/* SEND_CSD */zz
#define CMD10  (10)			/* SEND_CID */

NOTICE The ZZ
 
Now yet another error:

Code:
MPLINK 4.39, Linker
Device Database Version 1.1
Copyright (c) 1998-2011 Microchip Technology Inc.
Error - section '.udata_main.o' can not fit the section. Section '.udata_main.o' length=0x0000044e
Errors    : 1

This is why i switched to ARM heh so many errors
 
Im about to abandon this code and transfer to ARM.. I will most likely use the LPC1114, its Faster, cheaper(half price)

It has half the memory but double the ram ... ill check for another MCU that will also qualify. The posted code is the final code so far. Just remove the zz and it should give you the udata issue.

Kind of dont want to use LPC2103 mainly because requires 1.8v for core and 3.3v for logic... to many extra external stuff
 
Last edited:
Status
Not open for further replies.
Cookies are required to use this site. You must accept them to continue using the site. Learn more…