Structs mess up big time or i mess up big time :(

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello All,

Ive been trying to use structs for easy organising information, but it seems something goes terribly wr0ng when i add an Array to the struct.

Here's my struct:

typedef struct
{
BYTE jmpBoot[3];
char OEMName[8];
WORD BytesPerSec;
BYTE SecPerClus;
WORD RsvdSecCnt;
BYTE NumFATs;
WORD RootEntCnt;
WORD TotSec16;
BYTE Media;
WORD FATSz16;
WORD SecPerTrk;
WORD NumHeads;
DWORD HiddSec;
DWORD TotSec32;
DWORD FATSz32;
WORD ExtFlags;
WORD FSver;
DWORD RootClus;
WORD FSInfo;
WORD BkBootSec;
BYTE Reserved[12];
BYTE DrvNum;
BYTE Reserved1;
BYTE Bootsig;
DWORD VollID;
char VollLab[11];
char FilSysType[8];
} FAT32_BPBrec;

Here's my problem:
(copied from terminal output)
*** FAT INFO ***
Fat Size: 4017 FATSz32,chString,10);
s_printf("Fat Size: "); s_printf(chString); s_printf("\n");

utoa(BPB->BytesPerSec,chString,10);
s_printf("Sector Size: "); s_printf(chString); s_printf("\n");

utoa(BPB->SecPerClus*512,chString,10);
s_printf("Cluster Size: "); s_printf(chString); s_printf("\n");

ultoa(BPB->TotSec32,chString,10);
s_printf("Total SecCnt: "); s_printf(chString); s_printf("\n");

ultoa(BPB->RsvdSecCnt + (BPB->NumFATs * BPB->FATSz32),chString,10);
s_printf("Root Sector: "); s_printf(chString); s_printf("\n");

crap = (char*) &BPB->OEMName[0];
s_printf("OEM Name: "); s_printfstrict(crap,8); s_printf("\n");
crap = (char*) BPB->VollLab[0];
s_printf("Volume Label: "); s_printfstrict(crap,11); s_printf("\n");
s_printf("File System: "); s_printfstrict(BPB->FilSysType[0],8); s_printf("\n");
return(0);
}

Thank you in advance.
please flame if im stupid ok? :D

Cheers

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can't find the problem, but it seems like the arrays arent at the same address as the rest of the struct is.

HELP :'(

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

^^bump^^
:(

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

An array identifier is equal to the address of the first index of the array.

So this:
crap = (char*) &BPB->OEMName[0];

is equal to this:
crap = BPB->OEMName;

and is much easier to read.

So it makes this incorrect:
crap = (char*) BPB->VollLab[0];
s_printf("Volume Label: "); s_printfstrict(crap,11); s_printf("\n");
s_printf("File System: "); s_printfstrict(BPB->FilSysType[0],8); s_printf("\n");

It should be:
crap = BPB->VollLab;
s_printf("Volume Label: "); s_printfstrict(crap,11); s_printf("\n");
s_printf("File System: "); s_printfstrict(BPB->FilSysType,8); s_printf("\n");

However, it doesn't explain why you're getting garbage for OEMName (the others are incorrect, so you'll more than likely get garbage). You're using nonstandard functions s_printf and s_prointfstrict, so I can't comment if they are correct or not. You would have to post the code for those functions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry, crystal ball is on repair.

My gues is that your s_printf() is the root of your evil. ROM/RAM
confusion?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The time that ive spend before posting this post here is in the 10ish hours :(

sorry for being slacky with casts when i posted the question, but im sure ive already

<br />
tried crap = BPB->VollLab;<br />
and even s_printfstrict(BPB->VollLab, 8);<br />

Makes me wonder that s_printfstrict is the cause....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I guess its using SRAM only :D

Here's that strict print f routine for the 6963 LCD controller, ive included this header file into a lcd.c file that translates s_printfstrict into t6963_printfstrict... ive did that for being able to switc from controller type in later designs.

<br />
// Just print n-Number chars on the lcd.<br />
void t6963_printfstrict(char *chString, unsigned char nNumber)<br />
{<br />
	t6963_busycheck();</p>
<p>	while (nNumber>0)<br />
	{<br />
		output_ch_0(*chString);<br />
		t6963_putascii(*chString);<br />
		chString++;<br />
		nNumber--;<br />
	}<br />
}<br />

This will only read from the memory right?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's what joerg said,, the rom/ram mix up :(

DAMN ANSI C! and 'stu-pet mi'.

This problem also revealed that ALL strings used in my code are being copied to ram before usage? $.%.& EARTH?

I never wanted the strings to be copied from program memory to ram before they are being used.

How do I make a printf routine that reads from the flash rom ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avr-libc comes with a printf routine that can optionally use the
format string from ROM (function names have a _P appended). There's
currently no conversion specifier that allows reading arguments from
ROM although I once intented to implement this, but merely forgot
about that issue.

Use the PSTR() macro to create a string that lives directly in ROM.

See the documentation.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

oki ill read the docs :P

proejct status: I really frelled my code up this time. Back to [] 1

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

W00T !

Ive got it working.

My problem was actualy fairly simpel... but will cause a complete redo on the printing routines :D no buggy didn't like them anyway.

Thanx all

Here are the two types of printf statements im using, and working. do NOT pay any attention to the name of the second function. I was playing jojo with my keyboard.

//Print a memory string to the LCD.
void t6963_printfs(const char *chString, unsigned char ucLength)
{
char romcharacter;
// pgm_read_x_y reads a byte from the ROM-FLASH-FIXED memory.
while ((romcharacter = pgm_read_byte_near((unsigned short*)chString++)) && (ucLength > 0))
{
if ((romcharacter == 0x0a) || (romcharacter == 0x0d))
{
output_ch_0(0x0a); //home
output_ch_0(0x0d); //linefeed
ucT6963_TextLine++;
t6963_write16(T6963_VAL_TEXTHOME + (ucT6963_TextLine * T6963_VAL_TEXTAREA));
t6963_command(T6963_COM_ADDRESS);
}
else
{
output_ch_0(romcharacter);
t6963_putascii(romcharacter);
//PORTA = romcharacter;
ucLength--;
}
}
}

// This fratty routine reads a string from the internal ram or EXTERNAL RAM YES. Ive got some memory mapping differences between IO and MEMORY space, so im using memenable en lcdenable now. its in theorectily working order.! Cheers

void t6963_frat(char *pPtr)
{
char chCharacter;

do
{
memenable;
chCharacter = *pPtr++;
lcdenable;

if (chCharacter>0x10)
{
output_ch_0(chCharacter);
t6963_putascii(chCharacter);
}

} while (chCharacter != 0x00);
}