Lpc2000

David Hawkins wrote:

>Hey Tom,
>
>  
>
>>>The only time I can ever think of needed to force a 
>>>particular code at a specific address is;
>>>
>>>      
>>>
>>Just because you know a couple of things doesn't mean that you 
>>know it all.
>>
>>    
>>
>
>Sorry, wasn't trying to sound like I knew it all, on
>the contrary, I'm learning too, so wanted to know why,
>given that I knew of two possible options.
>
>So, thanks for responding :)
>
>  
>
It was my problem, not yours.  Thank you anyway.

>>If you recognized the "AT" directive then you would have 
>>understood that the question was regard to locating a section
>>to a hard address. Typically this is done to describe where
>>something such as a binary image produced by something other
>>than the compiler.  Or, it is done to physically locate entire
>>Sections of code into external memory devices.
>>
>>Ok?
>>    
>>
>
>Yep, I understand now that Michel responded with a more detailed
>response and showed that he wanted to locate a function at a
>specific address. His original email was vague on the 'why',
>which was why I wrote my response.
>
>Since you are familiar with linker scripts, perhaps you can answer
>a question for me :)
>
>  
>
The code examples that you mentioned before are appropriate for the 
high-level referencing of objects, referencing where they lie in the 
memory map.  Linker scripts are for the physical placement of objects 
within that memory map, the "ordering" of the memory.

IIRC, the "AT" was used by Microsoft in their linkers to describe where 
fixed sections of memory resided.  However, you could not fill that 
region with code though, it was more of a template, a concept more than 
physically usefull.

While most of the Philips LPC2xxx ARM chips have a simple memory 
architecture, other ARM systems don't.  With "classic" controller 
systems, you have external RAM, ROM and hardware connected to chip 
selects.  The programmed value of the chip select regions along with the 
linker script would be how you define where those objects resided and 
gain access to them.  Then you could use the typedef approach to further 
refine that objects description and assign an address which points to 
that object in C / Assembler.

By use of the linker, you can also describe a region of memory within 
Flash / RAM as a kind of "hole", or protected area.  As in "don't put 
anything here".  Then, using objcopy, you can pull out the individual 
Sections (.text, .data, etc) from the linked image and put them into 
seperate files.  Then those seperate files can be physically combined 
(cat'ed together) to build a ROM-able image.

We did this with the uClinux kernel, the kernel was ORG'ed to run at 
0000h in RAM, and the file system was at the top of the RAM (end).  In a 
case such as that, you could have a huge distance between the RAM memory 
address and that of the filesystem.  The gap between the end of the 
kernel and start of the filesystem was the Heap.  This is what the 
Absolute Linking with GCC doc described, how to deal with describing how 
to logically place the two parts into the final image.  As the final 
image was ELF, not BINARY, the hole did not take up space, but we need 
to get that ELF file into ROM / Compact Flash.  This is where objcopy 
came in.

For the LPC2000 series, creating such a "hole" is still an advantage.   
The LPC2000 will execute code from RAM, you could describe an area of 
the SRAM which is an area where you could pull executable code in from 
an MMC / Compact Flash and execute it.  For example, if you only need 
your system configuration menus / user interactive setup code 
infrequently, why put it in the valuable Flash area.  You can simply 
pull it in from the Flash Drive, execute it, and throw it away when you 
are done!

Again, I apologize for my short temper.  :-/


Regards,

TomW


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