Go Down

Topic: GLCD library version 3 (Read 84893 times) previous topic - next topic

bperrybap



I found this statement in here: http://gcc.gnu.org/gcc-4.6/changes.html
Quote
On AVR, variables with the progmem attribute to locate data in flash memory must be qualified as const.


It seems, that PROGMEM requires "const" since gcc 4.6.x.

What an odd choice that they have made. (To break all the old code)
Seems like it should have been a warning when left off as it is obvious what the intent is.

Quote

I think my local gcc was updated from 4.5.x to 4.7.x on my last Ubuntu update to 12.10.

I think you are very brave to run the most recent avr gcc releases.
Doesn't the latest AVR stuff have knowledge about const using progmem and how to fetch the data
from progmem on its own without requiring user code to have to use progmem access routines?


Quote

I also assume, that the Windows Arduino version comes with an old gcc version. Arduino IDE for Windows will work as long as an old gcc version is shipped with it.


The latest Arduino IDE 1.0.1 also supplies its own full AVR toolset for linux.
which is currently 4.3.2

Are you using the IDE and what IDE version are you using?
If no IDE are you using -Werror ?


Quote

My suggestion is to update all GLCD v3 font definitions with the "const" keyword.

Yeah, I agree. My concern is that they will change their mind again.
I'll put it in for the next release - It will require an update to FontCreator2 as well.
I was planning on doing a quick turn release to put in Leonardo support, but I need to
get a few volunteers to test it as I don't have a Leonardo board.
The first round of testing with one person went well and it seems to work
but I want a few more people to test it before I push it out.

I've seen stuff about automatically supporting "const" to put data in progmem
so that the C code no longer has to use progmem access routines to access data stored in flash when using "const".
(I thought that was in gcc starting with 4.6)
I'm not sure what impact that would have on data still being accessed using progmem access
routines.
And also how literal character strings will work as they are normally const by default and
if the compiler now moves const variables to progemem that would seem to break things
when pointers are used, particularly since I bet "const" was not strictly used in many people's
pointer declarations.

I'll have to closely look at all the pointers in code.

--- bill

olikraus

Quote
Are you using the IDE and what IDE version are you using?
If no IDE are you using -Werror ?

I got the same error with Arduino IDE 1.0 and 1.0.1
At least i have not intentionally changed/removed the avr-gcc. But maybe some modifications had forced the IDE to use the avr-gcc from the Ubuntu package.

Quote
I was planning on doing a quick turn release to put in Leonardo support, but I need to
get a few volunteers to test it as I don't have a Leonardo board.


I was about to do release testing for the GLCDv3 variant of M2tklib. I could do this testing with your GLCD update and a Leonardo board.

Oliver

bperrybap


I was about to do release testing for the GLCDv3 variant of M2tklib. I could do this testing with your GLCD update and a Leonardo board.

That sounds great.
I'm going to have to try to replicate the problem.
I have not been able to reproduce this yet.
Are you by chance using the "arduino" package?
I am not. I always download and install the IDE myself as it allows me to install multiple
versions of the IDE for testing.
I have no idea what the arduino package does or where it installs.
In the past it was very problematic so I have continued to avoid it.

I'll have to create a VM for Ubuntu 12.10 (yuck.... for me the new Ubuntu releases are totally unusable)
to see what is going on with Ubuntu.
From what I've seen on Mint 13 (which pulls in from ubuntu 12.04) and Ubuntu 10.10,
IDE version 1.0.1 uses its own included gcc toolset (avr-gcc 4.3.2) even if you have a locally
installed version.
And while IDE 1.0 will use the locally installed gcc, Mint 13 uses avr-gcc 4.5.3

My concern is that the newer compiler will have other issues and modifications
needed to make the code actually work once it compiles.

--- bill

olikraus

I have created a fresh installation of Arduino 1.0.1 IDE. GLCDv3 runs without problems now. So it is really an issue with the latest avr-gcc version.

Let me know if i can do some test with GLCD and Leonardo Board.

Oliver

rainwulf

Hey Guys. Just bought some gLCDS of ebay,
http://cgi.ebay.com.au/ws/eBayISAPI.dll?ViewItem&item=280920620504&ssPageName=ADME:X:RTQ:AU:1123#ht_2101wt_906

