 |
 |
| View previous topic :: View next topic |
| Author |
Message |
neochrome32
Joined: 09 Jun 2013
Posts: 153
|
| sizeof is wrong? |
 Posted: Tue Jun 25, 2013 9:50 pm |
 |
|
well not sure what happened, was locked?? profanity?
i cant see it.. anyways..
STILL having the problem that the structures are all wrong?
| Code: |
typedef struct _diskinforec{
char_t hJumpCode[3];
char_t OEMName[8];
uint16_t hBytesPerSector;
char_t bSectorsPerCluster;
uint16_t Reserved1;
char_t FATCopies;
uint16_t hMaxRootEntries;
uint16_t hSectors;
char_t Descriptor;
uint16_t holdSectorsPerFat;
uint16_t hSectorsPerTrack;
uint16_t hNumberofHeads;
uint32_t hNumberofHidden;
uint32_t hNumberofSectors;
uint32_t hSectorsPerFat;
uint16_t hFlags;
uint16_t hFAT32Version;
uint32_t hRootStartCluster;
} diskinforec;
typedef struct {
uint32_t MMCAddress;
uint32_t FATstartidx;
uint32_t gStartSector;
uint32_t gFirstDataSector;
uint16_t gDirEntryIdx;
uint32_t gDirEntrySector;
uint16_t gFirstEmptyDirEntry;
uint32_t gFirstDirEntryCluster;
} FAT32Vars;
typedef struct _direntry{
char_t sName[8];
char_t spam[3];
char_t bAttr;
char_t bReserved[8];
uint16_t hClusterH;
uint16_t hTime;
uint16_t hDate;
uint16_t hCluster;
uint32_t wSize;
} DIR;
typedef struct {
char_t IOpuffer[MMCSD_MAX_BLOCK_SIZE];
DIR DirEntry;
uint32_t CurrentCluster;
uint16_t posinsector;
uint32_t position;
uint32_t dirSector;
uint16_t dirIdx;
char_t mode;
char_t Free;
} FILE;
typedef struct {
uint16_t tm_year;
char_t tm_mon;
char_t tm_day;
char_t tm_mday;
char_t tm_hour;
char_t tm_min;
char_t tm_sec;
} TimeRecord;
TimeRecord myrec; // this variable is updated in regular intervals in DoIdle()
uint32_t FATTable[128];
uint32_t gFirstEmptyCluster;
FAT32Vars gFAT32Vars;
FILE gFiles[MAXFILES];
diskinforec DiskInfo;
#byte gStartSectorL = gFAT32Vars+8
#byte gStartSectorH = gFAT32Vars+9
#byte gStartSectorHL = gFAT32Vars+10
#define END_OF_DIR 17
#define DIRENTRYS_PER_SECTOR 16
#define CHARACTERS_IN_LONG_FILENAMES 13
|
im getting the wrong sizes out.
on the 8BIT processor the size of this is 48
on the 16bit, im getting 52, now i understand that this chip is 16bit wide, so the structures are showing up ok
if i do this...
| Code: |
void MoveToDiscInfo(){
Diskinfo.hJumpCode[0] = gFiles[MAXFILES-1].IOpuffer[0];
Diskinfo.hJumpCode[1] = gFiles[MAXFILES-1].IOpuffer[1];
Diskinfo.hJumpCode[2] = gFiles[MAXFILES-1].IOpuffer[2];
Diskinfo.OEMName[0] = gFiles[MAXFILES-1].IOpuffer[3];
Diskinfo.OEMName[1] = gFiles[MAXFILES-1].IOpuffer[4];
Diskinfo.OEMName[2] = gFiles[MAXFILES-1].IOpuffer[5];
Diskinfo.OEMName[3] = gFiles[MAXFILES-1].IOpuffer[6];
Diskinfo.OEMName[4] = gFiles[MAXFILES-1].IOpuffer[7];
Diskinfo.OEMName[5] = gFiles[MAXFILES-1].IOpuffer[8];
Diskinfo.OEMName[6] = gFiles[MAXFILES-1].IOpuffer[9];
Diskinfo.OEMName[7] = gFiles[MAXFILES-1].IOpuffer[10];
Diskinfo.hBytesPerSector = make16(gFiles[MAXFILES-1].IOpuffer[12],gFiles[MAXFILES-1].IOpuffer[11]);
Diskinfo.bSectorsPerCluster = gFiles[MAXFILES-1].IOpuffer[13];
Diskinfo.Reserved1 = make16(gFiles[MAXFILES-1].IOpuffer[15],gFiles[MAXFILES-1].IOpuffer[14]);
Diskinfo.FATCopies = gFiles[MAXFILES-1].IOpuffer[16];
Diskinfo.hMaxRootEntries = make16(gFiles[MAXFILES-1].IOpuffer[18],gFiles[MAXFILES-1].IOpuffer[17]);
Diskinfo.hSectors = make16(gFiles[MAXFILES-1].IOpuffer[20],gFiles[MAXFILES-1].IOpuffer[19]);
Diskinfo.Descriptor = gFiles[MAXFILES-1].IOpuffer[21];
Diskinfo.holdSectorsPerFat = make16(gFiles[MAXFILES-1].IOpuffer[23],gFiles[MAXFILES-1].IOpuffer[22]);
Diskinfo.hSectorsPerTrack = make16(gFiles[MAXFILES-1].IOpuffer[25],gFiles[MAXFILES-1].IOpuffer[24]);
Diskinfo.hNumberofHeads = make16(gFiles[MAXFILES-1].IOpuffer[27],gFiles[MAXFILES-1].IOpuffer[26]);
Diskinfo.hNumberofHidden = make32(gFiles[MAXFILES-1].IOpuffer[31], gFiles[MAXFILES-1].IOpuffer[30], gFiles[MAXFILES-1].IOpuffer[29], gFiles[MAXFILES-1].IOpuffer[28]);
Diskinfo.hNumberofSectors = make32(gFiles[MAXFILES-1].IOpuffer[35], gFiles[MAXFILES-1].IOpuffer[34], gFiles[MAXFILES-1].IOpuffer[33], gFiles[MAXFILES-1].IOpuffer[32]);
Diskinfo.hSectorsPerFat = make32(gFiles[MAXFILES-1].IOpuffer[39], gFiles[MAXFILES-1].IOpuffer[38], gFiles[MAXFILES-1].IOpuffer[37], gFiles[MAXFILES-1].IOpuffer[36]);
Diskinfo.hFlags = make16(gFiles[MAXFILES-1].IOpuffer[41],gFiles[MAXFILES-1].IOpuffer[40]);
Diskinfo.hFAT32Version = make16(gFiles[MAXFILES-1].IOpuffer[43],gFiles[MAXFILES-1].IOpuffer[42]);
Diskinfo.hRootStartCluster = make32(gFiles[MAXFILES-1].IOpuffer[47], gFiles[MAXFILES-1].IOpuffer[46], gFiles[MAXFILES-1].IOpuffer[45], gFiles[MAXFILES-1].IOpuffer[44]);
}
|
its a shocking way of doing this, but this puts the data in the right place
the code
memcpy(&diskinfo, gFiles[MAXFILES-1].IOPuffer,sizeof(diskinfo));
it mismatches, and i cant figure out why...
id rather use memcpy ..
-- to the moderator -- last topic was locked? but not sure where the profanity was, i meant no disrespect here :( |
|
 |
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Tue Jun 25, 2013 11:56 pm |
|
|
The problem is in the definition of the structure diskinforec (DOS FAT BPB), it can't work with PIC24,
or more generally with any processor that requires words aligned to even memory addresses. The compiler will insert
fill bytes to enforce correct alignment of words, unfortunately breaking the integrity of the BPB structure. You would
know if you ever looked into the assembly code.
Many C compilers have a feature to define a structure like the FAT BPB with a packed attribute which allows
to align words at odd addresses. But then, a direct word access would cause an address error trap. So in
any case, some special handling is required.
Technically, it's best to replace the definition of misaligned words by an uint8[2] type.
An access it through a _copyword() macro. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19538
|
|
| Posted: Wed Jun 26, 2013 12:45 am |
|
|
On the 'locking', some of the variable names you were (are still in one case) using, have got picked up by the filtering. Sometimes it is 'thick', and sees 'rude words' in things that are perfectly normal....
Note the variable names replaced by '[spam]' in the original post.
On the problem it is one of those things where working with the 'bigger' PIC's gets harder. Normally for stuff used internally it is not a problem, with the compiler just inserting extra alignment bytes, but where you want to force a particular alignment, to work in the outside world, it can get very annoying.
I've in the past just setup a single 'byte' array the size wanted, and used #define to give names to the data locations, copying these as needed to local variables.
Bes Wishes |
|
|
neochrome32
Joined: 09 Jun 2013
Posts: 153
|
|
| Posted: Wed Jun 26, 2013 7:54 am |
|
|
Thanks guys, i thought this was going off,
My Assembly isn't great so i didn't notice that problem...
it sort of pads out the structs...
time to rethink i think,
i got FAT to read and clusters ok enough now... but it still won't work on the writing/creating of files...
thanks again  |
|
|
|
|
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
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
