Hi! I'm using graphic LCD 128x64 with ks108 controller, ATmega32 and OpenGLCD. I want to use the screen with ATmega32, but I don't know how to wire them. Wiring it like and Arduino UNO doesn't work, probably because of different locations of MISO, RX, TX etc. I would be very thankful if somebody showed me how to wire an atmega32 with ks108 LCD to make it work using OpenGLCD.
I can help you (I'm the openGLCD author) but I need to know a few things.
which IDE platform are you using / have you installed to for the Atmega32 support?
Which specific board in the platform are you using?
Can you provide a link to the datasheet for the exact glcd you have?
You will likely have to run either a manual config or in core code (generic) mode since the library looks for very specific platform and board types for the low level configuration & optimizations and likely will not recognize the Atmega32 board as one of the devices it can optimize for.
--- bill
I'm using:
- Arduino IDE 1.8.19
- MCUDude - MightyCore GitHub - MCUdude/MightyCore: Arduino hardware package for ATmega1284, ATmega644, ATmega324, ATmega324PB, ATmega164, ATmega32, ATmega16 and ATmega8535
- I select ATmega32
- LCD-AG-128064H-DIW W/KK-E6
- http://lcd.hk2k2.at/LCD_Datasheet.pdf
Thanks, for responding.
-- Filip
The openGLCD library is pretty complex. Some of this is due to it being written 14 years ago when Arduino was just getting started.
I really need to update the code and move the code over to github and redo it to support the newer (and much nicer and easer) IDE library manager. Just haven't gotten to it.
It was originally on google code, then bitbucket.
I used bitbucket because issue tracking and file download capabilities are much butter than github. Not as nice as the old Google Code was but still better than github.
What makes the library code complicated is it uses direct port i/o when it can.
This makes the code lightning fast but comes with with a cost of complexity and the inability to configure pin usage in the sketch.
This is why the pins are configured in configuration header files.
The included html documentation talks about this.
The documentation can be found down in the "doc" directory under where the library was installed.
You should be able to use your preferred GUI file manager on your OS to click on openGLCDref.htm to bring it up.
It is quite extensive and includes full documentation on the entire API as well as information on wiring up the GLCD panel, how to wire up the potentiometer, the diagnostic sketch, and some troubleshooting tips.
There are pin configuration files for each board type and then a generic one that is used in generic mode which does not use direct port i/o.
While the generic "core-code" mode works, it will not be as fast as the board specific code.
All the configuration is initially controlled by the header file
openGLCD_Config.h
By default it is configured for a 128x4 ks0108 and for the pins is uses an "auto configuration" capability to configure the pins.
At compile time it will look at the environment and board and pick pin configuration header files and use i/o specific code for that environment.
For your case, since the atmega32 is not a recognized processor with no known board types, the code will fall back to the generic "Core-Code Mode" and use the pin configuration file:
config/ks0108/PinConfig_ks0108-CoreCode.h
If you look at that file you can see how which pins need to be connected to which GLCD pins.
By default, it uses the same pins as an UNO board.
The first thing you should run is the GLCDdiags sketch.
It is used to test the configuration, and help diagnose any configuration or wiring issues.
It can even be run before the h/w is even hooked up.
The first thing it does is print out the Arduino pins used and you can use that information to wire up the display.
A word of caution. Make VERY VERY VERY sure you are using the EXACT datasheet for the display you actually have as ks0108 pinouts are not standardized.
They are so different that if you use the incorrect one, it can fry the GLCD or the Arduino since even things like the power connections are not in the same places.
There are also some defines in the openGLCD_Config.h that can control some library capabilities. You will see them down in the "Optional User Defines" area.
One of note is the GLCDCFG_READ_CACHE which can offer a performance increase, particuarly in core-code mode.But it does cost 1k of RAM.
Let me know if you have any further questions.
--- bill
1 Like
Thanks for your comprehensive reply. Sorry for not responding for so long, I really haven't got time to sit to it...
It is working!
Well, at least partially....
When I display text on it with GLCD.print(""); everything works great, but when it comes to bitmaps, it doesn't. Using Arduino UNO, I checked if the same problem occurs, and it does not. Using UNO, I don't have any issues, even with bitmaps. But on ATmega32A this happens... [VIDEO] (In the video first I started Hello world program, and when the counter reached 24 I started uploading my sketch, it should show 3 bitmaps one after another, but you see what happens) After that, I uploaded GLCDdiags (I didn't show that on video), the same weird stuff happened. Here is the report from serial if it helps
Serial initialized
--------------------------------------------------------------------
Reported Arduino Revision: 1.8.19
F_CPU: 16000000
--------------------------------------------------------------------
Lib Configuration: openGLCD ver: 1.0rc3 build: v1.0rc3
Panel Configuration:ks0108-128x64
Pin Configuration:ks0108-CoreCode
--------------------------------------------------------------------
GLCD:ks0108 DisplayWidth:128 DisplayHeight:64
Chips:2 ChipWidth:64 ChipHeight:64
CSEL1:A0 CSEL2:A1
RW:A2 DI:A3 EN:A4
D0:8 D1:9 D2:10 D3:11
D4:4 D5:5 D6:6 D7:7
Delays: tDDR:320 tAS:140 tDSW:200 tWH:450 tWL:450
ChipSelects:
CHIP0:(A0,0x1, A1,0x0)
CHIP1:(A0,0x0, A1,0x1)
Data mode: Core-Code
Backlight: <Not configured>
--------------------------------------------------------------------
Diag Loop: 1
Initializing openGLCD
Displaying Library version Screen
Turning display on/off
Displaying ChipSelect Screens
Walking 1s data test
Compare error: 1 != 2
Compare error: 5 != 4
Compare error: 9 != 8
Compare error: 11 != 10
Compare error: 21 != 20
Compare error: 3 != 40
Compare error: 81 != 80
TEST FAILED
Test Count: 0 PASSED 1 FAILED
I don't know what's wrong, but that's certainly not connections. I rewired it many times, the same thing happens. Screen must be ok too, because this doesn't happen using Arduino UNO.
-- Filip
When there are issues like this it is pretty much always a wiring/connection issue. For the most part the GLCD is either dead or there is a wiring/connection issue.
It can either be a miswiring, a broken wire/ poor connection, shorted connections or poor solder joints (poor connection).
In some rare cases the GLCD or even AVR pin is damaged from a miswiring.
Unfortunately with this type of display, if there is any sort of wiring/connection issue, there can be odd behaviors.
While you may be seeing some "normal" functionality doing simple text writes, it likely doesn't exercise enough of the functionality or data path to see the issue.
For example, depending on the font, and the positions of the writes, reads from the GLCD may not be happening.
The test that fails writes then reads.
In all of the errors, bit 0 is set incorrectly to HIGH. This behavior is typical if there is an open on the connection.
But just because DB0 seems to be having issues it may not be that simple.
example, in this case it worked when writing 1 but not for any of the other values.
But I would definitely look very closely at the DB0 connection to see if there is an issue with the wire or the solder connection on that pin.
I'd also look closely at DB1 since that one also had an issue.
But then you can get very funky things when wires/connections are shorted.
I've seen issue where a very fine solder string or even a hair "shorted" between pins on the LCD module create very strange behaviors that were inconsistent.
So look very closely at all the solder connections.
I'd also have a very close look at the chip select wires and connections as there can be strange behaviors with issues there since it is possible to select more than one chip at a time (when cs signals are not working properly) and then you have them fighting over the bus on reads.
Photos of your wiring and any other photos of the display or video of the test might also be helpful.
--- bill
Well, I checked my setup for any shortages with a multimeter. There doesn't seem to be any. So we can rule out short circuit problems; we can also rule out problems with atmega, because I replaced it with a completely new one, and even the LCD is working for sure, because using Arduino UNO everything works properly. After doing all that, the LCD shows exactly the same thing.
For me, it looks like the hardware is working ok. It might not be, but I think that that's a difficulty with software. Perhaps there's an issue with the pins that are being used? My suspicion raises the fact that in atmega32A, for example, pins 8 and 9 are unusually RXD and TXD. Maybe I should reassign DB0 and DB1 (Maybe more…) to some other pins?
I attach photos of my circuit below. I checked the soldered board for any shortages, as mentioned before. Exactly the same issue took place when using the atmega on a breadboard, not a soldered one like in the picture.
Photos of my setup (don't mind the buttons on the breadboard, they aren't used).
--Filip
So is everything including GLCDdiags working with an UNO?
If so, we can try forcing the library to use core code mode on the UNO so that the exact same configuration & code is being used on both boards.
It is difficult to tell much with the photos.
In 13 years of supporting this code, pretty much every time I've seen a display this close to working it has been a wiring/connection issue.
In some cases it is an accidental miswiring of not connecting the LCD pin function to the configured Arduino pin.
Another thing I've seen issues with in platforms before is timing issues.
If the delay timing isn't auto configuring properly, the timing will be incorrect and all kinds of strange things can happen.
The code should auto adjust based on the F_CPU value, but perhaps there is an issue if using a clock about 16Mhz?
What clock speed is the ATMEGA32 running at?
I've also seen timing issues when the F_CPU does not match the actual frequency of the clock. Things will break if the actual clock is faster than F_CPU.
Back to connections:
It sure likes there is some sort of data bus issue and it seems most common to cause signal level errors on DB0.
There can be strange issues if things like control signals are cross wired or mixed up.
Are you positive that all the LCD pins are properly wired to the appropriate physical AVR pin for the associated Arduino pin for the board you have selected?
I've seen a few cases where platforms ( 644 platforms like Sanguino, bobduino, etc..) had some issues with digital pin mappings of analog pins.
i.e. they initially screwed up the Arduino analog pin number to digital pin mappings and so when you used an analog pin like A1, A2, etc.. you didn't get the proper pin for digital functions.
It goes back to long history and debate over AVR analog channel # vs Ardino analog pin number and some platforms have made mistakes in the pin mappings of the Arduino Analog pin number to AVR analog channel # and/or physical AVR pin when used as an Arduino digital pin.
i.e. analogRead(A0) and digitalWrite(A0, LOW) were two different physical AVR pins
How is the soldering?
You could try editing the PinConfig_ks0108-CoreCode.h file to configure a pin to reset the GLCD.
Sometimes the GLCD processor can go whacky and doesn't recover during normal initialization.
It can require a power cycle or a hard reset using the RST pin to get it back to a sane state.
--- bill
Finally! I managed to get it working 
. Turns out it was what I was suspecting, the DB0 and DB1 pins should be defined to other atmega pins. I redefined them to pins 12 and 13. That's all it took. Now the screen is working perfectly! Here is diags report after the change:
Serial initialized
--------------------------------------------------------------------
Reported Arduino Revision: 1.8.19
F_CPU: 16000000
--------------------------------------------------------------------
Lib Configuration: openGLCD ver: 1.0rc3 build: v1.0rc3
Panel Configuration:ks0108-128x64
Pin Configuration:ks0108-CoreCode
--------------------------------------------------------------------
GLCD:ks0108 DisplayWidth:128 DisplayHeight:64
Chips:2 ChipWidth:64 ChipHeight:64
CSEL1:A0 CSEL2:A1
RW:A2 DI:A3 EN:A4
D0:12 D1:13 D2:10 D3:11
D4:4 D5:5 D6:6 D7:7
Delays: tDDR:320 tAS:140 tDSW:200 tWH:450 tWL:450
ChipSelects:
CHIP0:(A0,0x1, A1,0x0)
CHIP1:(A0,0x0, A1,0x1)
Data mode: Core-Code
Backlight: <Not configured>
--------------------------------------------------------------------
Diag Loop: 1
Initializing openGLCD
Displaying Library version Screen
Turning display on/off
Displaying ChipSelect Screens
Walking 1s data test
Wr/Rd Chip Select Test
Testing GLCD memory pages
Horizontal Page Test Chip: 0 Pixels 0-63
Vertical Page Test Chip: 0 Pixels 0-63
Horizontal Page Test Chip: 1 Pixels 64-127
Vertical Page Test Chip: 1 Pixels 64-127
Full Module Horizontal Page Test:Pixels 0-127
Full Module Vertical Page Test:Pixels 0-127
TEST PASSED
GLCD.SetDot() speed (K ops/sec): 1.11
Test Count: 1 PASSED 0 FAILED
I'm not an expert, but I think that the DB0 and DB1 just can't be used by pins 8 and 9 with this chip because they are also RXD and TXD (look at the pinout). Well, at least changing this solved the problem for me.
Thank you so much for your help. It's so reliving to finally get it working.
P.S.
I'm planning to use your library for my open source project, and maybe (if everything goes right) I will be selling full kit to make it. It's going to be a versatile RC controller for cars, tanks, planes... Your library is on GNU v3, so I thought that using it commercially won't be a problem, but I just want to be sure and ask if you are ok with it. If yes, I will contact you when I release the project.
Thanks so much for help again,
-- Filip
I missed/forgot about special purpose functions. I should have looked closer.
More than likely a special control/config register has been configured to set up the pins for a serial port function which disables normal pin control.
If your code is all open source then there likely will be no issues, but it depends on what license you were wanting to use for your code and if there are any conflicting licenses among the various open source components being used.
It is always possible to use any lgpl/gpl licensed code in a commercial product, as long as it conforms to the license agreements for all the individual components used to build the s/w image in the product.
The authors of gpl v3 code (or any gpl/lgpl code) have no say on if the code can be used in a commercial product. The GNU licensing terms does not allow such restrictions.
However, when using gpl v3.0 source you must make ALL the source code of the entire project/product that is linked into the same executable image where any gpl v3.0 code is used available to anyone who asks for it.
For many commercial products that isn't acceptable to the maker since they want to keep certain parts of the product/project closed source.
gpl v3 does not allow that.
i.e. the cost for using gpl v3 is that ALL the source code used to create the executable image in the product is licensed with a license that is compatible with gpl v3.
This means that ALL the source code must be made open source and cannot be re-licensed with a different less restrictive license. like say MIT or BSD.
The entire product effectively becomes licensed as gpl v3 even if other sources may be lgpl or some other license that may have lesser licensing requirements than gpl v3.
For example if all the other code was licensed as total freeware, you would still have to make available the source to those other modules including any changes that you make to those freeware modules since gpl v3 requires that you disclose all the s/w used for building the image.
You also cannot put tighter licensing restrictions on your code (or any code used to build the image) than what gpl v3 allows as that would make it incompatible with gpl v3.
i.e. have monetary licensing fees, or restrictions on its use.
Even if you don't use any gpl v3 code but drop back to use only more permissive lgpl licensed code, in order to fully comply with the lgpl license there is still a requirement that the user must be able to modify and update any of the lgpl code used in the device.
This potentially means that the user must have a way to update any f/w in the device that uses the lgpl code.
For many that requirement is difficult to meet.
Anytime you use a gnu based compiler toolset like gcc/g++ there will be some amount of LGPL code linked in.
When building & selling a real product you have make sure that all the licenses used to build the image are compatible.
There are some software licenses that are not compatible with gpl v3.
And some like the CC BYSA licenses that are not compatible with anything but themselves.
CC BY SA is a useless & dumb license for s/w and should never be used.
Some CC BY SA licenses can legally can be linked with other open source for commercial purposes. However this only because with CC BY SA 4.0 that added a 1 time convert clause that allows the code be converted and re licensed as gpl v3
But after that conversion it can never be converted back.
So while the original author may like the restrictions of CC BY SA 4.0 it is useless because anybody can convert it to gpl v3 and then any changes or updates made to that gpl v3 version of the code can never go back to the more restrictive CC BY SA 4.0 version.
--- bill
I am curious on this project.
Do you need high speed graphic updates?
The reason I ask is I've been tossing around the idea of adding support to openGLCD to use an i/o expander to control the GLCD.
Something like a MCP23016
It would reduce the pin count down to two.
It wouldn't be as fast but it still should be quite usable.
And should be similar speed if the read cache was turned on so that reads came from the local cache vs having to go across i2c to read the glcd.
--- bill
I will make sure that all licenses are compatible. I am planning to use gnu v3 for my project too. I'm planning to use mainly openGLCD, RF24 and MPU6050 libraries, which are all GNU licensed. Thanks for all the information, I thought all that stuff with licenses will be a little less complicated to be honest.
The project is going to be like Arduino, you get a kit, and you can do what ever you want, especially change the code. I don't want to say too much, because it's still not very developed, and many things can change.
LCD will be used to display things like acceleration, rotation, battery status, temperature etc. High speed graphics would be useful for displaying things like rotation for example, which can
change rapidly, but I think that actual speed is going to be sufficient.
Reducing the pin count would be the best thing. Right now, using for example an UNO, the screen takes most of the pins. With the LCD using only 2 pins, I could even change the atmega32 to a bit cheaper and smaller atmega328. So, yes, I am 100% behind the idea of adding support to openGLCD to use an i/o expander. That would be awesome.
If you want to know more about the project, contact me by e-mail or private message, since this may not be the best place for such discussions.
Thanks once again,
-- Filip
Thanks for the information.
I think I need to finally get back to the library.
I need to move the code and documentation over to github and then clean up a bunch of stuff (like removing all the GLCDv3 compatibility stuff) and update the the code and examples for the more recent IDE tool set.
This code was started 15 years ago and hasn't been updated much in the past 10 years and not updated at all in about 5 years.
Once on github it can be added to the IDE library manager.
Then I'll look at adding i2c i/o exapander support.
Having i/o expander support will make things a lot simpler to wire up and will make it possible to use other fast low cost but pin limited platforms like the ESP8266 or ESP32.
It would likely be just as fast if not run faster with i2c on those platforms than an AVR based platform with direct pin control.
For performance you should see a difference between the UNO and your platform. UNO should be faster since the UNO will be using the much faster direct port i/o vs digitalWrite() and digitalRead()
You can get a relative speed comparison by running the openGLCD/ks0108example adn look at the relative frame rates of the demo.
I2c would likely run at least as fast if not faster than what you currently have on the ATmega32A since it is using digitalWrite() and digitalRead() for all the i/o.
--- bill
1 Like
Yup, ten years without updates is pretty long. I hope you succeed in getting back to it. Let know if there are any updates coming! I really could use the i2c I/O expanders support.
I will keep you updated on my project if I manage to finish it.
-- Filip
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.