m16c and lcd p9 read faliure?

Changing the port 9 DDR from output to input requires PRC bit 2 = 1 (PRCR =

4) *with interrupts disabled* otherwise the unlock can be lost before the DDR write. It sounds like you're changing the port direction but its failing.

Peter

=

the

Hi,

Now I have tried with disabling the interrupts however still won't work. I have also checked whether the direction change was ok by reading bac the pd9 which gave the 0x00.

Strange is when I am using a multimeter to see what voltages are currentl on the pins it it shows zero volt and the input data read by the controlle might change.

I am afraid that the display itself is faulty and won't power up leavin the p9 open. Actually there was as mistake giving 5V istead of 3.3V to th lcd-s control logic but now even with 3.3 doesn't seem to work. (i am stil wondering how the lcd is able to operate with ttl voltages if it get

3.3V...)

Ferenc

This message was sent using the comp.arch.embedded web interface o

Are we mind readers? What's wrong with included the offending section of your code and details of the hardware connections. Could be a hardware thing, you might have 8080 write mode selected or this or that or something. Do we get a prize for best guess?

*Peter*

fatso wrote:

Sorry and thanks for trying to help me.

The JCM12864 has the following pins:

*CS1 chip select RESET reset low for resetting *RS H for data L for control *RW read/write selection high for reading *E RW=H E=H data DB0-7 output, RW=L DB0-7 latched on falling E *DB-7 bidirectional data singals VDD +3.3 VSS Ground Vout voltage controller io C4+ C3+ C1- C1+ C2+ C2- capacitators V1 V2 V3 V4 V0 lcd driver supply voltages *PS parallel serial select. connected to H -> parallel

I've stated with a "*" which pins are connected to the MCU. in the lcd's documentation the interface is written to be m6800 so the C68 pins must be H inside the device. just like the CS2.

the code which is operating: #define EEE p8_0 #define RS p8_1 #define CS_DISP p8_7 #define RW p8_6 #define DATA p9 void setupDisplayPorts(void){ prc2 = 1; // enable writing to pd9 pd9 = 0xff; // port 9 is an outport pd8_0 = 1; // output E pd8_1 = 1; // output RS pd8_7 = 1; // output CS_DISP, chipselect pd8_6 = 1; // output RW asm("nop"); asm("nop"); asm("nop"); asm("nop"); RS = 0; // RS is the data/comman selector RW = 0; // RW is the read/writ control EEE = 0; // EEE is the data latc signal DATA = 0; // DATA is the eight bit dat bus CS_DISP = 0; // select the display asm("nop"); asm("nop"); asm("nop"); asm("nop"); return;

} ... setupDisplayPorts();

DATA = 0xaa; asm("fclr i");

prc2 = 1; // enable writing to pd9

pd9 = 0x00; // p9 input

asm("fset i");

EEE = 1;

RS = 0; //command

RW = 1; //read

while (1){

char x;

wait(10); // waits 1s

x=DATA;

RS232Send2(1,&x); // sends the data to the pc

wait(1); //waits 0.1s

};/**/

Ferenc

This message was sent using the comp.arch.embedded web interface on

Firstly, isn't E low, the passive state, so thats what it should be inited to. Secondly, the Mitsubishi compiler, at least, can and does combine port bit writes into an 'and' or 'or' port with constant. This can be bad news if your expecting the rising or falling edge of one pin to clock in the value of another pin

RS, RW etc should change while E is active.

bizarre? what is this about:

Peter D

inited

E is inited to 0. and also for output, however E is only for th communication not for the chipselect. CS1 is for the chipselect.

bit

value

Does it mean I should use BAND and BOR with CLR C and SET C instead?

according to the R/W characeristic. RS and RW should be set up first an then CS1 and E. I might made a mistake with this though.

I am trying to read the display's status with an endless loop so that I can test the pins with a multimater as well.

pc

Thank you again, however I seem to be stucked at the moment. Ferenc

This message was sent using the comp.arch.embedded web interface o

Normally, for a m6800 type bus you'd expect E and CS1 to be inactive, then RW and RS to to valid states, followed by CS1 going active, followed by E going active. After the transfer E goes inactive and then CS1. If you are outputing data its best done before E goes active.

No, just put the asm nops between each operation to stop it optimizing.

NO! I'm sure that that is wrong.

YES!

Peter

Thanks for the help so far.

i got a new display now and it turned out that the other was dead. now i am able to turn on the new one, seems to get the commands, howeve the reading from the port is faulty somehow. i can measure with a multimeter that there is 0V however the MPU reads back instead of 0. the following data should show up (in binary format); (BUSY, ADC, ON/OFF, RESETB, 0, 0, 0, 0) on/off is 1 when the display is off. when the pins have 01000000b (adc and on) then it reads 11111110b (0xfe) also reads the same when the display gives 01100000b (0x60) adc and off reads 0xfc when there is 00100000. (adc0 and off) i use the following code:

//port9 direction for input asm("fclr i"); prc2 = 1; asm("nop"); pd9 = 0x00; asm("nop"); asm("fset i"); RS = 0; asm("nop"); //command RW = 1; asm("nop"); //read EEE = 1;asm("nop"); //enable CS1 = 0;asm("nop"); //chip select //reading forever while (1){ char x; wait(10); //wait one sec x = DATA;asm("nop"); //read p9 #define DATA p9 RS232Send2(1,&x); //send to pc via wait(1); }

ferenc This message was sent using the comp.arch.embedded web interface o