Arduino Forum

Topics => Device Hacking => Topic started by: bobhaha on Oct 07, 2011, 01:56 pm

Title: Stealing data sent to an LCD
Post by: bobhaha on Oct 07, 2011, 01:56 pm
Hey guys,

I have done some basic work interfacing an arduino and an LCD and as far as I understand the arduino sends serial information to the LCD in order for the onboard IC's to understand and display on the screen.

Well I want to reverse this....

I have a device that measures a lasers power then displays the result on to the detachable LCD module.

Well I would like to take the info that the circuit is transmitting to the LCD and take that in as serial data to the arduino. Is this possible? The LCD module is a standard 16 pin configuration, so I assume pin 7 - 14 are used as serial outputs to the LCD correct?
Title: Re: Stealing data sent to an LCD
Post by: ams0178 on Oct 07, 2011, 02:49 pm
We'd need a little more info. Do you have a datasheet, part number, etc for the LCD you have?
Title: Re: Stealing data sent to an LCD
Post by: bobhaha on Oct 07, 2011, 03:26 pm
Model number is SVM802B-1/V2

Datasheet is here... http://www.datasheet4u.net/download.php?id=611907

I just need some direction (link, code snippet... anything) to intercept the data and make it into something the Arduino can understand.
Title: Re: Stealing data sent to an LCD
Post by: bobhaha on Oct 10, 2011, 03:59 pm
Anyone???
Title: Re: Stealing data sent to an LCD
Post by: robtillaart on Oct 10, 2011, 09:54 pm
Quote
so I assume pin 7 - 14 are used as serial outputs to the LCD correct?


Think not, I think it is parallel 7-14 = 8 datalines = 1 byte in parallel.

You could try to read them with a 74HC165 shiftin - http://www.arduino.cc/en/Tutorial/ShiftIn - and -  http://arduino.cc/en/Reference/ShiftIn -
Title: Re: Stealing data sent to an LCD
Post by: bobhaha on Oct 11, 2011, 06:05 am
So the chip basically "records" all input then spits it out once the ardunio asks for it.. is that correct?

If so, does it matter what format the incoming communication is in? I believe I have found the 4 terminals responsible for the data transmission. But I have confirmed that pin 7 - 14 are D0 - D7 So I assume this is where the data is sent.
Title: Re: Stealing data sent to an LCD
Post by: Morrolan on Oct 11, 2011, 05:05 pm
One thing - if it is a standard HD44780 compatible LCD, it is a Parallel device, not serial.  There are major differences between the 2 in how they work and what your solution has to be.

A Shift register will normally record 1 byte of data, i.e. 1 character.  It does this by shifting in 8 bits, 1 bit at a time.

Your Arduino really has to do nothing other than sit listening to the LCD lines though, in case it ends up missing something if it is off somewhere else executing something else in a program loop.



Title: Re: Stealing data sent to an LCD
Post by: bobhaha on Oct 11, 2011, 06:15 pm
As far as I know it is a standard HD44780... so it is a parallel interface device.

So with the suggested CD4021B shift register I can accomplish this? If this is not available what type of shift register am I looking for?

EDIT: Is this what I'm looking for? http://jaycar.com.au/products_uploaded/ZC4858.pdf

Thanks in advance
Title: Re: Stealing data sent to an LCD
Post by: robtillaart on Oct 11, 2011, 09:34 pm

Quote
Is this what I'm looking for?

looks good, maybe you should find a version that is easier to solder ?
Title: Re: Stealing data sent to an LCD
Post by: bobhaha on Oct 13, 2011, 07:04 am
Ok, So I've bought 2 of these shift registers now I need program them in.

I've connected them as shown below...

