• State Not Answered
  • Locked Locked
  • Replies 1 reply
  • Subscribers 21 subscribers
  • Views 801 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

Map I/O

Mike Hwang

I use Dallas 390 and I want to map the device I/O into RAM which can be accessed by Dallas 390.I have the following solution:
1.
Using XSEG in Ax51 as the following example

XSEG AT 08000h
IO_PORT: DS 1
The variable IO_PORT can be externed in head file.Through including the head file we can used IO_PORT directly.
//head file: head.h
extern unsigned char IO_PORT;

//source file:source.c
#include "head.h"
...
IO_PORT = 0x01;
...
But I found that I can't declare IO_PORT as follow:
XSEG AT 40BC00h
IO_PORT: DS 1
The linker complained address space overflow
But if I use _at_ in Cx51(v7.07+),the problem can be resolved.

2.
//file IO.c
unsigned char far IO_PORT _at_ 0x40BC00;
//head file:head.h
extern unsigned char far IO_PORT;
//using IO_PORT in sourc.c
#include "head.h"
...
IO_PORT = 0x01;
...
3.
Using the macros XBYTE or FVAR.But XBYTE has the segment(64KBs) limit,and FVAR generate many assembly instructions which include calling to a libray rutine.
#define IO_PORT 0x8000
unsigned int addr;
XBYTE[IO_PORT] = 0x01;
addr = 0x8000;
XBYTE[addr] = 0x01;//segment number + (addr)
FVAR(unsigned char,0x40BC00) = 0x01;
If varible addr is allocated in the 0x40th segment,then address unit 0x408000 is assigned using XBYTE[addr] = 0x01.The same phenomemon emerges if we delete the keyword farin the second solution:
unsigned char IO_PORT _at_ 0x8000;
...
IO_PORT = 0x01
...
If IO_PORT is allocated in the 0x40th segment,memory unit 0x408000 will be accessed.

It seems that the AT in Ax51 doesn't support the same ability as _at_ in Cx51,isn't it?
Does anybody has other solutions with mapping I/O?

Parents
  • 0

    Your core problem, I think, is that you shouldn't be using XSEG for this. XSEG is for classic '51s, but doesn't really match the capabilities of the Dallas 390. Use a SEGMENT and an RSEG directive, instead. Either that, or you simply forgot to use AX51 instead of A51, or didn't configure it for
    '390 contiguous mode.

    You'll probably see the C compiler do the same, if you have it generate ASM source code from your C _at_ definition. Using XSEG would be equivalent to omitting the far keyword in your C version --- that'll fail for the 0x40zzzz address range, too.

Reply
  • 0

    Your core problem, I think, is that you shouldn't be using XSEG for this. XSEG is for classic '51s, but doesn't really match the capabilities of the Dallas 390. Use a SEGMENT and an RSEG directive, instead. Either that, or you simply forgot to use AX51 instead of A51, or didn't configure it for
    '390 contiguous mode.

    You'll probably see the C compiler do the same, if you have it generate ASM source code from your C _at_ definition. Using XSEG would be equivalent to omitting the far keyword in your C version --- that'll fail for the 0x40zzzz address range, too.

Children
No data