Lpc2000

Hello,

I have been doing assembly so long, that I am having trouble with
my C program.

I have records of 64 bytes in length, and the start of the record area
must start on an even 0x0100 boundary in ram.

In assembly, doing tests on the pointer for being in the middle of a
record, or to jump to the next record is a piece of cake.

assuming:
unsigned char data[2048]; is aligned on an even boundary
unsigned char *ptr;
#define RECORD_SIZE 64
#define INCREMENT_MASK 0xffc0
#define LINE_MASK 0x3f		//record_size -1

	ptr = data;
	....
the compiler hates:
	ptr &= INCREMENT_MASK;	// in case we are in the middle of a rec
but tolerates this:
	ptr += RECORD_SIZE;	//jump to the start of the next record

since the ram area is 64k, i would think this would work.

TIA

Glen

Which compiler are you using?

Try this instead:

ptr = (unsigned char *)(((unsigned long)ptr) & 0xFFC0);

that's because when dealing with pointers, the + operator increments by the 
size of the object being pointed to.

unsigned long ptr;

ptr++; adds 4 to the value of pointer.

casting the pointer to a number allows you to do your binary manipulation, 
then cast it back to a pointer.

For you alignment question, check this out:

http://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html

-- Sean

At 19:06 2/6/2006, you wrote:

>Hello,
>
>I have been doing assembly so long, that I am having trouble with
>my C program.
>
>I have records of 64 bytes in length, and the start of the record area
>must start on an even 0x0100 boundary in ram.
>
>In assembly, doing tests on the pointer for being in the middle of a
>record, or to jump to the next record is a piece of cake.
>
>assuming:
>unsigned char data[2048]; is aligned on an even boundary
>unsigned char *ptr;
>#define RECORD_SIZE 64
>#define INCREMENT_MASK 0xffc0
>#define LINE_MASK 0x3f            //record_size -1
>
>       ptr = data;
>       ....
>the compiler hates:
>       ptr &= INCREMENT_MASK;      // in case we are in the middle of a rec
>but tolerates this:
>       ptr += RECORD_SIZE;      //jump to the start of the next record
>
>since the ram area is 64k, i would think this would work.
>
>TIA
>
>Glen
>
>
>
>
>
>SPONSORED LINKS
><http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=mfaAujKZXA2Z_vxre9sGnQ>Microcontrollers 
><http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=9jjd2D3GOLIESVQssLmLsA>Microprocessor 
><http://groups.yahoo.com/gads?t=ms&k=Intel+microprocessors&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=OMnZuqMZX95mgutt4B-tDw>Intel 
>microprocessors
><http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=Malspbd0T4Rq3M4Q0nHrfw>Pic 
>microcontrollers
>
>
>----------
>YAHOO! GROUPS LINKS
>
>    *  Visit your group "<http://groups.yahoo.com/group/lpc2000>lpc2000" 
> on the web.
>    *
>    *  To unsubscribe from this group, send an email to:
>    * 
> <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>lpc2000-unsubscribe@yahoogroups.com 
>
>    *
>    *  Your use of Yahoo! Groups is subject to the 
> <http://docs.yahoo.com/info/terms/>Yahoo! Terms of Service.
>
>
>----------

G B wrote:

>Hello,
>
>I have been doing assembly so long, that I am having trouble with
>my C program.
>
>I have records of 64 bytes in length, and the start of the record area
>must start on an even 0x0100 boundary in ram.
>
>  
>
Depends on the dev system you are using,  I suspect that the modified 
Keil compiler / linker will let you assign a hard address to a function 
with their 'AT' directive.  However, us lessor folk have to be content 
with simply editing the linker script and manually entering where that 
file is to be placed.

Something like this would take my pll_start.o and place it onto a 256 
byte boundry:

============= begin LPC2138ROM.LD ==================
SECTIONS
{
  /* first section is .text which is used for code */
  .text :
  {
    *crt0.o (.text)            /* Startup code */
    . = ALIGN(256);
    system/pll_start.o (.text)
    *(.text)                   /* remaining code */
    *(.rodata)                 /* read-only data (constants) */
    *(.rodata*)
    *(.glue_7)
    *(.glue_7t)
  } > ROM

  . = ALIGN(4);
  _etext = . ;
================== snip ================

The downside is that the gap between crt0.o and the start of the boundry 
is filled will empty space, the linker doesn't recover that area.

Regards,


TomW



-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------