And i have both two arduinos, and two LCDs, and i have rewired both multiple times, and no matter what i end up with this:


I tracked down the datasheet for this module, and i found out that the CS pin actually ISNT cs on this module, its programming mode, either serial or parrallel!

http://www.digole.com/images/file/Digole_12864_LCD.pdf
Thats the data sheet..
Any idea on how to make GLCD work with this panel?
it looks FANTASTIC, but as you can see, the garbage on the screen doesnt help.

rainwulf

#260
Nov 16, 2012, 12:01 pm Last Edit: Nov 16, 2012, 02:07 pm by rainwulf Reason: 1
Oh i forgot to mention, gLCD diags:

Code: [Select]
Diag Loop: 1
Initializing GLCD
GLCD initialization Failed: BUSY wait Timeout (status code: 1)
--------------------------------------------------------------------
Reported Arduino Revision: 1.2
--------------------------------------------------------------------
GLCD Lib Configuration: glcd ver: 3 glcd_Device ver: 1 gText ver: 1
GLCD Lib build date: Mon Dec  5 01:50:07 CST 2011
GLCD Lib build number: 442
Panel Configuration:ks0108
Pin Configuration:ks0108-Arduino
--------------------------------------------------------------------
GLCD:ks0108 DisplayWidth:128 DisplayHeight:64
Chips:2 ChipWidth:64 ChipHeight:64
CSEL1:14(PIN_C0) CSEL2:15(PIN_C1)
RES:19(PIN_C5) RW:16(PIN_C2) DI:17(PIN_C3) EN:18(PIN_C4)
D0:8(PIN_B0) D1:9(PIN_B1) D2:10(PIN_B2) D3:11(PIN_B3)
D4:4(PIN_D4) D5:5(PIN_D5) D6:6(PIN_D6) D7:7(PIN_D7)
Delays: tDDR:320 tAS:140 tDSW:200 tWH:450 tWL:450
ChipSelects: CHIP0:(14,0x1, 15,0x0) CHIP1:(14,0x0, 15,0x1)
Data mode:
d0-d3:nibble mode-Non-Atomic
d4-d7:nibble mode-Non-Atomic


So there is absolutely no CS in this particular design, so ... i dunno of GLCD can even work with it.


bperrybap

rainwulf,
Unfortunately, you have a ST7920 display and the glcd library does not support the st7920.
Have a look at this library which does support the st7920:
http://code.google.com/p/u8glib/

--- bill

rainwulf

awww crap!!
I was looking forward to using gLCD as its pretty awesome.

Thanks for your help!!

dc42

What's the problem? You can drive your ST7920-based display using u8glib, and that display needs only 2 Arduino output pins to drive it - unlike the parallel-only interface displays supported by the standard GLCD library.
Formal verification of safety-critical software, software development, and electronic design and prototyping. See http://www.eschertech.com. Please do not ask for unpaid help via PM, use the forum.

rainwulf

Its a lot slower with the 2 pin interface, and it doesnt seem to work with my 8 bit controller.
Even u8glib shows random noise, you can JUST make out the test graphics.

I dont know what the hell is going on...
I got text mode working though, using the code from dfrobot.

dc42

#265
Nov 18, 2012, 03:36 pm Last Edit: Nov 18, 2012, 03:38 pm by dc42 Reason: 1
The 2-pin interface is quite quick if you use the SPI pins and the SPI hardware to drive it. Unfortunately, the ST7920 it doesn't have a CS input, so it can't share the SPI pins with anything else unless you use external clock gating hardware.
Formal verification of safety-critical software, software development, and electronic design and prototyping. See http://www.eschertech.com. Please do not ask for unpaid help via PM, use the forum.

bperrybap


The 2-pin interface is quite quick if you use the SPI pins and the SPI hardware to drive it. Unfortunately, the ST7920 it doesn't have a CS input, so it can't share the SPI pins with anything else unless you use external clock gating hardware.


"quite quick" is relative.
While it is definitely usable,
it is not anywhere close to the speed of being able to control the pins directly.
For example, it takes 3 bytes across the SPI  and 24 sclk transitions to transfer a single byte on the st7920
Even if the the AVR was pushing the SPI at 8mhz that is 3us.
(fastest sclk rate on AVR is F_CPU/2 or 8mhz on 16mhz parts. so 24clock is 3us at 8mhz)
Just for a single byte transfer.
While 3us may sound fast, when doing thousands of updates it makes a difference.


