Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
02/09/06 23:19
Read: times


 
#109657 - Grrr
Responding to: ???'s previous message
Andy Neil said:
Billy Fairhurst said:
In this example they do the following observation:
"The example program writes stuff into memory ONLY for demonstration purposes. You should not use this method of writing into memory in structured, high-level programming languages."
QUESTION: if thisway of writing works, whats wrong with using it?

Here's the link: http://www.keil.com/download/docs/187.asp?bhcp=1

The example demostrates the fact that you can write to all the 8051's memory areas from C51.

What they're saying is that in structured, high-level programming you wouldn't go writing direct to hard-coded addresses - you would use named variables instead.

Now I've read the abstract and taken a hard look at the code. I don't particularly like the example, and here is why.

First, these are named variables. However, the author chose to locate them absolutely using the _at_ keyword so as to make them very easy for a novice to find in the memory window of the Keil simulator. Of course, absolute location should not be used in a real application for this reason alone, and that leaves me wondering if it wouldn't have been a better idea to omit them from the example. The user could always find the location of the destination buffers in the simulator anyway.

Secondly, strncpy() would probably be a more appropriate function to use in these type of situation. When copying buffers in general, string or otherwise, I think it's a good idea to always copy the lesser of the source length and destination length. This prevents accidental overruns (and truncates instead), while simultaneously avoiding copying unneeded garbage into the destination buffer beyond the end of the source.

Third, in none of the four examples is the null terminator actually copied to the destination buffer, as there is no space for it in any of the destination buffers. Worse, since the simulator starts out with zeroed memory, the user is lulled into thinking there is no problem with this behavior.

In summary, sample code should not be written like this unless its purpose is to illustrate bad practices. If the latter is true, the intentional use of the bad practices should explicitly documented in the comments.

In a slightly unrelated matter, absolute variable location, either via the _at_ keyword (or more poorly, via hardcoded literal addresses or preprocessor macros which expand into them) has a few notable applications:

1. Memory-mapped I/O. Creating well-named absolutely located variables for registers of peripherals helps promote clean driver code. These, of course, should be declared volatile to prevent the compiler from optimizing out any accesses generated to such addresses.

2. Long-term non-volatile storage. Certain types of data stored in NVRAM or other persistent storage should be absolutely located. This might include user configuration data (like an IP address and user preferences), log data, and so on. The idea here is that the addresses will remain constant with progressive firmware builds, making it easy for new versions of firmware to find important data left behind by its predecessors. In addition, this can be very useful for forensic analysis in which the nonvolatile device is removed from the target and analyzed in the lab using some other apparatus. When absolute addressing is used in this situation, a quick look at a header file is all that is necessary to learn where data of interest is located.

A desire simply to store some variables in a regular, slower external memory, however, does not justify absolute location. A user defined memory class would be a better choice, as it does not burden the user with maintaining the addresses and would not thwart potentially effective memory overlaying done by the toolchain.

--Sasha Jevtic

List of 25 messages in thread
TopicAuthorDate
storing serial data in memory            01/01/70 00:00      
   after 100.000 writes it dies            01/01/70 00:00      
   if internal memory is the problem            01/01/70 00:00      
      Battery backed NVRAM from Dallas            01/01/70 00:00      
         he seems not to need permanent storage            01/01/70 00:00      
            not permanent storage            01/01/70 00:00      
               if the problem is pin shortage            01/01/70 00:00      
                  PCR8750            01/01/70 00:00      
   Keil example-- writing to 8051 mem----            01/01/70 00:00      
      nope            01/01/70 00:00      
         Not quite...            01/01/70 00:00      
      memcpy()            01/01/70 00:00      
         yes, ANSI, but not really '51            01/01/70 00:00      
            Rubbish!            01/01/70 00:00      
               Rubbish? I said "on the edge"            01/01/70 00:00      
         Not quite...            01/01/70 00:00      
            Very clever            01/01/70 00:00      
               indeed, if you have the time            01/01/70 00:00      
                  Do you know that?            01/01/70 00:00      
                     there is a large advantage when reading            01/01/70 00:00      
                        1 - 4 byte types supported            01/01/70 00:00      
         example link            01/01/70 00:00      
      Demo only            01/01/70 00:00      
         Grrr            01/01/70 00:00      
   i think this got a bit off track            01/01/70 00:00      

Back to Subject List