Arduino as SPI slave with output to LCD? - Page 1
Forum section: electronics / projects

author: degreelessengineer
author_rank: Newbie
timestamp: December 31, 2019, 11:02:42 pm
content: I have been working on a Nikon flash which suffered a TAB bonding failure on the main lcd panel. I have been unable to locate an original LCD panel and have been connecting up various SPI displays of a similar resolution to try and get it working to no avail.I know the original pinout for the SPI communication and can see data coming from it. I am wondering if it would be possible to use an Arduino to read the SPI data and store the data into a variable.I have another working flash that I can read SPI data from and compare with what is displayed on screen. Using the second working flash, I would like to compile a list of SPI data that corresponds to what is displayed on the screen and output it to a standard LCD panel. Would this be possible with an Arduino?

author: Zapro
author_rank: Contributor
timestamp: January 01, 2020, 12:52:20 pm
content: Should be doableIf you can find a service manual for the flash, it might contain some hint on the communication on the display.// Per.

author: mikerj
author_rank: Super Contributor
timestamp: January 01, 2020, 01:35:46 pm
content: Note that SPI is a time critical protocol, unlike I2C the slave has no means of making the master device wait for it to process incoming or outgoing data. Depending on the clock speed this can be problematic when a master gives little turn around time e.g. the master sends a register address to to read and expects the slave to send the first bit of data on the next SCK clock cycle. Small, fast low latency SPI interrupt handlers on the slave are the order of the day.

author: madires
author_rank: Super Contributor
timestamp: January 01, 2020, 04:12:52 pm
content: For a low SPI clock rate it might work. But the main task is to figure out the LCD controller by looking at the commands sent. If you know the LCD controller you'll possibly find a matching display.

author: jpanhalt
author_rank: Super Contributor
timestamp: January 01, 2020, 05:39:21 pm
content: When you read the SPI from the good device, what are the characters? Is it 8-bit or 16-bit ( 2 sequential 8 bits). That is, are the characters just ASCII values (seems unlikely), a mixture of ASCII characters and commands, or values that you cannot interpret.You will need to separate screen navigation commands from characters, and if the Nikon screen was specially designed (i.e., has preset characters) you will have a lot of decoding to do. Is the Nikon screen a character screen or graphical screen? By graphical, I mean can individual pixels or bytes of pixels be addressed?I would start with deciphering the data from the good screen. SPI is an easy protocol to use (it just swaps bits) and can work down almost to DC, so that by itself should not be a hurdle.

author: degreelessengineer
author_rank: Newbie
timestamp: January 03, 2020, 03:06:31 am
content: The Nikon screen is a graphical 132x64 display according to the service manual. The service manual contained no information about the communication. The pinout to the display indicates that it is an SPI display. My logic analyzer is still on the way so I am not able to decode the signals just yet.As for locating a similar controller, I am unable to find any information on the manufacturer or model of the original display. How would I go about finding out which COG chip the display uses?

author: jpanhalt
author_rank: Super Contributor
timestamp: January 03, 2020, 03:45:27 am
content: OK, now we know it is a graphical display. Can you show a picture of the good one? Are there characters and graphics, color? Are you sure it is LCD? How may contacts are there on the connection?Look at a character , with a magnifying class. What size is it (pixel x pixel)? None of the graphical displays I have used have a built-in character map, so your screen may be painted one pixel wide by one pixel or byte high.Here is what part of a 5x7 ASCII table looks like:0x3E, 0x51, 0x49, 0x45, 0x3E,// 00x00, 0x42, 0x7F, 0x40, 0x00,// 10x42, 0x61, 0x51, 0x49, 0x46,// 2Here are the same bytes padded to fill 8 spaces -- the first and last two are always 0:0x00,0x3e,0x51,0x49,0x45,0x3e,0x00,0x00 ; 00x00,0x00,0x42,0x7f,0x40,0x00,0x00,0x00 ;10x00,0x42,0x61,0x51,0x49,0x46,0x00,0x00 ;2There are, of course, other fonts and character sizes. You have a bit of work ahead of you. If you have any idea of the controller, it will make it easier. Otherwise, take a common one and look for the same control codes.There should be one line (chip select, CS) that goes low and stays low during each transmission. There may be another line that goes low when the transmission is a command/control versus when it is data.You have a lot of work ahead of you.Alternatively, find a similar screen with the same number of connections, verify Vcc and Vss, and plug it in. If it is backlit, there may be other connections.

author: madires
author_rank: Super Contributor
timestamp: January 03, 2020, 02:38:26 pm
content: Quote from: degreelessengineer on January 03, 2020, 03:06:31 amMaybe ST7565R (monochrome), but there are more LCD controllers for that resolution. Please post the pinout. The signal names might give another hint.Quote from: degreelessengineer on January 03, 2020, 03:06:31 amBy analyzing the commands sent to the LCD controller since controllers have specific command sets. Meanwhile you could download data sheets of 132x64 controllers.