SD CARD wants

[Ian Rogers]

Jason... persevere.. the pic18f4682 has 80k code it WILL fit in here

 

[AtomSoft]

awesome! i dont have that pic on had tho but will order it asap

 

[Ian Rogers]

Before you order! There is also the pic18f4685 with 96k of code.

 

[AtomSoft]

Got one better .. cause its cheaper and will do

PIC18LF46J11 OR PIC18LF26J11

Has 64KB Flash, 4KB RAM

And only $4

the 26J11 comes in: SPDIP/SOIC/SSOP/QFN
the 46J11 comes in: QFN/TQFP

The 26J11 will be my choice since I/O pins isnt a issue

Also good to have something that runs off of 3.3v LF part because then you only need a 3.3v regulator

 

[AtomSoft]

Thanks for the info and help Ian... got to love this forum!

 

[AtomSoft]

Im going to order 2 of each package: SOIC, SSOP, QFN the PDIP isnt in stock at mouser so cant order it. But I can make a adapter for SOIC in like 15 min from plan to pcb so not a issue

SCRATCH THAT... ill order from digikey they also have the DIP so ill order 2 of : DIP, SOIC,QFN...

 

[emrez]

DATABANK NAME=gpr1 START=0x100 END=0x1FF
line change ;
DATABANK NAME=udata_main START=0x100 END=0x6FF // big data. ok
//DATABANK NAME=gpr2 START=0x200 END=0x2FF
.
.
.
//DATABANK NAME=gpr6

Now yet another error:

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

 

[AtomSoft]

thanks ill try that out now. I hate linker files.. they should have never made them heh... PIC are the only MCU i know with linker files and i have tested a ton of MCUs heh

Oh yeah, i just ordered the parts.. but since its sunday wont ship til tomorrow

 

[AtomSoft]

perfect first post "emrez" works like a charm

 

[AtomSoft]

OK i want to get my COMMENT scheme going.. is this understandable ?

/*
	READ: This command reads a file. 
	Parameters include:
	READ SSSS C F...

	SSSS = Seek Location, where to start when getting data (4 BYTES + SPACE)
	C = Count of bytes to return, MAX 128 (1 BYTE + SPACE)
	F... = FILE NAME (UP TO 120 BYTES + SPACE)

	EXAMPLE: READ 0000 10 HELLO.TXT

	The above example will return the first 10 bytes in the file HELLO.TXT
*/

 

[Sceadwian]

Perfectly understandable to me.

 

[AtomSoft]

ok cool. Had to ensure since i wont be making a PDF for this most likely...

 

[AtomSoft]

How about this one : https://pastebin.com/QRj3LD26

Is the layout ok

 

[AtomSoft]

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?

Ok so like a FIND function... and it will return a SIMPLE 0x01 if there and a 0x00 if not

 

[AtomSoft]

Ok so far i have:

LIST ALL FILES AND DIRECTORIES === DONE!
READ A FILE ================== DONE!
WRITE TO A FILE =============== NOT DONE!
APPEND TO A FILE ============== NOT DONE!
LIST FILES ONLY =============== DONE!
LIST DIR ONLY ================ DONE!
FIND A FILE ================== DONE!
FIND A DIR =================== DONE!

 

[Sceadwian]

I personally wouldn't notate each individual function like that at the function location, that should probably be done at the begging of the file, basically as soon as you open it up you see all the instructions of use and then you just use simple comments at the function level to refer to the note in the comments section, that way your comment section and code section are separate. Notation of individual functions should be kept to a minim as most C code is pretty readable, if you're doing anything you think is a little 'tricky' to understand in the specific function toss a comment in on it.

I think the find function should be a little more sophisticated, but that's only if you're interested in adding additional functionality at the expensive of the time it'll take you to code it, I think you should get your write/append done before you do anything else. There should be two search modes, one that will search for a filename and will return the full directory path of each instance of that filename searching the entire FAT system, and one that works as you describe to simply return a yes/no if there is a file in a specific location.

 

[AtomSoft]

Ah, i see I like the comments in line ... but people can remove or rearrange if they want. Since this is free for all im not going to kill myself heh.. but ill add that FIND FILE IN FAT [FFIF] function to search through it all..

Ill create the WRITE FILE and APPEND FILE first. I have been putting it off but dont know why ? i guess reading was more important to me at first

 

[AtomSoft]

Ah i thought about it and ill create a PDF to include with this. But just mainly will contain the HOW TO of the commands... All will like it more

 

[Sceadwian]

Writing is FAR more difficult and appending no easier. I've seen many file system implementations that have bugs or stopped at write functions because they look at it and went 'you need me to do WHAT?' Fat is easier than something like NTFS

 

[AtomSoft]

heh... yeah i got stuck so far but not at writing at parsing

Data would come in like

WRIT C FILENAME \R DATA \N

So if you send:

WRIT 0x03 HELLO.TXT \R HI! \N

It should make or rewrite a HELLO.TXT and PLACE "HI!" inside of it