(http://dl.dropbox.com/u/14298539/ShiftReg.jpg)

I've also used the code supplied here http://arduino.cc/en/Tutorial/ShftIn11 (http://arduino.cc/en/Tutorial/ShftIn11)

This only gives me outputs like below...

111000
-------------------
111000
-------------------
111000
-------------------
111000
-------------------
11100
-------------------
11000
-------------------
111000
-------------------
11100
-------------------
11000
-------------------
111000
-------------------
11000

Which I have tried to convert to bytes but only getting garbage.

I know the onboard chip runs at 4800 baud, how can I sync the shift register, Arduino and LCD display chip?
Title: Re: Stealing data sent to an LCD
Post by: bobhaha on Oct 15, 2011, 07:49 am
Aaaaaaanyone?  :~
Title: Re: Stealing data sent to an LCD
Post by: hellonearthis on Oct 15, 2011, 09:35 am
What does your code look like?  Would be interesting to see what your doing.

Still instead of interception what about reading from the LCD.
The LCD has ram so you could try to access it and copy what is in the screens memory.

http://www.adafruit.com/datasheets/HD44780.pdf
http://www.adafruit.com/datasheets/TC1602A-01T.pdf

Or, working with what you have, the character generator rom table in the TC1602A pdf might help you decode the response.
Title: Re: Stealing data sent to an LCD
Post by: bobhaha on Oct 15, 2011, 07:44 pm
I used the code found on the link I provided above.

Code: [Select]
//**************************************************************//
//  Name    : shiftIn Example 1.1                              //
//  Author  : Carlyn Maw                                        //
//  Date    : 25 Jan, 2007                                      //
//  Version : 1.0                                               //
//  Notes   : Code for using a CD4021B Shift Register    //
//          :                                                   //
//****************************************************************

//define where your pins are
int latchPin = 8;
int dataPin = 9;
int clockPin = 7;

//Define variables to hold the data
//for shift register.
//starting with a non-zero numbers can help
//troubleshoot
byte switchVar1 = 72;  //01001000

void setup() {
  //start serial
  Serial.begin(9600);

  //define pin modes
  pinMode(latchPin, OUTPUT);
  pinMode(clockPin, OUTPUT);
  pinMode(dataPin, INPUT);

}

void loop() {

  //Pulse the latch pin:
  //set it to 1 to collect parallel data
  digitalWrite(latchPin,1);
  //set it to 1 to collect parallel data, wait
  delayMicroseconds(20);
  //set it to 0 to transmit data serially 
  digitalWrite(latchPin,0);

  //while the shift register is in serial mode
  //collect each shift register into a byte
  //the register attached to the chip comes in first
  switchVar1 = shiftIn(dataPin, clockPin);

  //Print out the results.
  //leading 0's at the top of the byte
  //(7, 6, 5, etc) will be dropped before
  //the first pin that has a high input
  //reading 
  Serial.println(switchVar1, BYTE);

//white space
Serial.println("-------------------");
//delay so all these print satements can keep up.


}

//------------------------------------------------end main loop

////// ----------------------------------------shiftIn function
///// just needs the location of the data pin and the clock pin
///// it returns a byte with each bit in the byte corresponding
///// to a pin on the shift register. leftBit 7 = Pin 7 / Bit 0= Pin 0

byte shiftIn(int myDataPin, int myClockPin) {
  int i;
  int temp = 0;
  int pinState;
  byte myDataIn = 0;

  pinMode(myClockPin, OUTPUT);
  pinMode(myDataPin, INPUT);
//we will be holding the clock pin high 8 times (0,..,7) at the
//end of each time through the for loop

//at the begining of each loop when we set the clock low, it will
//be doing the necessary low to high drop to cause the shift
//register's DataPin to change state based on the value
//of the next bit in its serial information flow.
//The register transmits the information about the pins from pin 7 to pin 0
//so that is why our function counts down
  for (i=7; i>=0; i--)
  {
    digitalWrite(myClockPin, 0);
    delayMicroseconds(0.2);
    temp = digitalRead(myDataPin);
    if (temp) {
      pinState = 1;
      //set the bit to 0 no matter what
      myDataIn = myDataIn | (1 << i);
    }
    else {
      //turn it off -- only necessary for debuging
     //print statement since myDataIn starts as 0
      pinState = 0;
    }

    //Debuging print statements
    //Serial.print(pinState);
    //Serial.print("     ");
    //Serial.println (dataIn, BIN);

    digitalWrite(myClockPin, 1);

  }
  //debuging print statements whitespace
  //Serial.println();
  //Serial.println(myDataIn, BIN);
  return myDataIn;
}


I'm just trying to get some consistent results.

The output should look like this:

0mW
eng dnw up

But I'm getting a bunch of random letters with no consistency when I change the output to byte.
Title: Re: Stealing data sent to an LCD
Post by: robtillaart on Oct 15, 2011, 07:51 pm

Think you must look if the LCD has some sort of clock signal, and synchronize your duino to that.
Title: Re: Stealing data sent to an LCD
Post by: bobhaha on Oct 15, 2011, 08:21 pm
This is the pin config..

1. VSS
2. VDD
3. V0
4. RS
5. R/W
6. E
7 ---- 14
D0----D7

So which pin will give me the clock pin. Personally I think this can all be fixed with proper syncing. The wiring looks right.
Title: Re: Stealing data sent to an LCD
Post by: bobhaha on Oct 17, 2011, 07:50 am
Come on guys.... If you reply to a thread, keep checking back...
Title: Re: Stealing data sent to an LCD
Post by: hellonearthis on Oct 17, 2011, 08:50 am
There is a problem with your logic.

You don't seem to know/test to see when the screen is being updated.
I see you just have a loop that is constantly reading the screens data pins.
You need to work out how to be in sync with the data being send to the screens processor.
You then need to decode what the messages being sent to the screen is,
is it change to cursor location in screen memory or is it an update/change to the value in screen memory.
The character codes on page 15 of http://www.adafruit.com/datasheets/TC1602A-01T.pdf  might help decoding the text.

Also reading arduino-0022\libraries\LiquidCrystal\LiquidCrystal.cpp  may help in working out what's going on.

http://www.adafruit.com/datasheets/HD44780.pdf  Page 5 might also help.
Pin 6 E  - MPU Starts data read/write  that might also be the one to look at as it's this start you want to catch.
Also Page 8
Quote
Busy Flag (BF)
When the busy flag is 1, the HD44780U is in the internal operation mode, and the next instruction will not
be accepted. When RS = 0 and R/W = 1 (Table 1), the busy flag is output to DB7. The next instruction
must be written after ensuring that the busy flag is 0.


A good way to debug your routine is to have one arduino running the helloworld example and a 2nd arduino running your snoop hack.
That way you cut down on the random variables of getting it to work with a random device by getting it going with someone simple.

I am guessing you might be able to get timing/sync/update notification by monitoring pins 4 or 5 of the LCD, but NB that a guess.

Also when displaying your 8 bit codes include the leading 0's so 11100  is 00011100 make it easier to see what's going.

So your current returns where and I think decodes to;  (base on page 17 character codes from http://www.adafruit.com/datasheets/HD44780.pdf)

0011 1000 - 8  
-------------------
0011 1000 - 8
-------------------
0011 1000 - 8
-------------------
0011 1000 - 8
-------------------
0001 1100 - either blank or custom character 5a??
-------------------
0001 1000 - either blank or custom character 1a??  not sure
-------------------
0011 1000 - 8
-------------------
0001 1100 - ...
-------------------
0001 1000
-------------------
0011 1000
-------------------
0001 1000

I reserve the rigth to be wrong :)
Title: Re: Stealing data sent to an LCD
Post by: bobhaha on Oct 18, 2011, 10:33 am
Ok.... Now I'm getting somewhere...

Pin 6 - E is indeed the Clock pin I was looking for.... I modified the code below to only read from the shift register when the clock pin is high.

This is the current code...
Code: [Select]
//**************************************************************//
//  Name    : shiftIn Example 1.1                              //
//  Author  : Carlyn Maw                                        //
//  Date    : 25 Jan, 2007                                      //
//  Version : 1.0                                               //
//  Notes   : Code for using a CD4021B Shift Register     //
//          :                                                   //
//****************************************************************

//define where your pins are
int latchPin = 8;
int dataPin = 9;
int clockPin = 7;
int LEDClk = 3;

//Define variables to hold the data
//for shift register.
//starting with a non-zero numbers can help
//troubleshoot
byte switchVar1 = 72;  //01001000

void setup() {
 //start serial
 Serial.begin(9600);

 //define pin modes
 pinMode(latchPin, OUTPUT);
 pinMode(clockPin, OUTPUT);
 pinMode(dataPin, INPUT);
 pinMode(LEDClk, INPUT);

}

void loop() {

while (digitalRead(LEDClk) == HIGH ){
 //Pulse the latch pin:
 //set it to 1 to collect parallel data
 digitalWrite(latchPin,1);
 //set it to 1 to collect parallel data, wait
 //delayMicroseconds(20);
 //set it to 0 to transmit data serially  
 digitalWrite(latchPin,0);

 //while the shift register is in serial mode
 //collect each shift register into a byte
 //the register attached to the chip comes in first
 switchVar1 = shiftIn(dataPin, clockPin);

 //Print out the results.
 //leading 0's at the top of the byte
 //(7, 6, 5, etc) will be dropped before
 //the first pin that has a high input
 //reading  
 Serial.println(switchVar1, BIN);

//white space
Serial.println("-------------------");
//delay so all these print satements can keep up.


}}

//------------------------------------------------end main loop

////// ----------------------------------------shiftIn function
///// just needs the location of the data pin and the clock pin
///// it returns a byte with each bit in the byte corresponding
///// to a pin on the shift register. leftBit 7 = Pin 7 / Bit 0= Pin 0

byte shiftIn(int myDataPin, int myClockPin) {
 int i;
 int temp = 0;
 int pinState;
 byte myDataIn = 0;

 pinMode(myClockPin, OUTPUT);
 pinMode(myDataPin, INPUT);
//we will be holding the clock pin high 8 times (0,..,7) at the
//end of each time through the for loop

//at the begining of each loop when we set the clock low, it will
//be doing the necessary low to high drop to cause the shift
//register's DataPin to change state based on the value
//of the next bit in its serial information flow.
//The register transmits the information about the pins from pin 7 to pin 0
//so that is why our function counts down
 for (i=7; i>=0; i--)
 {
   digitalWrite(myClockPin, 0);
   //delayMicroseconds(0.2);
   temp = digitalRead(myDataPin);
   if (temp) {
     pinState = 1;
     //set the bit to 0 no matter what
     myDataIn = myDataIn | (1 << i);
   }
   else {
     //turn it off -- only necessary for debuging
    //print statement since myDataIn starts as 0
     pinState = 0;
   }

   //Debuging print statements
   //Serial.print(pinState);
   //Serial.print("     ");
   //Serial.println (dataIn, BIN);

   digitalWrite(myClockPin, 1);

 }
 //debuging print statements whitespace
 //Serial.println();
 //Serial.println(myDataIn, BIN);
 return myDataIn;
}


Here is the output I am getting.... (note the consistency in the output :D) This is in BIN (binary) output mode... (read all of it)

Code: [Select]

-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
0
-------------------
0
-------------------
0
-------------------
0
-------------------
0
-------------------
0
-------------------
0
-------------------
0
-------------------
0
-------------------
0
-------------------
0
-------------------
0
-------------------
0
-------------------
0
-------------------
0
-------------------
0
-------------------
0
-------------------
0
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111

***Repeat***



I have a feeling the Shift register and  arduino can not speak to each other fast enough... Do you think this could be the problem?

As I heat up the Laser sensor I can see shifts in the output... for example...


Code: [Select]
-------------------
11111111
-------------------
11111111
-------------------
11111111
-------------------
0
-------------------
0
-------------------
11111111
-------------------
0
-------------------
0
-------------------
11111111
-------------------
0
-------------------
0
-------------------
11111111
-------------------
0
-------------------
0
-------------------
0
-------------------
11111111
-------------------
0
-------------------
11111111
-------------------
0
-------------------
0
-------------------
11111111
-------------------
0
-------------------
0
-------------------
11111111
-------------------
0
-------------------
0
-------------------
11111111
-------------------
0
-------------------
0
-------------------
11111111
-------------------
11111111
-------------------
11111111
-------------------
11111111
-------------------
0
-------------------
0
-------------------
0
-------------------
0
-------------------
0


Does this make any sense to anyone?

How can I take this and turn it into meaningful data?
Title: Re: Stealing data sent to an LCD
Post by: justone on Oct 18, 2011, 07:28 pm
Just some thoughts. Have not gone thru the whole thread to see what has been discovered so these are only ideas.

First off I would determine if the lcd is being driven in 4 or 8 bit mode. That way you know what to look for in the data being sent.
Is the R/W being used? That adds to the complexity.The data bus is bi-directional.

I would just use the pins of the arduino to hookup to it bypassing the shift register to reduce the problem to its simplest before taking on another.

Treat the enable pin as an interrupt source and in the service routine read the data pins. You will also need to read the RS pin to
see if it's a command or data. If the R/W is being used then that will also need to be delt with.

Driving an lcd is not set in stone- meaning that there are several ways to do it and that would be my main task at hand in finding out how to interface to it.

Hope this helps.


Title: Re: Stealing data sent to an LCD
Post by: graynomad on Oct 19, 2011, 01:35 am
Quote
I have a feeling the Shift register and  arduino can not speak to each other fast enough

Possibly, if you have enough pins I wouldn't bother with the added complication of a serial SR, just read the signals directly through a port as justone suggested.

______
Rob
Title: Re: Stealing data sent to an LCD
Post by: bobhaha on Oct 20, 2011, 03:07 pm
How do I determine if its 4 bit or 8 bit? I've done some research and it only says that 8 bit mode will be used in high refresh scenarios, which this is not.

I put a LCD unit onto some breadboard and connected all the wires to the respective pins. I found that I only needed 8 pins, 2 for LCD power, 2 for backlight power and 4 for data transmission. I forgot to take notes of what pins they were... but when I get home I'll update this post.

Does that mean it's in 4 bit mode? Also does that mean if the E pin is not used it will set it up as always send data and not expect anything returned?
Title: Re: Stealing data sent to an LCD
Post by: graynomad on Oct 20, 2011, 04:04 pm
When writing to the display data is valid when E goes low right?

If you run E to an external interrupt and set the interrupt for a falling edge, then have the ISR read the data from the LCD control pins into an array you should have a mini logic analyzer.

Do this for say 1000 times then stop and spit the data out to the USB to the a terminal program.

If all the bytes have F (or 0) in the upper nibble it's a fair bet that you are running in 4-bit mode. Either way you should have data to analyze.

If your device it writing too fast this may not work, in which case a tight polling loop may be better.

______
Rob
Title: Re: Stealing data sent to an LCD
Post by: bobhaha on Oct 20, 2011, 04:29 pm
I understood approximately 10% of that....

What does this portion mean?

"If you run E to an external interrupt and set the interrupt for a falling edge"

As far as I understand / can work out, I can use the E pin to stop the device sending data to the shift register, then take in the data, release the E pin (return to low state) and repeat? Is that what you mean?
Title: Re: Stealing data sent to an LCD
Post by: graynomad on Oct 20, 2011, 04:54 pm
I would forget the shift register, I don't see what that does for you except add another layer of stuff to do.

I would connect E to one of the external interrupt pins, say INT0.

Now when the E signal drops indicating that there is valid data on the LCD data pins you get an interrupt. Connect the lowest six of the LCD data pins to the analogue inputs, we'll assume it's using 4-bit for the time being and add two more if needed later;

Then you write an ISR to handle and some code to print out the buffer

Code: [Select]

#define BUF_SIZE 100  // change this to a larger number when/if ti works
byte buffer[BUF_SIZE];
byte * ptr = buffer;
int count = 0;

void myISR () {
  *ptr = PINC; // reads the six data signals and stores them in the buffer
  ptr++;
  count++;
}

void setup () {
   attachInterrupt (0, myISR, FALLING);  // look this up in the reference
   Serial.begin (115200);

   while (count < BUF_SIZE) {};  // wait for BUF_SIZE interrupts to occur

   for (int i = 0; i < BUF_SIZE; i++) {
      Serial.println (buffer[i], HEX);
   }
}

void loop () {};


Hopefully that's close enough.

You should then get 100 bytes printed to the screen. If they all have bits 4 and 5 set (or cleared) then you can assume that only bits 0-3 are being used, hence the LCD is working in 4-bit mode.

______
Rob
Title: Re: Stealing data sent to an LCD
Post by: bobhaha on Oct 20, 2011, 05:18 pm
I'm not seeing any output... let me confirm

A0 - E pin
A1 - D0 from LCD
A2 - D1 from LCD
A3 - D2 from LCD
A4 - D3 from LCD
A5 - D4 from LCD
A6 - D5 from LCD
Title: Re: Stealing data sent to an LCD
Post by: graynomad on Oct 20, 2011, 05:28 pm
Arduino doesn't have an A6, or do you have a Mega?

______
Rob
Title: Re: Stealing data sent to an LCD
Post by: bobhaha on Oct 20, 2011, 05:30 pm
It's a nano. It has up to A7. Is this configured correctly?
Title: Re: Stealing data sent to an LCD
Post by: graynomad on Oct 20, 2011, 05:33 pm
OK I see, then try

D2 - E pin

A0 - D0 from LCD
A1 - D1 from LCD
A2 - D2 from LCD
A3 - D3 from LCD
A4 - D4 from LCD
A5 - D5 from LCD

______
Rob
Title: Re: Stealing data sent to an LCD
Post by: bobhaha on Oct 20, 2011, 05:38 pm
Still nothing on serial monitor....

If I go along the outputs with a small LED I'm getting activity on D4 and D5 (pin 12 & 13 respectively)

EDIT: also the TX light is staying on continuously.
Title: Re: Stealing data sent to an LCD
Post by: graynomad on Oct 20, 2011, 05:41 pm
put

serial.print (".");

in the ISR to see if it's ever being entered.

______
Rob
Title: Re: Stealing data sent to an LCD
Post by: graynomad on Oct 20, 2011, 05:44 pm
oops, change the count definition to

volatile int count = 0;
Title: Re: Stealing data sent to an LCD
Post by: bobhaha on Oct 20, 2011, 05:45 pm
Ok, now we are getting somewhere.... output is exactly as shown below.

...Oÿîîîîîîînÿnsnsnsnsnsnsnsnsnsnÿîîîîîîîîîînÿnsnsnsnsnsnsnsnsnsnÿîîîîîîîîîînÿnsnsnsns
Title: Re: Stealing data sent to an LCD
Post by: bobhaha on Oct 20, 2011, 05:47 pm
Ok... changed the count definition....

Here is the output...

Code: [Select]
...3F
3F
3F
3F
3F
3F
3F
3F
3F
0
0
30
0
20
0
20
10
30
0
0
0
0
0
0
0
10
20
0
0
0
20
0
10
0
0
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
0
0
30
0
20
0
20
10
30
0
0
0
0
0
0
0
10
20
0
0
0
20
0
10
0
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
0
0
30
0
20
0
20
10
30
0
0
0
0
0
0
0
10
20
0
0


EDIT: there is 103 periods (.) before the output... but the forum cuts it out.
Title: Re: Stealing data sent to an LCD
Post by: graynomad on Oct 20, 2011, 05:48 pm
Take out the print from the ISR.
Title: Re: Stealing data sent to an LCD
Post by: bobhaha on Oct 20, 2011, 05:51 pm
Code: [Select]
3F20
0
20
0
20
0
0
0
0
10
0
20
20
0
0
0
0
20
20
0
10
10
10
0
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
0
0
30
0
0
0
20
10
10
30
20
0
20
0
20
0
20
0
0
0
0
10
0
20
20
0
0
0
0
20
20
0
10
10
10
0
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
0
0
30
0
20
0
20
10
10
30
20
0
20
0
20
0
20
0
0
0
Title: Re: Stealing data sent to an LCD
Post by: graynomad on Oct 20, 2011, 05:53 pm
We we're getting something but it doesn't look very promising.

WHat is being displayed on the LCD

______
Rob
Title: Re: Stealing data sent to an LCD
Post by: bobhaha on Oct 20, 2011, 06:04 pm
It should be this....

0mW
EN DN UP
Title: Re: Stealing data sent to an LCD
Post by: graynomad on Oct 20, 2011, 06:05 pm
Most of those displays have a minimum E pulse width of 250-300nS I think. If yours is using such short pulses the code will not be quick enough.

______
Rob
Title: Re: Stealing data sent to an LCD
Post by: bobhaha on Oct 20, 2011, 06:10 pm
I'm pretty sure it works off 4800 baud rate.

Would a shift register work at all.... or is the interface speed between the arduino and shift register still too fast?
Title: Re: Stealing data sent to an LCD
Post by: graynomad on Oct 20, 2011, 06:12 pm
Quote
I'm pretty sure it works off 4800 baud rate.

I thought we determined this was NOT a serial LCD.

If you're using E and the data pins that it can't be, in which case 4800 baud doesn't mean anything.

______
Rob
Title: Re: Stealing data sent to an LCD
Post by: bobhaha on Oct 20, 2011, 06:17 pm
Oh my bad... Sorry, its obviously not a serial LCD. The only speed that the manufacturer supplies is 4800 baud for the main processor which by the way is a PIC14F628-26/P
Title: Re: Stealing data sent to an LCD
Post by: graynomad on Oct 20, 2011, 06:19 pm
Try this code
Code: [Select]
#define BUF_SIZE 100  // change this to a larger number when/if it works
byte buffer[BUF_SIZE];
byte * ptr = buffer;

void setup () {
   Serial.begin (115200);

   for (int i = 0; i < BUF_SIZE; i++) {
      while ((PIND & 4) == 0) ;  // wait for E = LOW
      *ptr = PINC;
       ptr++;
      while ((PIND & 4) != 0) ;  // wait for E = HIGH
    }

   for (int i = 0; i < BUF_SIZE; i++) {
      Serial.println (buffer[i], HEX);
   }
}

void loop () {};


Then I have to hit the sack.

______
Rob
Title: Re: Stealing data sent to an LCD
Post by: bobhaha on Oct 20, 2011, 06:37 pm
Code: [Select]
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10
10


EDIT: I'm also getting outputs like this....

Code: [Select]
0
0
0
0
0
0
0
10
10
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Title: Re: Stealing data sent to an LCD
Post by: graynomad on Oct 20, 2011, 06:48 pm
Hmm, different but no better.

There's either a bug in my code or the pulse is too short to be reliably trapped by the code.

You said
Quote
It should be this....

0mW
EN DN UP


What we are doing should not affect anything so the display should be working as per normal. Is it?

You may need an octal latch to catch the data, same as you were doing with the shift reg but use a latch instead and feed the latch outputs into A0-5 and revert to my first piece of code that used the interrupts.

Anyway it's too late here to think clearly about it.

______
Rob
Title: Re: Stealing data sent to an LCD
Post by: bobhaha on Oct 20, 2011, 06:54 pm
Well I need to take the LCD screen out of the socket to gain access to the data. But it should look like that yes.

I noticed when I put it on bread board and tried your code out the screen would fill with pixels in a loading kind of sequence. I thought that would have to do with floating pins so I removed the LCD. Right now the arduino is in a breadboard and the pins are directly connected to the socket, no LCD in between to skew results.

I'm from Sydney by the way.

Time for me to start my assignment... have a think about it and I will too... and if you can think of anything... just let me know.

You've been a great help so far!

Thanks!!!
Title: Re: Stealing data sent to an LCD
Post by: justone on Oct 20, 2011, 08:10 pm
Sorry if I haven't looked at everything again but it looks like you are moving along.

You mentioned something about the PIC and 4800 baud. If the PIC is only being used to drive the LCD by receiving serial commands then it would be easier to "steal " those than trying to dechiper the ones on the LCD.

It might help to at least define the model# of what you are interfacing to see if there is any data on it to help in this.
Pictures?

Assuming that you still need to look at the pins of the LCD then the LCD still might be driven by using the R/W function rather than by delays so by removing the LCD it would never be able to respond correctly.If you have gotten your program to trigger on the falling edge of E (enable) then I would at first see if the R/W (pin5) is being used. The R/W would be driven to the LCD so it does not to be in the circuit to test this.Just log that for awhile.If all you see are 0's then it's a safe bet that the programmer just used delays for timing. If the R/W is being used then the LCD must be in the circuit to be able to read anything (it could be fooled but that's another thing) useful on the data bus. So when R/W is High just ignore what is on the data bus.

I would also just look at DB4-DB7 (upper nibble) because even though it can be an 8 bit bus pretty much of the start up commands are  done using the upper nibble.

What you are really after is the initial sequence to see how this LCD is being driven.



Title: Re: Stealing data sent to an LCD
Post by: bobhaha on Oct 21, 2011, 12:23 pm
It's a kind homebrew / semi professional device. I bought it second hand (notice the hot glue :S)

I wouldn't be surprised if it was programmed with just delays it's not a very industrial device.

Here some pics if it helps... (sorry about the crappy phone pics)

(http://dl.dropbox.com/u/14298539/LPM/IMAG0768.jpg)

(http://dl.dropbox.com/u/14298539/LPM/IMAG0769.jpg)

(http://dl.dropbox.com/u/14298539/LPM/IMAG0770.jpg)

(http://dl.dropbox.com/u/14298539/LPM/IMAG0772.jpg)

(http://dl.dropbox.com/u/14298539/LPM/IMAG0771.jpg)

(http://dl.dropbox.com/u/14298539/LPM/IMAG0773.jpg)
Title: Re: Stealing data sent to an LCD
Post by: graynomad on Oct 21, 2011, 12:47 pm
Quote
I'm from Sydney by the way.

So I guess it was even later for you then, I'm in WA at present.

Do you have an octal latch to hand, a '374, '373 or similar? 373 would be best probably.

______
Rob
Title: Re: Stealing data sent to an LCD
Post by: bobhaha on Oct 21, 2011, 01:14 pm
Not on hand no.... But I can pick one up tomorrow.

This is what you are referring to correct?
http://jaycar.com.au/productView.asp?ID=ZS5273&keywords=octal+latch&form=KEYWORD

Datasheet: http://jaycar.com.au/products_uploaded/ZC4858.pdf

Looks like its a 373 as well.
Title: Re: Stealing data sent to an LCD
Post by: graynomad on Oct 21, 2011, 02:36 pm
Yes that's what I had in mind, but I've decided a '374 would be better

http://jaycar.com.au/productResults.asp?keywords=74ls374&keyform=KEYWORD&SUBMIT.x=0&SUBMIT.y=0 (http://jaycar.com.au/productResults.asp?keywords=74ls374&keyform=KEYWORD&SUBMIT.x=0&SUBMIT.y=0)

This is the circuit I'm thinking of.

(http://www.robgray.com/temp/lcd-data-latch.jpg)

Note you need an inverter as well.

This should latch the data and hold it until the next read/write to/from the LCD. This will give the Arduino longer (the entire time between LCD accesses) to grab the data, it still may not be long enough, in which case you better go buy a logic analyzer :)

Use the interrupt-driven code I first posted.

As justone says you may want to look at R/W as well and even RS, if it is working with 8 bits you can add a second 374 to grab these two control lines as well.

______
Rob
Title: Re: Stealing data sent to an LCD
Post by: bobhaha on Oct 21, 2011, 02:57 pm
I assume you mean a HEX inverter?

Any model number / info specific? The 741G04 doesn't give any results...

While I'm at Jaycar, what type of logic analyzer would I need? May as well grab one to test out.
Title: Re: Stealing data sent to an LCD
Post by: graynomad on Oct 21, 2011, 03:21 pm
Quote
741G04

1G == one gate, I only use SMDs so that's a single-inverter version of the 74xx04 (note it only has 4 pins). Yes get a HEX DIP version, LS, HCT etc, doesn't really matter I think.

Quote
While I'm at Jaycar, what type of logic analyzer would I need?

No chance at Jaycar I'm afraid. I use one of these

http://www.saleae.com/logic/ (http://www.saleae.com/logic/)

Only $150 and will sort this stuff out in no time. I never leave home without one :)

If you plan to spend any time with microprocessors do yourself a favour and buy one, or something similar.

______
Rob
Title: Re: Stealing data sent to an LCD
Post by: bobhaha on Oct 24, 2011, 03:29 am
Ok, so I've got the octal latch, but I don't think I have the correct inverter.

The one the guy gave me is a UA741CN. He said it was a voltage regulator and has the exact same function. It has 8 pins how ever :/

Jaycar doesn't have a datasheet for it either. But there is an external datasheet here

http://www.datasheetcatalog.org/datasheet/SGSThomsonMicroelectronics/mXyywtw.pdf

I have the DIP8 version.

Title: Re: Stealing data sent to an LCD
Post by: graynomad on Oct 24, 2011, 03:55 am
Typical of most (all?) employees in so-called electronics stores these days, they could find their arse with both hands and a map. Now if you had a question about a laughing clock or toy helicopter you'd be right.

Quote
He said it was a voltage regulator

About as wrong as you can get.

Quote
has the exact same function

Wrong again.

The 741 is an opamp, I grant that it can be used as an inverter but it is not an equivalent to a 74xx14/04.

I think you need to find a new shop :), actually don't bother, I think they're all the same these days.

This is what you need

http://jaycar.com.au/productView.asp?ID=ZS5004&keywords=74ls04&form=KEYWORD (http://jaycar.com.au/productView.asp?ID=ZS5004&keywords=74ls04&form=KEYWORD)

or

http://jaycar.com.au/productView.asp?ID=ZS5014&keywords=74ls14&form=KEYWORD (http://jaycar.com.au/productView.asp?ID=ZS5014&keywords=74ls14&form=KEYWORD)

Have you ordered your logic analyzer yet?

______
Rob
Title: Re: Stealing data sent to an LCD
Post by: bobhaha on Oct 24, 2011, 05:43 am
Actually funny story... when I was there, one of the employees were showing off a 90 Lumen torch to a group of cops and boasting how good it was compared to all the rest of the torches...

I just walked by and said check the lumen rating... then tapped on a torch half the size with 190 Lumen rating.

I know I should have asked for a second opinion cause this guy has given me problems before. I'll go back tomorrow for round two.
Title: Re: Stealing data sent to an LCD
Post by: justone on Oct 24, 2011, 08:14 pm
Don't know why all the troubles with getting the data but I do see where you are trying to grab the data on the falling edge E (enable pin).

I went and looked at what I've written for the avrs (I usually write in assembly and have just gotten into the arduino) and I also looked at the arduino library for the lcd's . The enable pin is usually held low when not writting to it. The data is placed on the bus then the enable is brought high for a brief period then it is brought low to write the data to the display.

If it were me I would enable the interrupt on the RISING edge of the enable pin.
Title: Re: Stealing data sent to an LCD
Post by: graynomad on Oct 25, 2011, 01:38 am
You may be right justone, the data sheet I looked at showed the data being valid on the falling edge and I assumed that they are all the same but maybe not.

In that case, as you say, change the interrupt level and ditch the inverter.

Maybe it will just work without the extra hardware if that's the problem.

______
Rob
Title: Re: Stealing data sent to an LCD
Post by: bobhaha on Oct 25, 2011, 07:14 am
Ok, I've edited the code to work on a rising edge... this is the output I'm getting in HEX

Code: [Select]
0
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F
3F


And this in BIN

Code: [Select]
0
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
111111
Title: Re: Stealing data sent to an LCD
Post by: graynomad on Oct 25, 2011, 07:34 am
There are 4 combinations to try.

Rising/falling edge.
With/without inverter.
______
Rob
Title: Re: Stealing data sent to an LCD
Post by: NiHaoMike on Nov 12, 2011, 05:19 am
Can you reverse engineer the PCB? I would guess that it's amplifying the signal to be digitized by the PIC for display. If you can reconnect that PIC input to a potentiometer, you can plot voltage input vs. display output and reverse engineer an equation for conversion.