[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] String Utilities and Memories

From: E. Weddington
Subject: Re: [avr-gcc-list] String Utilities and Memories
Date: Tue, 06 Sep 2005 05:40:57 -0600
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

Chinmay Pendharkar wrote:

Hi everyone,

I am a new member of this list. I have just started using AVRs and have been developing on a mega32 for a few months. My question is on memory access for string operations. I realise that the two different memories have different methods of accessing, escpically for string operations. The programm memory(ROM) can be accessed using the Program Space String Utilities library from avr-libc. And the RAM can be accessed by the Strings library from avr-libc. Is there a way to access both types of memories using a singular function which will intelligently judge on which of the two libraries is to be used? This basically leads to the question whether the two memories share address space? Or, whether a we can tell which memory the pointer is pointing to by looking at its value(Because, if it is posible then it such an intelligent function can be created quite easily). If it is possible, are there any libraries which have implemented such function. My question arises, since I was trying to create a generic function to read an process certain strings.I want to make it generic enough to access strings from different memories.
Hope I am not asking something that has been asked before. Thanks and Nojy,

Unfortunately, yes, you are asking something that has been asked before. :-)

Yes, everyone wants exactly as you describe. What is required is patches written for GCC to understand different address spaces (i.e. Harvard Architecture). This is not a trivial thing to write. For that matter even the *C language itself* does not know about these. However, there is a draft update to the C language standard that adds this ability. IIRC, there is one person who is working on GCC about this feature, but it takes a while to implement.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]