• State Not Answered
  • Locked Locked
  • Replies 12 replies
  • Subscribers 21 subscribers
  • Views 1887 views
  • Users 0 members are here
2025 survey

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.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

howto see what's in the data segment

Stijn Souffriau

C51 returns the following error:

*** ERROR C249: 'DATA': SEGMENT TOO LARGE

Rather than switching to the COMPACT or LARGE memory model I would like to manually declare some variables into xdata. I would however like to know what the compiler is actually putting in the data segment and what is taking up the most space. Is there some way I can get this information in the absence of the .MAP file?

Thanks,

Stijn

Parents
  • 0 in reply to HansBernhard Broeker

    Make the DATA segment temporarily bigger - is that even possible (architecture defined) if so how?

    Depends what "too large" means in this context. If it's smaller than architecturally limited then make it bigger, if it's already at the limit then try redirecting 'data' into larger segments that can accommodate it. It was a general suggestion about how to look at the problem if the .MAP was the only way to consider how the compiler/linker were behaving.

    You're never going to get 2 gallons of crap in a 1 gallon bucket, so if it's architecturally defined to have less capacity than the source needs, someone writing the source needs to actually think about that when coding it.

    What's the floor plan for the code/data on the platform you took the code from?

Reply
  • 0 in reply to HansBernhard Broeker

    Make the DATA segment temporarily bigger - is that even possible (architecture defined) if so how?

    Depends what "too large" means in this context. If it's smaller than architecturally limited then make it bigger, if it's already at the limit then try redirecting 'data' into larger segments that can accommodate it. It was a general suggestion about how to look at the problem if the .MAP was the only way to consider how the compiler/linker were behaving.

    You're never going to get 2 gallons of crap in a 1 gallon bucket, so if it's architecturally defined to have less capacity than the source needs, someone writing the source needs to actually think about that when coding it.

    What's the floor plan for the code/data on the platform you took the code from?

Children
No data