• State Not Answered
  • Locked Locked
  • Replies 1 reply
  • Subscribers 22 subscribers
  • Views 813 views
  • Users 0 members are here
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