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.
Since Keil (as opposed to some other compilers) do not supply the library in source, I have a question: I am tasked with debugging some glitches in a very strange design: External memory is used and ALE is disabled. To access external RAM one must latch the low address in an external latch by toggling a p1 pin before executing external RAM access (movx). My question thus is: do the routines in C51S EVER execute movx. I have no possibility of replacing thousands of hardware units, and already have the next version concept so I need the above question answered. Thanks in advance Erik
To the best of my knowlege, the answer is no. The small model is what you choose, for example, if you have a stand-alone design with no external RAM. In selecting this mode, all variable declarations (unless explicitly cast to a different memory type) are of type "data". Thus, all code and parameter passing is performed using internal data memory.
Actually it will access external memory, if the address is outside the internal memory range. As an example, any address above 0100H will generate an external memory access. Since the ALE is disabled on your chip, I don't know if this disables the addressing as well, but the compiler will generate code to access external memory.
I did a little more checking, and in the Phillips versions of 8051, if ALE is disabled, it is still activated when a MOVX instruction is executed. It is turned off for any on-chip access.
The ALE is actually not connected in this @#$%^& design. I have disassembled the code and found a few cases using CLODPTR, an undocumented "shortcut subroutine" which actually uses MOVX. I am not criticising the compiler, who in his right mind would design a compiler anticipating such a design, I am only looking for help in the hunt for the unknown MOVX'es.
do the routines in C51S EVER execute movx. The answer is YES. However, the small library routines do not locate any of their variables in XDATA and they do not access XDATA arbitrarily. They only access XDATA if you pass a pointer to an XDATA object. Since the library routines perform operations on objects that you point to (for example strcpy), if you pass a pointer to an object in XDATA, then the library routine is OBLIGATED to access XDATA. As long as you do not instruct any routines in the small library to access objects stored in XDATA, the library will not access XDATA. Now, of course, the library routines must include the code necessary to access XDATA (in case your program does that). So, if you disassemble your program, you'll see MOVX instructions in the disassembly. If you find cases where the small library routines access XDATA, it is because of a pointer to XDATA that you passed to the routine. Jon
Well, the small model just means that everything defaults to being in DATA - the user is still free to declare things in PDATA, XDATA, etc should the need (or whim) arise. Therefore the Library must support access to XDATA etc; eg, if you define a big string in XDATA, you still want your small-model printf to be able to print it. (OK, maybe not a brilliant example, but you get the idea?) So the Small Library shouldn't use XDATA for its own purposes, but should be able to handle any such requests which the user may make of it