8051 game project

Yes it does, indeed. But I have allocated those variables into specific memory locations like:

__data __at (0x10) unsigned short var1;
__data __at (0x11) unsigned char var2;

So, because a short int takes 2 bytes, it would be using 0x10 and 0x11 and therefore, overlapping var2 at 0x11.

PsySc0rpi0n

Right ..that makes sense
So the obvious question is..
why are you locating your data at fixed locations ?

It's just a matter of controlling what was going on during the code debugging with each variable!

If you are concerned about debugging only then I think you can open the map file which lists all your symbols in the program and their addresses. so you never have to fix location for your variables.

If you are concerned about debugging only then I think you can open the map file which lists all your symbols in the program and their addresses. so you never have to fix location for your variables.

ajay_bhargav

Yes, indeed, and I know about that but as I don't have yet enough knowledge to dig into those files, It's kinda useless to me to check them. And it's faster when I run the code, to have right next to my eyes, the value of each variable in the memory map the simulator I'm using has.

Best regards.
PsySc0rpi0n

It's obviously a personal choice. Digging into map and listing files need extra efforts. For debugging your method sounds fine.

But it's a way to debug to consider to the future and let the compiler to manage memory by itself!

I agree!

Hello once more...

I'm really struggling to make my hardware work with my code.

I've tried a small ASM code from a friend of mine and it worked perfectly but with my C code it's not working... I think I can't even init the LCD...

Can you help me break down my code and figure out where the problem is?

#include "reg_uC89C4xx.h"

#define RS P3_7
#define RW P3_6
#define E  P3_5

#define BF P1_7

#define CLR_E   (E  = 0)
#define SETB_E  (E  = 1)
#define SETB_RS (RS = 1)
#define CLR_RS  (RS = 0)
#define SETB_RW (RW = 1)
#define CLR_RW  (RW = 0)
#define SETB_BF (BF = 1)
#define CLR_BF  (BF = 0)

void send_string  (unsigned char *string);
void busy_f_check (void);
void e_delay      ();
void send_cmd     (unsigned char cmd);
void send_data    (unsigned char data);
void init_LCD     ();

void send_string (unsigned char *string){ /*send a string to the LCD DDRAM*/
    while (*string){
        send_data (*string);
        ++string;
    }
}

void busy_f_check (void){
    SETB_BF;
    SETB_E;
    CLR_RS;
    SETB_RW;
    while (BF){
        CLR_E;
        e_delay ();
        SETB_E;
    }
}

void e_delay (){
    TMOD = 0x01;
    TH0  = 0xFF;
    TL0  = 0xFA;
    TR0  = 0x01;
    while (!TF0);
    TR0  = 0x00;
    TF0  = 0x00;
}

void send_cmd (unsigned char cmd){
    busy_f_check ();
    P1 = cmd;
    CLR_RS;
    CLR_RW;
    CLR_E;
    e_delay ();
    SETB_E;
}

void send_data (unsigned char data){ /*send some data/char to LCD*/
    busy_f_check ();
    P1 = data;
    SETB_RS;
    CLR_RW;
    CLR_E;
    e_delay ();
    SETB_E;
}

void init_LCD (){
    send_cmd (0x38);/*configure LCD with 2 lines, 5x7 matrix*/
    send_cmd (0x0F);/*Display ON, Cursor Blinking, Cursor ON*/
    send_cmd (0x01);/*Clear display*/
    send_cmd (0x06);/*Increment cursor mode*/
}

void main (void) {
    SP = 0x40;
    init_LCD    ();
    send_cmd    (0x85);
    send_string ("HELLO");
    send_data   ('A');
    while (1);
}

there can be two main reasons:
1. Power up self init delay
2. Command/Data execution delay

So in init_LCD function add a small delay at start. and increase e_delay a little more. At start Keep it high and see if lcd works and then lower down e_delay bit by bit.

Ok. I'll try that. Let me just say that LCD is working flawlessly with a small ASM code a friend of mine gave me. So I can assume that all wiring is OK. Problem is really in software... What should be a reasonable value for e_delay function? I have done it with about 5uS that is about 7 or 8 times more than what they say in dataset it needs for tW.