The *BIG* issue when using SPI on glcds, is that there is no read capability.
That puts a big constraint on things. The library either has to create a full shadow buffer
or has to live with certain limitations.
Oliver took a balanced approach in u8glib by using a partial shadow buffer that moves around
to paint the display.
It does come with some limitations in that the user code must paint the display a
particular way. It also requires re-drawing the screen L/s times to update the display
where L is the size of the LCD display memory, and s is the size of the shadow memory.
For example on a 128x64 display the paint routine code will have to be called 8 times as the shadow
buffer is 8 pixels tall. It has to be called and run to full completion for each lcd page.
During each iteration, pixels that land in the shadow buffer are updated and at the end
of the iteration, the shadow buffer is pushed to the display.

This further slows things down.

And even after dealing with that, there is still some functionality that cannot be provided
without having full read access to the display data. Things like scrolling or being able draw
on top of the existing pixels.

It is still very usable but because of these issues and limitations, it ends up being quite a bit
slower than having direct control with read access.

That said, I do agree you do pay for the additional speed and capability it in terms of pins.

I've looked at supporting the st7920 in parallel mode. (It also has a 4 bit mode)
The issue that came up immediately is that the pixels in the st7920 are not
stored in its memory the same way pixels for ks0108, sed1520, and ks0713 are stored.
The existing code in glcd is highly optimized for a different pixel mapping and can't really
be made to easily work with the st7920.

The real answer, is to have a full shadow buffer and then you get the best of all worlds.
This would allow the library to have full access to the display pixels regardless of the interface used.
Because of the local shadow buffer the pixel to glcd memory pixel mapping becomes irrelevant.
It would also allow things like rotating the geometry on the display.
Lots of code in glcd could get smaller and faster if a shadow buffer were always used.
This issue is that the AVRs used in most Arduing boards don't have enough RAM to do that.
The chipkit, Maple, DUE, and even some of the "duinos" by third parties like teensy or the "sanguino" boards
do have enough ram to have a full shadow buffer.

I've been considering a glcd v4 design that may change things up and even
potentially require a frame buffer.

I also think, oliver could easily tweak u8glib to use a full shadow buffer
which would allow it work more like glcd and would give it a speed bump as well.

But as mentioned above, it requires more ram that is available on many AVR platforms.

--- bill


dc42


The real answer, is to have a full shadow buffer and then you get the best of all worlds.
This would allow the library to have full access to the display pixels regardless of the interface used.
Because of the local shadow buffer the pixel to glcd memory pixel mapping becomes irrelevant.


That's exactly what I do in my ST7920 library. Yes, it uses just over half the RAM  of an Arduino Uno; but I've not yet had any other tasks that don't fit comfortably in the remaining RAM, provided that I use PROGMEM for string literals and other constant data.
Formal verification of safety-critical software, software development, and electronic design and prototyping. See http://www.eschertech.com. Please do not ask for unpaid help via PM, use the forum.

bperrybap



The real answer, is to have a full shadow buffer and then you get the best of all worlds.
This would allow the library to have full access to the display pixels regardless of the interface used.
Because of the local shadow buffer the pixel to glcd memory pixel mapping becomes irrelevant.


That's exactly what I do in my ST7920 library. Yes, it uses just over half the RAM  of an Arduino Uno; but I've not yet had any other tasks that don't fit comfortably in the remaining RAM, provided that I use PROGMEM for string literals and other constant data.

agreed. It starts to get harder when the display gets larger than 128x64.

EvilMadScientist

I uploaded the "Big Nums" test sketch to my Arduino Uno connected to my KS0108-controlled LCD module. However, what should be on the left side of the display shifted to the right side, and what should be on the right side shifted to the left. Other than that, everything displays perfectly. I double checked the wiring and found no issues. Could someone please help me?

I bought the LCD from this vendor at Ebay.

http://www.ebay.com/itm/128-64-12864-128x64-Character-LCD-Module-Display-Screen-LCM-IC-KS0108B-104-/170899666269?pt=LH_DefaultDomain_0&hash=item27ca69f55d

Here's a picture of what goes on.



Thank you,
Maxwell

Go Up