Actel Core8051s

Actel documentation suggest just to change the header file Reg51.h with the core8051s registers, but it doesn't work.

And it really didn't occur to you that it might be necessary for you to inform us how it "doesn't work" for anybody to be able to offer meaningful assistance? I.e.: what did you do, what did you expect the result to be, and what was the actual result instead?

I suspect that more Keil libraries must be changed in order to adapt core8051s for uVision.

What observation or reasoning is that suspicion based on?

Actel documentation suggest just to change the header file Reg51.h with the core8051s registers, but it doesn't work.

And it really didn't occur to you that it might be necessary for you to inform us how it "doesn't work" for anybody to be able to offer meaningful assistance? I.e.: what did you do, what did you expect the result to be, and what was the actual result instead?

I suspect that more Keil libraries must be changed in order to adapt core8051s for uVision.

What observation or reasoning is that suspicion based on?

Hello,

Yes, you are right, I have been too ambiguous..

My program is very simple, just writing some data on GPIO output when a particular data is in GPIO input. With core8051s, the peripherals like GPIO are connected to the APB bus and thus memory-mapped from address 0xF000 to 0xFFFF. My GPIO is located in 0xF000 and the input and output registers are located in 0xF090 and 0xF0A0 respectively.

Here is my code:

#include <reg51.h>                             /* define core 8051s registers */

volatile unsigned char xdata GPIO_IN _at_ 0xF090;        /* GPIO data in */
volatile unsigned char xdata GPIO_OUT _at_ 0xF0A0;       /* GPIO data out */

void main (void)  {                            /* main program */


  unsigned char datain;


  while (1)  {                                 /* repeat forever */

        /*datain = GPIO_IN;     */
        if (datain == 0x00)
        {
                           GPIO_OUT = 0x88;
                }
    else
                {
                if (datain == 0x0F)
              {
               GPIO_OUT = 0x66;
              }
                else
                  {
                   if (datain == 0xF0)
                         {
                          GPIO_OUT = 0x77;
                 }
                   else
                      GPIO_OUT = 0x11;
                  }
                }

  }
}

I have programmed the core8051 (not s) before and I had no problems. With regard to the modification of core8051 Keil libraries, my suspicion is based on the Actel core8051 device database settings, which I have to use to run core8051s. Here are the options when core8051 device is selected:

BOOK0=DATASHTS\INTEL\ISM51.PDF("8051 Instruction Set Manual")
BOOK1=DATASHTS\ACTEL\8051DS-ADV.PDF("Datasheet")
CPU=IRAM(0-0xFF) IROM(0-0xFFF) CLOCK(12000000)
MON=S8051.DLL TP51.DLL("-p51")
REGFILE=REG51.H
SFILE="LIB\STARTUP.A51" ("Standard 8051 Startup Code")
SIM=S8051.DLL DCore51.DLL("-pDCore")

The code line I'm worried about is "SIM=S8051.DLL DCore51.DLL("-pDCore")", where S8051.DLL could be associated with core8051 but not with core8051s.

Moreover, in Keil ASM folder, I have found the file "REG51.INC", which I also had to modify in order to fit the core8051s registers.

Thank you for your fast reply. I hope my explanation helps now.

Thank you for your fast reply. I hope my explanation helps now

Well, frankly, they don't. You haven't even begun to explain how your code "doesn't work".

And similarity between two configurations alone is no justification for a suspicion that stuff won't work. No by a comfortable margin it isn't.

As far as the compiler is concerned, it just generates 8051 instructions: these are the same for all 8051 CPUs - including the Actel core.

Hence there is no difference to "The Libraries".

The only real differences lie in the memory layout, and the SFRs - all of which you can easily specify manually.

There is nothing special or "magic" about the header files supplied by Keil - they are exactly the same as any header file that you write yourself.

The only place that you really need specific support is in the Simulator...

Ok, the code seems to work in Keil, it compiles fine and the debbuging session shows how the DPTR register (a pointer to XDATA for 8051) has the correct memory address, but when I import the HEX code in my FPGA ROM (code memory) the simulation shows how there is no communication with the GPIO.

I will ask my question in a different way:

Does anyone has worked before with this Actel core8051s in Keil?
What were the compiler configuration parameters, headers or libraries changed from Actel core8051 device database in order to adapt this core to the Keil software?

Thank you.

Ok Andy, thank you for your explanation, I'll focus on my SFRs configuration.

Thanks

Forget my last post, I was writing it when Andy answered my question.

Not just SFRs - from some of your other posts, it seems that this core gives you the choice of mapping your custom peripherals into either SFR or XDATA space?

"Does anyone has worked before with this Actel core8051s in Keil?"

Not this core, but the Triscend TE5 worked on exactly the same principle...

As far as the Core (and, therefore, the compiler) is concerned, it just reads/writes SFRs or XDATA - it neither knows nor cares what custom peripheral functions may be behind those interfaces...

What "simulation" ?

Are you talking about Keil's CPU simulator in uVision, or something in your FPGA tools?

Yes, the core8051s maps the peripherals into XDATA space starting from address 0xF000.

The simulator is ModelSim, a FPGA software tool that shows the core signals in data and address buses, or movx, write, read, etc. In my Modelsim simulation, GPIO addresses F090 and F0A0 should appear in core address bus, but they don´t.
Now that I know that there are more microcontrollers that work in Keil with the same principle (memory mapped peripherals) I will check the HEX file generated by Keil to confirm that the correct instructions are read by the core.

"(memory mapped peripherals)"

The whole point of memory-mapping in any architecture (not just 8051) is that the CPU neither knows nor cares whether these are "real" memory accesses, or accesses to memory-mapped peripherals - the Address and Data bus operations are identical...