• State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 21 subscribers
  • Views 1600 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

DSEG AT Directive Problem

Michael Karas

I am having some difficulty with using the Keil A51 assembler. My 8051 derivative processor has 256 bytes of internal RAM. I have my code organized with a...

BSEG AT 0
BIT1 DBIT 1
BIT2 DBIT 1
BIT3 DBIT 1
  ...
  ...
BIT8 DBIT 1

Following this I have the data segment setup as starting at 0x21 because I know that the BSEG will be but one byte ending up at 0x20.
DSEG AT 021H
VAR1:
   DS   1
VAR2:
   DS   1
  ...
  ...
VARn:
   DS   1
;
BUF1:
   DS   32
BUF2:
   DS   26
BUF4:
   DS   16
BUF5:
   DS   16
STACK:
   DS   16
_RAM_TOP:
   DS   0

Now the problem is that the DSEG is growing beyond 0x7F (past end of 128 bytes) and the assembler is complaining about that. How can I get the assembler to quit complaining. All should be OK becasue in my code all of the various buffers are accessed indirectly by the type of code:
   MOV   R0, #BUF3
   MOV   @R0, A

I realize I could hard code a separate PSEG at 0x80, but then there ends up being a hole in the allocated memory and I wanted to avoid that to get the maximum utilization of my 256 bytes of RAM.

Any ideas ????

Michael Karas


<pre

  • 0 in reply to Andy Neil

    As Andy so succinctly put it, IDATA is the answer. As far as the linker in concerned, IDATA starts where DATA stops and (usually) the stack space goes at the end. IDATA is not restricted to the top 128 bytes; but is, potentially, the entire 256-byte indirectly addressable space.

  • 0 in reply to Graham Cole

    Of course, if you have xdata then you do get 256 bytes of pdata space that is accessed just as quickly as idata. Given that idata is such a valuable resource (e.g. it is needed for stack space) I would always go for pdata in preference to idata where it is available.

  • 0

    I solved my problem. I guess the biggest difficulty came from trying to use the type of absolute segment declaration I was using. I went to relocatable segments as shown below and let the linker decide where to put things. Now all is better!!

    BITS_SEG    SEGMENT     BIT
DATA_SEG    SEGMENT     DATA
BUFF_SEG    SEGMENT     IDATA
CODE_SEG    SEGMENT     CODE

     RSEG    BITS_SEG
BIT1:
     DBIT 1
BIT2:
     DBIT 1
BIT3:
     DBIT 1
      ...
      ...
BITn:
    DBIT 1
;
    RSEG    DATA_SEG
VAR1:
    DS   1
VAR2:
    DS   1
     ...
     ...
VARn:
    DS   1
;
    RSEG    BUFF_SEG
BUF1:
    DS   32
BUF2:
    DS   26
BUF3:
    DS   16
     ...
     ...
BUFn:
    DS   16
STACK:
    DS   16

    Thanks
    Michael Karas