Pages: 1 ... 7 8 [9] 10 11 ... 21   Go Down
Author Topic: GLCD library version 3  (Read 81298 times)
0 Members and 1 Guest are viewing this topic.
Offline Offline
Newbie
*
Karma: 0
Posts: 24
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Hi Bill,

I'm using a Mega 2560 board.  I'm still in early development but am looking at all power considerations.  Once the firmware is ready I'll be able to more accurately measure power draw.  Thanks for the 9v / AA battery tip, can I simply connect a battery powered USB 'dongle' (Energizer for example) to the board for power?

When ground is removed from the lcd and is restored a minute or so later, all the pixels return as previously initialized.  It seems perfect, so far.

I'll pm you those fonts.

Regards,

J

Have you actually measured the current draw for the logic itself?  It's supposed to be incredibly low i.e. may not be worth worrying about.
Logged

Offline Offline
Full Member
***
Karma: 2
Posts: 144
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Have you actually measured the current draw for the logic itself?  It's supposed to be incredibly low i.e. may not be worth worrying about.

No I haven't done any measuring yet but surely the lcd being on shortens run time on a battery.  Today a dual relay was implemented to turn off the lcd 5v & ground after a pre-set amount of time and it works nicely.  The lcd is also re-initialized when it powers back up.

I'm wondering though, can this be done without relays?

J
Logged

