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 all, I'm asking if anyone has found a better way to access user defined memory. That is, accessing memory that can't be reached w/the "movx" instruction, but must be accessed w/user code. I can get it done w/Far memory but don't want to buy the PDK. I finally found that I can use good old C51.exe & BL51.exe and generic pointers to get the job done. I can divide XDATA space into "standard" RAM and user defined RAM by writing my own ?C?CSTPTR & ?C?CLDPTR routines (these library routines resolve generic pointers at run time). This can get tedious (using pointers when I normally didn't have to) but it works. My main problem is that I have to be careful to use or store parameters passed between functions (via registers) right away or the compiler will store them in XDATA w/MOVX - which can cause trouble depending on the address. Anyway, if I'm careful this works. And, I don't see any other way to do this aside from buying the PDK. Has anyone else ever done this another way? Thanks for your time. Bill
You may want to check the following knowledgebase article. http://www.keil.com/support/docs/1964.htm It lists all of the load and store compiler routines that are currently used. There are quite a bit more than just the ?C?CSTPTR & ?C?CLDPTR routines that you mention. Basically, the compiler is at liberty to use any of these routines based on the level of optimization, the data types accessed, the access method, and any other side effects that may occur with the data or the pointer to it. The biggest argument against re-writing these routines is that they are not intended to be general-purpose user library functions. They are intended for use by the compiler only. As such, you cannot depend on Keil to leave these routines alone -- the arguments, registers used, and function names may change (especially in future releases where new features and optimizations and likely). Actually, we do augment these routines from time to time. The routines in the PK51 that are defined for accessing far memory are specified as user routines. The compiler uses them, but they are intended to be written and maintained by the user. In the past, when I've had to access multiple RAM (or EEPROM or FLASH) areas, I've typically written functions to read and write this area directly. It does not couple directly with the compiler and the C language, but it is certainly a lot easier to explain. Most of the projects I have been involved in required a hand-off to the maintenance team. I quickly learned that for my projects, I wanted code that was easy to maintain (or else I got called in years later to fix something that someone else broke). Jon
Jon, Good to hear from you. We know each other - I used to work for Marty Pawloski a while back. We've hung out a few times, years ago. I agree that the biggest danger is if a new compiler version changes how it deals with the library files it calls. However, once a project is complete, I archive the compiler with it in order to avoid those types of problems. Anyway, thanks for the very reasonable arguments against what I'm doing. You make some good points. Keil is a good product and I'm glad we choose it for this project. Maybe next time we'll upgrade to the whole shebang. I hope things are going well for you & yours. Take care, Bill