|
|
View previous topic :: View next topic |
Author |
Message |
Hans Wedemeyer
Joined: 15 Sep 2003 Posts: 226
|
SD memory card code |
Posted: Tue Jun 01, 2004 9:54 pm |
|
|
NikkC pointed me to :-
"Progressive Resources LLC sell source code for AVR mcus for reading and writing SD/MMC and CompactFlash. "
http://www.prllc.com/prllc_homemainFlash.htm
I needed to get on with the project and purchased the SD Flash File code from PRLLC. It handles large SD cards OK.
Porting to CCS PIC C took a few hours.
Final results are good, I'm happy with it.
Code size depends on which feature are selected, if Read Only is all that you need the code is small.
Including all functions to manage directories and files does bloat the code, so unless you are using the newer PIC18 series with 64K ROM the code may be too large.
I reduced the HEX file by 600 bytes by using different syntax for some operations, and I know if I work at it, I should be able to reduce it even more.
I can't report on speed, because this project is running at 3.4MHz (SPI at less than 1MHz) so it would be unfair to comment on it. For my project speed is not an issue.
Compiling with the latest CCS PCWH V3.202
ROM used: 27802 bytes (42%)
RAM used: 1853 (48%) at main() level
2264 (59%) worst case
Includes 300 bytes for main() and these functions:
initialize_media();
fcreate( buf, 0);
fputc_(char, file1);
fopen(buf, MODE);
fgetc_(file1);
fclose(file1);
chdir(buf);
mkdir(buf);
rmdir(buf);
remove(buf);
read_Directory();
fquickformat();
PRLLC were fast to respond to a question I had. They notify about Updates free for a year. After that it's up to the user to download as needed.
It's a good product, could be smaller, and should be available for CCS C .... hint ! |
|
|
MGP
Joined: 11 Sep 2003 Posts: 57
|
|
Posted: Wed Jun 02, 2004 10:32 am |
|
|
Thanks for the Info, Hans!
I've been considering purchasing the same libraries and your experience makes the decision a lot easier. |
|
|
JY Guest
|
Re: SD memory card code |
Posted: Fri Jun 04, 2004 1:03 am |
|
|
Hans Wedemeyer wrote: | NikkC pointed me to :-
"Progressive Resources LLC sell source code for AVR mcus for reading and writing SD/MMC and CompactFlash. "
http://www.prllc.com/prllc_homemainFlash.htm
I needed to get on with the project and purchased the SD Flash File code from PRLLC. It handles large SD cards OK.
Porting to CCS PIC C took a few hours.
Final results are good, I'm happy with it.
Code size depends on which feature are selected, if Read Only is all that you need the code is small.
Including all functions to manage directories and files does bloat the code, so unless you are using the newer PIC18 series with 64K ROM the code may be too large.
I reduced the HEX file by 600 bytes by using different syntax for some operations, and I know if I work at it, I should be able to reduce it even more.
I can't report on speed, because this project is running at 3.4MHz (SPI at less than 1MHz) so it would be unfair to comment on it. For my project speed is not an issue.
Compiling with the latest CCS PCWH V3.202
ROM used: 27802 bytes (42%)
RAM used: 1853 (48%) at main() level
2264 (59%) worst case
Includes 300 bytes for main() and these functions:
initialize_media();
fcreate( buf, 0);
fputc_(char, file1);
fopen(buf, MODE);
fgetc_(file1);
fclose(file1);
chdir(buf);
mkdir(buf);
rmdir(buf);
remove(buf);
read_Directory();
fquickformat();
PRLLC were fast to respond to a question I had. They notify about Updates free for a year. After that it's up to the user to download as needed.
It's a good product, could be smaller, and should be available for CCS C .... hint ! |
I take it that porting the code to HiTech-C won't work because a stack-based memory model is required?
Is CCS stack-based or static-overlay? |
|
|
MGP
Joined: 11 Sep 2003 Posts: 57
|
|
Posted: Fri Jun 04, 2004 2:10 pm |
|
|
Should be easier to port to HiTech C, since it's ANSI compatible (or more than CCS anyway) and the source for the PRLLC library is written in ANSI C.
I'm looking at (potentially) porting their libraries to PIC, TI MSP430 and Rabbit 2000/3000. I'm expecting the most trouble from CCS, since it's the least ANSI compatible.
The libraries are written totally in C, so the underlying compiler architecture should not matter as far as functionality is concerned as long as the compiler supports all the functions used in the library. How the compiler implements the object code should not matter. |
|
|
Guest
|
Re: SD memory card code |
Posted: Fri Jun 04, 2004 3:45 pm |
|
|
JY wrote: |
I take it that porting the code to HiTech-C won't work because a stack-based memory model is required?
Is CCS stack-based or static-overlay? |
Should not be a problem at all, porting to CCS took a few hours. I posted a queastion to this forum and no one replied, so I asked CCS tcch support about malloc(), I posted the the answer here on this forum.
I have worked with Rabbit, and can't see any reason why it could not port to that platform also.
It's farily simple code, took a bit of reading to get the flow in my head, but after that and the malloc() issue it worked just fine.
I'd like to see the code size below 20K ...! It will take a bit of work to do that. |
|
|
User Guest
|
Hans is it for sale? |
Posted: Fri Jun 04, 2004 4:32 pm |
|
|
Or up for grabs |
|
|
Guest
|
|
|
ralphpage Guest
|
sd memory card |
Posted: Sun Jun 06, 2004 7:40 am |
|
|
Nice job with the port! & thanks for the link
I had been collating data to write the SD drivers myself, but there is little point when its already been done, and for a realistic price. I will be buying their code! Is there any way you could just post the port, or somehow post it with the supplier? I would be happy to thow a few bucks your way. There must be a method, as long as the supplier gets his proper asking price for the source...any ideas? |
|
|
Guest
|
Re: sd memory card |
Posted: Sun Jun 06, 2004 1:49 pm |
|
|
ralphpage wrote: | Nice job with the port! & thanks for the link
I had been collating data to write the SD drivers myself, but there is little point when its already been done, and for a realistic price. I will be buying their code! Is there any way you could just post the port, or somehow post it with the supplier? I would be happy to thow a few bucks your way. There must be a method, as long as the supplier gets his proper asking price for the source...any ideas? |
Please contact PRLCC and ask if they have plans to do a PIC CCS version any time soon.
It really is very easy to port. It will take a few hours reading the code and getting the flow understood. It will help if you prep. with understanding FAT12 and FAT16. It will alos help if you read the SD card data sheets.... SandDisk has one data sheet at teh web site, and a search of the Web, will reveal several sources for Data sheets.
In my port I dumped FAT12, do not need it and don't want it...
Then the grunt work of doing the changes, with lots of testing, and a few self inflicted wounds, will add another few hours.
Depends on how good you are, I could see a real hotshot i.e. someone who knows SD cards and FAT16. porting it in 2-3 hours.
That's not me, and I had a self inflicted problem that wasted best part of an afternoon, and a spent a few hours sliming down the code.
If I can do it anyone can...
Best regards
Hans W |
|
|
JY Guest
|
Let's try it again... |
Posted: Sat Jun 12, 2004 12:44 am |
|
|
MGP wrote: | Should be easier to port to HiTech C, since it's ANSI compatible (or more than CCS anyway) and the source for the PRLLC library is written in ANSI C.
I'm looking at (potentially) porting their libraries to PIC, TI MSP430 and Rabbit 2000/3000. I'm expecting the most trouble from CCS, since it's the least ANSI compatible.
The libraries are written totally in C, so the underlying compiler architecture should not matter as far as functionality is concerned as long as the compiler supports all the functions used in the library. How the compiler implements the object code should not matter. |
These is no 'heap' or malloc() support in HiTech... it uses a static overlay memory model... therefore, it will not port. Why do I ask... |
|
|
Guest
|
Re: Let's try it again... |
Posted: Sat Jun 12, 2004 10:24 am |
|
|
JY wrote: | These is no 'heap' or malloc() support in HiTech... it uses a static overlay memory model... therefore, it will not port. Why do I ask... |
Well as I said it will be easy to port.... If the HiTech (spit) compiler is so wimpy that it does not support malloc()... perhaps it should be renamed to LoTech ! sorry I could not resist :-) then simply allocate the memory needed at compile time.
There is only one place (per open file) where a large block of memory is needed.
So if LoTech supports unions and structs, then you could allocate a block of memory that can be reused for other things...
Anyway my first attempt to port to CCS I ran into the malloc() issue (see my other post somewhere on this forum) and I simply made an array and reused it.
Hope this helps...
Hans W |
|
|
Kieran
Joined: 28 Nov 2003 Posts: 39 Location: Essex UK
|
Please contact PRLCC and ask if they have plans to do a PIC |
Posted: Wed Jun 16, 2004 10:29 am |
|
|
Asked and got the following
Quote: |
We are currently working on a port for CCS and the PIC18F45x series. We hope to release it in the next few weeks.
|
|
|
|
Guest
|
|
Posted: Wed Apr 19, 2006 5:25 am |
|
|
Hi
Will the PRIIO SD write library (FAT 16 only) work on the
PIC16F876 or 16F873 chips?
Thank you
a. |
|
|
Mark
Joined: 07 Sep 2003 Posts: 2838 Location: Atlanta, GA
|
|
Posted: Wed Apr 19, 2006 6:14 am |
|
|
If you check out the website,
Quote: | The file system requires 10-30K of program space and approximately 1.5K of SRAM (depending on user configuration).
| so the short answer would be no. If you were just trying to read, then you might be able to make it work. For writing, you need more RAM (you could externally buffer this) and you wouldn't have much FLASH left to do anything. You'd be better off using an 18F. |
|
|
tavioman
Joined: 22 Feb 2006 Posts: 65
|
|
Posted: Wed Apr 19, 2006 6:29 am |
|
|
Why porting the code from AVR since there is FlashFileSD for PIC also from prllc? |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|