a][+ ascii express, 110/300 novation cat, xmodem

Offline Offline
Newbie
*
Karma: 0
Posts: 24
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Have you actually measured the current draw for the logic itself?  It's supposed to be incredibly low i.e. may not be worth worrying about.

No I haven't done any measuring yet but surely the lcd being on shortens run time on a battery.  Today a dual relay was implemented to turn off the lcd 5v & ground after a pre-set amount of time and it works nicely.  The lcd is also re-initialized when it powers back up.

I'm wondering though, can this be done without relays?

J

I'm not as familiar with your controller, but in standby my measurements on my KS0713 LCD controller were in the range of 50uA - basically not enough to worry about as the leakage current of any switching device while in the ON state overshadowed the savings in power OFF state.

You certainly should be able to use a simple NPN transistor (2N2222 or 2N3904) on the ground line in place of the relay.  But keep in mind that any device is going to require power to operate which may negate any savings over just leaving the device in standby mode.  Also the increased cost may not be worth it if it's a production unit.  Adding a larger battery pack is also a valid option, or a small solar panel.
Logged

Dallas, TX USA
Online Online
Faraday Member
**
Karma: 70
Posts: 2763
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I'm not as familiar with your controller, but in standby my measurements on my KS0713 LCD controller were in the range of 50uA - basically not enough to worry about as the leakage current of any switching device while in the ON state overshadowed the savings in power OFF state.

The ks0108 datasheets don't seem to mention any sort of lower power mode. They do have a display "off"/"on" function,
but the datasheets don't mention anything about different power utilization with the display "off" vs "on".
I'm sure power use is lower when the display is off, but I've never bothered to measure it.

Out of curiosity, when you enter standby mode on the ks0713, do you do anything special with the data and control
lines from the AVR to get that reduced power? like make them inputs with the pullups disabled?

Quote
You certainly should be able to use a simple NPN transistor (2N2222 or 2N3904) on the ground line in place of the relay.  But keep in mind that any device is going to require power to operate which may negate any savings over just leaving the device in standby mode.  Also the increased cost may not be worth it if it's a production unit.  Adding a larger battery pack is also a valid option, or a small solar panel.


Currently there is no glcd library API function to put the display into lower power mode or to
turn the display on/off.
So my concern is that power is being yanked from the glcd chips while the data and control lines are still actively driven
by the AVR.



--- bill

Logged

Offline Offline
Full Member
***
Karma: 2
Posts: 144
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I'm not aware of standby mode in the ks0108 but guesstimate that it could be turned off by disabling one or more lines by making them inputs as Bill suggested.  If it's not possible, I don't mind using the relays as it's relatively clean (or will be) and I get to think I fried my board every time the screen pops back on smiley  I don't think the relay control line eats up too much power, and the relays are only active when the screen is on.

More news to follow, thanks for your help & ideas.

J
Logged

a][+ ascii express, 110/300 novation cat, xmodem

Offline Offline
Newbie
*
Karma: 0
Posts: 3
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Is there any chance to see this lib ported for chipKit ?

Logged

Dallas, TX USA
Online Online
Faraday Member
**
Karma: 70
Posts: 2763
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

It can definitely be done.
I have not looked at the chipkit tools and libraries yet to see how difficult
integrating the low level i/o would be.
The easiest way would be to create a "portable" mode
where the code limits itself to using only "arduino" core code functions.
(Right now it uses some very complex macros to do direct AVR port i/o since
the Arduino core code functions like digitalWrite() are so slow)
A portable mode would offer extreme portability so it could work with
things like chipKit and Maple at the expense of performance.
But since the pic32 and ARM processors are so much faster than the AVR it
would probably still be as fast if not faster than the
current  AVR arduino code anyway.

The current low level i/o code is very modular and new i/o mechanisms can be slid in
fairly easily.
No doubt there will other issues that crop up when porting over the code
(like how to handle nanosecond type delays) but those can be dealt with
as they crop up.

It is more a matter of finding the time and energy to do it.

--- bill


Logged

United Kingdom
Offline Offline
Tesla Member
***
Karma: 227
Posts: 6639
Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Do you have any plans to support GLCDs that use the ST7920 controller, driven in serial mode? The nice thing about this arrangement is that it uses only 2 Arduino pins. I've written a basic library to display text on it with auto-kerning, and to do simple graphics functions; but I could do with higher level graphics functions, and it I don't want to re-invent the wheel.
Logged

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.

Maaseik, Belgium
Offline Offline
Newbie
*
Karma: 0
Posts: 32
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Maybe this will help you:
http://www.mindkits.co.nz/store/led-lcds/128x64-graphic-lcd
Logged

United Kingdom
Offline Offline
Tesla Member
***
Karma: 227
Posts: 6639
Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Thanks for the link; however my ST7920 glcd driver already does a lot more than the one linked to on that page does.
Logged

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.

Dallas, TX USA
Online Online
Faraday Member
**
Karma: 70
Posts: 2763
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

dc42,
I have looked at using serial mode in the past. It would be great to reduce the number of pins,
but as I recall, many of the displays, (and I believe this one as well), lose the ability
to read from the display when using their built in serial mode.
Currently the library code goes through many painful gyrations to avoid the use of a frame buffer.
It was a conscious decision to eat up additional flash space to avoid using much RAM
so that the library could function on all arduino boards including those like the m168 that
only have 1k of ram, which would never be able to support a frame buffer for a 128x64 display.
The current code can support any sized display up to 256x256 without using up any additional
RAM.
I guess I could toss in a serial mode using the existing "read cache" capability
(which isn't nearly as good as a true frame buffer) but would allow it to run on AVRs with
enough memory.

In the absence of switching over to using a real framebuffer,
I think my preference would be to design and sell a low cost i2c board(s) that would be able
to work on several different glcd displays. That way all the current AVRs from the m168 to the megas
and even the newer chipKits and Maples could use glcds using only 2 pins and potentially drive more than a single display.

Long term what needs to happen is somewhat related to the previous chipkit comment above.
My real preference would be to re-design the code to use a full frame buffer
and then many things get really easy including supporting alternate interfaces.
But once a frame buffer is used, it precludes support on certain boards with
certain sized displays since they would not have enough memory for the frame buffer.

I guess that is a long answer of saying, I've thought about it, but haven't really
solidified any plans yet.

--- bil
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 3
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I've modify the lib to work with chipKit32, as you suggested, the lib run using only pinMode/digitalWrite/digitalRead.
With that method I've run with success the GLCDdemo and get a 7.09fps on a ChipKit Max32 board.
I'm sure that this speed can/will be improved a lot, but it works !
Logged

Dallas, TX USA
Online Online
Faraday Member
**
Karma: 70
Posts: 2763
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

mikaelm,
Very nice!

So did do it by modifying the macros in include/glcd_io.h ?
That is the only file that will need modification.
All the i/o operations are controlled by the macros in that file.
lcdPinMode(), lcdDatadir(), lcdDataOut(), and lcdDataIn() being the main ones.


I'm curious what you used for lcdDelayNanoseconds()

I did it once about a year and a half ago as an experiment to see
how much better the direct port i/o was.
I remember it wasn't that difficult, and the performance dropped by like 70% on a 16Mhz AVR.
I didn't keep the header around with the ifdef to using only Arduino core functions
as I never thought anybody else would implement the same Arduino API on
other hardware given its horrendous overhead.
(Guess I missed that prediction)

I guess I should look at putting an Arduino "portable" mode back in
to the mainline code with an ifdef - it should not be that difficult as long as there
is a way to do nanosecond delays.

If there is a magic define set for the chipKit builds, then the code automatically fall back
to "portable" mode and use the proper ns delay function for the chipKit.


Can you provide more details or would you be interested in working with me off
line to get this into the mainline code for the library so that it "just works" for
chipkit?

--- bill

mikaelm,
One thing you can try that can improve the performance is to turn on the read cache.
uncomment the line for the GLCD_READ_CACHE define in glcd_Config.h


« Last Edit: November 21, 2011, 08:12:11 pm by bperrybap » Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 3
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I've modified glcd_io.h and add a generic_io.h one.

for lcdDelayNanoseconds, i've used an ultra simple :
Code:
#define lcdDelayNanoseconds(__ns) asm("nop") // not sure but it works

Here are the predefined macros for chipKit boards:
Code:
/* For PIC32 */
#define __PIC32MX__ 1
/* For Uno32 */
#define __32MX320F128H__ 1
/* For Max32 */
#define __32MX795F512L__ 1

The GLCD_READ_CACHE define improved things a lot!
now It's running at 19.5fps !!!!

I have email you the infos and source code.
« Last Edit: November 22, 2011, 06:16:45 pm by mikaelm » Logged

United Kingdom
Offline Offline
Tesla Member
***
Karma: 227
Posts: 6639
Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

I have looked at using serial mode in the past. It would be great to reduce the number of pins,
but as I recall, many of the displays, (and I believe this one as well), lose the ability
to read from the display when using their built in serial mode.
Currently the library code goes through many painful gyrations to avoid the use of a frame buffer.
It was a conscious decision to eat up additional flash space to avoid using much RAM
so that the library could function on all arduino boards including those like the m168 that
only have 1k of ram, which would never be able to support a frame buffer for a 128x64 display.
The current code can support any sized display up to 256x256 without using up any additional
RAM.

You are quite right, the ST7920 in serial mode doesn't let you read the data back. I was using a 128x64 glcd on an atmega328, and after experimenting with a partial buffer, I decided that in this application I could afford to use half the total RAM space for a frame buffer. I appreciate that this wouldn't always be an option.
Logged

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.

Pages: 1 ... 7 8 [9] 10 11 ... 21   Go Up
Jump to: