search

rookie / opengauge

Automatically exported from code.google.com/p/opengauge
0 stars 0 forks source link

Screen prob with GDM1602a #9

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. start up

What is the expected output? What do you see instead?
I can't see anything on the screen. Half the time I only get a few arrow
<-- (in 1 box not 3), the other half of the time I don't get anything at
all. The arrows only appear when I soft reset the Arduino with the buttons

What version of the product are you using? On what operating system?
Linux, Ubuntu 9.10 up-to-date
Arduino package 18
Obduino32K downloaded through svn today

Please provide any additional information below.
I'm using a GDM1602a screen, I normally use it with the LiquidCrystal. I
tested it to confirm that I've connected the screen correctly. Since I'm
not that experienced I was wondering if it's possible to adjust the source
to use LiquidCrystal? Or is there a reason I shouldn't do that?

Original issue reported on code.google.com by pat.vdl...@gmail.com on 13 Feb 2010 at 9:43

Attachments:

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
The delay per character in obduino was 5 milliseconds. that is 50 times longer 
than the delay per character in Arduino 17 and 18 !  I do have one LCD that 
needs about 350 usec there, but even that is 12 fold faster than obduino used.

I implemented busy flag testing conditionally. it does lengthen the code, but I 
think it is worthwhile. in most cases it will speed things up but if someone 
happens to have an LCD that is even slower than the two I bought at Axman it 
may work with the busy flag test.

The delay in lcd_commandWrite was shortened to 2 milliseconds.  lcd_cls() does 
take about 2 msec.  All the other commands can complete in the 100 or 350 usec 
timeframe, depending on whether we count the Axman LCDs. the 5 msec delay in 
obduino is clearly overkill.

In the LCD tab, I changed all of the pinMode, digitalWrite and digitalRead 
instances to equivalents from the digitalWriteFast library.  Paul Stoffregen's 
magic saved an amazing amount of flash memory with that maneuver; exactly how 
much will depend on whether the pins involved are PWM pins and whether their 
registers are above or below 0x0100 in memory. The maximal savings comes when 
the address is below 0x0100 and it is a non-PWM pin. In that case, instead of a 
multi-byte subroutine call, a single byte instruction is compiled.

Original comment by johnrain...@gmail.com on 29 Aug 2010 at 8:47

Attachments:

GoogleCodeExporter commented 9 years ago 
since the update to the LiquidCrystal lib the screen works properly now.

Original comment by pat.vdl...@gmail.com on 5 Oct 2010 at 4:46

GoogleCodeExporter commented 9 years ago 
As Per Pat.vdleer's comment, this issue has been resolved when using newest 
version of Arduino.

Original comment by matthews.mike@gmail.com on 4 Nov 2010 at 7:29