??? 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 |
Topic | Author | Date |
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 |