We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
hi,, how do i check whether my ram is neumann memory ?? write a program which writes to program memory and check ?? does whis program solve this question ..? if not tell me a way to find whether my ram is von neumann mapped ra, ??? thanks pruthvi
There should essentially never be a need to check such things. It's part of the hardware design, which your software is supposed to know. You can't test such things, because you cannot know what will happen if you try to jump into code in what you incorrectly presumed is von-Neuman mapped RAM, but is actually non-existent or unused code memory.
You can't test such things Well, you could write a test. You could MOVC from an address and MOVX from the same offset, and see if the code in program store matches the data in data store. And you could try a write with MOVX and see if the MOVC data changes. But you'd still have to know (a priori) the memory map to know which areas of data space are supposed to match the code space. And, as Hans says, the author of the software should know what the hardware architecture is when they write the code. Usually the software itself just presumes that the hardware is actually the hardware on which it was designed to execute.
"Usually the software itself just presumes that the hardware is actually the hardware on which it was designed to execute." Or, if the software is designed torun on a number of hardware variants, some means of identification is built into the hardware - eg, a hardware-id readable by the software.
a hardware-id readable by the software Yes. The thing to be careful of here -- at least with 8051 designs with limited resources -- is having your run-time image burdened with a lot of dead code for all the alternatives. Any given device will only be one of those variants, but a single image will still have the code for all the others. If the hardware is all very similar, it may not matter. If the hardware differs greatly, you may wind up with a lot of useless code. Depending on the details, you may want to make this decision at compile time, resulting in separate images for each type of hardware. Or, you might have one load (to rule them all) and do the detection at runtime. One nice way to write code to deal with such problems at runtime would be to read the hardware ID, and then bind a bunch of function pointers for the appropriate alternative. Unfortunately, the way the Keil tools generally handle C function pointers make this approach a bit painful. You'll be in for a lot of manual editing of the overlay tree, and you'll have to be careful with your module interfaces and allocation of them to banks if you use bank switching.
"One nice way to write code to deal with such problems at runtime would be to read the hardware ID, and then bind a bunch of function pointers..." Another way could be a kind of "static" code-banking: Your startup code reads the hardware-ID, then sets the "bank select" magic - and this is never changed again til the next reboot. Thus the "dead" code for the other variants need not consume any 8051 address space! Yet another option, if you do In-System Programming (ISP), would be to have the programming utility read the hardware-id, and automatically choose the appropriate code to download.