GLCD 192x32 manual driving (no library)

Hi all.

Could someone please provide me any info on how to manually (via port manipulation, no library! ) drive the display on the attached picture..? Basically, I cant really find any useful info on how its made in the core itself (I'm not interested in the library written functions).

This is taken from schematics, and it's pretty much all I know about the display. Resolution is 192x32 dot matrix, monochrome.

Thanks**!

Hi

It is difficult to say anything, without knowing more information about this display.

Indeed looking for a 192x32 in the internet does not help much. All displays i found are based on the ST7920 controller. However the schematic does not fit to the ST7920. I personally assume it is a ST7565 controller.

The correct controller manual will answer your question on how to use this display without library.

Oliver

Hi, @olikraus.

Thank you for your answer.

Yes, I know it is difficult to say anything else, but the thing is just in that, → I have no idea what is the controller of the display. It is fit on the PCB which have 2 of these displays, and is driven in some kind of multiplex. (Data pins are common, so are the CS, Reset and A0 pins, while E2# and E1# are unique per display.
Unfortunately, the manufacturer is only telling me it’s custom made display for them, and they don’t want to provide any datasheet or any info at all. It seems like they’re not happy with the idea I’m trying to make my own controller for their PCB! (it’s funny though. I got the schematics easily, but no way to provide driver’s datasheet…)

Other than that, is there any guess you could point me out to, to try out several instructions & data writes, to try out if any of them will manage to get pixels shown? I’m cool with only writing one byte to it successfully, then I can build from that.

But, is the code like this bellow (nevermind the delays, I use them just for tryout, instead of seeking for busy flag) ever gonna work, if I manage to get correct bit order at all, or is it not ok at all?

PORTD = 0x02; // (data pins value)
delayMicrosecons(100); // (for instructions to be surely done by the time of new data send)
PORTC = 0x01; // (control CS/Reset / E2# pins value)

I never used port manipulation before, nor GLCD without library… :confused:

Thanks!

Controlling a glcd is not trivial. It isn't as simple as just twiddling a few signal lines. Yes there is some signal line twiddling at the very lowest level but then it takes quite a bit of code sending module specific commands just to get the modules initialized and then quite a bit of code to do things like drawing font glyphs and drawing functions.
Also, in some cases at the very low h/w level there are timing requirements for the signals and delays that must be honored. If you violate the timing it won't work properly or at all.
In terms of AVR raw port i/o, that is the last thing I'd be worried about right now as AVR raw port i/o is for making things fast. Before trying to make things fast, I'd focus on just trying to make it work and digitalWrite(), digitalRead() is fine for that.

What exactly do you have?
Where did this display come from?
Is it just the 27 pin glcd module or is is part of something else?
If it is more than just the 27 pin glcd module what is it?
And then is it currently working with something else or is just a module that you are trying to make work?

It looks like it is 3v so be careful not to hook it up to 5V arduino signals as that may fry the module.
It also looks like they are using it in write only mode based on the RD signal being tied high.
This means that if you can't get access to RD signal to change that, you won't be able to read the status information or any of the glcd module bit memory data even you do eventually figure out the chipset.

Trying to reverse engineer this will get very challenging if you don't know what glcd chipset is being used.
Based on the pins I agree with Oliver that it looks like a ST7565 chip set, but some of the SED series chipsets have similar A0, CS, and E signals.

If you have this display working in something else you could attach a logic analyzer to look at the signals to see how they used in a working system. If you examine the signals, this will probably provide enough information to be able to determine which chip set is on the module.

For the amount of work involved, I would consider buying another module with a known chipset that perhaps even has a library already written for it.

I fully agree with Bill. It is probably not worth to do the reverse engineering.

However, if you still like to continue, I assume it is a ST7565 controller or at least some controller which is more or less compatible (e.g. UC1701).
The schematic implements the charge pump for the ST7565, so the charge pump has to be enabled with 0x02f command.
If you send the following bytes after reset while setting A0 to GND, you may see some random pixel:

  0x0a2,                /* LCD bias 1/9 */
  0x02f,                /* all power  control circuits on */
  0x027,                /* set V0 voltage resistor ratio to large */
  0x081,                /* set contrast */
  0x018,                /* contrast value*/
  0x0a4,                /* normal display (not all on) */
  0x0af,                /* display on */

Additionally you should be able to measure around 10V at some of the CAP pins and probably also at Vout. If you see the 10V and some random pixel, then it is a ST7565 based display...

Oliver

bperrybap:
Controlling a glcd is not trivial. It isn't as simple as just twiddling a few signal lines. Yes there is some signal line twiddling at the very lowest level but then it takes quite a bit of code sending module specific commands just to get the modules initialized and then quite a bit of code to do things like drawing font glyphs and drawing functions.

As said, at the moment I'm after actually getting it to show any pixels at all.

bperrybap:
Also, in some cases at the very low h/w level there are timing requirements for the signals and delays that must be honored. If you violate the timing it won't work properly or at all.
In terms of AVR raw port i/o, that is the last thing I'd be worried about right now as AVR raw port i/o is for making things fast. Before trying to make things fast, I'd focus on just trying to make it work and digitalWrite(), digitalRead() is fine for that.

Basically, using PORTx is for the sake of writing the whole byte, instead of pin by pin...

bperrybap:
What exactly do you have?
Where did this display come from?
Is it just the 27 pin glcd module or is is part of something else?
If it is more than just the 27 pin glcd module what is it?
And then is it currently working with something else or is just a module that you are trying to make work?

What I have is a device with two boards, one of it having 5 such displays, and the other just 2. The later is the one I'm fooling around.
It's not the display itself, its the whole PCB. And it's driven via D0-D7 pins, + A0-A6 pins (these are used for addressing board and element (LCD1, LCD2 via E1#, E2# pins...), using HC138 and HC238 chipsets Meanwhile, D0-D7 are connected to several other HC373 chips as well. But all this is irrelevant, as I fixed the A ports so that I have just 2 possible scenarious: Either having D0, D1 and D2 to control pins CS, Reset and A0, OR! having E2# enabled (set it from H to L). This is also all that the original controller does for the LCD control. (Note: Once CS, Reset and A0 are set, when switching to E2#, they stay in their last state, as they are latched via HC373!)

This is long story short, but this is all irrelevant, as I have already manipulated this manually so that I have access to it. The question now remains, what to write to pins CS, Reset, A0 when E2# is HIGH, and what to write to D0 - D7 when E2# is LOW (active?).

It is currently already working with its original controller, but since they're driving that much displays on single connection, + put a heavy load on the processor that refreshes them, it is often noticed that the LCDs are refreshing from 0,5 up to the 3 seconds. I'm basically after to get them work so that I can feed data I want onto them.

bperrybap:
It looks like it is 3v so be careful not to hook it up to 5V arduino signals as that may fry the module.
It also looks like they are using it in write only mode based on the RD signal being tied high.
This means that if you can't get access to RD signal to change that, you won't be able to read the status information or any of the glcd module bit memory data even you do eventually figure out the chipset.

5V to 3V reducer is already on board. The whole board is powered via 5V, and the Data pins are accepted as 5V. This is confirmed.

RD -> I know, and I guess that if they can work with that, I should be able to as well. Right?

bperrybap:
Trying to reverse engineer this will get very challenging if you don't know what glcd chipset is being used.
Based on the pins I agree with Oliver that it looks like a ST7565 chip set, but some of the SED series chipsets have similar A0, CS, and E signals.

If you have this display working in something else you could attach a logic analyzer to look at the signals to see how they used in a working system. If you examine the signals, this will probably provide enough information to be able to determine which chip set is on the module.

I know, therefore I'm asking for any help that could speed this up for me and help me figure out what it could be. Even if this means trying multiple methods to see if any will trigger some pixels...
I'm still waiting for the 16ch logic analyzer to be delivered, but even once it does, I assume there's gonna be whole plenty of information there, since it's same bus for all those displays and multiple LED diodes and pushbuttons. (Yes, A0-A6 selects what data are D0-D7 sending/receiving to/from the controller).

bperrybap:
For the amount of work involved, I would consider buying another module with a known chipset that perhaps even has a library already written for it.

The fact is, that this is already made, and I want to make used out of it. + it is way cheaper than making my own (it has enclosure and all..).

  • that, I know at least 3 person who has this same device, so if I manage to figure it out, it's gonna be helpful for all of us.

I'm also totally intending to put this as freeware / opensource, but unfortunatelly can't tell exactly what it is publicly. Can provide more info via PM though!

Thank you so far for your info, looking forward for anything more!*

Best**

olikraus:
I fully agree with Bill. It is probably not worth to do the reverse engineering.

However, if you still like to continue, I assume it is a ST7565 controller or at least some controller which is more or less compatible (e.g. UC1701).
The schematic implements the charge pump for the ST7565, so the charge pump has to be enabled with 0x02f command.
If you send the following bytes after reset while setting A0 to GND, you may see some random pixel:

  0x0a2,                /* LCD bias 1/9 */

0x02f,                /* all power  control circuits on /
  0x027,                /
set V0 voltage resistor ratio to large /
  0x081,                /
set contrast /
  0x018,                /
contrast value*/
  0x0a4,                /* normal display (not all on) /
  0x0af,                /
display on */




Additionally you should be able to measure around 10V at some of the CAP pins and probably also at Vout. If you see the 10V and some random pixel, then it is a ST7565 based display...

Oliver

Yes, due to the facts posted in the answer just above this → I do wish to continue. And thank you for your support and help!!

Just one little thing:
Whyle sending these bytes. should E2# be HIGH or LOW? (note, by default on the circuit it’s HIGH!)

For the ST7565 one byte is entered with a low pulse on WR signal, which is E2 in your schematic. This means, you must first apply the byte to the data signals and 0V to A0, then give a high - low - high pulse on E2. See the timing diagram in the ST7565 datasheet.

Oliver

Edit: It must be logical zero for A0 (command mode)

Given Oliver's u8glib supports the ST7565, I'd hook up display and use that library.
Why go through all the trouble re-inventing the wheel since writing a glcd library (which is essentially what you talking about doing) is not trivial?

But if you want to go down the DIY path,
first thing is to understand the low level signal protocol. That will be in the chipset documentation. It will explain how the signals work and the necessary timing.
Study the ST7565 documentation to understand how the low level signaling works.
Once you understand that, you can write low level data and command routines.
Once you have those written you can write the higher level initialization routines to initialize the chips. The information on the commands and their options and parameters will be in the chipset documentation.
Once you have the chips initialized, you can then start to write the higher routines to do things like turn on/off pixels.
Keep in mind that up until this point, it can be very difficult to debug since the display will typically not show any visible signs of working until you actually start to write data to it to turn on pixels.
A logic analyzer is very useful during the low level debugging as you can look at the signals and make sure they are working the way the chipset documentation describes and have the proper timing.

Once you have the ability to turn on/off pixels, you can write higher routines to do things like draw lines, circles, shapes, etc...
To render text on the display you will have to find or create font data and then write the routines to read that font data and draw the corresponding pixels, and then handle things like inter character spacing, line wrapping, scrolling etc....

Reading font data on the AVR sucks because of the AVR's internal architecture that requires using all the PROGMEM macros and indirect access routines. While it works, it is messy and more complicated than on the other processors. On all the other processors it is much easier since they can access const data directly.

When writing the code to handle drawing pixels, you will have to decide if you are going to buffer the pixel data or read the pixel data from the glcd memory. It can be done either way. And then if you decide to buffer the pixel data, do you buffer all the pixels on the display or just a portion of the pixels?
u8glib buffers a portion of the display to save memory.
openGLCD either buffers none of the display or all of it, but it currently doesn't support ST7565

bperrybap:
Given Oliver's u8glib supports the ST7565, I'd hook up display and use that library.
Why go through all the trouble re-inventing the wheel since writing a glcd library (which is essentially what you talking about doing) is not trivial?

This is because as said in the posts before -> It's not possible to use the library, since it can't use shared pins. -> The A0, Reset and CS pins in my case are the same as D0, D1 and D2 via latched switch, using other addressing pins, which determine whether the D0, 1 and 2 are delivered to the upper 3 control pins or not. So library is out of the way, and tearing it apart seems more time consuming than to try and figure out at least single pixel write the manual DIY way.

bperrybap:
But if you want to go down the DIY path,
first thing is to understand the low level signal protocol. That will be in the chipset documentation. It will explain how the signals work and the necessary timing.
Study the ST7565 documentation to understand how the low level signaling works.
Once you understand that, you can write low level data and command routines.
Once you have those written you can write the higher level initialization routines to initialize the chips. The information on the commands and their options and parameters will be in the chipset documentation.
Once you have the chips initialized, you can then start to write the higher routines to do things like turn on/off pixels.
Keep in mind that up until this point, it can be very difficult to debug since the display will typically not show any visible signs of working until you actually start to write data to it to turn on pixels.
A logic analyzer is very useful during the low level debugging as you can look at the signals and make sure they are working the way the chipset documentation describes and have the proper timing.

This is true. I'm no expert in low level data, so I do need some clarifications here and there, but I did review several documentations about this. However, unfortunately there is no docs about this very display, and I did not check mentioned ST7565's datasheet very detailed, to be honest.

bperrybap:
Once you have the ability to turn on/off pixels, you can write higher routines to do things like draw lines, circles, shapes, etc...
To render text on the display you will have to find or create font data and then write the routines to read that font data and draw the corresponding pixels, and then handle things like inter character spacing, line wrapping, scrolling etc....

Reading font data on the AVR sucks because of the AVR's internal architecture that requires using all the PROGMEM macros and indirect access routines. While it works, it is messy and more complicated than on the other processors. On all the other processors it is much easier since they can access const data directly.

When writing the code to handle drawing pixels, you will have to decide if you are going to buffer the pixel data or read the pixel data from the glcd memory. It can be done either way. And then if you decide to buffer the pixel data, do you buffer all the pixels on the display or just a portion of the pixels?
u8glib buffers a portion of the display to save memory.
openGLCD either buffers none of the display or all of it, but it currently doesn't support ST7565

I'm basically not after any fonts etc at all. Firstly, I want to be able to just write some pixels on the lcd itself - to get it workin'.

Once this is done, I'm gonna apply the logic I already did for the other stuff, and simply make byte-to-display converter, and let it simply pass input pixels to the lcd. That's the goal of the project. The fonts, bitmaps etc are then up to the PC to work out and translate. This is gonna be pure "dummy" controller for the PC based app. :slight_smile:

Bdw thanks for tons of interesting informations in your post though! You guys seem to have these things in your hand! :slight_smile:

Ps: Oliver, I'll get right back to you once I try these out. Thanks so far!

Nah, I can't get this thing working with the code you provided, @Oliver. The screen remains blank, even after sending the comands you wrote.

I'm doing it like this:

  1. Set LCD's CS to 0, Reset to 1, A0 to 0 and backlight to 1.
  2. I set data pins to your values, in exact order, 1 by 1, changing them after step 3) between each.
  3. I give E2 low - high pulse (select E2, which gets it to Low, then deselect E2 which sets it to High). Time between - I tried from 50uS up to 1mS for enable pin, but no luck.

Display backlight is turned on successfully, but that's about it what I get to do with it.

Just to confirm from the scheme: All three, CS, Reset and A0 are 0 active, correct? That means, that setting CS to 0, Reset to 1 and A0 to 0 should make it listen to instructions, right?

Best regards,

M.

Hi

Again datasheet might be more accurate.

Start with the following levels:
Reset = 1
CS = 1
A0 = 0
E2/WR = 1
D0..7 = anything

Step 1:
Do a long (>100ms) low pulse on reset line (high - low - high transitions)

Step 2:
Set CS to low (GND). It is important to do this only when reset is high. This means, this step must be done while reset is high.

Step 3:
Apply suitable values to A0 and D0..7

Step 4:
Send a low pulse on E2/WR (high - low - high transitions)

Step 5:
Go back to Step 3 as long as there is data available.

There are a couple of unknown things here:

  • Are we right in assuming the ST7565 as a controller
  • Is the hardware wired as expected (schematic fits to your hardware?)
  • Is your software doing the right thing?
  • Is the sequence from me suitable to bring up any pictures or is the sequence wrong in some way?
    have a look here for a working sequence: Google Code Archive - Long-term storage for Google Code Project Hosting.
    maybe update your sequence to update enable all pixel for example (see the datasheet for this command)

All in all: You must first ensure that your hardware is working: You have to check the digital lines whether ALL lines are working correctly. You have to read the datasheet and understand the commands, which are accepted by the controller.

Oliver

Hi! Once again, thank you so much for taking time for me and my troubles... :slight_smile:

First, I'll start with your latest paragraph:

olikraus:
There are a couple of unknown things here:

  • Are we right in assuming the ST7565 as a controller
  • Is the hardware wired as expected (schematic fits to your hardware?)
  • Is your software doing the right thing?
  • Is the sequence from me suitable to bring up any pictures or is the sequence wrong in some way?
    have a look here for a working sequence: https://code.google.com/p/u8glib/source/browse/csrc/u8g_dev_st7565_dogm128.c
    maybe update your sequence to update enable all pixel for example (see the datasheet for this command)

All in all: You must first ensure that your hardware is working: You have to check the digital lines whether ALL lines are working correctly. You have to read the datasheet and understand the commands, which are accepted by the controller.

  • No idea, but I silently hoped we (you) are. :slight_smile:

  • Schematic is from this exact piece of hardware. The pcb with display is a console, and the schematics are provided from the manufacturer for this exact model of console, for this exact pcb. Also, everything else works just as on schematics (there are buttons, LEDs, sliders... see the full schematics bellow in the links, please...)

  • the software should do it right as per your description. Given the fact that I'm reading buttons, sliders and setting LEDs to light up correctly as expected, I think I can fairly assume I'm doing the right steps in the software part... I hope. -> Code attached bellow (and explained)

-No idea. Could be right, or could be right but not for this LCD... that's the thing about guessing here... :confused:
I noticed that if the LCD is connected to it's original controller, at initialization (before any pixels are set) the pixels become "visible" like the contrast get's higher. I suspect that's the part when the original controller initializes the displays. Meanwhile, with my current code this doesn't happen yet....

  • Hardware is working 100%. If connected to original controller using same flat cable, it works as it should. Also, since the data pins are shared for all actions (Cs, Reset, A0, Backlight, data pins, and buttons, leds, etc..) they must work correctly, otherwise other things wouldn't work.

olikraus:
Start with the following levels:
Reset = 1
CS = 1
A0 = 0
E2/WR = 1
D0..7 = anything

Step 1:
Do a long (>100ms) low pulse on reset line (high - low - high transitions)

Step 2:
Set CS to low (GND). It is important to do this only when reset is high. This means, this step must be done while reset is high.

Step 3:
Apply suitable values to A0 and D0..7

Step 4:
Send a low pulse on E2/WR (high - low - high transitions)

Step 5:
Go back to Step 3 as long as there is data available.

Oliver

So, to make things clearer for the code review (and more complicated to the whole case itself...)

  • PORTL in my code is port with pins D7 to D0 for my PCB
  • PORTA in my code is port with pins A0 to A7 for my PCB ->this is basically addressing.

For PORTA: 0x42 Sets LCD's E2# to LOW. While any other address on PORTA -> E2# is HIGH!!
In this case, with transaction H-L-H as you described, the D0-D7 pins (on PORTL) are accepted on the LCDs D0-D7 pins, if I'm not mistaken...

0x46 Sets DATA PINS (PORTL) to become pins CS(D0), Reset(D1), A0(D2), LCD Backlight (D6/D7).
Whenever 0x46 is applied, the Data pins are applied to the LCD's pins above. When PORTA is something different than 0x46, the last set values REMAIN onto the LCD's pins above -> this is because they are driven via LATCH enable 74HC373 chip, where 0x46 is "Latch enable" trigger....

0xFF -> this is the "blind" port. Meaning, with this port set, nothing happens; I use this as a transition to change data pins blinded, before I apply it to wherever I need.

  • PORTL
    this goes from D0 (lowest bit) to D7 (highest bit). So for setting display's settings as per your last post, this would be:
    -0x43 (CS1, Reset 1, A0 0)
    -0x41 (CS1, Reset 0, A0 0)
    --- 150mS delay for reset
    -0x43 (back to CS1, Reset 1, A0 0)
    -0x42 (CS0, Reset 1, A0 0)

Then I start setting D0-7 ports with your previous post values, with transitions E2# High-Low-High between each, as you said.

This is the code:

  PORTL = 0x43;      // CS 1, Reset 1, A0 0
  delay(1);
  PORTA = 0x46;     // Apply values
  delay(1);
  PORTA = 0xFF;     // Latch values -> PORTL can be safely changed
  delay(1); 
  

  PORTL = 0x41;    // CS1, Reset 0, A0 0
  delay(1);
  PORTA = 0x46;    // Apply values
  delay(1);
  PORTA = 0xFF;    // Latch values -> PORTL can be safely changed
  delay(150);         // wait 150mS before changing Reset back!!!
  
  PORTL = 0x43;    // back to CS1, Reset1, A0 0
  delay(1);
  PORTA = 0x46;   // Apply values
  delay(1);
  PORTA = 0xFF;    // Latch values
  delay(1);
  
  PORTL = 0x42;     // While Reset 1 -> Change CS 0, Reset 1, A0 0
  delay(1);
  PORTA = 0x46;    // Apply values 
  delay(1);
  PORTA = 0xFF;    // Latch values
  delay(1);


  // initialize LCDs per Oliver's code  //

  PORTL = 0x0a2;             // Value 1
  delay(1); 
  PORTA = 0x42;               // Set E2# to LOW
  delayMicroseconds(500);
  PORTA = 0xFF;                // Set E2# back to HIGH
  delay(1);                        // and repeat with different values on D7-D0

  PORTL = 0x02f;
  delay(1);
  PORTA = 0x42;
  delayMicroseconds(500);
  PORTA = 0xFF;
  delay(1);

  PORTL = 0x027;
  delay(1);
  PORTA = 0x42;
  delayMicroseconds(500);
  PORTA = 0xFF;
  delay(1);

  PORTL = 0x081;
  delay(1);
  PORTA = 0x42;
  delayMicroseconds(500);
  PORTA = 0xFF;
  delay(1);

  PORTL = 0x018;
  delay(1);
  PORTA = 0x42;
  delayMicroseconds(500);
  PORTA = 0xFF;
  delay(1);

  PORTL = 0x0a4;
  delay(1);
  PORTA = 0x42;
  delayMicroseconds(500);
  PORTA = 0xFF;
  delay(1);

  PORTL = 0x0af;
  delay(1);
  PORTA = 0x42;
  delayMicroseconds(500);
  PORTA = 0xFF;
  delay(1);

I hope you understand why I left this multiplexing out in original question, as it is preset, but unnecessary complicates the code so it takes some time to understand the code, I guess....

Anyway, I just tried with this code above -> as per your latest suggestion, but still don't see a thing.
I'm gonna try to find and apply "All on" function now as well... will report the findings.

Once again thank you very much!!!

Attached: Full schematic.

Page1 Page2

Please note: It will be deleted within 48 hours from the link.

M.

piqui:
I'm still waiting for the 16ch logic analyzer to be delivered, but even once it does, I assume there's gonna be whole plenty of information there, since it's same bus for all those displays and multiple LED diodes and pushbuttons. (Yes, A0-A6 selects what data are D0-D7 sending/receiving to/from the controller).

True to some extent. However, since you will hooking up the analyzer to the pins of one of the glcds.
You will only be looking at the data lines when the other signals are indicating that something is being sent to the glcd.
i.e. you have to qualify the data lines by looking at the CS and A0 signals.

I wouldn't waste too much time guessing at things given you have a logic analyzer showing up.
Once you can see the signals you should be able to look at them to determine the commands being set which can be used verify which glcd you have based on comparing the commands to the datasheets of the suspected glcd modules.
A bit tedious but it can be done.

bperrybap:
True to some extent. However, since you will hooking up the analyzer to the pins of one of the glcds.
You will only be looking at the data lines when the other signals are indicating that something is being sent to the glcd.
i.e. you have to qualify the data lines by looking at the CS and A0 signals.

True. I was planning to actually use that E2# as trigger to see the LCD data, and E6 as trigger to see the instructions data. I hope I’ll get something useful.

bperrybap:
I wouldn’t waste too much time guessing at things given you have a logic analyzer showing up.
Once you can see the signals you should be able to look at them to determine the commands being set which can be used verify which glcd you have based on comparing the commands to the datasheets of the suspected glcd modules.
A bit tedious but it can be done.

It should be delivered by friday, hopefully. Still though, I wanted to see if there’s any change to get through without having the analyzer… Looks wasting time though… Without Oliver, I wouldn’t have tried even half of the options I did by now… Sadly, no luck so far though…

Let’s hope for the best, if not successfully before, at least at the time analyzer is delivered.

What a complicated schematic. The code looks correct if the dip switch is set to all off and BSEL is connected to GND. However i would suggest to write some sub-procedures in your code. My suggestion is to write three functions:

void setControlSignals(uint8_t reset, uint8_t cs, uint8_ta0);
void setWRPulse(void);
void setDataLevels(uint8_t data);

Only these three functions shell use the PORT assignments. Based on this functions, you can write more complex functions like:

void writeData(uint8_t data) {
  setDataLevels(data);
  setWRPulse();
}

Your code will become MUCH more readble.

Oliver

olikraus:
What a complicated schematic. The code looks correct if the dip switch is set to all off and BSEL is connected to GND. However i would suggest to write some sub-procedures in your code. My suggestion is to write three functions:

void setControlSignals(uint8_t reset, uint8_t cs, uint8_ta0);
void setWRPulse(void);
void setDataLevels(uint8_t data);

Only these three functions shell use the PORT assignments. Based on this functions, you can write more complex functions like:

void writeData(uint8_t data) {

setDataLevels(data);
  setWRPulse();
}




Your code will become MUCH more readble.

Oliver

Couldn't agree more. Though, this saved them multiple connections for all boards. They practically connect up to 11 boards using 2 busses (based on addressing, it could all run on single bus, though I guess that speed is the limit...)
As per functions - thanks for the hint. I actually already have them separated, but due to initial issues when working things out, I made this "pure" function to call all directly, in order for easier debugging.... :wink:

Anyway, now I'd really need some extra help. I got the analyzer sooner than expected. I hooked it up directly to the bus, on all d pins, and a-pins as well. The thing won't power up! I mean, the system does, but LCDs remain dead. Also, random leds are blinking randomly.
The logic analyzer shows something going on on the A pins, while D pins are all constantly on 0xFF!
As soon as the analyer is disconnected from the bus and machine rebooted, it works normally... :confused:

How could the logic analyzer mess up the data signals?? Yes, I did connect the common GND... :confused:
Isn't it directed with diodes or something...? Since they're input only pins, I'd expect them to be... :S
Any suggestion?

piqui:
How could the logic analyzer mess up the data signals?? Yes, I did connect the common GND... :confused:
Isn't it directed with diodes or something...? Since they're input only pins, I'd expect them to be... :S
Any suggestion?

One thing could be that the overall circuit "works" but really doesn't actually work.
There are many devices out there like this. When I say "work" it means that it appears to work ok but has design issues that pushing things beyond their specifications so it reality doesn't truly work since there will be combinations of temperature and voltage where the system fails.
Say for example that the input loading on the data bus signals is way beyond spec but the circuit still "works".
If this is the case, it might "work" but then any additional input loading on the signals from adding the probes tips it over the edge and it no longer works.

The fact that the data lines are always 0xff seems suspicious.
Remember that you can only look at the data lines when the chip is selected and the strobe the glcd is in the right state.
At all other times the signal levels on the data lines have to be ignored.

I'm surprised that the system hangs when adding the probes since from the schematic it appeared that the glcd was being used in write-only mode so it shouldn't get hung up waiting for something like a stuck status bit.

Who makes the analyzer and what sampling frequency are you using?
Does that analyzer also support output signals or all the signals always inputs?

--- bill

bperrybap:
One thing could be that the overall circuit "works" but really doesn't actually work.
There are many devices out there like this. When I say "work" it means that it appears to work ok but has design issues that pushing things beyond their specifications so it reality doesn't truly work since there will be combinations of temperature and voltage where the system fails.
Say for example that the input loading on the data bus signals is way beyond spec but the circuit still "works".
If this is the case, it might "work" but then any additional input loading on the signals from adding the probes tips it over the edge and it no longer works.

Meaning? That I have too much input? I doubt. Data and A lines are all 5V logic state only, measured that. The analyzer is supposed to work in this range.

bperrybap:
The fact that the data lines are always 0xff seems suspicious.
Remember that you can only look at the data lines when the chip is selected and the strobe the glcd is in the right state.
At all other times the signal levels on the data lines have to be ignored.

Exactly my point for the 0xff.
Not entirely true. I mean, I hooked up the analyzer to the input pins, so basically I'm on the main bus, and should record all data, not LCD only. Therefore I was recording A pins as well, so that based on the A pin readouts I can see where the LCD part starts, and where it ends. This was simpler than soldering extra legs to the LCD pins just to hook up analyzer....
Interesting thing is, that based on schematic, the LCD data lines are basically directly connected to the input header, so for D pins it is really the same as if I'd solder the pins on the lcd directly. The A lines however goes to the ICs.

bperrybap:
I'm surprised that the system hangs when adding the probes since from the schematic it appeared that the glcd was being used in write-only mode so it shouldn't get hung up waiting for something like a stuck status bit.

Here I continue from the previous sentence -> it must be something with the controller itself, either it detects something else on the line and doesn't initialize, or I don't know...
It's not that the LCDs are hung, and waiting for stuck status bit, the controller doesn't transmit anything on D pins at all.... Like it's waiting for addressing to detect board (That would be the "Auto detect" diode on the schematic). I just don't get, why it wouldn't recognize the board that IS there, only if analyzer is also present... This makes no sense to me right now... (?)

bperrybap:
Who makes the analyzer and what sampling frequency are you using?
Does that analyzer also support output signals or all the signals always inputs?

--- bill

I got the Dynon instruments, model Elab 080. Here's the manual and specifications: http://www.osciloskopy.com/resources/elab/ELAB080userguideENG.pdf

I tried reading with 100kHz and 1MHz so far....

No. The pins are input only. It has separate header for output signals, triggers, etc...

thanks for looking into this!

M.

piqui:
Meaning? That I have too much input? I doubt. Data and A lines are all 5V logic state only, measured that. The analyzer is supposed to work in this range.

input load has nothing to do with voltage. It has to do with current. Each input puts a load on the signal. If you have too many loads, the overall signal can distort or even fail, either of which can create strange issues.
The data lines are driven by a HC373 which should have plenty of oomph. The part that looks really suspicious is the series resistors being used on all the data lines and E2 and E3 signals. And then the 18k pull down on it going into the WR# lcd signals.
This looks very screwy and looks like they were cheating using a series resistor as a "poor man's level shifter" to feed a 5v signal into a 3v input.
While this can work in some situations, it is very fragile and is a great example of something that "works" but doesn't really work.
Adding a load on this signal might be enough to break things if the probe is attached after the series resistor vs before it since the 10k resistor weakens the signal's drive capability so much.

I tried reading with 100kHz and 1MHz so far....

That is very slow. When I do testing for my glcd and lcd libraries and look at the signals, I use the maximum sample rate of my saleae logic at 24Mhz and sometimes it isn't quite fast enough to see the transition times, particularly when looking at serial clocked data.
It depends on how fast things are done as to what sample speed you need, but at least for my library code, 1Mhz would be way to slow and would not be able to see the transitions. I'm sending full commands to the LCD in less than 1us!