Hello I am working in a medical company they give me a program for At89C55wd when i want to debug the project,its message is :
error 56 : cant open file what is you opinion about this?
and i have #define lowPrsPressure *(XCHAR+0x81A2)
in program and XCHAR is undefined identifier i think XCHAR is similar to XBYTE. Can anybody help me? Thanks
So why aren't you asking "them" these questions about this program that "they" gave you??
Why do you suppose that complete strangers from far across the planet will know the code better than "they" who gave it to you??
I expect it is an address within the memory space.
Did the source come with any other objects, map files, listing file or images for what you are currently programming on to the device. Any source code control or documentation?
Dear Andrew Thanks for your reply because they don't know about their program! they have hex file and program their MCS I want to change some option but I can't debug the program. in the main program (it's name is CONTROL) we have header file address.h with XCHAR definer maybe in keil 2 this definition is correct.
know the company want to change the program and MCS to ARM but we should answer old customers requirement.
yes I know it's a memory address like XBYTE but compiler can't compile it maybe i should add some header file?
My _guess_ is that someone wanted a XCHAR with the intention of having a signed character in external memory and use XBYTE to represent an unsigned byte in external memory.
With the C51 compiler, you normally use XDATA to just inform about memory region but without caring about the type information. So you have to separately supply "unsigned char", "long", "struct my_data_type" or whatever type you want for the variable.
It's important to always put _all_ required files under source code control. When developing embedded code, that also means that it may be required to check in a number of header files supplied with the compiler - just to make sure that a developer that later has to port the code to a different compiler will be able to read the original definitions and then be able to understand how the original program functioned - that's required information when porting to a different compiler and/or processor.
So define it, then!
"I know it's a memory address like XBYTE"
So look at the definition of XBYTE, and create something similar for XCHAR ...
http://www.keil.com/support/man/docs/c51/c51_xbyte.htm
My point would be that you should start by examining ALL the old material and build data available for the software you are currently loading. Once you have understood how the old software was built, and on/with what, you will then be in a position to try and build it under some new environment/conditions.
Reverse engineer some of that data if need be, but at least come at this with some understanding of how the old stuff functions. Find the old engineers who worked on this last, and talk to them.